ResourceManagerは、YARN上で実行されているアプリケーションのリソース管理とスケジューリングを行う中心的な役割を担っています。そのため、Apache YARNクラスタにおける単一障害点となる可能性があります。このドキュメントでは、ResourceManagerの再起動機能の概要を示します。この機能は、ResourceManagerの再起動時にも機能し続け、エンドユーザーに対してResourceManagerのダウンタイムを不可視にする機能強化を提供します。
ResourceManagerには2種類の再起動があります。
作業非保持型RM再起動: この再起動は、アプリケーション/試行の状態やその他の資格情報などをプラグ可能な状態ストアに永続化するための機能強化を提供します。RMは再起動時に状態ストアからこの情報を再読み込みし、以前に実行されていたアプリケーションを再起動します。ユーザーはアプリケーションを再送信する必要はありません。
作業保持型RM再起動: これは、再起動時にNodeManagerからのコンテナ状態とApplicationMasterからのコンテナ要求を組み合わせることで、RMの実行状態を再構築することに焦点を当てています。作業非保持型RM再起動との主な違いは、RMの再起動後も以前に実行されていたアプリケーションがキルされない点です。そのため、RMの停止によってアプリケーションの作業が失われることはありません。
作業非保持型RM再起動
作業非保持型RM再起動では、RMはクライアントがアプリケーションを送信するときにアプリケーションメタデータ（ApplicationSubmissionContext）をプラグ可能な状態ストアに保存し、アプリケーションが完了したときに完了状態（失敗、キル、完了）と診断情報を保存します。さらに、RMはセキュアな環境で動作するために、セキュリティキー、トークンなどの資格情報も保存します。RMがシャットダウンしても、必要な情報（セキュアな環境で実行中の場合はアプリケーションメタデータと資格情報）が状態ストアに存在する限り、RMが再起動されると、状態ストアからアプリケーションメタデータを読み込み、アプリケーションを再送信できます。RMは、RMがダウンする前に既に完了していたアプリケーション（失敗、キル、完了）は再送信しません。
RMのダウンタイム中は、NodeManagerとクライアントはRMが起動するまでポーリングを続けます。RMが起動すると、ハートビートを介して通信していたすべてのNodeManagerとApplicationMasterに再同期コマンドを送信します。NMは管理されているすべてのコンテナをキルし、RMに再登録します。これらの再登録されたNodeManagerは、新しく参加したNodeManagerと同様です。AM（例：MapReduce AM）は、再同期コマンドを受信するとシャットダウンする必要があります。RMが再起動し、状態ストアからすべてのアプリケーションメタデータと資格情報をロードしてメモリに格納すると、まだ完了していない各アプリケーションに対して新しい試行（ApplicationMaster）を作成し、通常どおりアプリケーションを再起動します。前述のとおり、再起動時に再同期コマンドによってアプリケーションがキルされるため、この方法では以前に実行されていたアプリケーションの作業は失われます。
作業保持型RM再起動
作業保持型RM再起動では、RMはアプリケーション状態の永続性を確保し、リカバリ時にその状態を再読み込みします。この再起動は主に、YARNクラスタ全体の実行状態、特にRM内のセントラルスケジューラの状態を再構築することに焦点を当てています。セントラルスケジューラは、すべてのコンテナのライフサイクル、アプリケーションのヘッドルームとリソース要求、キューのリソース使用量などを追跡しています。このように、作業非保持型RM再起動のように、AMをキルしてアプリケーションを最初から再実行する必要がありません。アプリケーションは単にRMと再同期して、中断した場所から再開できます。
RMは、すべてのNMから送信されたコンテナ状態を利用して実行状態を復元します。NMは、再起動されたRMと再同期してもコンテナをキルしません。コンテナの管理を続け、再登録時にコンテナの状態をRMに送信します。RMは、これらのコンテナの情報を取り込むことで、コンテナインスタンスと関連するアプリケーションのスケジューリング状態を再構築します。一方、RMはシャットダウン時に未処理の要求を失う可能性があるため、AMは未処理のリソース要求をRMに再送信する必要があります。RMと通信するためにAMRMClientライブラリを使用するアプリケーションライターは、再同期時にAMがRMにリソース要求を再送信する部分については心配する必要はありません。これはライブラリ自体によって自動的に処理されます。
このセクションでは、RM再起動機能を有効にするために必要な設定について説明します。
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.recovery.enabled |
true |
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.store.class |
アプリケーション/試行の状態と資格情報を保存するために使用する状態ストアのクラス名。使用可能な状態ストアの実装には、ZooKeeperベースの状態ストア実装であるorg.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStoreと、HDFSやローカルFSなどのHadoopファイルシステムベースの状態ストア実装であるorg.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStoreがあります。org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStoreはLevelDBベースの状態ストア実装です。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStoreに設定されています。 |
ZooKeeperベースの状態ストア: ユーザーは自由にストレージを選択してRM再起動を設定できますが、RM HAをサポートするにはZooKeeperベースの状態ストアを使用する必要があります。理由は、ZooKeeperベースの状態ストアだけが、複数のRMがアクティブであると想定し、同時に状態ストアを編集しようとするスプリットブレイン状況を回避するためのフェンシングメカニズムをサポートしているためです。
ファイルシステムベースの状態ストア: HDFSとローカルFSベースの状態ストアがサポートされています。フェンシングメカニズムはサポートされていません。
LevelDBベースの状態ストア: LevelDBベースの状態ストアは、HDFSおよびZooKeeperベースの状態ストアよりも軽量とみなされています。LevelDBは、より優れたアトミック操作、状態更新あたりのI/O操作の削減、ファイルシステム上の総ファイル数の削減をサポートしています。フェンシングメカニズムはサポートされていません。
HDFSとローカルFSの両方の状態ストア実装をサポートしています。使用するファイルシステムの種類は、URIのスキームによって決定されます。例：hdfs://127.0.0.1:9000/rmstoreはHDFSをストレージとして使用し、file:///tmp/yarn/rmstoreはローカルFSをストレージとして使用します。URIにスキーム（hdfs://またはfile://）が指定されていない場合、使用するストレージの種類はcore-site.xmlで定義されているfs.defaultFSによって決定されます。
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.fs.state-store.uri |
RM状態が保存されるファイルシステムパスの場所を示すURI（例：hdfs://127.0.0.1:9000/rmstore）。デフォルト値は${hadoop.tmp.dir}/yarn/system/rmstoreです。ファイルシステム名が指定されていない場合、*conf/core-site.xmlで指定されたfs.default.nameが使用されます。 |
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.fs.state-store.retry-policy-spec |
Hadoopファイルシステムクライアントの再試行ポリシーの仕様。Hadoopファイルシステムクライアントの再試行は常に有効です。(t0, n0), (t1, n1), … のペアで指定します。最初の n0 回の再試行では平均 t0 ミリ秒スリープし、次の n1 回の再試行では平均 t1 ミリ秒スリープします。デフォルト値は (2000, 500) です。 |
| プロパティ | 説明 |
|---|---|
hadoop.zk.address |
ホスト名:ポート番号のペアをコンマで区切ったリストです。各ペアは、RMがRM状態を保存するために使用するZooKeeperサーバーに対応します（例：「127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002」）。 |
yarn.resourcemanager.zk-state-store.parent-path |
RM状態が保存されるルートznodeのフルパスです。デフォルト値は/rmstoreです。 |
| プロパティ | 説明 |
|---|---|
hadoop.zk.num-retries |
接続が失われた場合、RMがZooKeeperサーバーへの接続を試行する回数です。デフォルト値は500です。 |
hadoop.zk.retry-interval-ms |
ZooKeeperサーバーへの接続を試行する際の、再試行間のインターバル（ミリ秒単位）です。デフォルト値は2秒です。 |
hadoop.zk.timeout-ms |
ZooKeeperセッションのタイムアウト（ミリ秒単位）です。この設定は、ZooKeeperサーバーがセッションの期限切れを判断するために使用されます。セッションの期限切れは、サーバーがクライアントから（つまり、ハートビートなしで）セッションタイムアウト期間内に応答を受け取らなかった場合に発生します。デフォルト値は10秒です。 |
| プロパティ | 説明 |
|---|---|
hadoop.zk.acl |
ZooKeeper znodeへの権限を設定するために使用されるACLです。デフォルト値はworld:anyone:rwcdaです。 |
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.leveldb-state-store.path |
RM状態が保存されるローカルパスです。デフォルト値は${hadoop.tmp.dir}/yarn/system/rmstoreです。 |
| プロパティ | 説明 |
|---|---|
yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms |
RMのワークプレザービングリカバリ時に、新しいコンテナの割り当てを開始する前にRMが待機する時間（ミリ秒単位）を設定します。この待機期間により、新しいコンテナをアプリケーションに割り当てる前に、リカバリ時にクラスタ内のNMとの再同期が完了するまでRMが落ち着くことができます。 |
ワークプレザービングリカバリが有効な状態でRMが再起動すると、ContainerIdの文字列形式が変更されます。以前の形式はContainer_{clusterTimestamp}_{appId}_{attemptId}_{containerId}（例：Container_1410901177871_0001_01_000005）でした。
現在はContainer_e{epoch}_{clusterTimestamp}_{appId}_{attemptId}_{containerId}（例：Container_e17_1410901177871_0001_01_000005）に変更されています。
ここで、追加されたエポック番号は、0から始まり、RMが再起動するたびに1ずつ増加する単調増加整数です。エポック番号が0の場合は省略され、ContainerIdの文字列形式は以前と同じになります。
以下は、ZooKeeperベースのステートストアを使用したRMワークプレザービング再起動を有効にするための最小限の設定です。
<property> <description>Enable RM to recover state after starting. If true, then yarn.resourcemanager.store.class must be specified</description> <name>yarn.resourcemanager.recovery.enabled</name> <value>true</value> </property> <property> <description>The class to use as the persistent store.</description> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value> </property> <property> <description>Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state. This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore as the value for yarn.resourcemanager.store.class</description> <name>hadoop.zk.address</name> <value>127.0.0.1:2181</value> </property>