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

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

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

SageMaker HyperPod には、次のクラスターの回復性機能があります。

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

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

カテゴリ ユーティリティ名 インスタンスタイプの互換性 説明
アクセラレーター DCGM ポリシー GPU クラスター内の各インスタンスは、 のXIDエラーを含むすべての GPU関連ポリシーを継続的にモニタリングしますNVIDIADCGM
アクセラレーター NVIDIA SMI GPU nvidia-smi ユーティリティは、 を管理およびモニタリングCLIするためによく知られていますGPUs。組み込みヘルスチェッカーは、 からの出力を解析nvidia-smiして、インスタンスのヘルスを判断します。
アクセラレーター Neuron sysfs Trainium Trainium 搭載インスタンスの場合、Neuron デバイスの正常性は、Neuron ドライバーによって直接伝達される Neuron sysfs のカウンターを読み取ることによって決まります。
ネットワーク EFA GPU および Trainium Elastic Fabric Adaptor (EFA) デバイスの診断に役立つように、EFAヘルスチェッカーは、インスタンス内で使用可能なすべてのEFAカードを使用して一連の接続テストを実行します。
ストレス DCGM 診断 GPU DCGM 診断レベル 2 は、システムGPUs内で を実習し、健康に関する徹底的な洞察を得るためにプレッシャーにさらすために使用されます。
ストレス CPU ストレス GPU および Trainium CPU ヘルスは Linux ストレスツールを使用して決定されます。このツールは、複数のスレッドを実行して 100% のCPU使用率を実現し、I/O オペレーションを実行します。

自動再開

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

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

注記

汎用リソース (GRES) が Slurm ノードにアタッチされている場合、通常、Slurm はノードの置き換えなどのノード割り当ての変更を許可しないため、 は失敗したジョブを再開できません。明示的に禁止されていない限り、 HyperPod 自動再開機能は、 GRESが有効なノードに関連付けられた障害のあるジョブを自動的に再キューに入れます。このプロセスでは、ジョブを停止し、ジョブキューに戻し、ジョブを最初から再開します。

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

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

ヒント

を使用する場合sbatch、環境を設定するための個別のスクリプトを作成し、単一のsrunコマンドを使用することで、バッチスクリプトをシンプルに維持できます。

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

    注記

    次のコード例は、ジョブに関連付けられた Slurm ノードリストを検出する方法を示しています。Slurm が提供する$SLURM_JOB_NODELIST環境変数は使用しないでください。この値は、ジョブを SageMaker HyperPod 自動再開した後に古くなる可能性があるためです。次のコード例は、 を置き換える新しいNODE_LIST変数を定義しSLURM_JOB_NODELISTMASTER_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
    ヒント

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

  2. ハードウェアに障害が発生した場合にsrunコマンドを自動的に再試行する必要があることを示す フラグを追加して--auto-resume=1、 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"

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

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

障害のあるノードが fail状態で継続的に停止している場合、最後に試行する手段は、ノードの状態を手動で に強制変更することですdown。これには管理者権限 (sudo 権限) が必要です。

警告

次のコマンドを実行する前に注意して進めてください。強制的にすべてのジョブが強制終了され、保存されていない作業がすべて失われる可能性があります。

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