翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# バージョン 3.8.0 の Slurm 動的ノード割り当て戦略
<a name="scheduler-node-allocation-v3-3.8.0"></a>

ParallelCluster は、バージョン 3.8.0 以降、**ジョブレベルの再開**または**ジョブレベルのスケーリング**をデフォルトの動的ノード割り当て戦略として使用してクラスターをスケールします。ParallelCluster は、各ジョブの要件、ジョブに割り当てられたノードの数、再開する必要があるノードに基づいてクラスターをスケールアップします。ParallelCluster は、この情報を SLURM\$1RESUME\$1FILE 環境変数から取得します。

動的ノードのスケーリングプロセスは、Amazon EC2 インスタンスを起動するステップと、起動した EC2 インスタンスを Slurm ノードに割り当てるステップの 2 つで構成されます。これら 2 つのステップは、どちらも**オールオアナッシング**ロジックまたは**ベストエフォート**ロジックを使用して実行できます。

Amazon EC2 インスタンスを起動する場合:
+ **オールオアナッシング**では、最小ターゲット容量が合計ターゲット容量に等しい場合に Amazon EC2 API を起動します。
+ **ベストエフォート**では、最小ターゲット容量が 1 に等しく、合計ターゲット容量がリクエスト容量に等しい場合に Amazon EC2 API を起動します。

Amazon EC2 インスタンスを Slurm ノードに割り当てる場合:
+ **オールオアナッシング**では、リクエストされたすべての Slurm ノードに Amazon EC2 インスタンスを割り当てることができる場合にのみ、Amazon EC2 インスタンスをノードに割り当てます。
+ **ベストエフォート**では、リクエストされたすべての Slurm ノードを Amazon EC2 インスタンス容量でカバーできない場合でも、Amazon EC2 インスタンスをノードに割り当てます。

  上の戦略の可能な組み合わせが、ParallelCluster の起動戦略になります。

**Example**  [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)

**オールオアナッシング**のスケーリング:

この戦略では、ジョブごとに Amazon EC2 起動インスタンス API コール AWS ParallelCluster を開始し、リクエストされたコンピューティングノードが正常に起動するために必要なすべてのインスタンスが必要です。ジョブごとの必要な容量が利用可能な場合にのみクラスターがスケールするため、スケーリングプロセスの最後にアイドルインスタンスが残ることはありません。

この戦略では、ジョブごとに Amazon EC2 インスタンスを起動するのに**オールオアナッシング**ロジックを使用するとともに、Amazon EC2 インスタンスを Slurm ノードに割り当てるのにも**オールオアナッシング**ロジックを使用します。

戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。リクエストが複数のコンピューティングリソースにまたがる場合や、500 ノードを超える場合、ParallelCluster は複数のバッチを使用して順次処理します。

いずれかのリソースのバッチに障害が発生すると、すべての関連する未使用の容量が終了するため、スケーリングプロセスの終了時にアイドルインスタンスは残りません。

制限事項
+ スケーリングにかかる時間は、Slurm 再開プログラムの実行ごとに送信されるジョブの数に正比例します。
+ スケーリングオペレーションは、デフォルトで 1,000 インスタンスに設定されている、RunInstances リソースアカウントの上限によって制限されます。この制限は、 AWSの EC2 API スロットリングポリシーに準拠しています。詳細については、[Amazon EC2 API スロットリングドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)」を参照してください。
+ 単一のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の EC2 起動 API コールは、すべての容量を単一のアベイラビリティーゾーンで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、単一のアベイラビリティーゾーンのキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールは、すべての容量を単一のインスタンスタイプで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールはサポートされず、ParallelCluster は代わりに**ベストエフォート**のスケーリングを実行します。

**貪欲なオールオアナッシング**のスケーリング:

このオールオアノッシング戦略のバリアントは、ジョブごとの必要な容量が利用可能な場合にのみクラスターをスケールし、スケーリングプロセスの最後にアイドルインスタンスが残らないようにする点は同じですが、ParallelCluster が開始する Amazon EC2 起動インスタンス API コールでは、最小ターゲット容量を 1 とし、リクエストされた容量までノードの起動数を最大化しようとします。この戦略では、すべてのジョブで EC2 インスタンスを起動するためにベストエフォートロジックを使用するとともに、ジョブごとに Amazon EC2 インスタンスを Slurm ノードに割り当てるためにも**オールオアノッシング**ロジックを使用します。

戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。複数のコンピューティングリソースにまたがるリクエスト、または 500 ノードを超えるリクエストの場合、ParellelCluster は複数のバッチを順次処理します。

これにより、スケーリングプロセス中に一時的なオーバースケーリングが発生してもスループットを最大化することで、スケーリングプロセスの最後にアイドルインスタンスが残らないようにします。

制限事項
+ 一時的なオーバースケーリングが発生し、スケーリングの完了前にインスタンスが実行中の状態に移行した場合は追加コストが発生することがあります。
+ all-or-nothing戦略と同じインスタンス制限が適用されます。ただし、 AWSの RunInstances リソースアカウント制限が適用されます。

**ベストエフォート**のスケーリング:

この戦略で開始する Amazon EC2 起動インスタンス API コールでは、最小容量を 1 とし、リクエストされた容量のすべてには対応できずにアイドルインスタンスがスケーリングプロセスの実行後に残るとしても、リクエストされた合計容量を達成しようとします。この戦略では、すべてのジョブで Amazon EC2 インスタンスを起動するためにベストエフォートロジックを使用するとともに、ジョブごとに Amazon EC2 インスタンスを Slurm ノードに割り当てるためにも**ベストエフォート**ロジックを使用します。

戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。リクエストが複数のコンピューティングリソースにまたがる場合や、500 ノードを超える場合、ParallelCluster は複数のバッチを使用して順次処理します。

この戦略では、さまざまなスケーリングプロセスでアイドルインスタンスが発生するとしても、複数のスケーリングプロセスの実行に対するデフォルトの 1,000 インスタンスの制限をはるかに超えてスケーリングできます。

制限事項
+ ジョブがリクエストしているノードの一部を割り当てることができない場合、スケーリングプロセスの最後にアイドル状態のインスタンスが発生する可能性があります。

**ParallelCluster 起動戦略**別に動的ノードのスケーリングがどのように動作するかについて、以下に例を示します。2 つのジョブを送信し、同じタイプのノードをそれぞれ 20 個、合計 40 個リクエストしたとします。しかし、リクエストした容量をカバーするために EC2 で利用できる Amazon EC2 インスタンスは 30 個のみです。

**オールオアナッシング**のスケーリング: 
+ 最初のジョブでは、**オールオアナッシング**の Amazon EC2 起動インスタンス API を呼び出し、20 個のインスタンスをリクエストします。呼び出しは成功して、20 個のインスタンスが起動します。
+ 最初のジョブでは、起動した 20 個のインスタンスを Slurm ノードに割り当てる**オールオアナッシング**ロジックも成功します。
+ 2 番目のジョブで、別の**オールオアナッシング**の Amazon EC2 起動インスタンス API を呼び出し、20 個のインスタンスをリクエストします。10 個のインスタンスの容量しか残っていないため、この呼び出しは失敗します。この時点ではインスタンスは起動されません

**貪欲なオールオアナッシング**のスケーリング:
+ **ベストエフォート**の Amazon EC2 起動インスタンス API を呼び出し、40 個のインスタンスをリクエストします。これは、すべてのジョブがリクエストしている合計容量です。結果として、30 個のインスタンスが起動します。
+ 最初のジョブで、起動したインスタンスのうち 20 個を Slurm ノードに割り当てる**オールオアナッシング**ロジックは成功します。
+ 2 番目のジョブでは、起動した残りのインスタンスを Slurm ノードに割り当てる別の**オールオアナッシング**ロジックを試行しますが、ジョブがリクエストしている合計 20 個に対して利用可能なインスタンスは 10 個しかないため、割り当ては失敗します。
+ 割り当てられない 10 個の起動済みインスタンスは終了します。

**ベストエフォート**のスケーリング:
+ **ベストエフォート**の Amazon EC2 起動インスタンス API を呼び出し、40 個のインスタンスをリクエストします。これは、すべてのジョブがリクエストしている合計容量です。結果として、30 個のインスタンスが起動します。
+ 最初のジョブで、起動した 20 個のインスタンスを Slurm ノードに割り当てる**ベストエフォート**ロジックが成功します。
+ 2 番目のジョブで、起動した残りの 10 個のインスタンスを Slurm ノードに割り当てる別の**ベストエフォート**ロジックは、リクエストされた合計容量が 20 個であっても、成功します。ただし、ジョブは 20 個のノードをリクエストしており、そのうちの 10 個のみに Amazon EC2 インスタンスを割り当てることができたため、スケーリングプロセスの今後のコールで欠落している 10 個のインスタンスを起動するのに十分な容量が見つかるか、スケジューラが他の既に実行中のコンピューティングノードでジョブをスケジュールするまで、ジョブは開始できず、インスタンスはアイドル状態のままになります。