翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # マルチキューモードの Slurm ガイド AWS ParallelCluster バージョン 2.9.0 では、複数のキューモードと Slurm Workload Manager () の新しいスケーリングアーキテクチャが導入されましたSlurm。 次のセクションでは、新しく導入されたスケーリングアーキテクチャを備えた Slurm クラスターを使用する際の一般的な概要を説明します。 ## 概要: 新しいスケーリングアーキテクチャは、Slurm の[「Cloud Scheduling Guide」](https://slurm.schedmd.com/elastic_computing.html)(クラウドスケジュールガイド) と省電力プラグインに基づいています。省電力プラグインの詳細については、「[Slurm Power Saving Guide](https://slurm.schedmd.com/power_save.html)」を参照してください。新しいアーキテクチャでは、クラスターで利用できる可能性のあるリソースは、通常、クラウドノードとして Slurm 設定にあらかじめ定義されています。 ## クラウドノードのライフサイクル クラウドノードはそのライフサイクルを通じて、すべてではないが以下のような状態になります。`POWER_SAVING`、`POWER_UP` (`pow_up`)、`ALLOCATED` (`alloc`)、および `POWER_DOWN` (`pow_dn`)。場合によっては、クラウドノードが `OFFLINE` 状態になることがあります。次のリストは、クラウドノードのライフサイクルにおけるこれらの状態のいくつかの側面を詳細に示しています。 + `POWER_SAVING` 状態のノードは、`sinfo` では `~` サフィックス (例: `idle~`) で表示されます。この状態では、ノードをバックアップする EC2 インスタンスは存在しません。ただし、Slurm は引き続きノードにジョブを割り当てることができます。 + `POWER_UP` 状態に遷移したノードは、`sinfo` では `#` サフィックス (例: `idle#`) で表示されます。 + Slurm が `POWER_SAVING` 状態のノードにジョブを割り当てると、そのノードは自動的に `POWER_UP` 状態に移行します。それ以外の場合は、`scontrol update nodename=nodename state=power_up` コマンドを使用して手動でノードを `POWER_UP` 状態にすることができます。この段階では、`ResumeProgram` が起動され、EC2 インスタンスが起動し、`POWER_UP` ノードをバックアップするように構成されます。 + 現在使用可能なノードは、`sinfo` にサフィックス (例: `idle`) なしで表示されます。ノードのセットアップが完了し、クラスターに参加した後、ジョブの実行が可能になります。この段階で、ノードは適切に設定され、使用可能な状態になります。原則として、EC2 のインスタンス数は利用可能なノード数と同じにすることを推奨します。通常、静的ノードはクラスター作成後、常に利用可能です。 + `POWER_DOWN` 状態に遷移しているノードは、`sinfo` に `%` サフィックス (例：`idle%`) で表示されます。動的ノードは [`scaledown_idletime`](scaling-section.md#scaledown-idletime) の後、自動的に `POWER_DOWN` 状態になります。対照的に、ほとんどの場合、静的ノードの電源はオフになりません。ただし、`scontrol update nodename=nodename state=powering_down` コマンドを使用して手動でノードを `POWER_DOWN` 状態にすることができます。この状態では、ノードに関連するインスタンスは終了し、ノードは [`scaledown_idletime`](scaling-section.md#scaledown-idletime) 後に将来使用するために `POWER_SAVING` 状態に戻されます。`scaledown-idletime` の設定は、`SuspendTimeout` の設定として Slurm のコンフィギュレーションに保存されます。 + オフラインのノードは、`sinfo` に `*` サフィックス (例: `down*`) で表示されます。Slurm コントローラーがノードにコンタクトできない場合、または静的ノードが無効化され、バッキングインスタンスが終了した場合、ノードはオフラインになります。 ここで、次の `sinfo` 例で示されるノードの状態を考えてみます。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 idle% gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 2 mix# ondemand-dy-c52xlarge-[1-2] ondemand up infinite 18 idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[1-2] ``` `spot-st-t2large-[1-2]` ノードと `efa-st-c5n18xlarge-1` ノードには、すでにバッキングインスタンスが設定されており、使用可能です。`ondemand-dy-c52xlarge-[1-2]` ノードは `POWER_UP` 状態であり、数分以内に利用可能になるはずです。`gpu-dy-g38xlarge-1` ノードは `POWER_DOWN` 状態であり、[`scaledown_idletime`](scaling-section.md#scaledown-idletime) (デフォルトは 120 秒) 後に `POWER_SAVING` 状態へ遷移します。 他のノードはすべて `POWER_SAVING` 状態で、EC2 インスタンスのバックアップはありません。 ## 使用可能なノードの操作 使用可能なノードは EC2 インスタンスによってバックアップされます。デフォルトでは、ノード名を使用してインスタンスに直接 SSH 接続することができます (例: `ssh efa-st-c5n18xlarge-1`)。インスタンスのプライベート IP アドレスは、`scontrol show nodes nodename` コマンドを使用して `NodeAddr` フィールドを確認することで取得することができます。利用できないノードについては、`NodeAddr` フィールドは稼働中の EC2 インスタンスにポイントしてはいけません。ノード名と同じにする必要があります。 ## ジョブの状態および送信 通常、送信されたジョブはすぐにシステム内のノードに割り当てられ、すべてのノードが割り当てられている場合は保留状態になります。 ジョブに割り当てられたノードに `POWER_SAVING` 状態のノードが含まれる場合、ジョブは、`CF` または `CONFIGURING` 状態で開始されます。このとき、ジョブは `POWER_SAVING` 状態のノードが `POWER_UP` 状態に遷移し、利用可能になるのを待ちます。 ジョブに割り当てられたすべてのノードが利用可能になると、`RUNNING` (`R`) 状態になります。 デフォルトでは、すべてのジョブはデフォルトのキュー (Slurm ではパーティションと呼ばれます) に送信されます。これは、キュー名の後に `*` サフィックスが付くことで示されます。`-p` ジョブ送信オプションを使用してキューを選択することができます。 すべてのノードには、ジョブ送信コマンドで使用可能な次の機能が設定されています。 + インスタンスタイプ (例: `c5.xlarge`) + ノードタイプ (`dynamic` または `static` のいずれか)。 `scontrol show nodes nodename` コマンドを使用して `AvailableFeatures` リストを確認することで、特定のノードで利用可能なすべての機能を確認することができます。 もう一つ考慮しなければならないのは、ジョブです。まず、クラスターの初期状態を考えてみましょう。`sinfo` コマンドを実行することで確認できます。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 10 idle~ gpu-dy-g38xlarge-[1-10] ondemand up infinite 20 idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[1-2] ``` なお、`spot` はデフォルトのキューです。`*` というサフィックスで表示されます。 1 つの静的ノードへのジョブをデフォルトキュー (`spot`) に送信します。 ``` $ sbatch --wrap "sleep 300" -N 1 -C static ``` ある動的ノードへのジョブを `EFA` キューに送信します。 ``` $ sbatch --wrap "sleep 300" -p efa -C dynamic ``` `c5.2xlarge` ノード 8 台、`t2.xlarge` ノード 2 台のジョブを `ondemand` キューに送信します。 ``` $ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]" ``` ある GPU ノードへのジョブを `gpu` キューに送信します。 ``` $ sbatch --wrap "sleep 300" -p gpu -G 1 ``` ここで、`squeue` コマンドを使ったジョブの状態を考えてみます。 ``` $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-g38xlarge-1 7 spot wrap ubuntu R 2:48 1 spot-st-t2large-1 8 efa wrap ubuntu R 0:39 1 efa-dy-c5n18xlarge-1 ``` ジョブ 7 と 8 (`spot` と `efa` のキュー) はすでに実行中です (`R`)。ジョブ 12 と 13 はまだ設定中 (`CF`) で、おそらくインスタンスが利用できるようになるのを待っています。 ``` # Nodes states corresponds to state of running jobs $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 3 idle~ efa-dy-c5n18xlarge-[2-4] efa up infinite 1 mix efa-dy-c5n18xlarge-1 efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 mix~ gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 10 mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] ondemand up infinite 10 idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 1 mix spot-st-t2large-1 spot* up infinite 1 idle spot-st-t2large-2 ``` ## ノードの状態および機能 ほとんどの場合、ノードの状態は、このトピックで前述したクラウドノードライフサイクルの特定のプロセス AWS ParallelCluster に従って、 によって完全に管理されます。 ただし、 は、 `DOWN`および `DRAINED`の状態の異常なノードと、異常なバッキングインスタンスを持つノード AWS ParallelCluster も置き換えまたは終了します。詳細については、「[`clustermgtd`](processes.md#clustermgtd)」を参照してください。 ## パーティションの状態 AWS ParallelCluster では、次のパーティション状態がサポートされています。Slurm パーティションは AWS ParallelClusterのキューです。 + `UP`: パーティションがアクティブ状態であることを示します。これは、パーティションのデフォルトの状態です。この状態では、パーティション内のすべてのノードがアクティブで、使用可能な状態です。 + `INACTIVE`: パーティションが非アクティブ状態であることを示す。この状態では、非アクティブなパーティションのノードをバックアップしているインスタンスはすべて終了します。非アクティブなパーティションのノードには、新しいインスタンスは起動しません。 ## pcluster の起動と停止 [`pcluster stop`](pcluster.stop.md) を実行すると、すべてのパーティションが `INACTIVE`状態になり、 AWS ParallelCluster プロセスはパーティションを `INACTIVE`状態のままにします。 [`pcluster start`](pcluster.start.md) を実行すると、最初はすべてのパーティションが `UP` の状態になります。ただし、 AWS ParallelCluster プロセスはパーティションを `UP`状態に保持しません。パーティションの状態を手動で変更する必要があります。数分後、すべての静的ノードが使用可能になります。パーティションを `UP` に設定しても、動的容量は向上しません。[`initial_count`](compute-resource-section.md#compute-resource-initial-count) が [`max_count`](compute-resource-section.md#compute-resource-max-count) より大きい場合、パーティションの状態が `UP` 状態に変化したときに [`initial_count`](compute-resource-section.md#compute-resource-initial-count) が満たされない可能性があります。 [`pcluster start`](pcluster.start.md) と [`pcluster stop`](pcluster.stop.md) が動作している場合、[`pcluster status`](pcluster.status.md) コマンドを実行して `ComputeFleetStatus` を確認することで、クラスターの状態を確認することができます。考えられる状態を以下に示します。 + `STOP_REQUESTED`: [`pcluster stop`](pcluster.stop.md) リクエストがクラスターに送信されます。 + `STOPPING`: `pcluster` プロセスは現在、クラスターを停止しています。 + `STOPPED`: `pcluster` プロセスは停止処理を終了し、すべてのパーティションは `INACTIVE` 状態になり、すべてのコンピューティングインスタンスは終了しました。 + `START_REQUESTED`: [`pcluster start`](pcluster.start.md) リクエストがクラスターに送信されます。 + `STARTING`: `pcluster` プロセスは現在、クラスターを起動中です + `RUNNING`: `pcluster` プロセスは起動処理を終了し、すべてのパーティションが `UP` 状態になり、数分後に静的ノードが利用可能になります。 ## キューの手動制御 場合によっては、クラスター内のノードやキュー (Slurm ではパーティションと呼ばれます) を手動で制御したいことがあります。次の共通の手順でクラスター内のノードを管理することができます。 + `POWER_SAVING` 状態の動的ノードをパワーアップさせます。`scontrol update nodename=nodename state=power_up` コマンドを実行するか、特定のノード数を要求するプレースホルダ `sleep 1` ジョブを送信し、Slurm に依存して必要な数のノードをパワーアップさせます。 + より前の動的ノードの電源を切る[`scaledown_idletime`](scaling-section.md#scaledown-idletime): `scontrol update nodename=nodename state=down` コマンド`DOWN`を使用して動的ノードを に設定します。 は、ダウンした動的ノード AWS ParallelCluster を自動的に終了およびリセットします。一般に、`scontrol update nodename=nodename state=power_down` コマンドを使用してノードを直接 `POWER_DOWN` に設定することは推奨しません。これは、 AWS ParallelCluster が自動的にパワーダウン処理を行うためです。手動で行う必要がありません。そのため、可能な限りノードを `DOWN` に設定することをお勧めします。 + キュー (パーティション) を無効にする、または特定のパーティションの静止ノードをすべて停止する: `scontrol update partition=queue name state=inactive` コマンドで特定のキューを `INACTIVE` に設定します。この操作により、パーティション内のすべてのインスタンスバッキングノードが終了します。 + キュー (パーティション) を有効にする: `scontrol update partition=queue name state=up` コマンドで `INACTIVE` に特定のキューを設定します。 ## スケーリング動作および調整 ここでは、通常のスケーリングワークフローの例を示します。 + スケジューラは、2 つのノードを必要とするジョブを受け取ります。 + スケジューラは 2 つのノードを `POWER_UP` 状態に遷移させ、ノード名 (例: `queue1-dy-c5xlarge-[1-2]`) で `ResumeProgram` を呼び出す。 + `ResumeProgram` は EC2 インスタンスを 2 台起動し、`queue1-dy-c5xlarge-[1-2]` のプライベート IP アドレスとホストネームを割り当て、`ResumeTimeout` (デフォルトの期間は 60 分 (1 時間)) を待ってからノードのリセットを行います。 + インスタンスが設定され、クラスターに参加します。インスタンス上でジョブの実行を開始します。 + ジョブが完了しました。 + 設定された `SuspendTime` が経過した後 ([`scaledown_idletime`](scaling-section.md#scaledown-idletime) に設定されています)、インスタンスはスケジューラによって `POWER_SAVING` 状態になります。スケジューラは `queue1-dy-c5xlarge-[1-2]` を `POWER_DOWN` 状態にし、ノード名で `SuspendProgram` を呼び出します。 + `SuspendProgram` は 2 つのノードに対して呼び出されます。ノードは、例えば `SuspendTimeout` のために `idle%` を維持することで、`POWER_DOWN` 状態を維持します (デフォルトの期間は 120 秒 (2 分))。`clustermgtd` は、ノードがパワーダウンしていることを検出した後、バッキングインスタンスを終了します。その後、`queue1-dy-c5xlarge-[1-2]` をアイドル状態に設定し、プライベート IP アドレスとホスト名をリセットして、将来のジョブのために再びパワーアップできるようにします。 ここで、処理がうまくいかず、何らかの理由で特定のノードのインスタンスが起動できない場合、次のようなことが起こります。 + スケジューラは、2 つのノードを必要とするジョブを受け取ります。 + スケジューラは 2 つのクラウドでのバーストノードを `POWER_UP` 状態にし、ノード名で `ResumeProgram` を呼び出します (例: `queue1-dy-c5xlarge-[1-2]`)。 + `ResumeProgram` は EC2 インスタンスを 1 台だけ起動し、`queue1-dy-c5xlarge-1` の設定を行いましたが、`queue1-dy-c5xlarge-2` 用のインスタンスの起動に失敗しました。 + `queue1-dy-c5xlarge-1` は影響を受けず、`POWER_UP` の状態になった後にオンラインになります。 + `queue1-dy-c5xlarge-2` は `POWER_DOWN` 状態になり、Slurm がノード障害を検出したため、自動的にジョブが再クエリされます。 + `queue1-dy-c5xlarge-2` は `SuspendTimeout` の後に利用可能になります (デフォルトは 120 秒 (2 分))。その間、ジョブは再キューされ、別のノードで実行を開始することができます。 + 上記のプロセスは、使用可能なノードで障害が発生せずにジョブを実行できるようになるまで繰り返されます。 必要に応じて調整可能な 2 つのタイミングパラメータがあります。 + `ResumeTimeout` (デフォルトは 60 分 (1 時間)): `ResumeTimeout` は、Slurm がノードをダウン状態にするまでの待ち時間を制御します。 + インストール前後の処理に時間がかかる場合は、これを拡張するのも有効です。 + これは、問題が発生した場合に がノードを交換またはリセットするまでに AWS ParallelCluster 待機する最大時間でもあります。コンピューティングノードは、起動時やセットアップ時に何らかのエラーが発生した場合、自己終了します。次に、 AWS ParallelCluster プロセスは、インスタンスが終了したことを確認すると、ノードの交換を行います。 + `SuspendTimeout` (デフォルトは 120 秒 (2 分))。`SuspendTimeout` は、ノードがシステムに戻され、再び使用できるようになるまでの時間を制御します。 + `SuspendTimeout` が短いと、ノードのリセットが早くなり、Slurm はより頻繁にインスタンスの起動を試みることができます。 + `SuspendTimeout` が長いと、故障したノードのリセットが遅くなります。その間、Slurm は他のノードの利用を試みます。`SuspendTimeout` が数分以上であれば、Slurm はシステム内の全ノードの循環を試みます。1,000 ノード以上の大規模システムでは、失敗したジョブを頻繁に再キューイングすることによって Slurm のストレスを軽減するために、より長い `SuspendTimeout` が有効であると考えられます。 + `SuspendTimeout` は、ノードのバッキングインスタンスの終了を AWS ParallelCluster 待機した時間を参照しないことに注意してください。`power down` ノードのバックアップインスタンスは即座に終了します。通常、終了プロセスは数分で完了します。ただし、この間、ノードはパワーダウン状態にあり、スケジューラで利用することはできません。 ## 新しいアーキテクチャのログ 次のリストは、マルチキューアーキテクチャのキーログを含んでいます。Amazon CloudWatch Logs で使用されるログストリーム名は、`{hostname}.{instance_id}.{logIdentifier}` という形式になっており、*logIdentifier* がログ名の後に続きます。詳細については、「[Amazon CloudWatch Logs との統合](cloudwatch-logs.md)」を参照してください。 + `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`) + `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`) + `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`) + `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`) + `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`) + `slurmd`: `/var/log/slurmd.log` (`slurmd`) ## よくある問題とデバッグの方法: **起動、パワーアップ、またはクラスターへの参加に失敗したノード:** + 動的ノード: + `ResumeProgram` ログを確認し、ノードで `ResumeProgram` が呼び出されたことがあるかどうかを確認します。そうでない場合は、`slurmctld` ログを確認し、Slurm がノードで `ResumeProgram` に電話をかけようとしたことがあるかどうかを判断します。`ResumeProgram` のパーミッションが正しくない場合、サイレントで失敗することがあります。 + `ResumeProgram` が呼び出された場合、そのノードに対してインスタンスが起動されたかどうかを確認します。インスタンスを起動できない場合は、インスタンスの起動に失敗した理由を示す明確なエラーメッセージが表示されます。 + インスタンスが起動した場合、ブートストラッププロセスの実行時に何らかの問題が発生した可能性があります。`ResumeProgram` ログから対応するプライベート IP アドレスとインスタンス ID を探し、CloudWatch Logs で特定のインスタンスの対応するブートストラップのログを見ます。 + 静的ノード: + `clustermgtd` ログをチェックして、ノードに対してインスタンスが起動されたかどうかを確認します。そうでない場合は、インスタンスの起動に失敗した原因について、明確なエラーが表示されるはずです。 + インスタンスを起動していた場合、ブートストラップ処理中に何らかの問題が発生しています。`clustermgtd` ログから対応するプライベート IP とインスタンス ID を探し、CloudWatch Logs で特定のインスタンスの対応するブートストラップのログを見ます。 **ノードが予期せず置換または終了したノードの障害** + ノードが予期せず置換または終了したノード + 通常、`clustermgtd` はすべてのノードのメンテナンスアクションを処理します。`clustermgtd` がノードを置換または終了させたかどうかを確認するには、`clustermgtd` のログを確認します。 + `clustermgtd` がノードを置換または終了させた場合、その理由を示すメッセージが表示されます。スケジューラ関連 (ノードが `DOWN` だった場合など) の場合は、`slurmctld` ログで詳細を確認します。EC2 が原因の場合は、ツールを使用し、そのインスタンスのステータスやログを確認します。例えば、インスタンスにスケジュールされたイベントがあったかどうか、EC2 ヘルスステータスのチェックに失敗したかどうかを確認できます。 + `clustermgtd` がノードを終了させなかった場合、`computemgtd` がノードを終了させたか、EC2 がスポットインスタンスを再要求するためにインスタンスを終了させたかどうかを確認します。 + ノードの障害 + 通常、ノードに障害が発生した場合、ジョブは自動的に再キューされます。`slurmctld` ログを見て、ジョブやノードがなぜ失敗したかを確認し、そこから状況を分析します。 **インスタンスの置換やターミネーション時の障害、ノードのパワーダウン時の障害** + 一般に、`clustermgtd` は期待されるすべてのインスタンス終了アクションを処理します。`clustermgtd` ログを見て、ノードの置換または終了に失敗した理由を確認する。 + [`scaledown_idletime`](scaling-section.md#scaledown-idletime) に失敗した動的ノードの場合、`SuspendProgram` のログから、特定のノードを引数にした `slurmctld` によるプログラムがあるかどうかを確認します。`SuspendProgram` は実際に特定のアクションを実行するわけではありません。呼び出されたときだけログに記録されます。すべてのインスタンスの終了と `NodeAddr` リセットは `clustermgtd` により完了します。Slurm は `IDLE` の後、`SuspendTimeout` にノードを入れます。 **その他の問題** + AWS ParallelCluster はジョブの割り当てやスケーリングの決定を行いません。Slurm の指示に従い、リソースを起動、終了、維持を試みるだけです。 ジョブの割り当て、ノードの割り当て、スケーリングの決定に関する問題については、`slurmctld` ログを見てエラーを確認します。