このドキュメントでは、YARN ReservationSystemの概要を簡単に説明します。
YARNのReservationSystemは、ユーザーが時間の前後（およびその間）にリソースを予約できるようにすることで、重要なプロダクションジョブを非常に予測可能な方法で実行できるようにします。ReservationSystemは慎重なアドミッションコントロールを実行し、（クラスタサイズの%ではなく）絶対的なリソース量に関する保証を提供します。予約は、可変的であるか、またはギャングセマンティクスを持つことができ、時間によって変化するリソース要件を持つことができます。ReservationSystemはYARN ResourceManagerのコンポーネントです。
上の図を参照して、典型的な予約は次の手順で進みます。
ステップ0 ユーザー（またはその代理で自動化されたツール）は予約作成リクエストを送信し、ReservationIdを含むレスポンスを受け取ります。
ステップ1 ユーザー（またはその代理で自動化されたツール）は、Reservation Definition Language（RDL）と前のステップで取得したReservationIdで指定された予約リクエストを送信します。これは、時間経過に伴うユーザーのリソースニーズ（例：リソースのスカイライン）と時間的制約（例：期限）を記述します。これは、通常のクライアントからRMへのプロトコルを介してプログラム的に、またはRMのREST APIを介して行うことができます。同じReservationIdで、RDLが同じである予約が送信された場合、新しい予約は作成されず、リクエストは成功します。RDLが異なる場合、予約は拒否され、リクエストは失敗します。
ステップ2 ReservationSystemは、ReservationAgent（図のGREE）を利用して、Plan内での予約の妥当な割り当てを見つけます。Planは、現在受け入れられているすべての予約とシステム内の利用可能なリソースを追跡するデータ構造です。
ステップ3 SharingPolicyは、受け入れられる予約に対して不変条件を適用し、予約を拒否する可能性のある方法を提供します。たとえば、CapacityOvertimePolicyを使用すると、ユーザーがすべての予約で要求できる瞬間的な最大容量と、期間にわたるリソースの積分の制限の両方を適用できます。たとえば、ユーザーは瞬間的にクラスタ容量の最大50%を予約できますが、24時間以内では平均10%を超えることはできません。
ステップ4 有効な検証が完了すると、ReservationSystemはユーザーにReservationId（航空券のようなもの）を返します。
ステップ5 時が来ると、PlanFollowerと呼ばれる新しいコンポーネントが、動的にキューを作成/調整/削除することで、プランの状態をスケジューラに公開します。
ステップ6 ユーザーは、ApplicationSubmissionContextの一部としてReservationIdを含めるだけで、予約可能なキューに1つ以上のジョブを送信できます。
ステップ7 スケジューラは、リソースの予約が尊重されるように作成された特別なキューからコンテナを提供します。予約の制限内では、ユーザーはリソースへのアクセスを保証されます。それ以上のリソース共有は、標準的なCapacity/Fairness共有で進みます。
ステップ8 システムには、クラスタ容量の低下に適応するメカニズムが含まれています。これには、可能な場合は予約を「移動」するか、以前に受け入れられた予約の最小量を拒否する（他の予約が全量を受け取るようにするため）ことで再計画することが含まれます。
ReservationSystemの設定は簡単です。現在、CapacitySchedulerとFairSchedulerの両方で予約のサポートを追加しました。capacity-scheduler.xmlまたはfair-scheduler.xmlの任意のリーフキューを「予約」に使用できるようにマークできます（詳細については、CapacitySchedulerとFairSchedulerを参照してください）。その後、そのキュー内の容量/フェアシェアを使用して予約を行うことができます。ジョブは予約なしで予約可能なキューに送信することもできます。その場合、アクティブな予約内で実行されているジョブによって残された容量で、ベストエフォートモードで実行されます。