社内のHadoop本読書会のスライドです

1. Apache Hadoop YARN勉強会
8. Capacity Scheduler in YARN
Shuya Tsukamoto
2016/09/08

2. Apache Hadoop YARN勉強会
今回は８章
Capacity Scheduler in YARN
複数の組織・ユーザでクラスタを共有する話

3. Hadoop ver.1
Capacity Scheduling自体はVersion1時代からある概念
CapacityTaskScheduler
Ver1のリソース単位はスロット, Ver2はコンテナ
Ver2のCapacitySchedulerの概念の多くはVer1のCapacityTaskSchedulerを継承している

4. Capacity Scheduler Configuration

5. Capacity Scheduler Configuration
YARNではCapacitySchedulerがデフォルト
明示的に変更する必要がある場合は、ResourceManager上のyarn-site.xmlの以下を変更
yarn.resourcemanager.scheduler.class
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

6. Capacity Scheduler Configuration
CapacitySchedulerはcapacity-scheduler.xmlに依存
capacity-scheduler.xmlを変更した後で、以下のコマンドで実行中に適用可能
yarn rmadmin -refreshQueues
クラスタの管理者(yarn.admin.aclで設定されたユーザ)のみ実行可能

7. Queues

8. Queues
YARNのスケジューリングの基本単位がqueue
queueは様々なユーザによって投稿されたアプリケーションの論理的集合か、複数の
キューの組み合わせのどちらか
CapacityScheduler内のqueueは以下のプロパティを持つ

9. Queues
● A short queue name
● A full queue path name
● A list of child queues and applications associated with them
● Guaranteed capacity of the queue
● Maximum capacity to which a queue can grow
● A list of active users and the corresponding limits of sharing between users
● State of the queue
● ACLs governing the access to the queue
いろいろあるけど全部後の節で詳しく語られる

10. Hierarchical Queues

11. Hierarchical Queues

12. 2種類のQueue
● parent queues
● leaf queues

13. parent queues
● 組織やサブ組織のリソース管理を可能にする
● 親queueや葉queueを含むことができる
● 直接アプリケーションの投稿を受けることはできない
● 最上位の親queue(ROOTのところ?)はROOT queueと呼ばれる
● クラスタ自体を意味する

14. leaf queues
● 親queueの下にいる
● アプリケーションの投稿を受け付ける
● 子はいない

15. parent/leaf queuesで何ができる？
管理者は様々な組織・サブ組織にキャパシティ割当できる（詳細後述）
30%60%10%

16. Scheduling Among Queues
ROOT queueはfirst level親queue間で配るキャパシティの量と、
子queueスケジューリングの実行を理解している
各親queueも同じキャパシティ制約に従う
葉queueは同時に1ユーザがそのqueue内で取得できるリソースの制限を配慮しつつ、アク
ティブなアプリケーションのリストを持つ...?(自信なし)
(potentially from multiple users, and schedule resources)

17. Defining Hierarchical Queues
Hadoop ver1時代はフラットなqueueだったが、階層的に
ユニークなqueue pathsが必要
ROOT queueからドット区切りで記述（例、後述）

18. Queue Access Control

19. Queue Access Control
(Linux)ユーザ・グループごとにqueueへのアクセスを制御可能
yarn.scheduler.capacity.root.finance-wizards.acl_submit_applications
で設定可能
フォーマットは
カンマ区切りのユーザ名と半角スペースとカンマ区切りのグループ名
または
アスタリスク

20. Queue Access Control
e.g. “sherlock,pacioli cfo-group”
sherlock,pacioliユーザとcfo-groupグループがアクセス可能
e.g. “ cfo-group”
cfo-groupグループがアクセス可能
e.g. “*”
全員アクセス可能

21. Capacity Management with Queues

22. Capacity Management with Queues
複数の親queues, 葉queues(つまり複数の組織)がある中で、どうやってキャパシティを割り
当てるかの話
一言で言うとqueueごとに比率を設定して分配

23. Capacity Management with Queues

24. Capacity Management with Queues
yarn.scheduler.capacity.root.grumpy-engineers.capacity = 60
同様にfinance-wizards = 10, marketing-moguls = 30
(合計は100%以下でなければならない)

25. Capacity Management with Queues
葉queues にも設定可能
yarn.scheduler.capacity.root.grumpy-engineers.infinite-monkeys.capacity = 20
同様にpesky-testers = 80

26. Capacity Management with Queues
クラスタ全体で1000GBのキャパシティがあると想定
grumpy-engineersは60%なので600GB
infinite-monkeys 20%, pesky-testers 80%なので、それぞれ
120GB, 480GB割り当てられる

27. User Limits

28. User Limits
葉queueには様々なユーザによって投稿されたアプリケーションのスケジューリングを公平
にする責任もある
ユーザに対してキャパシティの制限をかけることができる
e.g.
yarn.scheduler.capacity.root.finance-wizards.thrifty-treasurers.minimum-user-limit-perce
nt
20

29. User Limits
thrifty-treasurersで各ユーザが利用できるキャパシティの下限が20%
2ユーザがアプリを投稿した場合は50%ずつ、3ユーザなら33%ずつ
5ユーザなら20%ずつ
6ユーザなら6人目は待たされる

30. User Limits
yarn.scheduler.capacity.root.finance-wizards.user-limit-factor
queueに設定されたキャパシティを越えてリソース確保できる度合い?(自身なし)
値が2なら、通常の2倍確保可能

31. Reservations

32. Reservations
大量にリソースを利用する大きいアプリがqueueに積まれたが、空きが無い場合
他の小さいアプリを実行するといつまでも空きができず、
大きいアプリが実行できない
予約という仕組みで解決
(翻訳間に合わず)

33. State of the Queues

34. State of the Queues
queueにはRUNNINGとSTOPPEDの２つの状態がある
デフォルトはRUNNING
STOPPEDだとアプリケーション投稿を受け付けない
親queueも葉queueも停止可能
親queueを停止すると子孫のqueueuも無効に

35. State of the Queues
設定例
yarn.scheduler.capacity.root.finance-wizards.state
RUNNING
ユーザが他のキューを利用するように移行するときなどに使える
現在実行中のアプリの完了を待ちつつ、新規実行を停止できる

36. Limits on Applications

37. Limits on Applications
投稿されたアプリケーションの最大数の制限(running + pending)
デフォルトは10000
アクシデントや悪意のあるユーザによる手に負えない負荷に起因するスラッシン
グ?(system thrash)を防ぐためのもの
yarn.scheduler.capacity.maximum-applications で調整可能
yarn.scheduler.capacity.<queue-path>.maximum-applications で上書き可能

38. Limits on Applications (ApplicationMaster)
ApplicationMaster(AM)が大量に立ち上がってコンテナリリース待ち(cross-application
deadlock)になるとマズい
AMがクラスタ内で利用できるリソースの制限。デフォルト10%
yarn.scheduler.capacity.maximum-am-resource-percent
これも
yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
で上書き可能

39. User Interface

40. User Interface
Capacity schedulerとともにResourceManager(RM)が開始されるとschedulerのページも見
れるようになる。
いつもの。