• 原文: http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/FairScheduler.html
• バージョン: 3.0.0-alpha1
• ライセンス: Apache License

目的

このドキュメントでは、Hadoop用のプラガブルスケジューラであるFairSchedulerについて説明します。このスケジューラは、YARNアプリケーションが大規模なクラスタでリソースを公平に共有できるようにします。

イントロダクション

フェアスケジューリングは、すべてのアプリケーションが平均して同じリソースの時間を共有するように、アプリケーションにリソースを割り当てる方法です。Hadoop NextGenは、複数のリソースタイプのスケジューリングが可能です。デフォルトでは、フェアスケジューラはスケジューリングフェアネス決定をメモリのみに基づいて行います。Ghodsiらによって開発されたDominant Resource Fairnessの概念を使用して、メモリとCPUの両方でスケジュールを設定することもできます。実行中のアプリケーションが1つだけある場合、そのアプリケーションはクラスタ全体を使用します。他のアプリが送信されると、解放されたリソースが新しいアプリに割り当てられ、最終的に各アプリはほぼ同じ量のリソースを取得します。アプリを一つのキューに並べるデフォルトのHadoopスケジューラとは異なり、短いアプリが妥当な時間で終了しつつも、長寿命のアプリがリソース不足に陥ることはありません。また、多数のユーザー間でクラスタを共有することも合理的な方法です。 最後に、公平な共有は、アプリの優先順位でも機能します。優先順位は、各アプリが取得すべき総リソースの割合を決定するための重みとして使用されます。

スケジューラはアプリケーションをいくつかの「キュー」にまとめ、これらのキュー間でリソースを公平に共有します。 デフォルトでは、すべてのユーザーが「default」という単一のキューを共有しますが、アプリケーションがコンテナリソース要求内のキューを具体的にリストしていれば、要求はそのキューに送信されます。 また、構成を介して要求に含まれるユーザー名に基づいてキューを割り当てることもできます。 各キュー内では、実行中のアプリケーション間でリソースを共有するためにスケジューリングポリシーが使用されます。 デフォルトはメモリベースの公平な共有ですが、Dominant Resource Fairnessを持つFIFOとマルチリソースも設定できます。 キューを階層化してリソースを分割し、ウェイトを設定してクラスタを特定の割合で共有することができます。

公正な共有を提供することに加えて、フェアスケジューラでは保証された最小の共有をキューに割り当てることができ、特定のユーザー、グループまたは本番アプリケーションが常に十分なリソースを確保するのに役立ちます。 キューにアプリが含まれている場合、少なくとも最小シェアを獲得しますが、キューに完全保証されたシェアが必要ない場合、超過分は実行中の他のアプリケーションに分割されます。 これにより、スケジューラはキューの容量を保証し、これらのキューにはアプリケーションが含まれていない場合にリソースを効率的に利用できます。

フェアスケジューラは、デフォルトではすべてのアプリケーションを実行しますが、configファイルを使用して、実行中のアプリを実行するアプリ数をユーザごとおよびキューごとに制限することもできます。 これは、一度に何百ものアプリケーションを送信しなければならない時に便利です。より一般的には、一度に多数のアプリケーションを実行することによって、中間データが非常に多く生成されたりコンテキスト切り替えが多すぎたりしてしまうといった場合に、パフォーマンスを向上させるために役立ちます。 アプリケーションを制限しても、その後に送信されたアプリケーションは失敗することはなく、ユーザーの以前のアプリが終了するまでスケジューラーのキューで待機するだけです。

プラガブルなポリシーを持つ階層キュー

フェアスケジューラは、階層型キューをサポートしています。 すべてのキューは、「root」という名前のキューから発生します。 利用可能なリソースは、典型的なフェアスケジューリング方式でrootキューの子に分散されます。 次に、子キュー達は、同じ方法で子キューに割り当てられたリソースを配布します。 アプリケーションはリーフキューでのみスケジュールすることができます。 キューは、フェアスケジューラ割り当てファイルに親のサブ要素として配置することによって、他のキューの子として指定することができます。

待ち行列の名前は、親の名前で始まり、ピリオドを区切り文字とします。 したがって、rootキューの下の「queue1」という名前のキューは「root.queue1」と呼ばれ、「parent1」という名前のキューの下の「queue2」という名前のキューは「root.parent1.queue2」と呼ばれます。 キューを参照する場合、名前のroot部分はオプションなので、queue1は単に「queue1」と呼ばれ、queue2は単に「parent1.queue2」と呼ばれます。

さらに、フェアスケジューラでは、各キューに異なるカスタムポリシーを設定して、ユーザーがどのような方法でキューのリソースを共有できるようにすることができます。 カスタムポリシーは、org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicyを拡張することで構築できます。 FifoPolicy、FairSharePolicy（デフォルト）、DominantResourceFairnessPolicyは組み込みであり、簡単に使用できます。

元の（MR1）フェアスケジューラに存在していた特定のアドオンはまだサポートされていません。 その中で、特定のアプリを優先的に "強化"するカスタムポリシーの使用があります。

キューにアプリケーションを自動的に配置する

フェアスケジューラを使用すると、管理者は送信されたアプリケーションを適切なキューに自動的に配置するポリシーを構成できます。 配置は、サブミッターのユーザーおよびグループ、およびアプリケーションによって渡される要求されたキューに依存する可能性があります。 ポリシーは、投入されるアプリケーションを分類するために順番に適用される一連のルールで構成されます。 各ルールは、アプリをキューに入れたり、拒否したり、次のルールに進みます。 これらのポリシーの設定方法については、以下の割り当てファイル形式を参照してください。

インストール

フェアスケジューラを使用するには、まず、yarn-site.xmlで適切なスケジューラクラスを割り当てます。

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

設定

フェアスケジューラをカスタマイズするには、通常、2つのファイルを変更する必要があります。 まず、スケジューラ全体のオプションは、既存のコンフィグレーションディレクトリのyarn-site.xmlファイルにコンフィグレーションプロパティを追加することで設定できます。 第2に、ほとんどの場合、ユーザは、どのキューが存在するか、それぞれの重みと容量を列挙した割り当てファイルを作成したいと思うでしょう。 アロケーションファイルは10秒ごとにリロードされ、その場で変更が行われます。

yarn-site.xmlに配置できるプロパティ

割り当てファイル形式

割り当てファイルはXML形式でなければなりません。 フォーマットには、5種類の要素が含まれています。

queue要素

キューを表します。queue要素はオプションの属性 'type'を取ることができます。これは、 'parent'に設定すると、親キューになります。 リーフキューを設定せずに親キューを作成する場合に便利です。 各queue要素には、次のプロパティが含まれます。

• minResources: 「X mb、Y vcores」の形式で、キューが資格を与えられる最小限のリソース。 単一リソース公平性ポリシーの場合、vcores値は無視されます。 キューの最小共有が満たされない場合、同じ親の下にある他のキューの前に使用可能なリソースが提供されます。 単一リソース公平ポリシーのもとでは、キューのメモリ使用量が最小メモリシェアよりも小さい場合、キューは不満とみなされます。 支配的なリソース公平性の下では、クラスタ容量に対する支配的なリソースの使用率がそのリソースの最小のシェアよりも低い場合、キューは満たされていないとみなされます。 この状況で複数のキューが満たされない場合、リソースは、関連リソースの使用率と最小値の最小の比率でキューに移動します。 すでに実行されているジョブがこれらのリソースを使用している可能性があるため、アプリケーションがサブミットするときに、最小値を下回るキューが最小値に達しないことがあります。
• maxResources： "X mb、Y vcores"の形式でキューが許可される最大リソース。 キューには、この制限を超える集約使用率を設定するコンテナは割り当てられません。
• maxChildResources： "X mb、Y vcores"の形式で、アドホックな子キューが許可される最大リソース。 このプロパティセットを持つキューの直接の子である任意のアドホックキューには、それに応じてmaxResourcesプロパティが設定されます。
• maxRunningApps：キューからのアプリケーションの数を一度に制限します。
• maxAMShare：アプリケーションマスターを実行するために使用できるキューの公平なシェアの割合を制限します。 このプロパティは、リーフキューに対してのみ使用できます。 たとえば、1.0fに設定すると、リーフ・キュー内のAMは、メモリーとCPUのフェア・シェアの両方を100％使用することができます。 -1.0fの値はこの機能を無効にし、amShareはチェックされません。 デフォルト値は0.5fです。
• weight：クラスタを他のキューと非比例で共有する。 デフォルトのウェイトは1に設定され、ウェイト2のキューはデフォルトウェイトのキューの約2倍のリソースを受信します。
• schedulingPolicy：任意のキューのスケジュールポリシーを設定します。 指定できる値は、 "fifo" / "fair" / "drf"またはorg.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicyを継承する任意のクラスです。 デフォルトは "fair"です。 "fifo"の場合は、より早い提出時間を持つアプリケーションにコンテナが優先されますが、以前のアプリの要求を満たした後にクラスタに残っているスペースがあると、後で提出されるアプリケーションが同時に実行されます。
• aclSubmitApps：キューにアプリケーションを送信できるユーザーおよび/またはグループのリスト。 このリストの形式とキューACLの仕組みの詳細については、以下のACLセクションを参照してください。
• aclAdministerApps：キューを管理できるユーザーおよび/またはグループのリスト。 現在、唯一の管理アクションはアプリケーションを強制終了することです。 このリストの形式とキューACLの仕組みの詳細については、以下のACLセクションを参照してください。
• minSharePreemptionTimeout：他のキューからリソースを取得するためにコンテナをプリエンプトしようとする前に、キューが最小シェアの下にある秒数。 設定されていない場合、キューはその親キューから値を継承します。
• fairSharePreemptionTimeout：他のキューからリソースを取得するためにコンテナをプリエンプトしようとする前に、キューが公平な共有のしきい値を下回っている秒数。 設定されていない場合、キューはその親キューから値を継承します。
• fairSharePreemptionThreshold：キューの公平な共有優先しきい値。 キューがfairSharePreemptionThreshold * fairShareリソースを受け取らずにfairSharePreemptionTimeoutを待つ場合、他のキューからリソースを取るようにコンテナをプリエンプトすることができます。 設定されていない場合、キューはその親キューから値を継承します。

user要素

個々のユーザーの動作を管理する設定を表します。 それらは単一のプロパティーを含むことができます：maxRunningApps、特定のユーザーの実行中のアプリ数の制限。

userMaxAppsDefault要素

制限が特に指定されていないユーザーのデフォルトの実行中のアプリの制限を設定します。

defaultFairSharePreemptionTimeout要素

ルートキューのフェアシェアプリエンプションタイムアウトを設定します。ルートキューのfairSharePreemptionTimeout要素によってオーバーライドされます。

defaultMinSharePreemptionTimeout要素

ルートキューの最小共有プリエンプションタイムアウトを設定します。ルートキューのminSharePreemptionTimeout要素によってオーバーライドされます。

defaultFairSharePreemptionThreshold要素

ルートキューの公平共有優先閾値を設定します。ルートキューのfairSharePreemptionThreshold要素によってオーバーライドされます。

queueMaxAppsDefault要素

キューのデフォルトの実行中のアプリケーション制限を設定します。各キューのmaxRunningApps要素によってオーバーライドされます。

queueMaxResourcesDefault要素

キューのデフォルトの最大リソース制限を設定します。各キューのmaxResources要素によってオーバーライドされます。

queueMaxAMShareDefault要素

キューのデフォルトのAMリソース制限を設定します。各キュー内のmaxAMShare要素によってオーバーライドされます。

defaultQueueSchedulingPolicy要素

キューのデフォルトスケジューリングポリシーを設定します。 指定されている場合は、各キューのschedulingPolicy要素によってオーバーライドされます。 デフォルトは "fair"です。

queuePlacementPolicy要素

スケジューラに、送信されてくるアプリケーションをキューに配置する方法を通知するルール要素のリストを含む要素。 ルールは、リストされている順に適用されます。 ルールは引数を取るかもしれません。 すべてのルールは、ルールが新しいキューを作成できるかどうかを示す "create"引数を受け入れます。 "Create"のデフォルトはtrueです。 falseに設定されている場合、ルールは割り当てファイルで設定されていないキューにアプリケーションを配置します。次のルールに進みます。 最後のルールは、継続を発行できないルールでなければなりません。 有効なルールは次のとおりです。

• specified：アプリケーションは要求したキューに置かれます。アプリがキューを要求しなかった場合、つまり「デフォルト」が指定されている場合は、処理を続行します。アプリがキュー名の開始または終了を要求した場合、「.q1」や「q1」などの名前は拒否されます。
• user：アプリケーションは、それを送信したユーザーの名前でキューに入れられます。ユーザー名の期間は「_ドット」で置き換えられます。つまり、ユーザー「first.last」のキュー名は「first_dot_last」です。
• primaryGroup：アプリケーションは、それを送信したユーザーのプライマリグループの名前を持つキューに配置されます。グループ名の期間は「_ドット」で置き換えられます。つまり、グループ「one.two」のキュー名は「one_dot_two」です。
• secondaryGroupExistingQueue：アプリケーションは、それを送信したユーザーのセカンダリグループと一致する名前を持つキューに配置されます。構成済みのキューと一致する最初の2次グループが選択されます。グループ名の期間は「_ドット」に置き換えられます。つまり、そのキューが存在する場合、セカンダリグループの1つとして「one.two」のユーザが「one_dot_two」キューに配置されます。
• nestedUserQueue：アプリケーションは、ネストされたルールによって提案されたキューの下にあるユーザの名前を持つキューに配置されます。これは "user"ルールがルートキューの下でのみユーザキューを作成する間、 "nestedUserQueue"ルールに違いがあり、ユーザキューは任意の親キューの下に作成できます。nestedUserQueueルールは、ネストされたルールが親キューを返す場合にのみ適用されることに注意してください。親キューを設定するには、キューの 'type'属性を 'parent'に設定するか、そのキューの下に少なくとも1つのリーフを設定してそれを親にします。サンプルユースケースのサンプル割り当てを参照してください。
• default：アプリはデフォルトルールの 'queue'属性で指定されたキューに配置されます。 'queue'属性が指定されていない場合、アプリは 'root.default'キューに配置されます。 reject：アプリは拒否されます。

ここでは、割り当てファイルの例を示します。

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>
  <queueMaxResourcesDefault>40000 mb,0vcores</queueMaxResourcesDefault>

  <!-- Queue 'secondary_group_queue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  <maxChildResources>4096 mb,4vcores</maxChildResources>
  </queue>

  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>

  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

オリジナルのFairSchedulerとの後方互換性のために、 "queue"要素の代わりに "pool"要素の名前を付けることができます。

キューアクセス制御リスト

キューアクセス制御リスト（ACL）を使用すると、管理者は特定のキューに対して誰が操作を行うかを制御できます。 それらはaclSubmitAppsおよびaclAdministerAppsプロパティーで構成され、キューごとに設定できます。 現在サポートされている唯一の管理アクションは、アプリケーションを強制終了することです。 管理者はアプリケーションをアプリケーションに提出することもできます。 これらのプロパティは、 "user1、user2 group1、group2"または "group1、group2"のような形式で値をとります。 ユーザ/グループがキューACLのメンバーである場合、またはそのキューの祖先のいずれかのキューACLのメンバーである場合、キューに対するアクションは許可されます。 したがって、queue2がqueue1内にあり、user1がqueue1のACLにあり、user2がqueue2のACLにある場合、両方のユーザーはqueue2に送信できます。

注意：区切り文字はスペース文字です。 ACLグループのみを指定するには、スペース文字で値を開始します。

ルートキューのACLはデフォルトでは「」で、ACLが渡されるため、すべてのキューにすべてのアプリケーションが送信され、強制終了される可能性があります。 アクセスの制限を開始するには、ルートキューのACLを「」以外に変更します。

予約アクセス制御リスト

予約アクセス制御リスト（ACL）により、管理者は特定のキューに対して予約操作を行うことができるユーザーを制御できます。 それらは、aclAdministerReservations、aclListReservations、およびaclSubmitReservationsプロパティーで構成され、キューごとに設定できます。 現在サポートされている管理アクションは、予約の更新と削除です。 管理者は、キュー上のすべての予約を送信して一覧表示することもできます。 これらのプロパティは、 "user1、user2 group1、group2"または "group1、group2"のような形式で値をとります。 ユーザー/グループが予約ACLのメンバーである場合、キューに対するアクションは許可されます。 どのユーザーも、自分の予約を更新、削除、または一覧表示できることに注意してください。 予約ACLが有効であるが定義されていない場合、誰もがアクセス権を持ちます。

管理

フェアスケジューラは、実行時にいくつかのメカニズムを使用して管理をサポートします。

実行時の構成の変更

割り振りファイルを編集することにより、実行時に最小限の共有、制限、重み、優先割り込みのタイムアウト、キュースケジュールポリシーを変更することができます。 スケジューラーは、ファイルが変更されたことを確認してから10〜15秒後にこのファイルをリロードします。

Web UIによる監視

現在のアプリケーション、キュー、フェアシェアは、ResourceManagerのWebインターフェイス（http：//ResourceManager URL/cluster/scheduler）で調べることができます。

Webインターフェイスの各キューには、次のフィールドがあります。

• Used Resources - キュー内のコンテナに割り当てられたリソースの合計。
• Num Active Applications - 少なくとも1つのコンテナを受け取ったキュー内のアプリケーションの数。
• Num Pending Applications - まだコンテナを受け取っていないキュー内のアプリケーションの数。
• Min Resources - キューに保証されている構成済み最小リソース。
• Max Resources - キューに許可されている構成された最大リソース。
• Instantaneous Fair Share（インスタントフェアシェア） - キューのリソースの瞬間的な公正なシェア。これらのシェアは、アクティブキュー（実行中のアプリケーションを持つキュー）のみを考慮し、スケジューリングの決定に使用されます。キューは、他のキューがそれらを使用していないときに、共有を超えてリソースを割り当てられることがあります。リソースの消費量が瞬間的な公平な配分以下にあるキューは、そのコンテナがプリエンプトされることはありません。
• Steady Fair Share - キューの安定したリソースの公正な共有。これらの共有は、アクティブかどうか（実行中のアプリケーションがあるかどうか）に関係なく、すべてのキューを考慮します。これらはあまり頻繁に計算されず、構成や容量が変更された場合にのみ変更されます。ユーザーが期待できるリソースに可視性を提供し、Web UIに表示することを意図しています。

キュー間のアプリケーションの移動

フェアスケジューラは、実行中のアプリケーションを別のキューに移動することをサポートしています。 これは、重要なアプリケーションを優先度の高いキューに移動する場合や、重要でないアプリケーションを優先度の低いキューに移動する場合に便利です。 アプリは、yarn application -movetoqueue appID -queue targetQueueName を実行することによって移動できます。

アプリケーションをキューに移動すると、既存の割り当ては、公平性を判断する目的のために古いキューではなく新しいキューの割り当てでカウントされます。 そのキューにアプリケーションのリソースを追加するとmaxRunningAppsまたはmaxResourcesの制約に違反すると、アプリケーションをキューに移動しようとすると失敗します。