Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vérifications de surveillance approfondie de l’état

SageMaker HyperPod effectue des contrôles de santé approfondis sur les instances de Slurm-orchestrated cluster afin de garantir la fiabilité et la stabilité du matériel et de l'infrastructure sous-jacents. Des contrôles de santé approfondis peuvent être exécutés automatiquement lorsque des instances sont créées ou ajoutées à un cluster (au démarrage), ou vous pouvez les déclencher manuellement à tout moment (à la demande) à l'aide de l'StartClusterHealthCheckAPI. Cette approche proactive permet d'identifier et d'atténuer les problèmes potentiels tout au long du cycle de vie du cluster.

Lors de contrôles de santé approfondis, les nœuds concernés sont placés dans une réservation de maintenance Slurm afin d'empêcher que des tâches ne soient planifiées sur ces nœuds. Une fois toutes les vérifications passées, les nœuds sont libérés de la réservation et deviennent disponibles pour les charges de travail.

Types de bilans de santé approfondis

SageMaker HyperPod prend en charge deux catégories de tests de santé approfondis pour les clusters Slurm :

Liste des bilans de santé approfondis effectués par SageMaker HyperPod

SageMaker HyperPod exécute les contrôles de santé approfondis suivants.

Instance-level bilans de santé approfondis (InstanceStress)

Cluster-level bilans de santé approfondis (InstanceConnectivity)

On-start bilans de santé approfondis

On-start des contrôles de santé approfondis s'exécutent automatiquement lorsque les instances sont mises en service pour la première fois, lors de la création du cluster ou lorsque de nouvelles instances sont ajoutées via UpdateCluster. Cela garantit que chaque nœud passe la validation matérielle avant d'accepter des charges de travail.

Permettre des contrôles de santé approfondis au démarrage

Pour activer les contrôles de santé approfondis au démarrage, spécifiez le OnStartDeepHealthChecks paramètre dans la configuration du groupe d'instances lors de la création ou de la mise à jour d'un cluster.

Exemple : création d'un cluster avec des contrôles de santé approfondis au démarrage

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

Que se passe-t-il lors des contrôles de santé approfondis au démarrage

Lorsque des contrôles de santé approfondis sont activés au démarrage, le processus suivant se produit :

Le cluster passe à InService une fois qu'au moins le nœud contrôleur est en cours d'exécution. Les nœuds de travail affichent DeepHealthCheckInProgress leur statut pendant les tests et passent à une étape Running après la réussite.

Surveillance des contrôles de santé approfondis au démarrage

Vous pouvez surveiller l'état des contrôles de santé approfondis au démarrage à l'aide de l'API Amazon SageMaker AI ou des commandes Slurm.

Vérifiez l'état du nœud à l'aide du AWS Command Line Interface

aws sagemaker list-cluster-nodes \
  --cluster-name my-slurm-cluster

Les nœuds soumis à des contrôles de santé approfondis s'affichent InstanceStatus.Status commeDeepHealthCheckInProgress.

Vérifiez l'état de Slurm via SSM sur le nœud du contrôleur

# View node states
sinfo -a -N -l

# View maintenance reservation
scontrol show reservations

# View running DHC jobs
squeue -a

Les nœuds soumis à un contrôle de santé approfondi apparaissent dans la hyperpod-deep-health-check réservation et dans la hyperpod-system-maintenance partition.

Ajout de nœuds à un cluster avec des contrôles de santé approfondis activés au démarrage

Lorsque vous augmentez le niveau d'un cluster OnStartDeepHealthChecks configuré, les nouveaux nœuds sont automatiquement soumis à des contrôles de santé approfondis avant d'accepter des charges de travail. Les nœuds existants et les tâches en cours ne sont pas affectés.

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

Les nouveaux nœuds sont isolés dans la réservation de maintenance pendant que des contrôles de santé approfondis sont effectués. Les tâches nécessitant une capacité supplémentaire de la part des nouveaux nœuds attendent que ces nœuds passent des tests de santé approfondis et soient disponibles. Les tâches qui peuvent être satisfaites par les nœuds disponibles existants ne sont pas affectées.

On-demand bilans de santé approfondis

On-demand des contrôles de santé approfondis vous permettent de déclencher la validation matérielle sur les nœuds de cluster existants à tout moment à l'aide de l'StartClusterHealthCheckAPI. Cela est utile pour la validation périodique de l'état de santé ou après des problèmes matériels suspects.

Exécution de contrôles de santé approfondis à la demande depuis la console

Vous pouvez effectuer des contrôles de santé approfondis sur les instances de HyperPod cluster directement depuis la console SageMaker AI.

Une bannière de réussite confirme que les vérifications ont été lancées. Les instances ne sont pas disponibles pour les charges de travail lors des vérifications, qui peuvent prendre plus d'une heure. Surveillez l'état de l'instance dans le tableau Instances : il indique le contrôle de santé approfondi en cours d'exécution. Lorsque des problèmes sont détectés et que la restauration automatique est activée, les instances défectueuses sont SageMaker HyperPod automatiquement redémarrées ou remplacées.

Déclencher des vérifications de santé approfondies à la demande à l'aide AWS Command Line Interface

Vous pouvez spécifier les groupes d'instances et les contrôles à exécuter. Une seule demande de vérification approfondie de l'état de santé à la demande peut être active par cluster à la fois.

aws sagemaker start-cluster-health-check \
  --cluster-name my-slurm-cluster \
  --deep-health-check-configurations '[
    {
      "InstanceGroupName": "worker-group",
      "DeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]'

Comportement avec les charges de travail en cours

Lorsque des contrôles de santé approfondis à la demande sont déclenchés sur des nœuds exécutant des tâches :

Journaux issus des vérifications de surveillance approfondie de l’état

Vous trouverez ci-dessous des exemples de journaux issus des bilans de santé SageMaker HyperPod approfondis.

Cluster-level journaux

Les journaux de contrôle de santé approfondis au niveau du cluster sont stockés dans votre groupe de journaux à l'adresse CloudWatch . /aws/sagemaker/Clusters/<cluster_name>/<cluster_id>

Les flux de journaux sont consignés dans DeepHealthCheckResults/<log_stream_id>.

Instance-level journaux

Sur chaque nœud, les journaux de contrôle de santé approfondis sont stockés dans/var/log/aws/clusters/sagemaker-deep-health-check.log.

Vous pouvez accéder au journal via SSM :

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

Consultez ensuite le journal :

cat /var/log/aws/clusters/sagemaker-deep-health-check.log

Exemple de sortie 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

Exemple de sortie 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

Exemple de sortie 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

Exemple de résultat d'échec d'un contrôle de santé approfondi

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

Auto-resume comportement avec des bilans de santé approfondis

Si des contrôles de santé approfondis ne sont pas activés, lorsqu'un nœud est remplacé pendant la reprise automatique, le nœud de remplacement est immédiatement ajouté au cluster et la tâche reprise automatiquement peut être planifiée immédiatement sur celui-ci.

Lorsque les contrôles de santé approfondis sont activés, le nœud de remplacement doit passer tous les contrôles de santé approfondis configurés avant qu'il ne soit disponible. Cependant, la reprise automatique de la tâche n'a pas besoin d'attendre le nœud de remplacement : elle peut être planifiée sur n'importe quel autre nœud disponible du cluster. La tâche n'attend que si aucun autre nœud n'est disponible.

Considérations supplémentaires