yarn application-master
TRANSCRIPT
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 が複数になってしまった場合などのハンドリングはしましょうねと書いてありました.