翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # マルチキューモードの Slurm ガイド ここでは、キュー (パーティション) ノードSlurmの管理 AWS ParallelCluster 方法と、キューとノードの状態をモニタリングする方法について説明します。 ## 概要: スケーリングアーキテクチャは、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` 状態に遷移します。 `su` ルートユーザーとして次のコマンドを使用し、手動でノードを `POWER_UP` 状態に遷移させることもできます。 ``` $ scontrol update nodename={{nodename}} state=power_up ``` この段階で `ResumeProgram` が呼び出され、EC2 インスタンスが起動して構成され、ノードが `POWER_UP` 状態に遷移します。 + **現在使用可能なノード**は、`sinfo` にサフィックス (例: `idle`) なしで表示されます。ノードのセットアップが完了し、クラスターに参加した後、ジョブの実行が可能になります。この段階で、ノードは適切に設定され、使用可能な状態になります。 原則として、Amazon EC2 インスタンス数は利用可能なノード数と同じにすることを推奨します。通常、静的ノードはクラスター作成後に利用可能です。 + **`POWER_DOWN` 状態に遷移しているノード**は、`sinfo` に `%` サフィックス (例: `idle%`) で表示されます。動的ノードは [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) の後、自動的に `POWER_DOWN` 状態になります。対照的に、ほとんどの場合、静的ノードの電源はオフになりません。ただし、`su` ルートユーザーとして次のコマンドを使用し、手動でノードを `POWER_DOWN` 状態に配置できます。 ``` $ scontrol update nodename={{nodename}} state=down reason="manual draining" ``` この状態では、ノードに関連するインスタンスは終了し、ノードは [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 後に使用可能になるように `POWER_SAVING` 状態に戻されます。 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) の設定は、Slurm の設定の `SuspendTimeout` 設定に保存されます。 + **オフラインのノード**は、`sinfo` に `*` サフィックス (例: `down*`) で表示されます。Slurm コントローラーがノードにコンタクトできない場合、または静的ノードが無効化され、バッキングインスタンスが終了した場合、ノードはオフラインになります。 次の `sinfo` の例で示されるノードの状態を考えてみます。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 idle% gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2] ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2] ``` `spot-st-spotcompute2-[1-2]` ノードと `efa-st-efacompute1-1` ノードには、すでにバッキングインスタンスが設定されており、使用可能です。`ondemand-dy-ondemandcompute1-[1-2]` ノードは `POWER_UP` 状態であり、数分以内に利用可能になるはずです。`gpu-dy-gpucompute1-1` ノードは `POWER_DOWN` 状態であり、`POWER_SAVING` (デフォルトは 10 分) 後に [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 状態へ遷移します。 他のノードはすべて `POWER_SAVING` 状態で、EC2 インスタンスのバックアップはありません。 ## 使用可能なノードの操作 利用可能なノードは Amazon EC2 インスタンスによってバッキングされます。デフォルトでは、ノード名を使用してインスタンスに直接 SSH 接続することができます (例: `ssh efa-st-efacompute1-1`)。インスタンスのプライベート IP アドレスは、次のコマンドを使用して取得することができます。 ``` $ scontrol show nodes {{nodename}} ``` 返された `NodeAddr` フィールドの IP アドレスを確認します。 ノードが利用可能でない場合、`NodeAddr` フィールドは稼働中の Amazon 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-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10] ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2] ``` なお、`spot` はデフォルトのキューです。`*` というサフィックスで表示されます。 デフォルトキュー (`spot`) の 1 つの静的ノードにジョブを送信します。 ``` $ sbatch --wrap {{"sleep 300"}} -N {{1}} -C {{static}} ``` `EFA` キューのある動的ノードにジョブを送信します。 ``` $ sbatch --wrap {{"sleep 300"}} -p {{efa}} -C {{dynamic}} ``` `ondemand` キューの `c5.2xlarge` ノード 8 台、`t2.xlarge` ノード 2 台にジョブを送信します。 ``` $ 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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1 7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1 8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-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-efacompute1-[2-4] efa up infinite 1 mix efa-dy-efacompute1-1 efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 mix~ gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 1 mix spot-st-spotcompute2-1 spot* up infinite 1 idle spot-st-spotcompute2-2 ``` ## ノードの状態および機能 ほとんどの場合、ノードの状態は、このトピックで前述したクラウドノードライフサイクルの特定のプロセス AWS ParallelCluster に従って、 によって完全に管理されます。 ただし、 は、 `DOWN`および `DRAINED`の状態の異常なノードと、異常なバッキングインスタンスを持つノード AWS ParallelCluster も置き換えまたは終了します。詳細については、「[`clustermgtd`](processes-v3.md#clustermgtd-v3)」を参照してください。 ## パーティションの状態 AWS ParallelCluster は、次のパーティション状態をサポートしています。Slurm パーティションは AWS ParallelClusterのキューです。 + `UP`: パーティションがアクティブ状態であることを示します。これは、パーティションのデフォルトの状態です。この状態では、パーティション内のすべてのノードがアクティブで、使用可能な状態です。 + `INACTIVE`: パーティションが非アクティブ状態であることを示す。この状態では、非アクティブなパーティションのノードをバックアップしているインスタンスはすべて終了します。非アクティブなパーティションのノードには、新しいインスタンスは起動しません。 ## pcluster update-compute-fleet + **コンピューティングフリートの停止** - 次のコマンドを実行すると、すべてのパーティションは `INACTIVE`状態に移行し、 AWS ParallelCluster プロセスはパーティションを `INACTIVE`状態に保ちます。 ``` $ pcluster update-compute-fleet --cluster-name {{testSlurm}} \ --region {{eu-west-1}} --status STOP_REQUESTED ``` + **コンピューティングフリートの起動** - 次のコマンドを実行すると、すべてのパーティションが最初に `UP` の状態に遷移します。ただし、 AWS ParallelCluster プロセスはパーティションを `UP`状態に保持しません。パーティションの状態を手動で変更する必要があります。数分後、すべての静的ノードが使用可能になります。パーティションを `UP` に設定しても、動的容量は向上しません。 ``` $ pcluster update-compute-fleet --cluster-name {{testSlurm}} \ --region {{eu-west-1}} --status START_REQUESTED ``` `update-compute-fleet` が動作している場合、`pcluster describe-compute-fleet` コマンドを実行して `Status` を確認することで、クラスターの状態を確認することができます。考えられる状態を以下に示します。 + `STOP_REQUESTED`: コンピューティングフリートの停止リクエストがクラスターに送信されます。 + `STOPPING`: `pcluster` プロセスは現在、コンピューティングフリートを停止しています。 + `STOPPED`: `pcluster` プロセスは停止処理を終了し、すべてのパーティションは `INACTIVE` 状態になり、すべてのコンピューティングインスタンスは終了しました。 + `START_REQUESTED`: コンピューティングフリートの開始リクエストがクラスターに送信されます。 + `STARTING`: `pcluster` プロセスは現在、クラスターを起動中です。 + `RUNNING`: `pcluster` プロセスは起動処理を終了し、すべてのパーティションが `UP` 状態になり、数分後に静的ノードが利用可能になります。 + `PROTECTED`：このステータスは、一部のパーティションでブートストラップが失敗し続けていることを示しています。影響を受けたパーティションは非アクティブになります。問題を調査し、`update-compute-fleet` を実行して、フリートを再度有効化してください。 ## キューの手動制御 場合によっては、クラスター内のノードやキュー (Slurm ではパーティションと呼ばれます) を手動で制御したいことがあります。次の共通の手順で `scontrol` コマンドを使用してクラスター内のノードを管理することができます。 + **`POWER_SAVING` 状態の動的ノードの電源を入れる** `su` ルートユーザーとしてコマンドを実行します。 ``` $ scontrol update nodename={{nodename}} state=power_up ``` 特定の数のノードをリクエストするプレースホルダー `sleep 1` のジョブを送信し、Slurm に依存して必要な数のノードの電源を入れることもできます。 + **[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) の前に動的ノードの電源を切る** `su` ルートユーザーとしてコマンドを使用して、動的ノードを `DOWN` に設定することをお勧めします。 ``` $ scontrol update nodename={{nodename}} state=down reason="manually draining" ``` AWS ParallelCluster は、ダウンした動的ノードを自動的に終了およびリセットします。 一般的に、`scontrol update nodename={{nodename}} state=power_down` コマンドを使用してノードを直接 `POWER_DOWN` に設定することはお勧めしません。これは、 AWS ParallelCluster が自動的にパワーダウン処理を行うためです。 + **キュー (パーティション) を無効にするか、特定のパーティションのすべての静的ノードを停止する** `su` ルートユーザーとしてコマンドを使用して、特定のキューを `INACTIVE` に設定します。 ``` $ scontrol update partition={{queuename}} state=inactive ``` この操作により、パーティション内のすべてのインスタンスバッキングノードが終了します。 + **キュー (パーティション) を有効にする** `su` ルートユーザーとしてコマンドを使用して、特定のキューを `UP` に設定します。 ``` $ scontrol update partition={{queuename}} state=up ``` ## スケーリング動作および調整 **ここでは、通常のスケーリングワークフローの例を示します。** + スケジューラは、2 つのノードを必要とするジョブを受け取ります。 + スケジューラは 2 つのノードを `POWER_UP` 状態に遷移させ、ノード名 (例: `queue1-dy-spotcompute1-[1-2]`) で `ResumeProgram` を呼び出す。 + `ResumeProgram` は Amazon EC2 インスタンスを 2 つ起動し、`queue1-dy-spotcompute1-[1-2]` のプライベート IP アドレスとホストネームを割り当て、`ResumeTimeout` (デフォルトの期間は 30 分) を待ってからノードをリセットします。 + インスタンスが設定され、クラスターに参加します。インスタンスでジョブの実行を開始します。 + ジョブは完了し、実行は停止します。 + 設定された `SuspendTime` が経過した後 ([`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) に設定されています)、スケジューラはインスタンスを `POWER_SAVING` 状態に設定します。次に、スケジューラは `queue1-dy-spotcompute1-[1-2]` を `POWER_DOWN` 状態に設定し、ノード名で `SuspendProgram` を呼び出します。 + `SuspendProgram` は 2 つのノードに対して呼び出されます。ノードは、例えば `SuspendTimeout` のために `idle%` を維持することで、`POWER_DOWN` 状態を維持します (デフォルトの期間は 120 秒 (2 分))。`clustermgtd` は、ノードがパワーダウンしていることを検出した後、バッキングインスタンスを終了します。次に、`queue1-dy-spotcompute1-[1-2]` はアイドル状態に遷移し、プライベート IP アドレスとホスト名はリセットされ、今後のジョブに備えて電源を入れる準備をします。 **処理がうまくいかず、何らかの理由で特定のノードのインスタンスが起動できない場合、次のようなことが起こります。** + スケジューラが、2 つのノードを必要とするジョブを受け取る。 + スケジューラが 2 つのクラウドでのバーストノードを `POWER_UP` 状態に遷移させ、ノード名 (例: `queue1-dy-spotcompute1-[1-2]`) で `ResumeProgram` を呼び出す。 + `ResumeProgram` は 1 つの Amazon EC2 インスタンスだけを起動して `queue1-dy-spotcompute1-1` を設定し、別のインスタンス `queue1-dy-spotcompute1-2` は起動に失敗する。 + `queue1-dy-spotcompute1-1` は影響を受けず、`POWER_UP` 状態に到達した後、オンラインになる。 + `queue1-dy-spotcompute1-2` が `POWER_DOWN` 状態に遷移し、Slurm がノード障害を検出するため、自動的にジョブが再キューされる。 + `queue1-dy-spotcompute1-2` が `SuspendTimeout` の後に利用可能になる (デフォルトは 120 秒 (2 分))。その間、ジョブは再キューされ、別のノードで実行を開始することができます。 + 上記のプロセスが、使用可能なノードで障害が発生せずにジョブを実行できるようになるまで繰り返される。 **必要に応じて調整可能な 2 つのタイミングパラメータがあります。** + **`ResumeTimeout` (デフォルトは 30 分)**: `ResumeTimeout` は、ノードがダウン状態に遷移するまで Slurm が待機する時間を制御します。 + インストール前後の処理に時間がかかる場合は、`ResumeTimeout` を拡張するのも有効です。 + `ResumeTimeout` は、また、問題が発生した場合にノードを交換またはリセットするまでに、 AWS ParallelCluster が待機する最大時間です。コンピューティングノードは、起動またはセットアップ中にエラーが発生した場合に自己終了します。 AWS ParallelCluster プロセスは、終了したインスタンスの検出時にノードを置き換えます。 + **`SuspendTimeout` (デフォルトは 120 秒 (2 分))**: `SuspendTimeout` は、ノードがシステムに戻され、再び使用できるようになるまでの時間を制御します。 + `SuspendTimeout` が短いと、ノードのリセットが早くなり、Slurm はより頻繁にインスタンスの起動を試みることができます。 + `SuspendTimeout` が長いと、故障したノードのリセットが遅くなります。その間、Slurm は他のノードの使用を試みます。`SuspendTimeout` が数分以上であれば、Slurm はシステム内の全ノードの循環を試みます。1,000 ノード以上の大規模システムでは、失敗したジョブを頻繁に再キューする場合に Slurm のストレスを軽減するために、より長い `SuspendTimeout` が有効である場合があります。 + `SuspendTimeout` は、 がノードのバッキングインスタンスを終了するのを AWS ParallelCluster 待機する時間を参照しないことに注意してください。`POWER_DOWN` ノードのバックアップインスタンスは即座に終了します。通常、終了プロセスは数分で完了します。ただし、この間、ノードは `POWER_DOWN` 状態にあり、スケジューラで利用することはできません。 ## アーキテクチャのログ 次のリストには、キーのログが含まれています。Amazon CloudWatch Logs で使用されるログストリーム名は、`{{{hostname}}}.{{{instance_id}}}.{{{logIdentifier}}}` という形式になっており、{{logIdentifier}} がログ名の後に続きます。 + `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` ログで詳細を確認します。理由が Amazon EC2 関連の場合は、Amazon CloudWatch コンソール、Amazon EC2 コンソール、CLI、SDK などのツールを使用して、そのインスタンスのステータスまたはログを確認します。例えば、インスタンスにスケジュールされたイベントがあったかどうか、Amazon EC2 ヘルスステータスのチェックに失敗したかどうかを確認できます。 + `clustermgtd` がノードを終了させなかった場合、`computemgtd` がノードを終了させたか、EC2 がスポットインスタンスを再要求するためにインスタンスを終了させたかどうかを確認します。 + ノードの障害。 + 通常、ノードに障害が発生した場合、ジョブは自動的に再キューされます。`slurmctld` ログを見て、ジョブやノードがなぜ失敗したかを確認し、そこから状況を評価します。 **インスタンスの置換やターミネーション時の障害、ノードのパワーダウン時の障害** + 一般に、`clustermgtd` は期待されるすべてのインスタンス終了アクションを処理します。`clustermgtd` ログを見て、ノードの置換または終了に失敗した理由を確認する。 + [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) に失敗した動的ノードの場合、`SuspendProgram` のログから、`slurmctld` プロセスが特定のノードを引数にした呼び出しを行ったかどうかを確認します。`SuspendProgram` は実際に特定のアクションを実行するわけではありません。呼び出されたときだけログに記録されます。すべてのインスタンスの終了と `NodeAddr` リセットは `clustermgtd` により完了します。Slurm は `SuspendTimeout` の後、ノードを `IDLE` に遷移させます。 **その他の問題:** + AWS ParallelCluster はジョブの割り当てやスケーリングの決定を行いません。Slurm の指示に従い、リソースを起動、終了、維持を試みるだけです。 ジョブの割り当て、ノードの割り当て、スケーリングの決定に関する問題については、`slurmctld` ログを見てエラーを確認します。