Apache Hadoop YARN勉強会8. Capacity Scheduler in YARN

Shuya Tsukamoto2016/09/08

Apache Hadoop YARN勉強会

今回は８章

Capacity Scheduler in YARN

複数の組織・ユーザでクラスタを共有する話

Hadoop ver.1

Capacity Scheduling自体はVersion1時代からある概念

CapacityTaskScheduler

Ver1のリソース単位はスロット, Ver2はコンテナ

Ver2のCapacitySchedulerの概念の多くはVer1のCapacityTaskSchedulerを継承している

Capacity Scheduler Configuration

Capacity Scheduler Configuration

YARNではCapacitySchedulerがデフォルト

明示的に変更する必要がある場合は、ResourceManager上のyarn-site.xmlの以下を変更

yarn.resourcemanager.scheduler.class

org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

Capacity Scheduler Configuration

CapacitySchedulerはcapacity-scheduler.xmlに依存

capacity-scheduler.xmlを変更した後で、以下のコマンドで実行中に適用可能

yarn rmadmin -refreshQueues

クラスタの管理者(yarn.admin.aclで設定されたユーザ)のみ実行可能

Queues

Queues

YARNのスケジューリングの基本単位がqueue

queueは様々なユーザによって投稿されたアプリケーションの論理的集合か、複数の

キューの組み合わせのどちらか

CapacityScheduler内のqueueは以下のプロパティを持つ

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

いろいろあるけど全部後の節で詳しく語られる

Hierarchical Queues

Hierarchical Queues

2種類のQueue

● parent queues

● leaf queues

parent queues

● 組織やサブ組織のリソース管理を可能にする

● 親queueや葉queueを含むことができる

● 直接アプリケーションの投稿を受けることはできない

● 最上位の親queue(ROOTのところ?)はROOT queueと呼ばれる

● クラスタ自体を意味する

leaf queues

● 親queueの下にいる

● アプリケーションの投稿を受け付ける

● 子はいない

parent/leaf queuesで何ができる？

管理者は様々な組織・サブ組織にキャパシティ割当できる（詳細後述）

30%60%10%

Scheduling Among Queues

ROOT queueはfirst level親queue間で配るキャパシティの量と、

子queueスケジューリングの実行を理解している

各親queueも同じキャパシティ制約に従う

葉queueは同時に1ユーザがそのqueue内で取得できるリソースの制限を配慮しつつ、アク

ティブなアプリケーションのリストを持つ...?(自信なし)(potentially from multiple users, and schedule resources)

Defining Hierarchical Queues

Hadoop ver1時代はフラットなqueueだったが、階層的に

ユニークなqueue pathsが必要

ROOT queueからドット区切りで記述（例、後述）

Queue Access Control

Queue Access Control

(Linux)ユーザ・グループごとにqueueへのアクセスを制御可能

yarn.scheduler.capacity.root.finance-wizards.acl_submit_applications

で設定可能

フォーマットは

カンマ区切りのユーザ名と半角スペースとカンマ区切りのグループ名

または

アスタリスク

Queue Access Control

e.g. “sherlock,pacioli cfo-group”sherlock,pacioliユーザとcfo-groupグループがアクセス可能

e.g. “ cfo-group”cfo-groupグループがアクセス可能

e.g. “*”全員アクセス可能

Capacity Management with Queues

Capacity Management with Queues

複数の親queues, 葉queues(つまり複数の組織)がある中で、どうやってキャパシティを割り

当てるかの話

一言で言うとqueueごとに比率を設定して分配

Capacity Management with Queues

Capacity Management with Queues

yarn.scheduler.capacity.root.grumpy-engineers.capacity = 60

同様にfinance-wizards = 10, marketing-moguls = 30

(合計は100%以下でなければならない)

Capacity Management with Queues

葉queues にも設定可能

yarn.scheduler.capacity.root.grumpy-engineers.infinite-monkeys.capacity = 20

同様にpesky-testers = 80

Capacity Management with Queues

クラスタ全体で1000GBのキャパシティがあると想定

grumpy-engineersは60%なので600GB

infinite-monkeys 20%, pesky-testers 80%なので、それぞれ

120GB, 480GB割り当てられる

User Limits

User Limits

葉queueには様々なユーザによって投稿されたアプリケーションのスケジューリングを公平

にする責任もある

ユーザに対してキャパシティの制限をかけることができる

e.g.

yarn.scheduler.capacity.root.finance-wizards.thrifty-treasurers.minimum-user-limit-percent

20

User Limits

thrifty-treasurersで各ユーザが利用できるキャパシティの下限が20%

2ユーザがアプリを投稿した場合は50%ずつ、3ユーザなら33%ずつ

5ユーザなら20%ずつ

6ユーザなら6人目は待たされる

User Limits

yarn.scheduler.capacity.root.finance-wizards.user-limit-factor

queueに設定されたキャパシティを越えてリソース確保できる度合い?(自身なし)

値が2なら、通常の2倍確保可能

Reservations

Reservations

大量にリソースを利用する大きいアプリがqueueに積まれたが、空きが無い場合

他の小さいアプリを実行するといつまでも空きができず、

大きいアプリが実行できない

予約という仕組みで解決

(翻訳間に合わず)

State of the Queues

State of the Queues

queueにはRUNNINGとSTOPPEDの２つの状態がある

デフォルトはRUNNING

STOPPEDだとアプリケーション投稿を受け付けない

親queueも葉queueも停止可能

親queueを停止すると子孫のqueueuも無効に

State of the Queues

設定例

yarn.scheduler.capacity.root.finance-wizards.state

RUNNING

ユーザが他のキューを利用するように移行するときなどに使える

現在実行中のアプリの完了を待ちつつ、新規実行を停止できる

Limits on Applications

Limits on Applications

投稿されたアプリケーションの最大数の制限(running + pending)

デフォルトは10000

アクシデントや悪意のあるユーザによる手に負えない負荷に起因するスラッシン

グ?(system thrash)を防ぐためのもの

yarn.scheduler.capacity.maximum-applications で調整可能

yarn.scheduler.capacity.<queue-path>.maximum-applications で上書き可能

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

で上書き可能

User Interface

User Interface

Capacity schedulerとともにResourceManager(RM)が開始されるとschedulerのページも見

れるようになる。

いつもの。