AWS ParallelCluster の GPU ヘルスチェックを G4dn インスタンスで試してみた
はじめに
GPU インスタンスで長時間のトレーニングジョブを走らせていると、GPU 障害によってジョブが途中で失敗することがあります。障害発生後に手作業でノードを切り離し、ジョブを再投入する作業は手間がかかります。AWS ParallelCluster 3.6.0 で導入された GPU ヘルスチェック機能を使うと、ジョブ開始前に GPU の健全性を診断し、不良ノードへのジョブ割り当てを未然に防げます。というわけで、GPU ヘルスチェックの動作について確認した結果を共有します。
確認結果
ParallelCluster v3.15.1 で GPU ヘルスチェックを g4dn.xlarge のキューに設定し、GPU ジョブ投入時の動作をログで確認しました。
GPU ヘルスチェックは ジョブ実行前に走ります。Slurm prolog として DCGM 診断を実施し、Pass すればジョブ本体に進みます。g4dn.xlarge では約 18 秒で完了しました。
ヘルスチェックに失敗したジョブは、別の GPU インスタンスで実行されます。失敗ノードは DRAIN になり新規ジョブを受け付けなくなります。nohold_on_prolog_fail 設定により再キューされたジョブが、健全な別ノードに割り当てられます。
| 観点 | 結果 |
|---|---|
| 検証バージョン | AWS ParallelCluster v3.15.1（ap-northeast-1・ubuntu2404） |
| ヘルスチェック実行タイミング | ジョブ開始直前（Slurm prolog） |
| DCGM 診断結果 | software / memory / pcie が全て Pass（DCGM level 2、g4dn.xlarge で所要 約 18 秒） |
| ヘルスチェックのログ保存先 | コンピュートノード上 /var/log/parallelcluster/slurm_health_check.log / CloudWatch Logs |
| 失敗時の動作 | ノードが DRAIN → ジョブ再キュー → 別の健全なノードで実行 |
検証環境
- AWS ParallelCluster 3.6.0 以降（検証は v3.15.1 で実施）
- 対象リージョン: ap-northeast-1（東京）
- NVIDIA GPU を搭載したインスタンスタイプ（本記事では
g4dn.xlargeを使用）
ParallelCluster における GPU ヘルスチェックとは
GPU ヘルスチェックは、Slurm の prolog スクリプトとして動作します。prolog とは、ジョブ本体が実行される直前にスケジューラが呼び出すスクリプトです。
具体的には 90_pcluster_health_check_manager がプロローグとして実行されます。このスクリプトが NVIDIA DCGM（Data Center GPU Manager）の dcgmi コマンドを使い、run level 2 のヘルスチェックを実行します。
DCGM とはなにかというと、NVIDIA が提供する GPU の監視・診断ツールで、GPU の各種状態をプログラムから取得・検査できます。
チェック項目は次の 4 点です。
- NVIDIA ソフトウェアスタックの動作確認
- PCIe / NVLink のステータス
- GPU メモリ機能
- GPU メモリ帯域
チェック実行中は nvidia-dcgm / nvidia-fabricmanager サービスと GPU 永続化モードを一時的に有効化し、終了後に初期状態へ戻します。特定の GPU セットにジョブが割り当てられていればその GPU のみを対象とし、割り当てがなければノード上の全 GPU を対象とします。
同一ノードへの同時チェック要求が複数ある場合は最初の 1 件だけ実行されます。残りはスキップされるため、多数のジョブが同時起動しても診断が重複しません。
If a compute node receives 2 or more
Gpuhealth check requests at the same time, only the first health check runs and the others are skipped.
やってみた
クラスター設定ファイルの作成
GPU ヘルスチェックを有効化するには、クラスター設定ファイルの HealthChecks.Gpu.Enabled を true にするだけです。設定箇所は 2 か所から選べます。
SlurmQueues[].HealthChecks.Gpu.Enabled（キュー全体に適用）SlurmQueues[].ComputeResources[].HealthChecks.Gpu.Enabled（個別コンピュートリソースに適用。キューレベルの設定を上書き）
今回はキューレベルで有効化します。
Region: ap-northeast-1
Image:
Os: ubuntu2404
Tags:
- Key: Name
Value: cluster-v3.15.1-gpu-healthcheck
HeadNode:
InstanceType: t3a.small
Networking:
ElasticIp: false
SubnetId: subnet-xxxxxxxxxxxxxxxxx
LocalStorage:
RootVolume:
Size: 45
Encrypted: true
VolumeType: gp3
Iops: 3000
Throughput: 125
Iam:
AdditionalIamPolicies:
- Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Scheduling:
Scheduler: slurm
SlurmSettings:
ScaledownIdletime: 5
SlurmQueues:
- Name: gpu
HealthChecks:
Gpu:
Enabled: true # GPU ヘルスチェックを有効化
ComputeResources:
- Name: g4dn
Instances:
- InstanceType: g4dn.xlarge
MinCount: 0
MaxCount: 1
ComputeSettings:
LocalStorage:
RootVolume:
Size: 45
Encrypted: true
VolumeType: gp3
Iops: 3000
Throughput: 125
CapacityType: ONDEMAND
Networking:
SubnetIds:
- subnet-xxxxxxxxxxxxxxxxx
Iam:
AdditionalIamPolicies:
- Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Monitoring:
Logs:
CloudWatch:
Enabled: true
RetentionInDays: 180
DeletionPolicy: "Delete"
Dashboards:
CloudWatch:
Enabled: false
クラスターの作成
設定ファイルをローカルに保存し、クラスターを作成します。
pcluster create-cluster \
--cluster-name gpu-healthcheck-test \
--cluster-configuration cluster-config.yaml
キーペア未指定の KeyPairValidator 警告は、Session Manager 接続するため無視します。
{
"cluster": {
"clusterName": "gpu-healthcheck-test",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:<ACCOUNT_ID>:stack/gpu-healthcheck-test/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"region": "ap-northeast-1",
"version": "3.15.1",
"clusterStatus": "CREATE_IN_PROGRESS",
"scheduler": {
"type": "slurm"
}
},
"validationMessages": [
{
"level": "WARNING",
"type": "KeyPairValidator",
"message": "If you do not specify a key pair, you can't connect to the instance unless you choose an AMI that is configured to allow users another way to log in"
}
]
}
CloudFormation スタックの作成が始まります。完了まで 20 分程度かかります。
pcluster describe-cluster \
--cluster-name gpu-healthcheck-test \
--query "clusterStatus"
"CREATE_COMPLETE"
ヘッドノードへの接続とキュー状態の確認
クラスター作成が完了したら、ヘッドノードに Session Manager で接続します。ヘッドノードのインスタンス ID は次のコマンドで確認できます。
pcluster describe-cluster \
--cluster-name gpu-healthcheck-test \
--query "headNode.instanceId"
Session Manager では ssm-user で接続されるため、sudo su - ubuntu で ubuntu ユーザーに切り替えてから Slurm コマンドを実行します。sinfo でキューとノードの状態を確認します。
sinfo
idle~ はコンピュートノードがまだ起動していない（オンデマンドでスケールアップを待っている）状態です。
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
gpu* up infinite 1 idle~ gpu-dy-g4dn-1
GPU ジョブの投入
GPU を 1 基要求し、nvidia-smi を実行する簡単なジョブスクリプトを作成して投入します。sleep 120 は、コンピュートノード上でログを確認する時間を確保するために入れています。
cat << 'EOF' > gpu_job.sh
#!/bin/bash
#SBATCH --partition=gpu
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --gres=gpu:1
#SBATCH --job-name=gpu-hc-test
sleep 120
nvidia-smi
EOF
sbatch gpu_job.sh
Submitted batch job 2
squeue でジョブの状態を確認します。投入直後はコンピュートノードが未起動のため PD（Pending）です。
squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 gpu gpu-hc-t ubuntu PD 0:00 1 (None)
コンピュートノードの起動には数分かかります。sinfo で見るとノードの状態が idle~ → mix~（起動要求）→ mix#（起動処理中、約 3 分）→ mix（ジョブ実行中）と遷移します。mix になるとジョブが R（Running）へ変わります。
squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 gpu gpu-hc-t ubuntu R 0:05 1 gpu-dy-g4dn-1
R（Running）になったタイミングでは、prolog の GPU ヘルスチェックは完走しています。
ヘルスチェックログの確認（ノード上）
ジョブが Running になった後、コンピュートノードに Session Manager で接続してログを確認します。接続先のインスタンスは、squeue のノード名（gpu-dy-g4dn-1）から EC2 コンソールや Fleet Manager で特定できます。
接続後、ヘルスチェックログを確認します。
sudo cat /var/log/parallelcluster/slurm_health_check.log
software / memory / pcie が全て Pass と出力されていることを確認します。
2026-06-13 02:24:46,026 - [90_pcluster_health_check_manager] - INFO - Job 2 - Calling ParallelCluster Health Check Manager for queue (gpu) and compute resource (g4dn)
2026-06-13 02:24:46,133 - [health_check_manager.py:main] - INFO - JobID 2 - HealthCheckManager startup.
2026-06-13 02:24:46,151 - [health_check_manager.py:_execute_health_checks] - INFO - JobID 2 - Executing Health Check 'Gpu' for queue 'gpu' and compute resource 'g4dn'
2026-06-13 02:24:46,194 - [gpu_health_check.sh] - INFO - JobID 2 - GPU list is 'GPU 0: Tesla T4 (UUID: GPU-f8399bfa-1b17-56a1-a4af-097b824130f5)'
2026-06-13 02:24:46,208 - [gpu_health_check.sh] - INFO - JobID 2 - Starting nvidia-dcgm service since it is not running
2026-06-13 02:24:46,392 - [gpu_health_check.sh] - INFO - JobID 2 - Persistence mode already enabled for target GPU '0'
2026-06-13 02:24:46,403 - [gpu_health_check.sh] - INFO - JobID 2 - Running GPU Health Check with DCGMI level 2
Successfully ran diagnostic for group.
+---------------------------+------------------------------------------------+
| Diagnostic | Result |
+===========================+================================================+
|----- Metadata ----------+------------------------------------------------|
| DCGM Version | 4.5.1 |
| Driver Version Detected | 580.126.20 |
| GPU Device IDs Detected | 1eb8 |
|----- Deployment --------+------------------------------------------------|
| software | Pass |
| | GPU0: Pass |
+----- Hardware ----------+------------------------------------------------+
| memory | Pass |
| | GPU0: Pass |
+----- Integration -------+------------------------------------------------+
| pcie | Pass |
| | GPU0: Pass |
+---------------------------+------------------------------------------------+
2026-06-13 02:25:03,378 - [gpu_health_check.sh] - INFO - JobID 2 - The GPU Health Check succeeded
2026-06-13 02:25:03,379 - [gpu_health_check.sh] - INFO - JobID 2 - Restoring previous configurations
2026-06-13 02:25:03,380 - [gpu_health_check.sh] - INFO - JobID 2 - Stopping nvidia-dcgm service
2026-06-13 02:25:04,472 - [health_check_manager.py:main] - INFO - JobID 2 - HealthCheckManager finished with exit code '0'.
ログから次の流れが確認できます。
- prolog
90_pcluster_health_check_managerがジョブ 2 の開始直前に起動 - GPU を検出し、Tesla T4 の UUID・シリアル番号を記録
nvidia-dcgmサービスが未起動のため一時的に起動し、チェック後に停止して元の状態へ復元（GPU 永続化モードは元から有効のため変更なし）- DCGM level 2 の診断で software / memory / pcie が全て
Pass The GPU Health Check succeededを出力してジョブ本体へ進む
健全な GPU では結果に Pass のみが並びます。異常があれば Warning / Fail が出力され、後述の失敗時の動作に移ります。
CloudWatch Logs でのログ確認
同じログは CloudWatch でも確認できます。ロググループ名はクラスター名に作成時のタイムスタンプが付いた形式で、今回は /aws/parallelcluster/gpu-healthcheck-test-202606130137 でした。この中にノードごとのログストリームが自動作成されます。
aws logs describe-log-streams \
--log-group-name /aws/parallelcluster/gpu-healthcheck-test-202606130137 \
--query 'logStreams[?contains(logStreamName, `slurm_health_check`)].logStreamName'
[
"ip-10-0-0-215.i-068bcc70a24e4f591.slurm_health_check",
"ip-10-0-0-215.i-068bcc70a24e4f591.slurm_health_check_events"
]
この中にコンピュートノード内で確認したログと同じ内容が保存されています。
ジョブ完了の確認
sleep 120 の後に nvidia-smi が実行され、ジョブが完了します。squeue が空になれば完了です。
squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
ジョブの標準出力（slurm-<ジョブID>.out）で nvidia-smi の結果を確認します。
cat ~/slurm-2.out
Sat Jun 13 02:27:04 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.126.20 Driver Version: 580.126.20 CUDA Version: 13.0 |
+-----------------------------------------+------------------------+----------------------+
| 0 Tesla T4 On | 00000000:00:1E.0 Off | 0 |
| N/A 31C P8 13W / 70W | 0MiB / 15360MiB | 0% Default |
+-----------------------------------------+------------------------+----------------------+
ヘルスチェックが Pass した後に、ジョブ本体の nvidia-smi が GPU インスタンス上で実行されています。
ヘルスチェック失敗時の挙動（仕様）
実際に GPU 障害を注入する検証は今回実施していないため、公式ドキュメントの仕様を整理します。
- ヘルスチェック失敗 → ノードが
DRAIN状態になる DRAINノードには新規ジョブが割り当てられない- 実行中のジョブはそのまま完了まで継続
- 動的ノード: 全ジョブ完了後にインスタンスが終了
- 静的ノード: 全ジョブ完了後にインスタンスが置換
If a compute node fails a
Gpuhealth check, the compute node state changes toDRAIN. New jobs don't start on this node. Existing jobs run to completion. After all running jobs complete, the compute node terminates if it's a dynamic node, and it's replaced if it's a static node.
なお prolog（ヘルスチェック）で失敗したジョブは再キューされ、別の健全なノードで実行されます。 ParallelCluster の Slurm 設定に SchedulerParameters=nohold_on_prolog_fail が含まれているため、prolog 失敗時にジョブが HOLD されず再キューに戻ります。失敗ノードは DRAIN になるため、再キューされたジョブは別のノードに割り当てられます。
抑えておきたいポイント
私が把握したかった内容はこの辺りと、1 つ上のヘルスチェック失敗時の挙動です。
prolog ハング
特定のインスタンスタイプでヘルスチェックが長引くと "Prolog hung" エラーが発生します。BatchStartTimeout のデフォルトは 180 秒（3 分）です。p4d.24xlarge でのチェックは約 3 分かかるとされており、タイムアウトの調整が必要になる場合があります。今回の g4dn.xlarge（NVIDIA T4・単一 GPU）では約 18 秒で完了し、この問題は起きませんでした。
他の検証事例では、p5.48xlarge（H100 x8）で約 5 分かかりタイムアウトしたという報告があります。公式ドキュメントには「8 GPU ノードで 3 分以下」と記載されていますが、NVSwitch / NVLink を持つ P5 のような複雑な GPU トポロジーでは診断が長引くことが考えられます。既知の問題として扱われており、ParallelCluster の GitHub Wiki にも同様の記載があります。
ジョブ開始までの時間が伸びる
ヘルスチェックは prolog として同期実行されるため、ジョブ開始までに数秒〜数分の遅延が発生します。短時間ジョブを多数並列投入する場合はオーバヘッドが大きいため、ヘルスチェックの有効・無効を使い分けてください。
GPU メモリが大量のインスタンス
合計 GPU メモリが 327680 MiB（約 320 GB）を超えるインスタンスタイプでは、GPU ヘルスチェックの有効化は推奨されていません。 合計 GPU メモリが大きいインスタンスタイプを使う場合は、事前に GPU メモリ合計を確認してください。
まとめ
確認したかった挙動は次の 2 点です。
GPU ヘルスチェックは ジョブ実行前に走ります。Slurm prolog として DCGM 診断を実施し、Pass すればジョブ本体に進みます。診断は g4dn.xlarge で約 18 秒でした。
ヘルスチェックに失敗したジョブは、別の GPU インスタンスで実行されます。失敗ノードは DRAIN になり新規ジョブを受け付けなくなります。nohold_on_prolog_fail 設定により再キューされたジョブが、健全な別ノードに割り当てられます。
おわりに
ParallelCluster でも 1 行の設定で DCGM 診断を prolog に組み込めるとわかりました。HyperPod の Deep Health Check と比べ、なにがどうできるのかを把握したかったので試してみた結果の共有でした。
