Vertex AI Training クラスタには、コンピューティング ノードの信頼性と Slurm ジョブの安定性を確保するための包括的なヘルスチェック システムが統合されています。このシステムには、自動復元オプションと手動復元オプションの両方が用意されています。ジョブの実行中に自動プロセスが実行され、GPU の健全性やディスク使用量などの重要なコンポーネントをモニタリングして、障害が発生したノードを自動的に置き換えます。ユーザーの介入が必要な状況では、トレーニング クラスタに reportFaultyNodes API が用意されています。この API を使用すると、障害のある特定のノードを手動で削除する、あるいは基盤となるホストでのハードウェア障害の疑いを報告する、といったことが可能です。
テスト ワークロードを実行して GPU の機能を確認する
ステップ 1: SSH を使用してクラスタノードに接続する
Cloud Shell または Google Cloud コンソールから、IAP を使用してログインノードに接続します。次の例は、Cloud Shell のコマンドを示しています。
gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID
ステップ 2: 標準の Slurm コマンドを実行する
ログインノードに接続したら、いくつかの標準の Slurm コマンドを実行してクラスタが正常に機能していることを確認します。
~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
partition1* up infinite 2 idle hcsa3m1236-a3mnodeset-[0-1]
次に、バッチジョブを送信します。
~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"
ホーム ディレクトリに slurm-job-id.out ファイルが作成されていることを確認します。
ステップ 3: GPU ワークロードを実行する
次の内容を、test.sh という名前のスクリプト ファイルとしてホーム ディレクトリに保存します。
#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi
srun nvidia-smi -L
スクリプトの権限を 755 に設定して実行可能にし、Slurm ジョブを送信します。
~$ sbatch ./test.sh
Slurm は、スクリプトの出力を slurm-job-id.out という名前のファイルに保存します。
予想される出力:
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)
クラスタの健全性の検証
このセクションでは、トレーニング クラスタ イメージにプリインストールされている Cluster Health Scanner（CHS）ツールを使用して、トレーニング クラスタをテストする方法について説明します。CHS ツールはクラスタの健全性をチェックします。DCGM 診断や NCCL テストなどのテストを実行して、クラスタでワークロードを実行する準備ができていることを確認します。
クラスタのログインノードから次のスクリプトを実行し、CHS ツールを使用してテストを実行できます。
export CLUSTER_ID=<your_cluster_id>
export PARTITION=a3u
export MACHINE_TYPE=a3-ultragpu-8g
cd ~
/opt/cluster-health-scanner/deploy/slurm/cluster-validation.sh \
--nodelist=${CLUSTER_ID}-${PARTITION}-[0-1] \
--nodes=2 \
--partition=${PARTITION} \
--machine-type=${MACHINE_TYPE} \
--relative-exec-path=../../opt/cluster-health-scanner/deploy/slurm \
--results-dir=results
テストが正常に実行されると、次の 2 つの結果が返されます。
- 概要出力: 概要がコンソールに出力されます。次の例のようになります。
- 詳細ログ: 完全なレポートについては、
~/resultsディレクトリに保存されている詳細ログをご覧ください。
Starting DCGM Diagnostics...
DCGM diagnostics passing on all nodes!
Starting NCCL all_reduce_perf...
CURR_NODES: cluster-id-0
cluster-id-1
NCCL test passing on all nodes!
自動ヘルスチェックと復元
ノードの信頼性を確保するため、トレーニング クラスタは次の自動チェック スイートを使用してノードの健全性を継続的にモニタリングします。トレーニング クラスタは、Slurm の prolog（ジョブの開始前）と epilog（ジョブの完了後）でヘルスチェックを実行します。
ヘルスチェック スイート
- GPU の健全性:
nvidia-smi、dcgmi、xidコードのモニタリングなど、個々の GPU の詳細な診断を行います。 - ディスク使用量: 重要なパーティション（
/、/mnt/localssd、/mnt/localdisk）のディスク使用量が多いかどうかを確認し、容量不足によるジョブの失敗を防ぎます。 - ネットワークの健全性: プライマリ ネットワーク インターフェースに IPv4 アドレスがあることを確認します。問題が見つかった場合は、インターフェースをリセットして自己修復を試みます。
- CPU 負荷: システムの負荷の平均をモニタリングし、事前定義されたしきい値を超えた場合は警告をログに記録します。
障害復旧プロセス
チェックで回復不能な重大なエラーが検出されると、Vertex AI Training クラスタは自動的に障害復旧プロセスを開始します。標準プロセスには、障害のあるノードのドレイン、影響を受ける Slurm ジョブの再キュー、ドレインされたノードの削除と再作成、正常な状態への復元が含まれます。
この自動復元には、次の条件が適用されます。
再起動の制限: 影響を受ける Slurm ジョブがすでに設定された回数だけ再起動されている場合、復元プロセスはスキップされます。
GPU 使用率: ノードで実行されているジョブで使用可能なすべての GPU が使用されていない場合も、ノードの削除と再作成はスキップされます。この場合、ノードがドレインされるだけで、新しいジョブがスケジュールされないようにします。
障害のあるコンピューティング ノードを手動で管理する
トレーニング クラスタは、障害のあるコンピューティング ノードを手動でレポートして管理するための API を提供します。これは、自動ヘルスチェックで問題が解決しない場合に特に役立ちます。これらのオペレーションは、一度に 1 つのノードでのみ実行できます。
| アクション | 説明 | 最適な用途 |
|---|---|---|
| ノードを削除する | 指定された障害のあるノードをクラスタから削除します。これがデフォルトのアクションです。 | 一般的なエラーが発生した場合、またはノードが応答せず、リサイクルが必要な場合。 |
| ホストの不具合を報告する | 基盤となる物理ホストに障害が発生したことを報告し、修復プロセスまたは移行プロセスをトリガーします。 | GPU ノードをホストする物理マシンでハードウェア障害が発生した可能性がある場合。 |
アクション 1: 障害のあるノードを削除する
このアクションでは、指定されたノードを削除します。このオペレーションの結果は、ノードが Slurm によって「静的」または「動的」のどちらに分類されるかによって異なります。
静的ノード: 削除されたノードのインデックスがノードプールの最小ノード数よりも小さい場合、同じ名前と仕様で新しいコンピューティング ノードが再作成されます。
動的ノード: 削除されたノードのインデックスが最小ノード数より大きい場合、そのノードにスケジュール設定された保留中のワークロードがある場合にのみ再作成されます。それ以外の場合は削除されます。
これらの例では、API エンドポイントを操作するための便利な認証済みショートカットである gcurl エイリアスを使用します。次のコマンドでは、必要な認証ヘッダーを含む curl のエイリアスを作成します。
alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'
ノードを削除する API リクエスト
障害のあるノードを削除するには、次の POST リクエストを実行します。NODE_ID は CLUSTER_ID-NODEPOOL_ID-INDEX の形式にする必要があります。
gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'
オペレーションのステータスを確認する
オペレーションのステータスを確認することで、reportFaultyNodes アクションの結果をモニタリングできます。
gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID
アクション 2: ホストの不具合を報告する
ハードウェア障害が疑われる場合は、GPU ノードの物理ホストを障害として報告できます。
サポートされている VM: A3 Ultra と A4 High-GPU
ノードの状態: API を呼び出す前に、ターゲット ノードが
RUNNING状態になっている必要があります。呼び出しが成功するとREPAIRINGに移行し、ホストが修復されるか、新しいホストでノードが再作成されるとRUNNINGに戻ります。これはベスト エフォート型のオペレーションです。
前提条件: IAM ロールを付与する
この機能を使用するには、Vertex AI サービス エージェントに Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）ロールを付与する必要があります。
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") gcloud projects add-iam-policy-binding PROJECT_ID\ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.iam.gserviceaccount.com" \ --role="roles/compute.instanceAdmin.v1"
ホストを報告する API リクエスト
次の POST リクエストを実行して、基盤となるホストを障害ありとして報告します。その際、faultReasons に対して観察された動作と説明を 1 つ以上指定する必要があります。
behavior フィールドには、次のいずれかの値を使用する必要があります。
| 動作 | 説明 |
|---|---|
PERFORMANCE |
VM に接続されている GPU は、クラスタ内の他の GPU と比較してパフォーマンスに問題があります。ログに XID エラーが表示されず、Compute Engine でサイレント データ破損などの他の一般的な障害パターンが検出されていません。 |
SILENT_DATA_CORRUPTION |
VM でデータ破損が発生していますが、VM の実行は継続されています。これは、vCPU の不良、ソフトウェアのバグ、カーネルの問題などが原因で発生することがあります。 |
UNRECOVERABLE_GPU_ERROR |
XID で修復不可能な GPU エラーを特定しました。 |
BEHAVIOR_UNSPECIFIED |
VM の問題が不明です。 |
API リクエストの例を次に示します。
gcurl -X POST \
https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
-d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'
すべてを組み合わせる
自動ヘルスチェックとこのページで説明する手動制御の両方を活用することで、復元力の高いトレーニング環境を維持できます。障害のあるノードの削除や、ハードウェアの問題の報告によって、クラスタの健全性を積極的に管理することで、最大稼働時間とトレーニング ジョブの正常な完了を確保できます。問題が解決しない場合や複雑な場合は、 Google Cloud サポートチームに相談して、詳細な診断とサポートを受けることを検討してください。
次のステップ
フォールト トレラント用にトレーニング クラスタを構成することは、完全でプロダクション レディな MLOps ワークフローを構築するうえで重要なステップです。
- トレーニング ジョブをモニタリングしてデバッグする: トレーニング ジョブの進行状況、リソース使用率、健全性を追跡します。これには、ノードが復元されたときや、障害のためにジョブが再起動されたときを特定する方法も含まれます。
- Vertex AI Pipelines で復元可能なジョブをオーケストレートする: 本番環境では、Vertex AI Pipelines を使用して、復元可能なトレーニング ジョブをクラスタに送信する自動化された反復可能なワークフローを作成します。
- モデルの管理とデプロイ: 復元力のあるトレーニング ジョブが完了したら、Vertex AI Model Registry を使用してモデル アーティファクトをバージョン管理してから、モデルをエンドポイントにデプロイしてオンライン推論リクエストを処理します。