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

ディープヘルスチェック

SageMaker HyperPod は、Slurm がオーケストレーションしたクラスターインスタンスに対してディープヘルスチェックを実行し、基盤となるハードウェアとインフラストラクチャの信頼性と安定性を確保します。ディープヘルスチェックは、インスタンスがクラスターに作成または追加されたとき (オンスタート) に自動的に実行することも、StartClusterHealthCheck API を使用していつでも手動で (オンデマンドで) トリガーすることもできます。このプロアクティブアプローチは、クラスターのライフサイクル全体で潜在的な問題を特定して軽減するのに役立ちます。

ディープヘルスチェック中、影響を受けるノードは Slurm メンテナンス予約に配置され、ジョブがスケジュールされないようにします。すべてのチェックに合格すると、ノードは予約から解放され、ワークロードで使用できるようになります。

ディープヘルスチェックタイプ

SageMaker HyperPod は、Slurm クラスターの 2 つのカテゴリのディープヘルスチェックをサポートしています。

SageMaker HyperPod によって行われたディープヘルスチェックのリスト

SageMaker HyperPod は、次のディープヘルスチェックを実行します。

インスタンスレベルのディープヘルスチェック (InstanceStress)

クラスターレベルのディープヘルスチェック (InstanceConnectivity)

起動時のディープヘルスチェック

起動時のディープヘルスチェックは、インスタンスが最初にプロビジョニングされたとき、つまりクラスターの作成時または UpdateCluster 経由で新しいインスタンスが追加されたときに自動的に実行されます。これにより、すべてのノードがワークロードを受け入れる前にハードウェア検証に合格します。

起動時のディープヘルスチェックの有効化

起動時のディープヘルスチェックを有効にするには、クラスターを作成または更新するときにインスタンスグループ設定で 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 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 API を使用して、いつでも既存のクラスターノードでハードウェア検証をトリガーできます。これは、定期的なヘルス検証や、ハードウェアの問題が疑われた後に役立ちます。

コンソールからオンデマンドのディープヘルスチェックを実行する

HyperPod クラスターインスタンスでディープヘルスチェックを SageMaker AI コンソールから直接実行できます。

成功バナーは、チェックが開始されたことを確認します。インスタンスは、チェック中にワークロードでは使用できません。これには 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"]
    }
  ]'

実行中のワークロードの動作

ジョブを実行しているノードでオンデマンドのディープヘルスチェックがトリガーされた場合:

ディープヘルスチェックからのログ

SageMaker HyperPod のディープヘルスチェックからのログの例を次に示します。

クラスターレベルのログ

クラスターレベルのディープヘルスチェックログは、 の CloudWatch ロググループに保存されます/aws/sagemaker/Clusters/<cluster_name>/<cluster_id>。

ログストリームは DeepHealthCheckResults/<log_stream_id> に記録されます。

インスタンスレベルのログ

各ノードでは、ディープヘルスチェックログは に保存されます/var/log/aws/clusters/sagemaker-deep-health-check.log。

ログには SSM 経由でアクセスできます。

aws ssm start-session \
  --target "sagemaker-cluster:<cluster_id>_<instance_group>-<instance_id>"

次に、ログを表示します。

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"
}

ディープヘルスチェックによる自動再開動作

ディープヘルスチェックが有効になっていない場合、自動再開中にノードが置き換えられると、置き換えノードはすぐにクラスターに追加され、自動再開ジョブはすぐにスケジュールできます。

ディープヘルスチェックを有効にすると、代替ノードは、設定済みのすべてのディープヘルスチェックに合格する必要があります。ただし、自動再開ジョブは代替ノードを待つ必要はありません。クラスター内の他の使用可能なノードでスケジュールできます。ジョブは、他のノードが利用できない場合にのみ待機します。

その他の考慮事項