翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # SageMaker HyperPod クラスターの回復性 Slurm オーケストレーションによる SageMaker HyperPod には、次のクラスター耐障害性機能が用意されています。 **Topics** + [ヘルスモニタリングエージェント](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md) + [自動ノード復旧と自動再開](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) + [Slurm を使用してノードを手動で置換または再起動する](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md) # ヘルスモニタリングエージェント このセクションでは、アクセラレーター (GPU コアと Trainium コア) やネットワーク (EFA) などのデバイスに関する問題について、SageMaker HyperPod がクラスターインスタンスのヘルスを定期的にモニタリングするために使用するヘルスチェックのセットについて説明します。SageMaker HyperPod ヘルスモニタリングエージェント (HMA) は、各 GPU ベースまたは Trainium ベースのインスタンスのヘルスステータスを継続的にモニタリングします。インスタンスまたは GPU の障害を検出すると、エージェントはインスタンスを異常としてマークします。 SageMaker HyperPod HMA は、EKS オーケストレーターと Slurm オーケストレーターの両方で同じヘルスチェックを実行します。HMA の詳細については、「」を参照してください[ヘルスモニタリングシステム](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)。 # 自動ノード復旧と自動再開 **注記** 2025 年 9 月 11 日現在、HyperPod with Slurm オーケストレーションはヘルスモニタリングエージェントをサポートするようになりました。この機能を使用するには、[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) を実行し、AMI の最新バージョンに更新します。 このセクションでは、Amazon SageMaker HyperPod の 2 つの補完的なレジリエンス機能について説明します。手動による介入なしで障害のあるインフラストラクチャを置き換える自動ノード復旧と、ハードウェア障害後に最後のチェックポイントからトレーニングジョブを再開する自動再開機能です。 ## 自動ノード復旧の仕組み クラスターの作成または更新中、クラスター管理者ユーザーは、クラスターレベルで `Automatic` (推奨) から`None` のノード (インスタンス) 復旧オプションを選択できます。`Automatic` に設定すると、SageMaker HyperPod は障害のあるノードを自動的に再起動するか置き換えます。 **重要** `Automatic` オプションを設定することをお勧めします。デフォルトでは、クラスターは自動ノード復旧で設定されます。 自動ノード復旧は、ヘルスモニタリングエージェント、基本的なヘルスチェック、ディープヘルスチェックから問題が見つかったときに実行されます。`None` に設定した場合、障害が検出されるとヘルスモニタリングエージェントはインスタンスにラベルを付けますが、影響を受けるノードに対して修復または復旧アクションを自動的に開始しません。このオプションはお勧めしません。 ## Amazon SageMaker HyperPod 自動再開機能を使用したトレーニングジョブの実行 このセクションでは、SageMaker HyperPod の自動再開機能を使用してトレーニングジョブを実行する方法について説明します。これにより、16 ノードを超えるクラスターでハードウェア障害が発生した場合に、最後に保存したチェックポイントからトレーニングジョブを自動的に回復するゼロタッチ回復インフラストラクチャが提供されます。 自動再開機能を使用すると、ハードウェア障害またはトレーニング間の一時的な問題が原因でジョブが失敗した場合、SageMaker HyperPod 自動再開はノード置き換えワークフローを開始し、障害のあるノードが置き換えられた後にジョブを再開します。自動再開の使用中にジョブが失敗するたびに、次のハードウェアチェックが実行されます。 | Category | ユーティリティ名 | インスタンスタイプの互換性 | 説明 | | --- | --- | --- | --- | | アクセラレーター | NVIDIA SMI | GPU | [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) ユーティリティは、GPU を管理およびモニタリングするためのよく知られた CLI です。組み込みヘルスチェッカーは、nvidia-smi からの出力を解析して、インスタンスのヘルスを判断します。 | | アクセラレーター | Neuron sysfs | Trainium | Trainium 搭載インスタンスの場合、Neuron デバイスのヘルスは、Neuron ドライバーによって直接伝達される [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) からカウンターを読み取ることで決まります。 | | Network | EFA | GPU と Trainium | Elastic Fabric Adaptor (EFA) デバイスの診断に役立つように、EFA ヘルスチェッカーはインスタンス内で使用可能なすべての EFA カードを使用して一連の接続テストを実行します。 | **注記** [汎用リソース (GRES)](https://slurm.schedmd.com/gres.html) が Slurm ノードにアタッチされている場合、Slurm は通常、ノードの置き換えなど、ノード割り当ての変更を許可しないため、失敗したジョブを再開することはできません。明示的に禁止されていない限り、HyperPod 自動再開機能は GRES 対応ノードに関連付けられた障害のあるジョブを自動的にキューに入れ直します。このプロセスでは、ジョブを停止して、ジョブキューに戻した後、最初からジョブを再開します。 **Slurm で SageMaker HyperPod 自動再開機能を使用する** Slurm で SageMaker HyperPod 自動再開を使用する場合、`salloc` または `sbatch` を使用して取得した排他的割り当て内でジョブを実行する必要があります。いずれの場合も、ジョブを再開するときにすべての設定ステップが 1 つの `srun` コマンドで実行されるよう、エントリポイントスクリプトを変更する必要があります。エントリポイントスクリプトでは、停止前にジョブステップが実行されていた環境と一致するよう、置き換えられたノードに環境を設定することが重要です。次の手順は、エントリポイントスクリプトを準備して環境の一貫性を維持し、単一の`srun`コマンドとして実行する方法を示しています。 **ヒント** `sbatch` を使用する場合、環境を設定するための別個のスクリプトを作成し、1 つの `srun` コマンドを使用することにより、バッチスクリプトをシンプルに維持できます。 1. 次のコード例を使用してスクリプトを作成し、`train_auto_resume.sh` として保存します。このスクリプトは、置き換えられたノードに対して以前に手動設定が行われていないことを前提として、トレーニング環境のセットアップをデプロイします。これにより、環境がノードに依存しなくなるため、ノードが置き換えられると、ジョブを再開する前にノードで同じ環境がプロビジョニングされます。 **注記** 次のコード例は、ジョブに関連付けられた Slurm ノードリストを検出する方法を示しています。SageMaker HyperPod がジョブを自動的に再開すると、その値が古くなる可能性があるため、Slurm が提供する `$SLURM_JOB_NODELIST` 環境変数を使用しないでください。次のコード例は、`SLURM_JOB_NODELIST` を置き換える新しい `NODE_LIST` 変数を定義し、`NODE_LIST`変数から `MASTER_NODE` および `MASTER_ADDR` 変数を設定する方法を示しています。 ``` #!/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 \ " # Execute the torchrun command in the 'pytorch' Conda environment, # streaming output live /opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd ``` **ヒント** 上記のスクリプトを使用して、ジョブに追加の依存関係をインストールするためのコマンドを追加できます。ただし、依存関係インストールスクリプトは、クラスターの作成時に使用される[一連のライフサイクルスクリプト](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)に保持することをお勧めします。共有ディレクトリにホストされている仮想環境を使用する場合、このスクリプトを利用して仮想環境をアクティブ化することもできます。 1. ハードウェア障害が発生した場合に `srun` コマンドを自動的に再試行する必要があることを示すフラグ `--auto-resume=1` を追加することにより、SageMaker HyperPod 自動再開を有効にしてジョブを起動します。 **注記** `sbatch` または `salloc` を使用してリソース割り当てを設定した場合、割り当て内で複数の `srun` コマンドを実行できます。障害が発生した場合、SageMaker HyperPod 自動再開機能は、フラグ `--auto-resume=1` を持つ `srun` コマンドの現在の[ジョブステップ](https://slurm.schedmd.com/job_launch.html#step_allocation)でのみ動作します。つまり、`srun` コマンドで自動再開をアクティブ化しても、リソース割り当てセッション内で起動された他の `srun` コマンドには適用されません。 `auto-resume` が有効な `srun` コマンドの例を次に示します。 **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 を使用する** まず排他的割り当てを取得し、`--auto-resume` フラグとエントリポイントスクリプトを使用して `srun` コマンドを実行します。 ``` salloc -N 2 --exclusive srun --auto-resume=1 train_auto_resume.sh ``` ## 自動ノード復旧と自動再開が連携する方法 自動ノード復旧システムと自動再開システムの両方がアクティブな場合、障害を処理するための調整されたアプローチに従います。HMA がハードウェア障害を検出すると、ジョブレベルのステータスに関係なく、ノードはドレインとしてマークされます。ノードの自動復旧を有効にすると、ノードで実行されているすべてのジョブが終了すると、ノードは自動的に置き換えられます。このシナリオでは、自動再開が有効になっているジョブの場合、ステップにゼロ以外の終了ステータスがある場合、自動再開が開始されます (ノードが置き換えられるとジョブが再開されます）。自動再開が有効になっていないジョブは単に終了するため、管理者またはユーザーが手動で再送信する必要があります。 **注記** 自動再開を使用する場合、ハードウェア障害が検出されると、ノードは常に置き換えられます (再起動なし）。 # Slurm を使用してノードを手動で置換または再起動する このセクションでは、ノードを手動で再起動または置き換えるタイミングと、両方を行う方法について説明します。 ## ノードを手動で再起動または置き換えるタイミング HyperPod 自動再開機能は、Slurm ノードの状態が `fail` または `down` に変わるかどうかをモニタリングします。`sinfo` を実行することで、Slurm ノードの状態を確認できます。 ノードがスタックまたは応答せず、自動再開プロセスが復旧しない場合は、手動で復旧を開始できます。ノードの再起動と置き換えの選択は、問題の性質によって異なります。システムのハング、メモリリーク、GPU ドライバーの問題、カーネルの更新、ハングプロセスなど、一時的な問題やソフトウェア関連の問題が発生した場合は、再起動を検討してください。ただし、GPUs の障害、メモリまたはネットワークの障害、ヘルスチェックの失敗の繰り返し、複数回の再起動の試行後も応答しないノードなど、永続的またはハードウェア関連の問題が発生した場合は、ノードの交換が適しています。 ## ノードを手動で再起動または置き換える方法 SageMaker HyperPod には、手動ノード復旧のための 2 つの方法があります。推奨されるアプローチは、SageMaker HyperPod Reboot and Replace APIs を使用することです。これにより、すべてのオーケストレーターで動作するより高速で透過的な復旧プロセスが提供されます。または、 などの従来の Slurm コマンドを使用できますが`scontrol update`、このレガシーメソッドには Slurm のコントローラーノードへの直接アクセスが必要です。どちらの方法でも、同じ SageMaker HyperPod 復旧プロセスがアクティブ化されます。 ## 再起動 API を使用してノードを手動で再起動する **BatchRebootClusterNodes** を使用して、SageMaker HyperPod クラスター内の障害のあるノードを手動で再起動できます。 を使用してクラスターの 2 つのインスタンスで再起動オペレーションを実行する例を次に示します AWS Command Line Interface。 ``` aws sagemaker batch-reboot-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## 置き換え API を使用してノードを手動で置き換える **BatchReplaceClusterNodes** を使用して、SageMaker HyperPod クラスター内の障害のあるノードを手動で置き換えることができます。 を使用してクラスターの 2 つのインスタンスで置換オペレーションを実行する例を次に示します AWS Command Line Interface。 ``` aws sagemaker batch-replace-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## Slurm を使用してノードを手動で再起動する Scontrol Slurm コマンドを使用してノード復旧をトリガーすることもできます。これらのコマンドは Slurm コントロールプレーンと直接やり取りし、基盤となる同じ SageMaker HyperPod 復旧メカニズムを呼び出します。 次のコマンド で、 を、再起動する障害のあるインスタンスの Slurm ノード名 (ホスト名) に置き換えます。 ``` scontrol update node= state=fail reason="Action:Reboot" ``` これにより、ノードは指定された理由で FAIL としてマークされます。SageMaker HyperPod はこれを検出し、インスタンスを再起動します。オペレーション中は、ノードの状態を変更したり、Slurm コントローラーを再起動したりしないでください。 ## Slurm を使用してノードを手動で置き換える 次のように scontrol update コマンドを使用して、ノードを置き換えることができます。 次のコマンドで、 を置き換える障害のあるインスタンスの Slurm ノード名 (ホスト名) ``に置き換えます。 ``` scontrol update node= state=fail reason="Action:Replace" ``` このコマンドを実行すると、ノードは `fail`状態になり、現在実行中のジョブが終了するのを待ち、正常なインスタンスに置き換えられ、同じホスト名で復元されます。このプロセスにかかる時間は、アベイラビリティーゾーンで使用可能なインスタンスとライフサイクルスクリプトの実行にかかる時間によって異なります。更新および置き換えプロセス中は、ノードの状態を手動で変更したり、Slurm コントローラーを再起動したりしないでください。置き換えに失敗する可能性があります。長期間経過してもノードが回復されず、`idle` 状態にならない場合、[AWS サポート](https://console.aws.amazon.com/support/)にお問い合わせください。 ## ノードを手動で強制変更する 障害のあるノードが継続的に `fail` 状態のままになっている場合、最後の手段として、ノードの状態を手動で強制的に `down` に変更してみることもできます。これには、管理者権限 (sudo アクセス許可) が必要です。 **警告** 次のコマンドを実行するとすべてのジョブが強制終了され、保存されていない作業がすべて失われる可能性があるため、実行する前に慎重に進めてください。 ``` scontrol update node= state=down reason="Action:Replace" ```