Slurm 複数キューモードのガイド

• POWER_SAVING 状態のノードは、sinfo では ~ サフィックス (例: idle~) で表示されます。この状態では、ノードをバックアップするEC2インスタンスはありません。ただし、Slurm は、引き続きジョブをノードに割り当てることができます。

• POWER_UP 状態に遷移したノードは、sinfo では # サフィックス (例: idle#) で表示されます。ノードが POWER_UP状態に自動的に移行すると、Slurm は、 POWER_SAVING状態のノードにジョブを割り当てます。

  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 ノード以上) では、 に対するストレスを軽減するために、より長い時間が有益SuspendTimeoutである可能性があります。Slurm 失敗したジョブを頻繁に再キューに入れようとするとき。

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

• 静的ノード:

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

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

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

  • 通常、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 は、 IDLEの後にノードを に移行しますSuspendTimeout。

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

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