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 d'état 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 la planification de tâches sur ceux-ci. Une fois toutes les vérifications effectué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 contrôles 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 lors du premier provisionnement des instances, 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 les charges de travail.

Activation de contrôles de santé approfondis dès le 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 bilans de santé approfondis au démarrage

Lorsque les contrôles de santé approfondis au démarrage sont activés, 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 état pendant les tests et passent à une version Running après la réussite.

Surveillance des bilans 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 sous la formeDeepHealthCheckInProgress.

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 au démarrage activés

Lorsque vous agrandissez un cluster déjà 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 d'exécution 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éserve de maintenance pendant que des contrôles d'état approfondis sont effectués. Les tâches qui nécessitent la capacité supplémentaire des nouveaux nœuds attendent que ces nœuds passent des contrôles d'état 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 d'état approfondis vous permettent de déclencher la validation matérielle sur les nœuds de cluster existants à tout moment à l'aide de l'StartClusterHealthCheckAPI. Ceci est utile pour la validation périodique de l'état de santé ou en cas de suspicion de problèmes matériels.

Exécution de bilans 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 contrôles ont été initiés. Les instances ne sont pas disponibles pour les charges de travail pendant les vérifications, qui peuvent prendre plus d'une heure. Surveillez l'état de l'instance dans le tableau Instances : il indique un 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, redémarre ou remplace SageMaker HyperPod automatiquement les instances défectueuses.

Déclencher des bilans de santé approfondis à la demande AWS Command Line Interface

Vous pouvez spécifier les groupes d'instances et les vérifications à exécuter. Une seule demande de bilan de santé approfondi à 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 lors de l'exécution de charges de travail

Lorsque des contrôles d'état approfondis à la demande sont déclenchés sur des nœuds qui exécutent des tâches :

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

Voici des exemples de journaux issus des contrôles 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 bilan 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 les contrôles d'état 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 sur celui-ci immédiatement.

Lorsque les contrôles de santé approfondis sont activés, le nœud de remplacement doit réussir tous les tests de santé approfondis configurés avant d'être disponible. Cependant, la tâche reprise automatiquement 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'est en attente que si aucun autre nœud n'est disponible.

Considérations supplémentaires