バージョン 3.8.0 の Slurm 動的ノード割り当て戦略

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

動的ノードのスケーリングプロセスは、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 の起動戦略になります。

The available ParallelCluster 起動戦略 that can be set into the ScalingStrategy cluster configuration to be used with ジョブレベルのスケーリング are:

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

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

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

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

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

制限

• スケーリングにかかる時間は、Slurm 再開プログラムの実行ごとに送信されるジョブの数に正比例します。

• スケーリングオペレーションは、デフォルトで 1,000 インスタンスに設定されている、RunInstances リソースアカウントの上限によって制限されます。この制限は、 AWSの EC2 API スロットリングポリシーに準拠しています。詳細については、Amazon EC2 API スロットリングドキュメント」を参照してください。

• 単一のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、オールオアナッシングの 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 個のインスタンスを起動するのに十分な容量が見つかるか、スケジューラが他の既に実行中のコンピューティングノードでジョブをスケジュールするまで、ジョブは開始できず、インスタンスはアイドル状態のままになります。