Slurm クラスター保護モード - AWS ParallelCluster
保護モードパラメータ保護ステータスでのクラスターステータスの確認保護ステータスを非アクティブ化する方法保護ステータスをアクティブ化するブートストラップ障害保護モードをデバッグする方法

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

Slurm クラスター保護モード

保護モードを有効にしてクラスターを実行すると、 はコンピューティングノードの起動時にコンピューティングノードのブートストラップ障害 AWS ParallelCluster を監視および追跡します。これは、これらの障害が継続的に発生しているかどうかを検出するために行われます。

キュー (パーティション) で以下が検出されると、クラスターは保護ステータスになります。

  1. コンピューティングノードが正常に起動せず、コンピューティングノードのブートストラップ障害が連続して発生する。

  2. 障害カウントが事前に定義されたしきい値に達した。

クラスターが保護ステータスになると、 は、事前定義されたしきい値以上で障害が発生したキューを AWS ParallelCluster 無効にします。

Slurm クラスター保護モードが AWS ParallelCluster バージョン 3.0.0 に追加されました。

保護モードを使用すると、コンピューティングノードのブートストラップ障害サイクルに費やす時間とリソースを削減できます。

保護モードパラメータ

protected_failure_count

protected_failure_count は、クラスターの保護ステータスを有効にするキュー (パーティション) の連続した障害の数を指定します。

デフォルトの protected_failure_count は 10 で、保護モードは有効になっています。

protected_failure_count が 0 より大きい場合、保護モードは有効になります。

protected_failure_count が 0 以下の場合、保護モードは無効になります。

protected_failure_count の値は、HeadNode の /etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf にある clustermgtd 設定ファイルにパラメータを追加することで変更できます。

このパラメータはいつでも更新でき、そのためにコンピューティングフリートを停止する必要はありません。障害カウントが protected_failure_count に達する前にキューで起動が成功すると、障害カウントはゼロにリセットされます。

保護ステータスでのクラスターステータスの確認

クラスターが保護ステータスの場合、コンピューティングフリートのステータスとノードのステータスを確認できます。

コンピューティングフリートのステータス

保護ステータスで動作しているクラスターでは、コンピューティングフリートのステータスは PROTECTED です。

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id>
{
   "status": "PROTECTED",
   "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}

ノードのステータス

ブートストラップ障害が発生し、保護ステータスをアクティブにしたキュー (パーティション) を調べるには、クラスターにログインして sinfo コマンドを実行します。protected_failure_count 以上のブートストラップ障害があるパーティションは、INACTIVE 状態です。protected_failure_count 以上のブートストラップ障害が発生していないパーティションは、UP 状態にあり、想定どおりに動作します。

PROTECTED ステータスは実行中のジョブには影響しません。protected_failure_count 以上のブートストラップ障害があるパーティションでジョブが実行されている場合、パーティションは実行中のジョブの完了後に INACTIVE に設定されます。

次の例で示されるノードの状態を考慮します。

$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]

コンピューティングノードのブートストラップ障害が 10 回連続で検出されたため、パーティション queue1 は INACTIVE になりました。

ノード queue1-dy-c5xlarge-[1-10] の背後にあるインスタンスは起動しましたが、異常状態のためクラスターに参加できませんでした。

クラスターは保護ステータスです。

パーティション queue2 は、queue1 のブートストラップ障害の影響を受けていません。UP 状態であり、まだジョブを実行することができます。

保護ステータスを非アクティブ化する方法

ブートストラップエラーが解決されたら、以下のコマンドを実行してクラスターを保護ステータスから解除できます。

$ pcluster update-compute-fleet --cluster-name <cluster-name> \
  --region <region-id> \
  --status START_REQUESTED

保護ステータスをアクティブ化するブートストラップ障害

保護ステータスをアクティブ化するブートストラップエラーは、次の 3 つのタイプに分割されます。タイプと問題を特定するには、ログが AWS ParallelCluster 生成されたかどうかを確認します。ログが生成された場合は、そのログでエラーの詳細を確認できます。詳細については、「ログの取得と保存」を参照してください。

  1. インスタンスが自己終了する原因となるブートストラップエラー

    インスタンスが SlurmQueues/CustomActions/OnNodeStart/OnNodeConfigured スクリプトのエラーが原因で自己終了するなど、インスタンスはブートストラッププロセスの早い段階で失敗します。

    動的ノードの場合は、次のようなエラーを探します。

    Node bootstrap error: Node ... is in power up state without valid backing instance

    静的ノードの場合は、clustermgtd ログ (/var/log/parallelcluster/clustermgtd) に次のようなエラーがないか確認します。

    Node bootstrap error: Node ... is in power up state without valid backing instance

  2. ノード resume_timeout または node_replacement_timeout が期限切れになります。

    インスタンスは resume_timeout (動的ノードの場合) または node_replacement_timeout (静的ノードの場合) 内のクラスターに参加できません。タイムアウト前に自己終了することはありません。例えば、クラスターに対してネットワークが正しく設定されておらず、タイムアウトが期限切れになった後にノードが Slurm によって DOWN 状態に設定されます。

    動的ノードの場合は、次のようなエラーを探します。

    Node bootstrap error: Resume timeout expires for node

    静的ノードの場合は、clustermgtd ログ (/var/log/parallelcluster/clustermgtd) に次のようなエラーがないか確認します。

    Node bootstrap error: Replacement timeout expires for node ... in replacement.

  3. ノードはヘルスチェックを失敗します。

    ノードの背後にあるインスタンスが Amazon EC2 ヘルスチェックまたはスケジュールされたイベントのヘルスチェックに失敗し、ノードはブートストラップ障害ノードとして扱われます。この場合、インスタンスは制御できない理由で終了します AWS ParallelCluster。

    clustermgtd ログ (/var/log/parallelcluster/clustermgtd) に次のようなエラーがないか確認します。

    Node bootstrap error: Node %s failed during bootstrap when performing health check.

  4. コンピューティングノードは Slurm の登録に失敗します。

    slurmd デーモンと Slurm コントロールデーモン (slurmctld) の登録が失敗し、コンピューティングノードの状態が INVALID_REG 状態に変更します。CustomSlurmSettings コンピューティングノードの仕様エラーで設定されたコンピューティングノードなど、間違えて設定された Slurm コンピューティングノードによって、このエラーが発生する可能性があります。

    ヘッドノードの slurmctld ログファイル (/var/log/slurmctld.log)、または障害が発生したコンピューティングノードの slurmd ログファイル (/var/log/slurmd.log) に次のようなエラーがないか確認します。

    Setting node %s to INVAL with reason: ...

保護モードをデバッグする方法

クラスターが保護ステータスにあり、 から AWS ParallelCluster 生成されたclustermgtdログHeadNodeと問題のあるコンピューティングノードからcloud-init-output生成されたログがある場合は、ログでエラーの詳細を確認できます。ログの取得方法の詳細については、「ログの取得と保存」を参照してください。

ヘッドノードの clustermgtd ログ (/var/log/parallelcluster/clustermgtd)

ログメッセージには、ブートストラップ障害が発生したパーティションと、対応するブートストラップ障害カウントが表示されます。

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions  
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.

clustermgtd ログで、Found the following bootstrap failure nodes を検索して、ブートストラップに失敗したノードを見つけます。

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING - 
Found the following bootstrap failure nodes: (x2)  ['queue1-st-c5large-1(192.168.110.155)',  'broken-st-c5large-2(192.168.65.215)']

clustermgtd ログで、Node bootstrap error を検索して障害の原因を見つけます。

[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error: 
Node broken-st-c5large-2(192.168.65.215) is currently in  replacement and no backing instance

コンピューティングノードの cloud-init-output ログ (/var/log/cloud-init-output.log)

clustermgtd ログでブートストラップ障害ノードのプライベート IP アドレスを取得したら、コンピューティングノードにログインするか、ログの取得と保存 のガイダンスに従ってログを取得することで、対応するコンピューティングノードのログを確認することができます。ほとんどの場合、問題のあるノードの /var/log/cloud-init-output ログには、コンピューティングノードのブートストラップ障害の原因となった手順が示されています。