SageMaker HyperPod クラスターの耐障害性 - Amazon SageMaker
クラスターヘルスチェック自動再開によって自動再開されない障害ノードを交換する方法 HyperPod

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

SageMaker HyperPod クラスターの耐障害性

SageMaker HyperPod には、以下のクラスター復元機能が備わっています。

クラスターヘルスチェック

このセクションでは、アクセラレータ (GPU および Trainium コア) やネットワーク (EFA) などのデバイスに問題がないか、 SageMaker HyperPod クラスターインスタンスの状態を定期的に監視するために使用する一連のヘルスチェックについて説明します。

カテゴリ ユーティリティ名 インスタンスタイプの互換性 説明
アクセラレーター DCGM ポリシー GPU クラスター内の各インスタンスは、NVIDIA DCGM を使用して XID エラーを含むすべての GPU 関連ポリシーを継続的に監視します。
NVIDIA SMI GPU nvidia-smiユーティリティは、GPUを管理および監視するためのよく知られたCLI です。ビルトインのヘルスチェッカーが出力を解析してインスタンスの状態を判断します。nvidia-smi
ニューロン sysfs Trainium Trainium 搭載インスタンスの場合、Neuron デバイスの状態は Neuron ドライバーによって直接伝達される Neuron sysfs からカウンターを読み取ることによって決定されます。
ネットワーク EFA GPU とトライニウム Elastic Fabric Adaptor (EFA) デバイスの診断に役立つように、EFA ヘルスチェッカーはインスタンス内で使用可能なすべての EFA カードを使用して一連の接続テストを実行します。
ストレス DCGM 診断 GPU DCGM 診断レベル 2 は、システム内の GPU に負荷をかけ、状態に関する詳細な情報を得るために使用します。
CPU stress GPU とトレニウム CPU の状態は Linux stress ツールを使用して決定されます。このツールは、複数のスレッドを実行して CPU 使用率を 100% にし、I/O 操作を実行します。

自動再開

このセクションでは、16 ノードを超えるクラスターでハードウェア障害が発生した場合に、 SageMaker HyperPod 最後に保存したチェックポイントからトレーニングジョブを自動的に回復するゼロタッチ復元インフラストラクチャを提供する自動再開機能を使用してトレーニングジョブを実行する方法について説明します。

自動再開機能を使用すると、ハードウェア障害またはトレーニングの間の一時的な問題が原因でジョブが失敗した場合、 SageMaker HyperPod 自動再開によりノード交換ワークフローが開始され、障害のあるノードが交換された後にジョブが再開されます。

SageMaker HyperPod Slurm での自動再開機能の使用

Slurm SageMaker HyperPod で自動再開を使用する場合は、またはを使用して取得した排他的割り当て内でジョブを実行する必要があります。salloc sbatchいずれにしても、ジョブを再開するときにすべてのセットアップステップが 1 srun つのコマンドで実行されるように、エントリポイントスクリプトを変更する必要があります。エントリポイントスクリプトでは、ジョブステップが停止される前に実行されていた環境と一致するように、交換したノードの環境を設定することが重要です。以下の手順は、環境の一貫性を保つためにエントリポイントスクリプトを準備し、1 つのコマンドとして実行する方法を示しています。srun

ヒント

を使用する場合sbatch、環境設定用のスクリプトを別に作成し、1 つのコマンドを使用するだけで、バッチスクリプトをシンプルに保つことができます。srun

  1. 次のコード例を使用してスクリプトを作成し、名前を付けて保存しますtrain_auto_resume.sh。このスクリプトは、置き換えられたノードに対して以前に手動設定が行われていないことを前提として、トレーニング環境の設定をデプロイします。これにより、環境がノードに依存しないことが保証され、ノードを交換しても、ジョブを再開する前に同じ環境がノードにプロビジョニングされます。

    注記

    以下のコード例は、ジョブに関連付けられた Slurm ノードリストを検出する方法を示しています。Slurm $SLURM_JOB_NODELIST が提供する環境変数は使用しないでください。 SageMaker HyperPod ジョブの自動再開後に値が古くなる可能性があります。以下のコード例は、NODE_LIST置換する新しい変数を定義しSLURM_JOB_NODELIST、MASTER_NODEMASTER_ADDRその変数からと変数を設定する方法を示しています。NODE_LIST

    #!/bin/bash

# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.

# Place your training environment setup here. 
# Example: Install conda, docker, activate virtual env, etc.

# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
            awk -F= '/NodeList=/{print $2}' | \  # Extract NodeList field
            grep -v Exc)                         # Exclude nodes marked as excluded

# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
              head -n 1)                            # Select the first hostname as master node

# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
              awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
              awk '{print $1}')                   # Print the first part of NodeAddr


# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
                       --nproc_per_node=1 \
                       --node_rank=$SLURM_NODE \
                       --master-addr=$MASTER_ADDR \
                       --master_port=1234 \
                       <your_training_script.py>"

# Execute the torchrun command in the 'pytorch' Conda environment, 
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
    ヒント

    前述のスクリプトを使用して、ジョブに追加の依存関係をインストールするためのコマンドをさらに追加できます。ただし、依存関係のインストールスクリプトは、クラスターの作成時に使用するライフサイクルスクリプトのセットにとどめておくことをお勧めします。共有ディレクトリでホストされている仮想環境を使用する場合は、このスクリプトを使用して仮想環境をアクティブ化することもできます。

  2. --auto-resume=1srunハードウェア障害が発生した場合にコマンドを自動的に再試行する必要があることを示すフラグを追加して、 SageMaker HyperPod 自動再開を有効にした状態でジョブを起動します。

    注記

    sbatchまたはを使用してリソース割り当てを設定した場合はsalloc、srunその割り当て内で複数のコマンドを実行できます。障害が発生した場合、 SageMaker HyperPodsrun--auto-resume=1自動再開機能はフラグの付いたコマンドの現在のジョブステップでのみ動作します。つまり、srunあるコマンドで自動再開を有効にしても、srunリソース割り当てセッション内で起動された他のコマンドには適用されません。

    srun有効にしたコマンドの例を以下に示します。auto-resume

    sbatch を使用する

    環境を設定するロジックのほとんどはすでに組み込まれているためtrain_auto_resume.sh、バッチスクリプトは次のコード例のような単純なものになるはずです。batch.sh次のバッチスクリプトがとして保存されていると仮定します。

    #!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh

    以下のコマンドを使用して、前述のバッチスクリプトを実行します。

    sbatch batch.sh

    salloc を使用する

    まず、排他的割り当てを取得し、srun--auto-resumeフラグとエントリポイントスクリプトを指定してコマンドを実行します。

    salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh

によって自動再開されない障害ノードを交換する方法 HyperPod

HyperPod 自動再開機能は、Slurm ノードの状態がまたはに変わるかどうかを監視します。fail downSlurm ノードの状態はを実行することで確認できます。sinfo

HyperPod 問題が発生しても自動再開機能では修正されないノードがある場合は、次のコマンドを実行してノードの状態をに変更することをお勧めします。fail

scontrol update node=<ip-ipv4> state=fail reason="Action:Replace"

前述のコマンド例では、<ip-ipv4>置き換えたい障害のあるインスタンスの Slurm ノード名 (ホスト名) に置き換えます。

このコマンドを実行すると、failノードは元の状態になり、現在実行中のジョブが終了するのを待ち、正常なインスタンスに置き換えられ、同じホスト名で復旧されます。この処理には、アベイラビリティーゾーンで使用可能なインスタンスや、ライフサイクルスクリプトの実行にかかる時間によっては時間がかかります。更新と交換のプロセス中は、ノードの状態を手動で変更したり、Slurm Controller を再起動したりしないでください。これを行うと、交換に失敗する可能性があります。ノードが回復しないか、idle長時間経ってもその状態に戻らない場合は、AWS Support に連絡してください。

fail障害のあるノードが引き続きその状態のままである場合、最後の手段はノードの状態を手動でに強制的に変更することですdown。これには管理者権限 (sudo 権限) が必要です。

警告

以下のコマンドを実行すると、すべてのジョブが強制終了され、保存されていない作業がすべて失われる可能性があるため、注意して実行してください。

scontrol update node=<ip-ipv4> state=down reason="Action:Replace"