マルチキューモードの Slurm ガイド

• 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 の後、自動的に POWER_DOWN 状態になります。対照的に、ほとんどの場合、静的ノードの電源はオフになりません。ただし、su ルートユーザーとして次のコマンドを使用し、手動でノードを POWER_DOWN 状態に配置できます。

  $ scontrol update nodename=nodename state=down reason="manual draining"

  この状態では、ノードに関連するインスタンスは終了し、ノードは ScaledownIdletime 後に使用可能になるように POWER_SAVING 状態に戻されます。

  ScaledownIdletime の設定は、Slurm の設定の SuspendTimeout 設定に保存されます。

• オフラインのノードは、sinfo に * サフィックス (例: down*) で表示されます。Slurm コントローラーがノードにコンタクトできない場合、または静的ノードが無効化され、バッキングインスタンスが終了した場合、ノードはオフラインになります。

• インスタンスタイプ (例: c5.xlarge)

• ノードタイプ (dynamic または static のいずれか)。

• UP: パーティションがアクティブ状態であることを示します。これは、パーティションのデフォルトの状態です。この状態では、パーティション内のすべてのノードがアクティブで、使用可能な状態です。

• INACTIVE: パーティションが非アクティブ状態であることを示す。この状態では、非アクティブなパーティションのノードをバックアップしているインスタンスはすべて終了します。非アクティブなパーティションのノードには、新しいインスタンスは起動しません。

• コンピューティングフリートの停止 - 次のコマンドを実行すると、すべてのパーティションが 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

• STOP_REQUESTED: コンピューティングフリートの停止リクエストがクラスターに送信されます。

• STOPPING: pcluster プロセスは現在、コンピューティングフリートを停止しています。

• STOPPED: pcluster プロセスは停止処理を終了し、すべてのパーティションは INACTIVE 状態になり、すべてのコンピューティングインスタンスは終了しました。

• START_REQUESTED: コンピューティングフリートの開始リクエストがクラスターに送信されます。

• STARTING: pcluster プロセスは現在、クラスターを起動中です。

• RUNNING: pcluster プロセスは起動処理を終了し、すべてのパーティションが UP 状態になり、数分後に静的ノードが利用可能になります。

• PROTECTED：このステータスは、一部のパーティションでブートストラップが失敗し続けていることを示しています。影響を受けたパーティションは非アクティブになります。問題を調査し、update-compute-fleet を実行して、フリートを再度有効化してください。

• POWER_SAVING 状態の動的ノードの電源を入れる

  su ルートユーザーとしてコマンドを実行します。

  $ scontrol update nodename=nodename state=power_up

  特定の数のノードをリクエストするプレースホルダー sleep 1 のジョブを送信し、Slurm に依存して必要な数のノードの電源を入れることもできます。

• 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 は 2 つの Amazon EC2 インスタンスを起動しqueue1-dy-spotcompute1-[1-2]、 のプライベート IP アドレスとホスト名を割り当て、 を待機します ResumeTimeout (デフォルト期間は 30 分です。その後、ノードをリセットします。

• インスタンスが設定され、クラスターに参加します。インスタンスでジョブの実行を開始します。

• ジョブは完了し、実行は停止します。

• 設定された SuspendTime が経過した後 (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 つの (1) Amazon EC2 インスタンスのみを起動しqueue1-dy-spotcompute1-1、1 つの (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 状態にあり、スケジューラで利用することはできません。

• 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 を検索し、Logs で特定のインスタンスに対応するブートストラップ CloudWatch ログを確認します。

• 静的ノード:

  • clustermgtd ログをチェックして、ノードに対してインスタンスが起動されたかどうかを確認します。インスタンスが起動しなかった場合は、インスタンスの起動に失敗した原因について、明確なエラーが表示されるはずです。

  • インスタンスを起動していた場合、ブートストラップ処理で何らかの問題が発生しています。clustermgtd ログから対応するプライベート IP とインスタンス ID を検索し、Logs で特定のインスタンスに対応するブートストラップ CloudWatch ログを確認します。

• ノードが予期せず置換または終了した。

  • 通常、clustermgtd はすべてのノードのメンテナンスアクションを処理します。clustermgtd がノードを置換または終了させたかどうかを確認するには、clustermgtd のログを確認します。

  • clustermgtd がノードを置換または終了させた場合、その理由を示すメッセージが表示されます。スケジューラ関連 (ノードが DOWN だった場合など) の場合は、slurmctld ログで詳細を確認します。その理由が Amazon EC2 に関連する場合は、Amazon CloudWatch または Amazon EC2 コンソール、CLI、または SDKsなどのツールを使用して、そのインスタンスのステータスまたはログを確認します。例えば、インスタンスにスケジュールされたイベントがあるか、Amazon EC2 ヘルスステータスチェックに失敗したかを確認できます。

  • clustermgtd がノードを終了させなかった場合、computemgtd がノードを終了させたか、EC2 がスポットインスタンスを再要求するためにインスタンスを終了させたかどうかを確認します。

• ノードの障害。

  • 通常、ノードに障害が発生した場合、ジョブは自動的に再キューされます。slurmctld ログを見て、ジョブやノードがなぜ失敗したかを確認し、そこから状況を評価します。

• 一般に、clustermgtd は期待されるすべてのインスタンス終了アクションを処理します。clustermgtd ログを見て、ノードの置換または終了に失敗した理由を確認する。

• ScaledownIdletime に失敗した動的ノードの場合、SuspendProgram のログから、slurmctld プロセスが特定のノードを引数にした呼び出しを行ったかどうかを確認します。SuspendProgram は実際に特定のアクションを実行するわけではありません。呼び出されたときだけログに記録されます。すべてのインスタンスの終了と NodeAddr リセットは clustermgtd により完了します。Slurm は SuspendTimeout の後、ノードを IDLE に遷移させます。

• AWS ParallelCluster は、ジョブの割り当てやスケーリングの決定を行いません。Slurm の指示に従い、リソースを起動、終了、維持を試みるだけです。

  ジョブの割り当て、ノードの割り当て、スケーリングの決定に関する問題については、slurmctld ログを見てエラーを確認します。