Hadoop: Capacity Scheduler

目的

このドキュメントでは、CapacitySchedulerについて説明します。これは、複数のテナントが大型クラスタを安全に共有できるようにするHadoopのプラグ可能なスケジューラであり、割り当てられた容量の制約下で、アプリケーションにタイムリーにリソースが割り当てられます。

概要

CapacitySchedulerは、クラスタのスループットと利用率を最大化しながら、オペレータフレンドリーな方法で共有されたマルチテナントクラスタとしてHadoopアプリケーションを実行するように設計されています。

従来、各組織は、ピーク時またはピークに近い状況下で組織のSLAを満たすのに十分な容量を持つ独自のプライベートなコンピューティングリソースを持っていました。これは一般的に、平均利用率の低下と、組織ごとに1つずつ複数の独立したクラスタを管理するためのオーバーヘッドにつながります。組織間でクラスタを共有することは、大規模なHadoopインストールを実行する費用対効果の高い方法です。これにより、プライベートクラスタを作成することなく、規模の経済効果を得ることができます。しかし、組織は、SLAにとって重要なリソースを他者が使用することを懸念しているため、クラスタの共有を懸念しています。

CapacitySchedulerは、各組織に容量保証を提供しながら、大規模クラスタの共有を可能にするように設計されています。中心となる考え方は、Hadoopクラスタ内の利用可能なリソースが、コンピューティングニーズに基づいてクラスタを共同で資金提供する複数の組織間で共有されることです。さらに、組織は、他者によって使用されていない余剰容量にアクセスできるという利点があります。これは、費用対効果の高い方法で組織に弾力性を提供します。

組織間でクラスタを共有するには、マルチテナントの強力なサポートが必要です。各組織に容量が保証され、共有クラスタが単一の不正なアプリケーション、ユーザー、またはそれらのセットの影響を受けないようにするための保護策が用意されている必要があるためです。CapacitySchedulerは、単一のアプリケーション、ユーザー、またはキューがクラスタのリソースを不釣り合いに消費できないようにする厳格な制限セットを提供します。また、CapacitySchedulerは、単一のユーザーとキューからの初期化済みおよび保留中のアプリケーションに制限を提供して、クラスタの公平性と安定性を確保します。

CapacitySchedulerによって提供される主要な抽象化は、キューの概念です。これらのキューは、通常、管理者によって共有クラスタの経済性を反映するように設定されます。

リソース共有に関するさらなる制御と予測可能性を提供するために、CapacitySchedulerは、他のキューがフリーリソースを使用できるようになる前に、組織のサブキュー間でリソースが共有されるようにする階層型キューをサポートし、それによって特定の組織のアプリケーション間でフリーリソースを共有するためのアフィニティを提供します。

機能

CapacitySchedulerは、次の機能をサポートしています。

  • 階層型キュー - キューの階層がサポートされており、他のキューがフリーリソースを使用できるようになる前に、組織のサブキュー間でリソースが共有されるようにし、より多くの制御と予測可能性を提供します。

  • 容量保証 - キューには、特定の容量のリソースが利用可能になるという意味で、グリッドの容量の一部が割り当てられます。キューに送信されたすべてのアプリケーションは、キューに割り当てられた容量にアクセスできます。管理者は、各キューに割り当てられた容量に、ソフト制限とオプションのハード制限を設定できます。

  • セキュリティ - 各キューには、個々のキューにアプリケーションを送信できるユーザーを制御する厳格なACLがあります。また、ユーザーが他のユーザーのアプリケーションを閲覧および/または変更できないようにするための保護策もあります。また、キューごとの管理者ロールとシステム管理者ロールがサポートされています。

  • 弾力性 - フリーリソースは、その容量を超えて任意のキューに割り当てられます。将来のある時点で容量を下回って実行しているキューからこれらのリソースに対する需要がある場合、これらのリソースでスケジュールされたタスクが完了すると、容量を下回って実行しているキューのアプリケーションに割り当てられます（プリエンプションもサポートされています）。これにより、クラスタ内のリソースの人工的なサイロを防ぎ、利用率を向上させることで、キューに予測可能で弾力的な方法でリソースが利用可能になります。

  • マルチテナント - クラスタ全体が圧倒されないようにするために、単一のアプリケーション、ユーザー、およびキューがキューまたはクラスタ全体の資源を独占することを防ぐための包括的な制限セットが提供されています。

  • 運用性

    • 実行時設定 - 容量、ACLなどのキューの定義とプロパティは、ユーザーへの中断を最小限に抑えるために、管理者が安全な方法で実行時に変更できます。また、ユーザーと管理者がシステム内のさまざまなキューへのリソースの現在の割り当てを表示するためのコンソールが提供されています。管理者は実行時に追加のキューを追加できますが、キューが停止していて保留中/実行中のアプリがない場合を除き、実行時にキューを削除することはできません。

    • アプリケーションのドレイン - 管理者は、既存のアプリケーションが完了するまで実行される一方で、新しいアプリケーションが送信されないように、実行時にキューを停止できます。キューがSTOPPED状態の場合、新しいアプリケーションはそれ自体またはその子キューのいずれかに送信できません。既存のアプリケーションは完了まで継続されるため、キューを段階的にドレインできます。管理者は、停止したキューを開始することもできます。

  • リソースベースのスケジューリング - アプリケーションがデフォルトよりも高いリソース要件をオプションで指定できるため、異なるリソース要件を持つアプリケーションに対応できる、リソースを大量に消費するアプリケーションのサポート。現在、メモリがサポートされているリソース要件です。

  • デフォルトまたはユーザー定義の配置ルールに基づくキューマッピングインターフェース - この機能により、ユーザーは、あるデフォルトの配置ルールに基づいて、ジョブを特定のキューにマッピングできます。たとえば、ユーザーとグループ、またはアプリケーション名に基づいて。ユーザーは独自の配置ルールを定義することもできます。

  • 優先順位スケジューリング - この機能により、アプリケーションを異なる優先順位で送信およびスケジュールできます。整数値が高いほど、アプリケーションの優先順位が高くなります。現在、アプリケーションの優先順位は、FIFOオーダリングポリシーでのみサポートされています。

  • 絶対リソース設定 - 管理者は、パーセンテージベースの値を提供する代わりに、キューに絶対リソースを指定できます。これにより、管理者は特定のキューに必要なリソース量を設定するためのより優れた制御が可能になります。

  • リーフキューの動的な自動作成と管理 - この機能は、キューマッピングと組み合わせてリーフキューの自動作成をサポートします。現在、アプリケーションの配置をキューにマッピングするユーザーグループベースのキューマッピングをサポートしています。スケジューラは、親キューに設定されたポリシーに基づいて、これらのキューの容量管理もサポートしています。

設定

CapacitySchedulerを使用するResourceManagerの設定

ResourceManagerがCapacitySchedulerを使用するように設定するには、conf/yarn-site.xmlで次のプロパティを設定します。

プロパティ 値
yarn.resourcemanager.scheduler.class org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

キューの設定

etc/hadoop/capacity-scheduler.xmlは、CapacitySchedulerの設定ファイルです。

CapacitySchedulerには、rootという名前の定義済みキューがあります。システム内のすべてのキューは、rootキューの子です。

その他のキューは、コンマ区切りの子キューのリストでyarn.scheduler.capacity.root.queuesを設定することで設定できます。

CapacitySchedulerの設定では、キューの階層を設定するためのキューパスという概念を使用します。キューパスとは、rootから始まり、デリミタとして.(ドット)を使用したキュー階層のフルパスです。

特定のキューの子は、構成ノブ：yarn.scheduler.capacity.<queue-path>.queuesで定義できます。特に明記されていない限り、子は親からプロパティを直接継承しません。

以下は、3つの最上位の子キューa、b、cと、aとbのいくつかのサブキューの例です。

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>a,b,c</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.queues</name>
  <value>a1,a2</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.b.queues</name>
  <value>b1,b2,b3</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

キューのプロパティ

  • リソース割り当て
プロパティ 説明
yarn.scheduler.capacity.<queue-path>.capacity キューの*容量*をパーセンテージ（％）で浮動小数点数（例：12.5）または絶対リソースキューの最小容量で指定します。各レベルのすべてのキューの容量の合計は100に等しくなければなりません。ただし、絶対リソースが設定されている場合、子キューの絶対リソースの合計は、親の絶対リソース容量よりも小さくなる可能性があります。空きリソースがあれば、キュー内のアプリケーションはキューの容量よりも多くのリソースを消費し、弾力性を提供できます。
yarn.scheduler.capacity.<queue-path>.maximum-capacity キューの最大容量をパーセンテージ（％）で浮動小数点数または絶対リソースキューの最大容量で指定します。これは、キュー内のアプリケーションの*弾力性*を制限します。1）値は0〜100の間です。2）管理者は、各キューについて絶対最大容量≧絶対容量であることを確認する必要があります。また、この値を-1に設定すると、最大容量は100％になります。
yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent 各キューは、リソースに対する需要がある場合、いつでもユーザーに割り当てられるリソースの割合に制限を設けます。ユーザー制限は、最小値と最大値の間で変化します。前者（最小値）はこのプロパティ値に設定され、後者（最大値）はアプリケーションを送信したユーザーの数によって異なります。たとえば、このプロパティの値が25であるとします。2人のユーザーがキューにアプリケーションを送信した場合、単一のユーザーはキューリソースの50％以上を使用できません。3番目のユーザーがアプリケーションを送信すると、単一のユーザーはキューリソースの33％以上を使用できません。4人以上のユーザーの場合、どのユーザーもキューリソースの25％以上を使用できません。100の値は、ユーザー制限が適用されないことを意味します。デフォルトは100です。値は整数で指定します。
yarn.scheduler.capacity.<queue-path>.user-limit-factor 単一ユーザーがより多くのリソースを取得できるように構成できる、キュー容量の倍数です。デフォルトでは1に設定されており、クラスタがどれだけアイドル状態であっても、単一ユーザーがキューの構成済み容量を超えることは決してありません。値は浮動小数点数で指定します。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb リソースマネージャーで各コンテナ要求に割り当てるメモリの、キューごとの最大制限です。この設定は、クラスタ構成のyarn.scheduler.maximum-allocation-mbをオーバーライドします。この値は、クラスタの最大値以下である必要があります。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores リソースマネージャーで各コンテナ要求に割り当てる仮想コアの、キューごとの最大制限です。この設定は、クラスタ構成のyarn.scheduler.maximum-allocation-vcoresをオーバーライドします。この値は、クラスタの最大値以下である必要があります。
yarn.scheduler.capacity.<queue-path>.user-settings.<user-name>.weight この浮動小数点値は、キュー内のユーザーのリソース値のユーザー制限を計算する際に使用されます。この値により、キュー内の他のユーザーよりも各ユーザーの重みが大きくなったり小さくなったりします。たとえば、ユーザーAがキュー内のユーザーBとCよりも50％多くのリソースを受け取る必要がある場合、このプロパティはユーザーAに対して1.5に設定されます。ユーザーBとCはデフォルトで1.0になります。
  • 絶対リソース構成を使用したリソース割り当て

CapacitySchedulerは、キューの*容量*をパーセンテージで指定する代わりに、絶対リソースの構成をサポートしています。上記のyarn.scheduler.capacity.<queue-path>.capacityとyarn.scheduler.capacity.<queue-path>.max-capacityの構成セクションで述べたように、管理者は[memory=10240,vcores=12]のような絶対リソース値を指定できます。これは、10GBのメモリと12個の仮想コアを示す有効な構成です。

  • 実行中および保留中のアプリケーションの制限

CapacitySchedulerは、実行中および保留中のアプリケーションを制御するための次のパラメーターをサポートしています。

プロパティ 説明
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications システム内で同時にアクティブにできるアプリケーション（実行中と保留中の両方）の最大数です。各キューの制限は、キューの容量とユーザー制限に正比例します。これはハード制限であり、この制限に達したときに送信されたアプリケーションは拒否されます。デフォルトは10000です。これは、yarn.scheduler.capacity.maximum-applicationsを使用してすべてのキューに設定でき、yarn.scheduler.capacity.<queue-path>.maximum-applicationsを設定することで、キューごとにオーバーライドすることもできます。整数値が必要です。
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent アプリケーションマスターの実行に使用できるクラスタ内のリソースの最大パーセントです。これは、同時にアクティブなアプリケーションの数を制御します。各キューの制限は、キューの容量とユーザー制限に正比例します。浮動小数点数で指定します（例：0.5 = 50％）。デフォルトは10％です。これは、yarn.scheduler.capacity.maximum-am-resource-percentを使用してすべてのキューに設定でき、yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percentを設定することで、キューごとにオーバーライドすることもできます。
yarn.scheduler.capacity.max-parallel-apps / yarn.scheduler.capacity.<queue-path>.max-parallel-apps 同時に実行できるアプリケーションの最大数です。maximum-applicationsとは異なり、この制限に達してもアプリケーションの送信は*拒否されません*。代わりに、実行可能になるまでACCEPTED状態のままになります。これは、yarn.scheduler.capacity.max-parallel-appsを使用してすべてのキューに設定でき、yarn.scheduler.capacity.<queue-path>.max-parallel-appsを設定することで、キューごとにオーバーライドすることもできます。整数値が必要です。デフォルトでは、制限はありません。最大並列アプリケーション制限は、キュー階層内で継承されるプロパティであり、階層のすべてのブランチで最も低い値が適用される制限として選択されます。

ユーザーごとに並列アプリケーションの数を制限することもできます。

プロパティ 説明
yarn.scheduler.capacity.user.max-parallel-apps すべてのユーザーが同時に実行できるアプリケーションの最大数です。デフォルト値は無制限です。
yarn.scheduler.capacity.user.<username>.max-parallel-apps 特定のユーザーが同時に実行できるアプリケーションの最大数です。これはグローバル設定をオーバーライドします。

これらの制限の評価は、次の順序で行われます。

  1. maximum-applicationsチェック - 制限を超えた場合、送信はすぐに拒否されます。

  2. max-parallel-appsチェック - 送信は承認されますが、アプリケーションはRUNNING状態には遷移しません。キュー/ユーザーの制限が満たされるまで、ACCEPTED状態のままです。

  3. maximum-am-resource-percentチェック - 実行中のアプリケーションマスターが多すぎる場合、十分な空きスペースができるまでアプリケーションはACCEPTED状態のままです。

  • キューの管理と権限

CapacitySchedulerは、キューを管理するための次のパラメーターをサポートしています。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.state キューの*状態*です。RUNNINGまたはSTOPPEDのいずれかになります。キューがSTOPPED状態の場合、新しいアプリケーションは*それ自体*または*その子キューのいずれか*に送信できません。したがって、*ルート*キューがSTOPPEDの場合、クラスタ全体にアプリケーションを送信することはできません。既存のアプリケーションは完了まで継続されるため、キューを正常に*ドレイン*できます。値は列挙型として指定します。
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications 指定されたキューにアプリケーションを*送信*できるユーザーを制御する*ACL*です。指定されたユーザー/グループが指定されたキューまたは*階層内の親キューのいずれか*に必要なACLを持っている場合、アプリケーションを送信できます。このプロパティの*ACL*は、指定されていない場合は親キューから*継承され*ます。このリストのユーザー名の前にチルダ（〜）が付いている場合、実際のユーザーのACLによって、プロキシされたユーザーがキューに送信できるようになります。
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue 指定されたキューでアプリケーションを*管理*できるユーザーを制御する*ACL*です。指定されたユーザー/グループが指定されたキューまたは*階層内の親キューのいずれか*に必要なACLを持っている場合、アプリケーションを管理できます。このプロパティの*ACL*は、指定されていない場合は親キューから*継承され*ます。このリストのユーザー名の前にチルダ（〜）が付いている場合、実際のユーザーのACLによって、プロキシされたユーザーがキューのアプリを管理できるようになります。

注：*ACL*の形式は、user1、user2 space group1、group2です。*の特別な値は*誰でも*を意味します。spaceの特別な値は*誰もいない*ことを意味します。指定されていない場合、ルートキューのデフォルトは*です。

  • ユーザーまたはグループ、アプリケーション名、またはユーザー定義の配置ルールに基づくキューのマッピング

CapacitySchedulerは、ユーザーまたはグループ、ユーザーとグループ、またはアプリケーション名に基づいてキューのマッピングを構成するための次のパラメーターをサポートしています。ユーザーは独自の配置ルールを定義することもできます。

プロパティ 説明
yarn.scheduler.capacity.queue-mappings この構成は、ユーザーまたはグループを特定のキューにマッピングすることを指定します。単一のユーザーまたはユーザーのリストをキューにマッピングできます。構文：[u or g]:[name]:[queue_name][,next_mapping]*。ここで、u or gは、マッピングがユーザー用かグループ用かを表します。値はユーザーの場合はu、グループの場合はgです。nameは、ユーザー名またはグループ名を示します。アプリケーションを送信したユーザーを指定するには、%userを使用できます。queue_nameは、アプリケーションをマッピングする必要があるキュー名を示します。ユーザー名と同じキュー名を指定するには、%userを使用できます。ユーザーが属するプライマリグループの名前と同じキュー名を指定するには、%primary_groupを使用できます。セカンダリグループは%secondary_groupとして参照できます。
yarn.scheduler.queue-placement-rules.app-name この構成は、application_nameを特定のキューにマッピングすることを指定します。単一のアプリケーションまたはアプリケーションのリストをキューにマッピングできます。構文：[app_name]:[queue_name][,next_mapping]*。ここで、app_nameは、マッピングを行うアプリケーション名を示します。queue_nameは、アプリケーションをマッピングする必要があるキュー名を示します。現在のアプリケーションの名前をapp_nameとして指定するには、%applicationを使用できます。
yarn.scheduler.capacity.queue-mappings-override.enable この関数は、ユーザーが指定したキューをオーバーライドできるかどうかを指定するために使用されます。これはブール値であり、デフォルト値はfalseです。

例

以下の例は、単一のマッピングを個別に扱っています。コンマで区切られた値を持つ複数マッピングの場合、評価は左から右に行われ、最初の有効なマッピングが使用されます。以下の例では、複数マッピングの場合の実行時の実際の処理順序に基づいて、順序が文書化されています。

 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%primary_group.%user</value>
    <description>Maps users to queue with the same name as user but
    parent queue name should be same as primary group of the user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%secondary_group.%user</value>
    <description>Maps users to queue with the same name as user but
    parent queue name should be same as any secondary group of the user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%user</value>
    <description>Maps users to queues with the same name as user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user2:%primary_group</value>
    <description>user2 is mapped to queue name same as primary group</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user3:%secondary_group</value>
    <description>user3 is mapped to queue name same as secondary group</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user1:queue1</value>
    <description>user1 is mapped to queue1</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>g:group1:queue2</value>
    <description>group1 is mapped to queue2</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user1:queue1,u:user2:queue2</value>
    <description>Here, <user1> is mapped to <queue1>, <user2> is mapped to <queue2> respectively</description>
 </property>

  <property>
    <name>yarn.scheduler.queue-placement-rules.app-name</name>
    <value>appName1:queue1,%application:%application</value>
    <description>
      Here, <appName1> is mapped to <queue1>, maps applications to queues with
      the same name as application respectively. The mappings will be
      evaluated from left to right, and the first valid mapping will be used.
    </description>
  </property>
  • アプリケーションのキューのライフタイム

    CapacitySchedulerは、アプリケーションのライフタイムに関する次のパラメーターをサポートしています。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime キューに送信されたアプリケーションの最大存続時間（秒単位）。0以下の値は、無効として扱われます。デフォルトは-1です。正の値が設定されている場合、このキューに送信されたアプリケーションは、設定された存続時間を超えると強制終了されます。ユーザーは、アプリケーション送信コンテキストでアプリケーションごとの存続時間を指定することもできます。ただし、ユーザーの存続時間がキューの最大存続時間を超える場合は、キューの最大存続時間が優先されます。これは時点的な設定です。注：この機能は、キュー階層の任意のレベルで設定できます。子キューは、子レベルで上書きされない限り、親の値を継承します。値が0の場合、最大存続時間なしとなり、親の最大存続時間を上書きします。このプロパティが設定されていない場合、または負の値に設定されている場合、このキューの最大存続時間値は親から継承されます。
yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime キューに送信されたアプリケーションのデフォルトの存続時間（秒単位）。0以下の値は、無効として扱われます。ユーザーが存続時間値を指定せずにアプリケーションを送信した場合、この値が使用されます。これは時点的な設定です。この機能は、キュー階層の任意のレベルで設定できます。子キューは、子レベルで上書きされない限り、親の値を継承します。0以下の値に設定されている場合、キューの最大値も無制限にする必要があります。デフォルトの存続時間は、最大存続時間を超えることはできません。

アプリケーション優先順位の設定。

アプリケーションの優先順位は、FIFO順序付けポリシーと併用した場合のみ機能します。デフォルトの順序付けポリシーはFIFOです。

アプリケーションのデフォルトの優先順位は、クラスタレベルとキューレベルで設定できます。

  • クラスタレベルの優先順位：クラスタの最大優先順位よりも高い優先順位で送信されたアプリケーションは、その優先順位がクラスタの最大優先順位にリセットされます。クラスタの最大優先順位の設定ファイルは、$HADOOP_HOME/etc/hadoop/yarn-site.xmlです。
プロパティ 説明
yarn.cluster.max-application-priority クラスタ内の最大アプリケーション優先順位を定義します。
  • リーフキューレベルの優先順位：各リーフキューは、管理者によってデフォルトの優先順位が提供されます。優先順位が指定されていないアプリケーションには、キューのデフォルトの優先順位が使用されます。キューレベルの優先順位の設定ファイルは、$HADOOP_HOME/etc/hadoop/capacity-scheduler.xmlです。
プロパティ 説明
yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority リーフキュー内のデフォルトのアプリケーション優先順位を定義します。

注：アプリケーションが別のキューに移動された場合、アプリケーションの優先順位は変更されません。

Capacity Schedulerコンテナプリエンプション

CapacitySchedulerは、リソース使用量が保証された容量を超えているキューからコンテナのプリエンプションをサポートしています。アプリケーションコンテナのプリエンプションをサポートするには、yarn-site.xmlで次の設定パラメータを有効にする必要があります。

プロパティ 説明
yarn.resourcemanager.scheduler.monitor.enable スケジューラに影響を与える一連の定期的なモニタ（yarn.resourcemanager.scheduler.monitor.policiesで指定）を有効にします。デフォルト値はfalseです。
yarn.resourcemanager.scheduler.monitor.policies スケジューラとやり取りするSchedulingEditPolicyクラスのリスト。設定されたポリシーは、スケジューラと互換性がある必要があります。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicyであり、これはCapacitySchedulerと互換性があります。

yarn.resourcemanager.scheduler.monitor.policiesにProportionalCapacityPreemptionPolicyクラスが設定されている場合、コンテナのプリエンプションを制御するために、yarn-site.xmlで次の設定パラメータを設定できます。

プロパティ 説明
yarn.resourcemanager.monitor.capacity.preemption.observe_only trueの場合、ポリシーを実行しますが、プリエンプションとキルイベントでクラスタに影響を与えません。デフォルト値はfalseです。
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval このProportionalCapacityPreemptionPolicyポリシーの呼び出し間の時間（ミリ秒単位）。デフォルト値は3000です。
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill アプリケーションからプリエンプションを要求してからコンテナを強制終了するまでの時間（ミリ秒単位）。デフォルト値は15000です。
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round 1ラウンドでプリエンプションされるリソースの最大パーセンテージ。この値を制御することで、クラスタからコンテナが回収されるペースを調整できます。合計で必要なプリエンプションを計算した後、ポリシーはその範囲内にスケールバックします。デフォルト値は0.1です。
yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity プリエンプションのために無視されるターゲット容量を超えるリソースの最大量。これは、ターゲット容量の周囲にデッドゾーンを定義し、計算されたターゲットバランスの周りのスレッショルドと振動を防ぐのに役立ちます。値が高いほど、容量までの時間が遅くなり、（自然な完了がない場合）保証された容量への収束を防ぐ可能性があります。デフォルト値は0.1です。
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor 計算されたプリエンプションターゲットが与えられた場合、自然に期限切れになるコンテナを考慮し、デルタのこのパーセンテージのみをプリエンプションします。これは、デッドゾーン（MAX_IGNORED_OVER_CAPACITY）への幾何学的収束の速度を決定します。たとえば、終了係数が0.5の場合、自然な終了がない場合でも、5 * WAIT_TIME_BEFORE_KILL以内にほぼ95％のリソースが回収されます。デフォルト値は0.2です。

CapacitySchedulerは、キューに送信されたアプリケーションコンテナのプリエンプションを制御するために、capacity-scheduler.xmlで次の設定をサポートしています。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.disable_preemption この設定をtrueに設定すると、特定のキューに送信されたアプリケーションコンテナのプリエンプションを選択的に無効にできます。このプロパティは、yarn.resourcemanager.scheduler.monitor.enableをtrueに、yarn.resourcemanager.scheduler.monitor.policiesをProportionalCapacityPreemptionPolicyに設定することでシステム全体のプリエンプションが有効になっている場合にのみ適用されます。このプロパティがキューに対して設定されていない場合、プロパティ値はキューの親から継承されます。デフォルト値はfalseです。
yarn.scheduler.capacity.<queue-path>.intra-queue-preemption.disable_preemption この設定をtrueに設定すると、特定のキューに送信されたアプリケーションコンテナのキュー内プリエンプションを選択的に無効にできます。このプロパティは、yarn.resourcemanager.scheduler.monitor.enableをtrueに、yarn.resourcemanager.scheduler.monitor.policiesをProportionalCapacityPreemptionPolicyに、yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.enabledをtrueに設定することでシステム全体のプリエンプションが有効になっている場合にのみ適用されます。このプロパティがキューに対して設定されていない場合、プロパティ値はキューの親から継承されます。デフォルト値はfalseです。

予約プロパティ

  • 予約の管理と権限

CapacitySchedulerは、予約の作成、削除、更新、一覧表示を制御するための次のパラメータをサポートしています。任意のユーザーは、独自の予約を更新、削除、または一覧表示できます。予約ACLが有効になっているが定義されていない場合、全員がアクセスできます。以下の例では、<queue>はキュー名です。たとえば、デフォルトキューでの予約の管理に予約ACLを設定するには、プロパティyarn.scheduler.capacity.root.default.acl_administer_reservationsを使用します。

プロパティ 説明
yarn.scheduler.capacity.root.<queue>.acl_administer_reservations 特定のキューへの予約を管理できるユーザーを制御するACL。指定されたユーザー/グループが指定されたキューに必要なACLを持っている場合、またはすべての予約を送信、削除、更新、および一覧表示できる場合。このプロパティのACLは、指定されていない場合、親キューから継承されません。
yarn.scheduler.capacity.root.<queue>.acl_list_reservations 特定のキューの予約を一覧表示できるユーザーを制御するACL。指定されたユーザー/グループが指定されたキューに必要なACLを持っている場合、すべてのアプリケーションを一覧表示できます。このプロパティのACLは、指定されていない場合、親キューから継承されません。
yarn.scheduler.capacity.root.<queue>.acl_submit_reservations 特定のキューに予約を送信できるユーザーを制御するACL。指定されたユーザー/グループが指定されたキューに必要なACLを持っている場合、予約を送信できます。このプロパティのACLは、指定されていない場合、親キューから継承されません。

CapacitySchedulerでのReservationSystemの設定

CapacitySchedulerは、ユーザーが事前にリソースを予約できるReservationSystemをサポートしています。アプリケーションは、送信時にreservationIdを指定することで、実行時に予約済みリソースを要求できます。ReservationSystemには、yarn-site.xmlで次の設定パラメータを設定できます。

プロパティ 説明
yarn.resourcemanager.reservation-system.enable 必須パラメータ：ResourceManagerでReservationSystemを有効にします。ブール値が必要です。デフォルト値はfalse、つまりReservationSystemはデフォルトでは有効になっていません。
yarn.resourcemanager.reservation-system.class オプションパラメータ：ReservationSystemのクラス名。デフォルト値は、設定されているスケジューラに基づいて選択されます。つまり、CapacitySchedulerが設定されている場合、CapacityReservationSystemになります。
yarn.resourcemanager.reservation-system.plan.follower オプションパラメータ：タイマーで実行され、CapacitySchedulerとPlanを同期するPlanFollowerのクラス名。デフォルト値は、設定されているスケジューラに基づいて選択されます。つまり、CapacitySchedulerが設定されている場合、CapacitySchedulerPlanFollowerになります。
yarn.resourcemanager.reservation-system.planfollower.time-step オプションパラメータ：PlanFollowerタイマーの頻度（ミリ秒単位）。Long値が必要です。デフォルト値は1000です。

ReservationSystemはCapacitySchedulerキュー階層と統合されており、現在、任意のLeafQueueに対して設定できます。CapacitySchedulerは、ReservationSystemを調整するための次のパラメータをサポートしています。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.reservable 必須パラメータ：ユーザーが予約できるリソースとしてキューのリソースをReservationSystemに示します。ブール値が必要です。デフォルト値はfalse、つまり予約はデフォルトではLeafQueuesでは有効になっていません。
yarn.scheduler.capacity.<queue-path>.reservation-agent オプションパラメータ：ユーザーの予約要求をPlanに配置しようとするReservationAgentの実装を決定するために使用されるクラス名。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedyです。
yarn.scheduler.capacity.<queue-path>.reservation-move-on-expiry 関連付けられた予約が期限切れになった場合に、アプリケーションを親のリザーバブルキュー（上記で設定）に移動するか、強制終了するかをReservationSystemに指定するためのオプションパラメータ。ブール値が必要です。デフォルト値はtrueであり、アプリケーションはリザーバブルキューに移動されます。
yarn.scheduler.capacity.<queue-path>.show-reservations-as-queues スケジューラUIで予約キューを表示または非表示にするためのオプションパラメータ。ブール値が必要です。デフォルト値はfalse、つまり予約キューは非表示になります。
yarn.scheduler.capacity.<queue-path>.reservation-policy オプションパラメータ：新しい予約が不変量に違反していないことを検証するSharingPolicyの実装を決定するために使用されるクラス名。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicyです。
yarn.scheduler.capacity.<queue-path>.reservation-window オプションパラメータ。SharingPolicyがPlanの制約が満たされているかどうかを検証する時間（ミリ秒単位）を表します。Long値が必要です。デフォルト値は1日です。
yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity オプション パラメータ：SharingPolicy が単一ユーザーに予約を許可する、パーセンテージ（％）で表した浮動小数点数としての最大容量。デフォルト値は 1、つまり 100％です。
yarn.scheduler.capacity.<queue-path>.average-capacity オプション パラメータ：SharingPolicy が単一ユーザーに予約を許可する、ReservationWindow にわたって集計されたパーセンテージ（％）で表した浮動小数点数としての平均許容容量。デフォルト値は 1、つまり 100％です。
yarn.scheduler.capacity.<queue-path>.reservation-planner オプション パラメータ：（スケジュールされたメンテナンスまたはノード障害のために）Plan 容量がユーザーが予約したリソースを下回った場合に呼び出される、Planner の実装を決定するために使用されるクラス名。デフォルト値は org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner であり、Plan をスキャンし、予約済みリソースがPlan 容量内になるまで、予約を承認順の逆順（LIFO）で貪欲に削除します。
yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window オプション パラメータ。Planner が Plan 内の制約が満たされているかどうかを検証する時間（ミリ秒単位）。長い値が期待されます。デフォルト値は 1 時間です。

リーフキューの動的な自動作成と管理

CapacityScheduler は、この機能を有効にするように構成されている親キューの下にリーフキューの自動作成をサポートしています。

  • キューマッピングによる動的に自動作成されたリーフキューの設定

yarn.scheduler.capacity.queue-mappings にリストされているユーザーグループキューマッピングは、自動作成されたリーフキューを作成する必要がある親キューを識別するための追加の親キューパラメーターを指定する必要があります。詳細は上記の「ユーザーまたはグループに基づくキューマッピング」セクションを参照してください。このような親キューでは、下記の「リーフキューの動的な自動作成と管理のための親キュー設定」セクションで説明されているように、子キューの自動作成も有効にする必要があることに注意してください。

例

 <property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1.%user</value>
   <description>
     Here, u:%user:parent1.%user mapping allows any <user> other than user1,
     user2 to be mapped to its own user specific leaf queue which
     will be auto-created under <parent1>.
   </description>
 </property>
  • リーフキューの動的な自動作成と管理のための親キュー設定

動的キュー自動作成と管理機能はCapacityScheduler キュー階層と統合されており、現在、リーフキューを自動作成するようにParentQueueに対して構成できます。このような親キューは、自動作成されたキューと共に他の事前に構成されたキューが共存することをサポートしていません。CapacityScheduler は、キューの自動作成を有効にするために次のパラメーターをサポートしています。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.enabled 必須 パラメータ：指定された親キューに対してリーフキューの自動作成を有効にする必要があることをCapacityScheduler に指示します。ブール値が必要です。デフォルト値はfalseであり、つまりParentQueueではデフォルトでリーフキューの自動作成は有効になっていません。
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.management-policy オプション パラメータ：この親キューの下でリーフキューとその容量を動的に管理するAutoCreatedQueueManagementPolicyの実装を決定するために使用されるクラス名。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.queuemanagement.GuaranteedOrZeroCapacityOverTimePolicyです。ユーザーまたはグループは、制限時間内に自動作成されたリーフキューにアプリケーションを送信し、使用を停止することがあります。したがって、親キューの下に自動作成されたリーフキューの数が、その保証された容量よりも多くなる可能性があります。現在のポリシーの実装では、親キューの容量の可用性と、リーフキュー全体のアプリケーションの送信順序に基づいて、構成済み容量またはゼロ容量をベストエフォートベースで割り当てます。
  • CapacitySchedulerによる自動作成されたリーフキューの構成

リーフキューの自動作成が有効になっている親キューは、自動作成されたリーフキューの自動構成のためのテンプレートパラメーターの構成をサポートしています。自動作成されたキューは、キューACL、絶対リソース構成を除く、すべてのリーフキュー構成パラメーターをサポートしています。キューACLは現在親キューから継承されます。つまり、リーフキューテンプレートでは構成できません。

プロパティ 説明
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.capacity 必須 パラメータ：自動作成されたリーフキューの最小保証容量を指定します。現在、自動作成されたリーフキューでは絶対リソース構成はサポートされていません。
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.<leaf-queue-property> オプション パラメータ：最大容量、ユーザー制限係数、最大amリソースパーセントなど、自動作成されたリーフキューで構成できる他のキューパラメーターについては、キューのプロパティセクションを参照してください。

例

 <property>
   <name>yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled</name>
   <value>true</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity</name>
    <value>5</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity</name>
    <value>100</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor</name>
    <value>3.0</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy</name>
    <value>fair</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.GPU.capacity</name>
    <value>50</value>
 </property>
 <property>
     <name>yarn.scheduler.capacity.root.parent1.accessible-node-labels</name>
     <value>GPU,SSD</value>
   </property>
 <property>
     <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels</name>
     <value>GPU</value>
  </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels.GPU.capacity</name>
    <value>5</value>
 </property>
  • 自動作成されたキュー管理のためのスケジューリング編集ポリシーの構成

管理者は、現在のスケジューリング編集ポリシーのリストに追加のorg.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.QueueManagementDynamicEditPolicyスケジューリング編集ポリシーを、yarn.resourcemanager.scheduler.monitor.policies構成でコンマ区切りの文字列として指定する必要があります。詳細は、上記の「Capacity Schedulerコンテナプリエンプション」セクションを参照してください。

プロパティ 説明
yarn.resourcemanager.monitor.capacity.queue-management.monitoring-interval このQueueManagementDynamicEditPolicyポリシーの呼び出し間の時間（ミリ秒単位）。デフォルト値は1500です。

その他のプロパティ

  • リソース計算機
プロパティ 説明
yarn.scheduler.capacity.resource-calculator スケジューラでリソースを比較するために使用するResourceCalculatorの実装。デフォルト（つまり、org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator）はメモリのみを使用しますが、DominantResourceCalculatorはメモリ、CPUなど多次元リソースの比較にDominant-resourceを使用します。Java ResourceCalculatorクラス名が期待されます。
  • データ局所性

Capacity Schedulerは、遅延スケジューリングを利用してタスクの局所性制約を尊重します。局所性制約には3つのレベルがあります。ノードローカル、ラックローカル、オフスイッチです。スケジューラは、局所性を満たすことができない場合に逃した機会の数をカウントし、その数がしきい値に達するまで待機してから、局所性制約を次のレベルに緩和します。しきい値は次のプロパティで構成できます。

プロパティ 説明
yarn.scheduler.capacity.node-locality-delay CapacitySchedulerがラックローカルコンテナのスケジュールを試みるまでの、スケジュール機会の失敗数。通常、これはクラスタ内のノード数に設定する必要があります。デフォルトでは、1つのラック内のノード数（約40）に設定されています。正の整数の値が必要です。
yarn.scheduler.capacity.rack-locality-additional-delay CapacitySchedulerがオフスイッチコンテナのスケジュールを試みるまでの、node-locality-delayを超える追加のスケジュール機会の失敗数。デフォルトではこの値は-1に設定されており、この場合、オフスイッチコンテナの割り当て機会の失敗数は、L * C / Nという式に基づいて計算されます。ここで、Lはリソース要求に指定された場所（ノードまたはラック）の数、Cは要求されたコンテナの数、Nはクラスタのサイズです。

YARNがファイルシステムとは別にデプロイされている場合、局所性は意味がないため、この機能を無効にする必要があります。これは、yarn.scheduler.capacity.node-locality-delayを-1に設定することで行うことができます。この場合、リクエストの局所性制約は無視されます。

  • ノードマネージャーハートビートごとのコンテナ割り当て

CapacityScheduler は、各ノードマネージャーのハートビートで割り当てることができるコンテナ数を制御するための次のパラメーターをサポートしています。これらのパラメーターは、yarn rmadmin -refreshQueues を介して更新可能です。

プロパティ 説明
yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled 1つのノードマネージャーハートビートで複数のコンテナ割り当てを許可するかどうか。デフォルトはtrueです。
yarn.scheduler.capacity.per-node-heartbeat.maximum-container-assignments multiple-assignments-enabledがtrueの場合、1つのノードマネージャーハートビートで割り当てることができるコンテナの最大数。デフォルト値は100で、ハートビートごとのコンテナ割り当ての最大数を100に制限します。この値を-1に設定すると、この制限は無効になります。
yarn.scheduler.capacity.per-node-heartbeat.maximum-offswitch-assignments multiple-assignments-enabledがtrueの場合、1つのノードマネージャーハートビートで割り当てることができるオフスイッチコンテナの最大数。デフォルトは1で、1つのハートビートで許可されるオフスイッチ割り当ては1つだけです。

CapacitySchedulerの構成の確認

インストールと構成が完了したら、YARNクラスタをWeb UIから起動した後に確認できます。

  • 通常の方法でYARNクラスタを起動します。

  • ResourceManager Web UIを開きます。

  • /scheduler Webページには、個々のキューのリソース使用状況が表示されます。

キュー構成の変更

キュー/スケジューラプロパティの変更、およびキューの追加/削除は、ファイルまたはAPIの2つの方法で行うことができます。この動作は、yarn-site.xml内のyarn.scheduler.configuration.store.classで変更できます。可能な値は、ファイルによるプロパティの変更を許可するfile、APIによるプロパティの変更を許可するが、再起動を跨いで変更を保持しないmemory、APIによるプロパティの変更を許可し、変更をleveldbバックエンドストアに保存するleveldb、およびAPIによるプロパティの変更を許可し、変更をZooKeeperバックエンドストアに保存するzkです。デフォルト値はfileです。

ファイルによるキュー構成の変更

ファイルで編集するには、conf/capacity-scheduler.xmlを編集し、yarn rmadmin -refreshQueuesを実行する必要があります。

$ vi $HADOOP_CONF_DIR/capacity-scheduler.xml
$ $HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues

ファイルによるキューの削除

ステップ1：キューを停止する

リーフキューを削除する前に、リーフキューには実行中/保留中のアプリケーションがなく、yarn.scheduler.capacity.<queue-path>.stateを変更することで停止する必要があります。[キュー管理と権限](CapacityScheduler.html#Queue Properties)セクションを参照してください。親キューを削除する前に、そのすべての子キューには実行中/保留中のアプリケーションがなく、停止する必要があります。親キューも停止する必要があります。

ステップ2：キューを削除する

ファイルからキュー構成を削除し、上記のようにリフレッシュを実行します。

APIによるキュー構成の変更

APIによる編集では、スケジューラ構成のバックエンドストアを使用します。これを有効にするには、yarn-site.xmlで次のパラメーターを構成できます。

注：この機能はアルファ段階であり、変更される可能性があります。

プロパティ 説明
yarn.scheduler.configuration.store.class 使用するバックエンドストアの種類。上記を参照してください。
yarn.scheduler.configuration.mutation.acl-policy.class どのユーザーがどのキューを変更できるかを制限するためのACLポリシーを構成できます。デフォルト値はorg.apache.hadoop.yarn.server.resourcemanager.scheduler.DefaultConfigurationMutationACLPolicyで、YARN管理者のみが構成変更を行うことができます。別の値はorg.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.conf.QueueAdminConfigurationMutationACLPolicyで、呼び出し元がキューの管理者である場合にのみキューの変更が許可されます。
yarn.scheduler.configuration.store.max-logs leveldbまたはZooKeeperを使用している場合、構成の変更はバックエンドストアに監査ログとして記録されます。この構成は、保存する監査ログの最大数を制御し、超過した場合は最も古いログを削除します。デフォルトは1000です。
yarn.scheduler.configuration.leveldb-store.path leveldbを使用する場合の構成ストアのストレージパス。デフォルト値は${hadoop.tmp.dir}/yarn/system/confstoreです。
yarn.scheduler.configuration.leveldb-store.compaction-interval-secs leveldbを使用する場合、構成ストアを圧縮する間隔（秒単位）。デフォルト値は86400、つまり1日です。
yarn.scheduler.configuration.zk-store.parent-path ZooKeeperを使用する場合の構成ストア関連情報のZooKeeperルートノードパス。デフォルト値は/confstoreです。

注：yarn.scheduler.configuration.store.classを使用してスケジューラ構成の変更を有効にすると、yarn rmadmin -refreshQueuesは無効になります。つまり、ファイルによる構成の更新はできなくなります。

スケジューラ設定の変更方法の例については、REST を使用した方法についてはYARN リソースマネージャ REST API を、コマンドラインを使用した方法についてはYARN コマンドリファレンス を参照してください。

コンテナの更新 (実験的 - API は将来変更される可能性があります)

アプリケーションマスターは、リソースマネージャからコンテナを受信すると、リソースマネージャに対してコンテナの特定の属性の更新を要求できます。

現在、サポートされているコンテナ更新の種類は2種類のみです。

  • リソース更新: AM は、RM に対してコンテナのリソースサイズを更新するよう要求できます。たとえば、2GB、2 vcore のコンテナを 4GB、2 vcore のコンテナに変更します。
  • 実行タイプ更新: AM は、RM に対してコンテナの実行タイプを更新するよう要求できます。たとえば、実行タイプをGUARANTEEDからOPPORTUNISTICに変更したり、その逆も可能です。

これは、AM がAllocateRequestProto内のupdated_containersフィールド（UpdateContainerRequestProto型のリスト）に入力することで実現されます。AM は、同じ割り当て呼び出しで複数のコンテナ更新要求を行うことができます。

UpdateContainerRequestProtoのスキーマは以下のとおりです。

message UpdateContainerRequestProto {
  required int32 container_version = 1;
  required ContainerIdProto container_id = 2;
  required ContainerUpdateTypeProto update_type = 3;
  optional ResourceProto capability = 4;
  optional ExecutionTypeProto execution_type = 5;
}

ContainerUpdateTypeProtoは列挙型です。

enum ContainerUpdateTypeProto {
  INCREASE_RESOURCE = 0;
  DECREASE_RESOURCE = 1;
  PROMOTE_EXECUTION_TYPE = 2;
  DEMOTE_EXECUTION_TYPE = 3;
}

上記の列挙型によって制約されているように、スケジューラは現在、1つの更新要求でコンテナのリソース更新または実行タイプのいずれかの変更をサポートしています。

AM は、RM から受信した最新のContainerProtoも提供する必要があります。これは、RM が更新を試みるコンテナです。

RM が要求されたコンテナを更新できた場合、更新されたコンテナは、同じ割り当て呼び出しまたは後続の呼び出しのいずれかのAllocateResponseProto戻り値のupdated_containersリストフィールド（UpdatedContainerProto型）で返されます。

UpdatedContainerProtoのスキーマは以下のとおりです。

message UpdatedContainerProto {
  required ContainerUpdateTypeProto update_type = 1;
  required ContainerProto container = 2;
}

コンテナに対して実行されたコンテナ更新の種類と、更新されたトークンを含む更新されたコンテナオブジェクトを指定します。

コンテナトークンは、その後、AM が対応する NM に対して、コンテナがまだ開始されていない場合はコンテナの開始、または更新されたトークンを使用してコンテナの更新を要求するために使用できます。

DECREASE_RESOURCEおよびDEMOTE_EXECUTION_TYPEコンテナ更新は自動的です。AM は、コンテナのリソースを明示的に減らすよう NM に要求する必要はありません。他の更新タイプでは、AM が NM に対してコンテナの更新を明示的に要求する必要があります。

yarn.resourcemanager.auto-update.containers設定パラメータがtrueに設定されている場合（デフォルトはfalse）、RM はすべてのコンテナ更新が自動的に行われるようにします。

アクティビティ

スケジューリングアクティビティは、重要なスケジューリングパスでのデバッグに使用されるアクティビティメッセージです。これらは記録され、スケジューラの性能への影響を最小限に抑えてRESTful APIを介して公開できます。現在、サポートされているアクティビティの種類は2種類あります。「スケジューラアクティビティ」と「アプリケーションアクティビティ」です。

スケジューラアクティビティ

スケジューラアクティビティには、スケジューリングサイクルで役立つスケジューリング情報が含まれており、スケジューラがどのようにコンテナを割り当てるかを示しています。スケジューラアクティビティREST API（http://rm-http-address:port/ws/v1/cluster/scheduler/activities）は、スケジューラアクティビティの記録を有効にし、キャッシュから取得する方法を提供します。パフォーマンスへの影響を排除するために、スケジューラはスケジューリングサイクルの終了時にアクティビティの記録を自動的に無効にします。最新のスケジューラアクティビティを取得するには、RESTful APIを再度クエリできます。

クエリパラメータ、出力構造、およびスケジューラアクティビティの例については、YARN リソースマネージャ REST APIを参照してください。

アプリケーションアクティビティ

アプリケーションアクティビティには、指定されたアプリケーションの役に立つスケジューリング情報が含まれており、要件がどのように満たされたか、またはスキップされたかを示します。アプリケーションアクティビティREST API（http://rm-http-address:port/ws/v1/cluster/scheduler/app-activities/{appid}）は、数秒以内に指定されたアプリケーションのアプリケーションアクティビティの記録を有効にしたり、キャッシュから履歴のアプリケーションアクティビティを取得したりする方法を提供します。「refresh」と「get」を含む利用可能なアクションは、「actions」パラメータで指定できます。

  • 「actions=refresh」パラメータでクエリを実行すると、指定されたアプリケーションのアプリケーションアクティビティの記録が一定時間（デフォルトは3秒）有効になり、次のようなシンプルな応答が得られます。{“appActivities”:{“applicationId”:“application_1562308866454_0001”,“diagnostic”:“Successfully received action: refresh”,“timestamp”:1562308869253,“dateTime”:“Fri Jul 05 14:41:09 CST 2019”}}。
  • 「actions=get」パラメータでクエリを実行しても記録は有効になりませんが、キャッシュから履歴のアプリケーションアクティビティが直接取得されます。
  • actionsパラメータが指定されていない場合、デフォルトのアクションは「refresh,get」であり、「refresh」と「get」の両方が実行されます。

クエリパラメータ、出力構造、およびアプリケーションアクティビティの例については、YARN リソースマネージャ REST APIを参照してください。

設定

CapacitySchedulerは、スケジューラ/アプリケーションアクティビティのキャッシュサイズと有効期限を制御するための以下のパラメータをサポートしています。

プロパティ 説明
yarn.resourcemanager.activities-manager.cleanup-interval-ms アクティビティのクリーンアップ間隔（ミリ秒単位）。デフォルトは5000です。
yarn.resourcemanager.activities-manager.scheduler-activities.ttl-ms スケジューラアクティビティの存続時間（ミリ秒単位）。デフォルトは600000です。
yarn.resourcemanager.activities-manager.app-activities.ttl-ms アプリケーションアクティビティの存続時間（ミリ秒単位）。デフォルトは600000です。
yarn.resourcemanager.activities-manager.app-activities.max-queue-length アプリケーションアクティビティの最大キューの長さ。デフォルトは100です。

Web UI

アクティビティ情報は、RM Web UIのアプリケーション試行ページで確認できます。未処理の要求がまとめて表示されます。最新の活動情報を得るには、更新ボタンをクリックするだけです。