E-MapReduce:YARN スケジューラ

YARN スケジューラはプラガブルなプラグインです。 YARN は、次のタイプのスケジューラを提供します。FIFO（First-In-First-Out）スケジューラ、Fair スケジューラ、および Capacity スケジューラ。

• FIFO スケジューラは最もシンプルなスケジューラです。複数のテナントにアプリケーションをスケジューリング用にサブミットすることはできません。これは、すべてのアプリケーションがクラスタリソースの割り当てなしに、スケジューリングのためにデフォルトキューにサブミットされることを示しています。この場合、アプリケーションは、他の制御やスケジューリング構成なしで、FIFO ポリシーに基づいてスケジュールされます。 FIFO スケジューラは単純なシナリオにのみ適しており、本番環境ではほとんど使用されません。

• Fair スケジューラは、Cloudera Distributed Hadoop（CDH）で使用されるデフォルトのスケジューラです。 CDH が Hortonworks Data Platform（HDP）とマージされた後、Cloudera Data Platform（CDP）が誕生し、Fair スケジューラの代わりに Capacity スケジューラを使用するようになりました。 Apache Hadoop を使用している場合は、Capacity スケジューラも推奨されます。 Fair スケジューラは、マルチテナント管理とリソーススケジューリング機能を提供します。機能には、マルチレベルキュー管理、クォータ管理、アクセス制御リスト（ACL）ベースの制御、リソースの共有、テナント間の公平なスケジューリング、テナント内でのアプリケーションのスケジューリング、リソースの予約とプリエンプション、非同期スケジューリングが含まれます。ただし、Fair スケジューラの開発は、Apache Hadoop の Capacity スケジューラの開発ほど最新ではありません。 Fair スケジューラは、クラスタのリソースレイアウトを考慮せず、ノードラベル、ノード属性、配置制約などのスケジューリング機能をサポートしていません。

• Capacity スケジューラは、Apache Hadoop、HDP、および CDP で使用されるデフォルトのスケジューラです。 Capacity スケジューラは、Fair スケジューラのすべての機能を含む、完全なマルチテナント管理とリソーススケジューリング機能を提供します。 Capacity スケジューラは、グローバルスケジューリングに基づいてクラスタのリソースレイアウトを最適化し、ホットスポットの問題のリスクを軽減し、クラスタリソースの使用率を最大化できます。 Capacity スケジューラは、ノードラベル、ノード属性、配置制約などのスケジューリング機能もサポートしています。

Capacity スケジューラの MainScheduler は、次のいずれかの方法を使用してトリガーできます。

• ノードのハートビート駆動型: Capacity スケジューラがノードのハートビートを受信すると、MainScheduler がトリガーされ、ノードに対してスケジュールできるアプリケーションが選択されます。このタイプのスケジューリングは、ノードのローカルスケジューリングです。 MainScheduler はハートビート間隔の影響を受け、ランダムスケジューリングに似ています。その結果、リソースが不足していてスケジューリング要件が満たされていないために、多数のノードがヒットしない可能性があります。これにより、スケジューリング効率が低下します。この方法は、スケジューリングパフォーマンスとスケジューリング機能に高い要件がないクラスタに適しています。

• 非同期スケジューリング: MainScheduler は、非同期スレッドまたは複数の並列スレッドによってトリガーされます。ノードリストからランダムなノードがスケジューリングのために選択されます。これにより、スケジューリングパフォーマンスが向上します。この方法は、スケジューリングパフォーマンスに高い要件があるが、スケジューリング機能に低い要件があるクラスタに適しています。

• グローバルスケジューリング: MainScheduler はグローバルスレッドによってトリガーされます。このタイプのスケジューリングは、アプリケーションのグローバルスケジューリングです。アプリケーションは、マルチテナントの公平性やアプリケーションの優先順位などの要因に基づいてスケジューリングのために選択されます。次に、ノードは、リソースサイズ、スケジューリング要件、アプリケーションのリソース配布などの要因に基づいてスケジューリングのために選択されます。このようにして、最適なスケジューリングの決定を行うことができます。この方法は、スケジューリングパフォーマンスとスケジューリング機能に高い要件があるクラスタに適しています。

次の図は、YARN 3.2 以降に基づくグローバルスケジューリングのアーキテクチャを示しています。

• MainScheduler は、リソースリクエストに基づく非同期マルチスレッド処理フレームワークです。 MainScheduler には、割り当てスレッドとサブミットスレッドが含まれています。 1 つ以上の割り当てスレッドを使用して、最も優先順位の高いリソースリクエストを見つけ、リソースサイズと配置制約に基づいて適切な候補ノードを選択し、割り当て提案を生成し、中間キューに割り当て提案を配置します。サブミットスレッドは、割り当て提案を使用し、さまざまな配置制約を再確認してから、割り当て提案をサブミットまたは拒否するために使用されます。サブミットスレッドを使用して、Capacity スケジューラのステータスを更新することもできます。

• ReScheduler は、定期的に実行される動的リソース監視フレームワークです。 ReScheduler には、キュー間プリエンプション、キュー内プリエンプション、予約リソースプリエンプションなどに関連する複数のリソース監視ポリシーが含まれています。

• ノードソートマネージャと配置制約マネージャは、MainScheduler のグローバルスケジューリングプラグインです。プラグインは、負荷分散と複雑な配置制約の管理に使用されます。

次の図は、Capacity スケジューラのグローバルスケジューリングプロセスを示しています。

• MainScheduler のコンテナ割り当てプロセス:

  1. パーティション（ノードラベル）を選択します。クラスタには、1 つ以上のパーティションが存在する場合があります。 MainScheduler は、パーティションにコンテナを順番に割り当てます。

  2. リーフキューを選択します。 MainScheduler は、ルートキューからキューを走査します。同じレベルの子キューは、リーフキューが見つかるまで、キューに割り当てられた保証リソースの割合の昇順で走査されます。前の図では、赤いキューはリソース使用率が高いことを示し、緑のキューはリソース使用率が低いことを示しています。リソースは優先的に緑のキューに割り当てられます。

  3. アプリケーションを選択します。 MainScheduler は、fair ポリシーまたは FIFO ポリシーに基づいてキュー内のアプリケーションを選択します。 fair ポリシーが使用されている場合、アプリケーションは、アプリケーションに割り当てられたメモリリソースの量の昇順で選択されます。 FIFO ポリシーが使用されている場合、アプリケーションは優先順位の降順、アプリケーション ID の昇順で選択されます。

  4. リクエストを選択します。 MainScheduler は、優先順位に基づいてリクエストを選択します。

  5. ソートされた候補ノードを選択します。 MainScheduler は、リクエストの配置制約に基づいて、ソートされたすべてのノードから特定のリソース要件を満たす候補ノードを検索します。

  6. 候補ノードを走査し、各候補ノードにコンテナを割り当てます。割り当てプロセス中に、MainScheduler は、キューまたはノードの割り当て済み、使用済み、または未確認のリソースを確認します。チェックに合格すると、割り当て提案が生成され、提案キューに入れられます。

• MainScheduler のコンテナサブミットプロセス: サブミットスレッドは、提案キューの割り当て提案を確認します。この場合、サブミットスレッドは、アプリケーション、ノード、および配置制約の要件が満たされているかどうかを確認します。要件が満たされていない場合、割り当て提案は破棄されます。要件が満たされている場合、割り当てられたコンテナが有効になり、アプリケーションまたはノードのリソースが更新されます。

• ReScheduler のリソースプリエンプションプロセス: クラスタの使用可能リソースの合計量が特定のリソースしきい値未満であり、特定のアプリケーションに割り当てられたリソースが不足している場合、ReScheduler はさまざまな方法を使用してリソースプリエンプションをトリガーする可能性があります。

  • キュー間プリエンプション: YARN では、キューの未使用の保証リソースを他のキューで共有できます。保証リソースが不足しているキュー内のアプリケーションがより多くのリソースを必要とするが、クラスタにアイドルリソースがない場合、キュー間プリエンプションがトリガーされます。キュー容量内のリソースは保証リソースであり、キュー容量を超えているが最大キュー容量未満のリソースは共有リソースです。

  • キュー内プリエンプション: ReScheduler は、キューの FIFO または fair ポリシーに基づいて、アプリケーションのリソースを監視および調整します。優先順位の高いアプリケーションがリソースを必要とするが、キューに割り当てられたリソースが使い果たされた場合、キュー内プリエンプションがトリガーされます。

  • 予約リソースプリエンプション: タスクが特定の条件を満たすと、タスクとタスク用に予約されているリソースが解放されます。たとえば、タイムアウト期間内にタスクにリソースが割り当てられない場合、タスクとタスク用に予約されているリソースが解放されます。

Capacity スケジューラは、次の機能を提供します。

• マルチレベルキュー管理: Capacity スケジューラを使用すると、複数のテナントで複数レベルのキューを管理できます。親キューのリソースクォータは、すべての子キューのリソース使用量を制限し、単一の子キューのリソースクォータは親キューのリソースクォータを超えることはできません。これにより、制御可能なマルチテナント管理が保証され、さまざまな複雑なアプリケーションシナリオの要件が満たされます。

• リソースクォータ: Capacity スケジューラを使用すると、キューに保証されているリソースと、キューで使用できるリソースの最大量を構成できます。また、キューで実行できるアプリケーションの最大数、ApplicationMaster が使用できるリソースの最大数、ユーザーが使用するリソースと構成済みリソースの比率も構成できます。このようにして、アプリケーション、タスクタイプ、ユーザーなど、複数のディメンションからキューを制御できます。

• 弾性リソースの共有: キュー内の弾性リソースの量は、次の式を使用して計算できます。最大キュー容量 - キュー容量。クラスタと親キューにアイドルリソースがある場合、子キューは他のキューの未使用の保証リソースを使用できます。これにより、異なるキューのリソースのスケジュールベースの再利用が保証され、クラスタのリソース使用率が向上します。

• ACL ベースの制御: Capacity スケジューラを使用すると、キューの権限を管理できます。複数のユーザーを指定してタスクをサブミットおよび管理したり、同じユーザーを指定して複数のキューを管理したりできます。

• テナント間キュースケジューリング: 同じレベルのキューは、キューの保証リソースの割合の昇順でスケジュールされます。これにより、保証リソースが少なく必要なキューが最初にスケジュールされます。キューの優先順位を構成する場合、同じレベルのキューは 2 つのグループに分けられます。使用リソースが保証リソース以下であるキューと、使用リソースが保証リソースを超えているキューです。リソースは、最初に使用リソースが保証リソース以下であるキューに割り当てられます。次に、2 つのグループのすべてのキューが優先順位の降順、保証リソースの割合の昇順でソートされます。

• テナント内アプリケーションスケジューリング: テナント内のアプリケーションは、FIFO または fair ポリシーに基づいてスケジュールされます。アプリケーションが FIFO ポリシーに基づいてスケジュールされている場合、テナント内のすべてのアプリケーションは、優先順位の降順、サブミット時間の昇順でスケジュールされます。アプリケーションが fair ポリシーに基づいてスケジュールされている場合、テナント内のすべてのアプリケーションは、アプリケーションによって使用されるリソースの割合の昇順、サブミット時間の昇順でスケジュールされます。

• プリエンプション: クラスタのリソースは常に変化しています。弾性リソースの共有、テナント内キューの公平なスケジューリング、テナント間アプリケーションスケジューリングの要件を満たすために、プリエンプションプロセスを使用して、キューとアプリケーションのリソース使用量のバランスを取ります。

基本的なキュー構成には、キューの階層関係、キューの容量、キューの最大容量の構成が含まれます。 YARN クラスタが企業の複数の部門とチームで共有されている場合、特定の組織モードと予想されるリソースの割合に基づいて YARN キューを編成できます。次の図に示すように、親キュー root には、dev、test、support、default の 4 つの子キューがあります。キューの保証リソースの割合は 50%、30%、10%、100% であり、キューの最大リソース量の割合は 100%、50%、30%、100% です。 dev キューには、training と services の 2 つの子キューがあります。子キューの保証リソースの割合は 40% と 60% であり、子キューの最大リソース量の割合はどちらも 100% です。

次の表に、キューの基本的な構成を示します。

[YARN スケジューラ] ページのリストには、キューの階層、保証リソースの割合、キューの最大リソース量の割合が表示されます。次の図では、塗りつぶされた灰色のボックスは各キューの最大リソース量の割合を表し、破線のボックスはクラスタリソースに対する各キューの保証リソースの割合を表します。キューを展開して、次の図に示すように、キューのステータス、リソース情報、アプリケーション情報、その他の構成などのキューの詳細を表示できます。

次の表に、キューの ACL 構成を示します。ほとんどの場合、ACL を無効にすることができます。ビジネス要件に基づいて ACL を有効にすることができます。

プリエンプションは、複数のテナント間でのキュースケジューリングの公平性とアプリケーションの優先順位を確保するために使用されます。スケジューリング要件が高いクラスタの場合、プリエンプションを有効にすることができます。 YARN V2.8.0 以降は、プリエンプション機能をサポートしています。次の表に、関連する構成を示します。

Capacity スケジューラを有効にするには、次の表に示す設定項目を構成します。

単一のタスクまたはコンテナのリソース制限は、次の表に示す設定項目によって決まります。