yarn application-master

APACHE HADOOP YARN

- Application Master 編 -

2

Resource Manager の説明との重複が多く， 重要そうな箇所は少なかった…

前置き

3今回の内容

Application Master (AM) のライフサイクルResourceRequest

4AM のライフサイクル

1. RM が AM を起動，登録2. AM が RM にコンテナリソースを要求3. AM が割り当てられたコンテナを起動4. 割り当てられたコンテナでタスクを実行5. Application が完了時に RM から AM の登録

を削除

5AM のライフサイクル

1. RM が AM を起動，登録2. AM が RM にコンテナリソースを要求3. AM が割り当てられたコンテナを起動4. 割り当てられたコンテナでタスクを実行5. Application が完了時に RM から AM の登録

を削除

NM, AM 自体の死活監視は RMコンテナの死活監視は AM

6AM のやっていること

RM

RM への heartbeatRM による AM の死活監視のた

め

ResourceRequestアプリケーションの内容を加味し

RM にコンテナを要求

NM

コンテナの起動Scheduler に割り当てられ

たコンテナの起動を要求 AM

コンテナの実行状況の管理タスクの進捗状況の監視や

コンテナの ( 再 ) 起動を要求

ココ

7AM の死活監視

RM が AM の死活監視をします．AM が RM に heartbeat を送っています．

( 後述の ResourceRequest もここに乗っかってます )

AM の RM への登録AM は RM に自身の URL 等を送っている．RM は submit 時に渡されたいろんな情報を送っている．

• Yarn で使えるリソースの上限等

以上 !!

8AM のやっていること

RM

RM への heartbeatRM による AM の死活監視のた

め

ResourceRequestアプリケーションの内容を加味し

RM にコンテナを要求

NM

コンテナの起動Scheduler に割り当てられ

たコンテナの起動を要求 AM

コンテナの実行状況の管理タスクの進捗状況の監視や

コンテナの ( 再 ) 起動を要求

ココ

9ResourceRequestAM から見ると…

RM に対して，自分の使いたいコンテナ ( 配置も含め )を使ってよいかどうか確認する処理

どの程度リソースを確保しなくてはならないかの 計算は AM 側で管理

10Request の決定方法 2 つ

Request の種類Static allocation

• すべてのコンテナリソース ( 配置も含め ) の要求をApplication が Submit された時点で決定するもの• ユーザの指定するパラメータ， Application の実装に依存

Dynamic allocation• 実行中に動的にリソースの配置を決定する．

• ユーザ指定のパラメータ， Application の実装，クラスタ内のリソースの空き状況を加味して決定

11ResourceRequest の例

Priority

Location Capability Num of Container relaxLocality

1 host-A-a 1Core-1GB 1 false1 host-A-b 1Core-1GB 1 true1 rack-A 1Core-1GB 2 false2 * 1Core-1GB 2 true

RMAM

Allocated [ContainerA-a-1]Status of

using{ContainerA-b-2: RUNNING}

Available [ContainerA-a-2, ContainerB-b-2]

12ResourceRequest の例

RMAM

割り当てに応じて随時更新

Priority

Location Capability Num of Container relaxLocality

1 hostA-b 1Core-1GB 1 true1 rackA 1Core-1GB 1 false2 * 1Core-1GB 1 true

(Location を必ず守らないといけないか )

13Request の fall through優先順位は概ね次の通り

1. ホスト単位2. ラック単位3. どれでも (= Application が要求しているリソースの総

数 )Priorit

yLocation Capability Num of Container relaxLocality

1 host-A-a 1Core-1GB 1 false1 host-A-b 1Core-1GB 1 true1 rack-A 1Core-1GB 2 false2 * 1Core-1GB 2 true

1123

14AM のやっていること

RM

RM への heartbeatRM による AM の死活監視のた

め

ResourceRequestアプリケーションの内容を加味し

RM にコンテナを要求

NM

コンテナの起動Scheduler に割り当てられ

たコンテナの起動を要求 AM

コンテナの実行状況の管理タスクの進捗状況の監視や

コンテナの ( 再 ) 起動を要求

ココ

15コンテナの起動

AM NM

ContainerLaunchContextContainer ID

Resource実行コマンド

環境変数

必要なファイルやライブラリ名

StartContainerResponseLaunch に成功したコンテナリスト

失敗したコンテナリスト

実行中コンテナの状態

※ 停止の場合も同様

起動

16AM のやっていること

RM

RM への heartbeatRM による AM の死活監視のた

め

ResourceRequestアプリケーションの内容を加味し

RM にコンテナを要求

NM

コンテナの起動Scheduler に割り当てられ

たコンテナの起動を要求 AM

コンテナの実行状況の管理タスクの進捗状況の監視や

コンテナの ( 再 ) 起動を要求

ココ

17ApplicationMaster とのやりとり

あまり詳しく書かれていませんでした

コンテナから AM に下記を送っているっぽい進捗状況実行状況 (RUNNING など ?) 　

18Container 異常終了時

AM は RM 経由で各コンテナの終了ステータスを受信

異常終了時のハンドリングは Application 側の責任

リトライ処理等は Application 中に実装が必要

19AM の異常終了時

RM が再起動をかけてくれる．実行中のタスクの状態は復元されない

異常終了とは別の話ですが…必ずしも同一のアプリに対する AM が一意である状態は

保証できないそう• Network 分断から復旧した場合など

Writer が複数になってしまった場合などのハンドリングはしましょうねと書いてありました．