翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ディープヘルスチェック
SageMaker HyperPod は、Slurm がオーケストレーションしたクラスターインスタンスに対して*ディープヘルスチェック*を実行し、基盤となるハードウェアとインフラストラクチャの信頼性と安定性を確保します。ディープヘルスチェックは、インスタンスがクラスターに作成または追加されたとき (*オンスタート*) に自動的に実行することも、[StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html) API を使用していつでも手動で (*オンデマンド*で) トリガーすることもできます。このプロアクティブアプローチは、クラスターのライフサイクル全体で潜在的な問題を特定して軽減するのに役立ちます。
ディープヘルスチェック中、影響を受けるノードは Slurm メンテナンス予約に配置され、ジョブがスケジュールされないようにします。すべてのチェックに合格すると、ノードは予約から解放され、ワークロードで使用できるようになります。
**重要**
ディープヘルスチェックを使用するには、最新の AMI バージョンに更新する必要があります。[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) を実行して、AMI の最新バージョンに更新します。古い AMI バージョンで実行している場合、ディープヘルスチェックが期待どおりに機能しない可能性があります。
## ディープヘルスチェックタイプ
SageMaker HyperPod は、Slurm クラスターの 2 つのカテゴリのディープヘルスチェックをサポートしています。
+ **InstanceStress** — ハードウェアストレステスト (CPU、メモリ、ディスク、GPU/PCI 検証）、DCGM GPU 診断、EFA ループバック接続などのインスタンスレベルのテストを実行します。これにより、個々のノードハードウェアの状態が検証されます。
+ **InstanceConnectivity** — 複数のノードでクラスターレベルの NCCL (NVIDIA Collective Communications Library) テストを実行して、ノード間の GPU 通信パフォーマンスを検証します。このチェックは、マルチノード GPU 通信機能を備えたインスタンスでのみサポートされます。
## SageMaker HyperPod によって行われたディープヘルスチェックのリスト
SageMaker HyperPod は、次のディープヘルスチェックを実行します。
**インスタンスレベルのディープヘルスチェック (InstanceStress)**
| Category | ユーティリティ名 | インスタンスタイプの互換性 | 説明 |
| --- | --- | --- | --- |
| アクセラレーター | GPU/NVLink の数 | GPU | GPU/NVLink の数を検証します。 |
| アクセラレーター | [DCGM 診断](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html)レベル 4 | GPU | 追加のメモリテストなど、レベル 4 で DCGM (NVIDIA Data Center GPU Manager) 診断 GPU を実行して、NVIDIA GPU の状態と機能を評価します。一般的な所要時間: GPU の数に応じて最大 45～90 分。 |
| Network | EFA | GPU | アタッチされた EFA デバイスで EFA ループバック帯域幅とレイテンシーテストを実行します。一般的な所要時間: 2～5 分。 |
**クラスターレベルのディープヘルスチェック (InstanceConnectivity)**
| Category | ユーティリティ名 | インスタンスタイプの互換性 | 説明 |
| --- | --- | --- | --- |
| アクセラレーター | NCCL テスト | GPU | 複数のノードで NCCL all\_reduceパフォーマンステストを実行して、ノード間の GPU 通信帯域幅を検証します。一般的な所要時間: ノード数に応じて 5～15 分。 |
## 起動時のディープヘルスチェック
起動時のディープヘルスチェックは、インスタンスが最初にプロビジョニングされたとき、つまりクラスターの作成時または [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) 経由で新しいインスタンスが追加されたときに自動的に実行されます。これにより、すべてのノードがワークロードを受け入れる前にハードウェア検証に合格します。
### 起動時のディープヘルスチェックの有効化
起動時のディープヘルスチェックを有効にするには、クラスターを作成または更新するときにインスタンスグループ設定で `OnStartDeepHealthChecks`パラメータを指定します。
**例: 起動時のディープヘルスチェックを使用してクラスターを作成する**
```
aws sagemaker create-cluster \
--cluster-name {{my-slurm-cluster}} \
--instance-groups '[
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "worker-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 4,
"LifeCycleConfig": {
"SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
"ThreadsPerCore": 1,
"OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
}
]' \
--vpc-config '{"SecurityGroupIds":["{{sg-12345678}}"],"Subnets":["{{subnet-12345678}}"]}'
```
### 起動時のディープヘルスチェック中に何が起こるか
起動時のディープヘルスチェックを有効にすると、次のプロセスが発生します。
1. **ノードプロビジョニング**: 新しいインスタンスが起動され、ライフサイクルスクリプトが実行されます。
1. **ノード分離**: HyperPod クラスターエージェントは、新しいノードを Slurm メンテナンス予約 (`hyperpod-deep-health-check`) に配置し、`hyperpod-system-maintenance`パーティションに追加します。ノードは Slurm 機能 でマークされます`SageMakerDeepHealthCheck:InProgress`。これにより、テスト中にジョブがこれらのノードでスケジュールされるのを防ぐことができます。
1. **テスト実行**: 次のテストは、`InstanceStress`チェックの一部として各ノードで実行されます。
+ **HARDWARE\_CHECK**: CPU、メモリ、ディスクのストレステスト`stress-ng`を実行し、GPU と PCI デバイスの数を検証します。一般的な所要時間: \~1～2 分。
+ **DCGM**: GPU メモリテストを含む NVIDIA DCGM 診断をレベル 4 で実行します。一般的な所要時間: GPU の数に応じて最大 45～90 分。
+ **EFA**: EFA ループバック帯域幅とレイテンシーテストを実行します。一般的な所要時間: 2～5 分。
`InstanceConnectivity` も有効になっている場合、次の追加テストが実行されます。
+ **NCCL**: 複数のノードで NCCL `all_reduce`パフォーマンステストを実行して、ノード間の GPU 通信帯域幅を検証します。一般的な所要時間: ノード数に応じて 5～15 分。
1. **結果処理**:
+ **合格**: ノードはメンテナンス予約から削除され、ディープヘルスチェック機能はクリアされ、ノードは割り当てられたパーティション内のジョブで使用可能になります。
+ **失敗**: ノードは分離されたままです。SageMaker HyperPod は、障害が発生したノードを自動的に置き換え、置き換え時にディープヘルスチェックを実行します。
クラスターは、少なくともコントローラーノードが実行されている 1 `InService`回 に移行します。ワーカーノードはテスト中に`DeepHealthCheckInProgress`ステータスを表示し、合格`Running`後に に移行します。
### 起動時のディープヘルスチェックのモニタリング
Amazon SageMaker AI API または Slurm コマンドを使用して、起動時のディープヘルスチェックのステータスをモニタリングできます。
**を使用してノードのステータスを確認する AWS Command Line Interface**
```
aws sagemaker list-cluster-nodes \
--cluster-name {{my-slurm-cluster}}
```
ディープヘルスチェックを受けているノードは `InstanceStatus.Status`と表示されます`DeepHealthCheckInProgress`。
**コントローラーノードの SSM 経由で Slurm の状態を確認する**
```
# View node states
sinfo -a -N -l
# View maintenance reservation
scontrol show reservations
# View running DHC jobs
squeue -a
```
ディープヘルスチェック対象のノードは、`hyperpod-deep-health-check`予約と`hyperpod-system-maintenance`パーティションに表示されます。
### 起動時のディープヘルスチェックを有効にしたクラスターへのノードの追加
が`OnStartDeepHealthChecks`設定されたクラスターをスケールアップすると、新しいノードはワークロードを受け入れる前にディープヘルスチェックを自動的に実行します。既存のノードと実行中のジョブは影響を受けません。
```
aws sagemaker update-cluster \
--cluster-name {{my-slurm-cluster}} \
--instance-groups '[
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "worker-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 8,
"LifeCycleConfig": {
"SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
"ThreadsPerCore": 1,
"OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
}
]'
```
新しいノードは、ディープヘルスチェックの実行中にメンテナンス予約で分離されます。新しいノードから追加の容量を必要とするジョブは、それらのノードがディープヘルスチェックに合格して使用可能になるまで待機します。既存の使用可能なノードで満たすことができるジョブは影響を受けません。
## オンデマンドのディープヘルスチェック
オンデマンドのディープヘルスチェックでは、[StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html) API を使用して、いつでも既存のクラスターノードでハードウェア検証をトリガーできます。これは、定期的なヘルス検証や、ハードウェアの問題が疑われた後に役立ちます。
**注記**
オンデマンドのディープヘルスチェックは、 が `NodeProvisioningMode`に設定されているクラスターではサポートされていません`Continuous`。
### コンソールからオンデマンドのディープヘルスチェックを実行する
HyperPod クラスターインスタンスでディープヘルスチェックを SageMaker AI コンソールから直接実行できます。
**コンソールからオンデマンドのディープヘルスチェックを実行するには**
1. SageMaker AI コンソールで [SageMaker AI コンソール](https://console.aws.amazon.com/sagemaker)を開きます。
1. ナビゲーションペインの **HyperPod** で、**クラスター**を選択します。
1. クラスターの名前を選択して、クラスターの詳細ページを開きます。
1. **インスタンス**テーブルで、ディープヘルスチェックを実行する 1 つ以上のインスタンスを選択します。
**注記**
サポートされているインスタンスファミリーには、g5、p4、p5 などがあります。アクセラレーションされていないインスタンスは自動的にスキップされます。
1. **「アクション**」を選択し、**「ディープヘルスチェックの実行**」を選択します。
1. **ストレスチェック**、**接続チェック**、またはその両方を選択します。
+ **ストレスチェック** — ロード中のアクセラレーターハードウェアを検証します ( に対応`InstanceStress`)。
+ **接続チェック** — ノード間のネットワーク通信を検証します ( に対応`InstanceConnectivity`)。
1. **ヘルスチェックの実行** を選択します。
成功バナーは、チェックが開始されたことを確認します。インスタンスは、チェック中にワークロードでは使用できません。これには 1 時間以上かかる場合があります。インスタンステーブルで**インスタンス**のステータスをモニタリングする — 実行中**に進行中のディープヘルスチェック**が表示されます。問題が検出され、自動復旧が有効になっている場合、SageMaker HyperPod は自動的に再起動するか、障害のあるインスタンスを置き換えます。
### を使用してオンデマンドのディープヘルスチェックをトリガーする AWS Command Line Interface
実行するインスタンスグループとチェックを指定できます。クラスターごとに一度にアクティブにできるオンデマンドのディープヘルスチェックリクエストは 1 つだけです。
```
aws sagemaker start-cluster-health-check \
--cluster-name {{my-slurm-cluster}} \
--deep-health-check-configurations '[
{
"InstanceGroupName": "worker-group",
"DeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
}
]'
```
### 実行中のワークロードの動作
ジョブを実行しているノードでオンデマンドのディープヘルスチェックがトリガーされた場合:
+ 実行中のジョブは中断または終了**されません**。
+ ディープヘルスチェックはキューに入れられ、現在のジョブが完了するまで待機します。実行中のジョブが 10 分以内に完了しない場合、ノードはディープヘルスチェックからスキップされます。
+ テスト中に新しいジョブがスケジュールされないように、ノードはメンテナンス予約に配置されます。
## ディープヘルスチェックからのログ
SageMaker HyperPod のディープヘルスチェックからのログの例を次に示します。
**クラスターレベルのログ**
クラスターレベルのディープヘルスチェックログは、 の CloudWatch ロググループに保存されます`/aws/sagemaker/Clusters//`。
ログストリームは `DeepHealthCheckResults/` に記録されます。
**インスタンスレベルのログ**
各ノードでは、ディープヘルスチェックログは に保存されます`/var/log/aws/clusters/sagemaker-deep-health-check.log`。
ログには SSM 経由でアクセスできます。
```
aws ssm start-session \
--target "sagemaker-cluster:{{}}_{{}}-{{}}"
```
次に、ログを表示します。
```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```
**HARDWARE\_CHECK 出力の例**
```
2026-03-29T18:03:14Z info Executing Hardware stress check with command: stress-ng
2026-03-29T18:04:20Z info stress-ng success
2026-03-29T18:04:20Z info GpuPci Count check success
```
**DCGM 出力の例**
```
2026-03-29T18:35:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 4
dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01
gpuDeviceIds: [2237] replacementRequired: false rebootRequired: false
```
**EFA 出力の例**
```
2026-03-29T18:36:28Z info EFA Loopback check passed for device: rdmap0s29
MaxBw: 58.59, AvgBw: 32.42, MaxTypicalLat: 30.87, AvgLat: 21.63
```
**ディープヘルスチェックの失敗出力の例**
```
{
"level": "error",
"ts": "2026-03-29T19:15:22Z",
"msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: ml.g5.8xlarge. ERROR: Bandwidth has less than threshold: Expected minimum threshold: 80, NCCL Test output Bw: 30"
}
```
## ディープヘルスチェックによる自動再開動作
ディープヘルスチェックが有効になっていない場合、自動再開中にノードが置き換えられると、置き換えノードはすぐにクラスターに追加され、自動再開ジョブはすぐにスケジュールできます。
ディープヘルスチェックを有効にすると、代替ノードは、設定済みのすべてのディープヘルスチェックに合格する必要があります。ただし、自動再開ジョブは代替ノードを待つ必要はありません。クラスター内の他の使用可能なノードでスケジュールできます。ジョブは、他のノードが利用できない場合にのみ待機します。
## その他の考慮事項
+ ディープヘルスチェックには、最新の AMI バージョンが必要です。[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) を実行して、ディープヘルスチェックを有効にする前にクラスターを更新します。
+ オンデマンドのディープヘルスチェックは、 が `NodeProvisioningMode`に設定されているクラスターではサポートされていません`Continuous`。
+ ディープヘルスチェックはワーカーノードでのみ実行されます。コントローラーノードとログインノードはディープヘルスチェックの対象ではありません。
+ クラスターごとに一度にアクティブにできるオンデマンドのディープヘルスチェックリクエストは 1 つだけです。
+ オンデマンドチェックによってノードの再起動または置換がトリガーされた場合、置換ノード`OnStartDeepHealthChecks`は、インスタンスグループで が有効になっている場合にのみディープヘルスチェックを実行します。それ以外の場合、ノードはディープヘルスチェックを再実行せずに再結合します。