翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
SageMaker HyperPod クラスターの耐障害性
SageMaker HyperPod には、次のクラスターの耐障害性機能があります。
クラスターヘルスチェック
このセクションでは、 SageMaker HyperPod を使用して、アクセラレータ (GPU および Trainium コア) やネットワーク () などのデバイスに関する問題についてクラスターインスタンスのヘルスを定期的にモニタリングするヘルスチェックのセットについて説明しますEFA。
カテゴリ | ユーティリティ名 | インスタンスタイプの互換性 | 説明 |
---|---|---|---|
アクセラレーター | DCGM ポリシー | GPU | クラスター内の各インスタンスは、 でのXIDエラーを含むすべての GPU関連ポリシーを継続的にモニタリングNVIDIAしますDCGM |
アクセラレーター | NVIDIA SMI | GPU | nvidia-sminvidia-smi して、インスタンスのヘルスを判断します。 |
アクセラレーター | Neuron sysfs | Trainium | Trainium 搭載インスタンスの場合、Neuron デバイスのヘルスは、Neuron ドライバーによって直接伝達される Neuron sysfs |
ネットワーク | EFA | GPU および Trainium | Elastic Fabric Adaptor (EFA) デバイスの診断に役立つように、EFAヘルスチェッカーはインスタンス内で使用可能なすべてのEFAカードを使用して一連の接続テストを実行します。 |
ストレス | DCGM 診断 |
GPU | DCGM 診断 |
ストレス | CPU ストレス | GPU および Trainium | CPU ヘルスは、Linux ストレス |
自動再開
このセクションでは、 SageMaker HyperPod 自動再開機能を使用してトレーニングジョブを実行する方法について説明します。これにより、16 個を超えるノードを持つクラスターでハードウェア障害が発生した場合に、最後に保存されたチェックポイントからトレーニングジョブを自動的に復旧するためのゼロタッチの回復力インフラストラクチャが提供されます。
自動再開機能を使用すると、ハードウェア障害またはトレーニング間の一時的な問題が原因でジョブが失敗した場合、 SageMaker HyperPod 自動再開はノード交換ワークフローを開始し、障害のあるノードが置き換えられた後にジョブを再起動します。
注記
汎用リソース (GRES)
Slurm で SageMaker HyperPod の自動再開機能の使用
Slurm で SageMaker HyperPod 自動再開を使用する場合は、 salloc
または を使用して取得した排他的配分内でジョブを実行する必要がありますsbatch
。いずれにしても、ジョブを再開するときにすべてのセットアップステップが 1 つのsrun
コマンドで実行されるように、エントリポイントスクリプトを変更する必要があります。エントリポイントスクリプトを使用して、停止する前にジョブステップが実行されていた環境と一致するように、置き換えられたノードに環境を設定することが重要です。次の優先順位は、環境を一貫性を保ち、単一のsrun
コマンドとして実行するためにエントリポイントスクリプトを準備する方法を示しています。
ヒント
を使用する場合sbatch
、環境を設定するための個別のスクリプトを作成し、単一のsrun
コマンドを使用して、バッチスクリプトをシンプルに維持できます。
-
次のコード例を使用してスクリプトを作成し、 として保存します
train_auto_resume.sh
。このスクリプトは、置き換えられたノードに対して以前に手動設定が行われていないことを前提として、トレーニング環境のセットアップをデプロイします。これにより、環境がノードに依存しないため、ノードが置き換えられると、ジョブを再開する前にノードで同じ環境がプロビジョニングされます。注記
次のコード例は、ジョブに関連付けられた Slurm ノードリストを検出する方法を示しています。Slurm が提供する
$SLURM_JOB_NODELIST
環境変数は、ジョブ SageMaker HyperPod を自動再開した後に値が古くなる可能性があるため、使用しないでください。次のコード例は、 を置き換える新しいNODE_LIST
変数を定義しSLURM_JOB_NODELIST
、MASTER_ADDR
変数からMASTER_NODE
および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ヒント
上記のスクリプトを使用して、ジョブに追加の依存関係をインストールするためのコマンドを追加できます。ただし、依存関係インストールスクリプトは、クラスターの作成中に使用される一連のライフサイクルスクリプトに保持することをお勧めします。共有ディレクトリでホストされている仮想環境を使用する場合は、このスクリプトを使用して仮想環境をアクティブ化することもできます。
-
ハードウェア障害が発生した場合
--auto-resume=1
にsrun
コマンドを自動的に再試行する必要があることを示すフラグを追加して、 SageMaker HyperPod 自動再開を有効にしてジョブを起動します。注記
sbatch
または を使用してリソース割り当てを設定している場合はsalloc
、割り当て内で複数のsrun
コマンドを実行できます。障害が発生した場合、 SageMaker HyperPod自動再開機能は、 フラグを持つsrun
コマンドの現在のジョブステップでのみ動作します --auto-resume=1
。つまり、srun
コマンドで自動再開をアクティブ化することは、リソース割り当てセッション内で起動された他のsrun
コマンドには適用されません。auto-resume
を有効にしたsrun
コマンドの例を次に示します。スバッチの使用
環境を設定するためのロジックのほとんどが既に にあるため
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 の使用
まず排他的な割り当てを取得し、
--auto-resume
フラグとエントリポイントスクリプトを使用してsrun
コマンドを実行します。salloc -N 2 --exclusive srun --auto-resume=1
train_auto_resume.sh
によって自動再開されていない障害のあるノードを置き換える方法 HyperPod
HyperPod 自動再開機能は、Slurm ノードの状態が fail
または に変わるかどうかをモニタリングしますdown
。を実行して、Slurm ノードの状態を確認できますsinfo
。
問題が発生しても HyperPod 自動再開機能で修正されない場合は、次のコマンドを実行してノードの状態を に変更することをお勧めしますfail
。
scontrol update node=
<ip-ipv4>
state=fail
reason="Action:Replace"
前のコマンド例では、 を置き換える障害のあるインスタンスの Slurm ノード名 (ホスト名)
に置き換えます。<ip-ipv4>
このコマンドを実行すると、ノードは fail
状態になり、現在実行中のジョブが終了するのを待ち、正常なインスタンスに置き換えられ、同じホスト名で復元されます。このプロセスには、アベイラビリティーゾーンで使用可能なインスタンスとライフサイクルスクリプトの実行にかかる時間に応じて時間がかかります。更新および交換プロセス中は、ノードの状態を手動で変更したり、Slurm コントローラーを再起動したりしないでください。そうすると、交換が失敗する可能性があります。長期間経過してもノードが復旧せず、 idle
状態にならない場合は、 AWS サポート
障害のあるノードが fail
状態で継続的にスタックしている場合、最後に試みる可能性のある手段は、ノードの状態を手動で に変更することですdown
。これには管理者権限 (sudo アクセス許可) が必要です。
警告
次のコマンドを実行する前に慎重に進めてください。強制的にすべてのジョブを強制終了させるため、保存されていない作業はすべて失われる可能性があります。
scontrol update node=
<ip-ipv4>
state=down
reason="Action:Replace"