マルチキューモードの Slurm ガイド - AWS ParallelCluster
概要:クラウドノードのライフサイクル使用可能なノードの操作ジョブの状態および送信ノードの状態および機能パーティションの状態pcluster の起動と停止キューの手動制御スケーリング動作および調整新しいアーキテクチャのログよくある問題とデバッグの方法:

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

AWS ParallelCluster バージョン 2.9.0 では、複数のキューモードと Slurm Workload Manager () の新しいスケーリングアーキテクチャが導入されましたSlurm。

次のセクションでは、新しく導入されたスケーリングアーキテクチャを備えた Slurm クラスターを使用する際の一般的な概要を説明します。

概要:

新しいスケーリングアーキテクチャは、Slurm の「Cloud Scheduling Guide」(クラウドスケジュールガイド) と省電力プラグインに基づいています。省電力プラグインの詳細については、「Slurm Power Saving Guide」を参照してください。新しいアーキテクチャでは、クラスターで利用できる可能性のあるリソースは、通常、クラウドノードとして 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 の後、自動的に POWER_DOWN 状態になります。対照的に、ほとんどの場合、静的ノードの電源はオフになりません。ただし、scontrol update nodename=nodename state=powering_down コマンドを使用して手動でノードを POWER_DOWN 状態にすることができます。この状態では、ノードに関連するインスタンスは終了し、ノードは 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 (デフォルトは 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」を参照してください。

パーティションの状態

AWS ParallelCluster は、次のパーティション状態をサポートしています。Slurm パーティションは AWS ParallelClusterのキューです。

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

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

pcluster の起動と停止

pcluster stop を実行すると、すべてのパーティションが INACTIVE状態になり、 AWS ParallelCluster プロセスはパーティションを INACTIVE状態のままにします。

pcluster start を実行すると、最初はすべてのパーティションが UP の状態になります。ただし、 AWS ParallelCluster プロセスはパーティションを UP状態に保持しません。パーティションの状態を手動で変更する必要があります。数分後、すべての静的ノードが使用可能になります。パーティションを UP に設定しても、動的容量は向上しません。initial_count が max_count より大きい場合、パーティションの状態が UP 状態に変化したときに initial_count が満たされない可能性があります。

pcluster start と pcluster stop が動作している場合、pcluster status コマンドを実行して ComputeFleetStatus を確認することで、クラスターの状態を確認することができます。考えられる状態を以下に示します。

  • STOP_REQUESTED: pcluster stop リクエストがクラスターに送信されます。

  • STOPPING: pcluster プロセスは現在、クラスターを停止しています。

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

  • START_REQUESTED: pcluster start リクエストがクラスターに送信されます。

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

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

キューの手動制御

場合によっては、クラスター内のノードやキュー (Slurm ではパーティションと呼ばれます) を手動で制御したいことがあります。次の共通の手順でクラスター内のノードを管理することができます。

  • POWER_SAVING 状態の動的ノードをパワーアップさせます。scontrol update nodename=nodename state=power_up コマンドを実行するか、特定のノード数を要求するプレースホルダ sleep 1 ジョブを送信し、Slurm に依存して必要な数のノードをパワーアップさせます。

  • より前の動的ノードの電源を切る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 に設定されています)、インスタンスはスケジューラによって 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 との統合」を参照してください。

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

その他の問題

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

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