

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks"></a>

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'[StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html)API. 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.

**Important**  
Pour utiliser des contrôles de santé approfondis, vous devez effectuer une mise à jour vers la dernière version de l'AMI. Exécutez [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)pour effectuer la mise à jour vers la dernière version de l'AMI. Si vous utilisez une ancienne version de l'AMI, les contrôles de santé approfondis risquent de ne pas fonctionner comme prévu.

## Types de bilans de santé approfondis
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-types"></a>

SageMaker HyperPod prend en charge deux catégories de tests de santé approfondis pour les clusters Slurm :
+ **InstanceStress**— Exécute des tests au niveau de l'instance, notamment des tests de stress matériel (processeur, mémoire, disque, GPU/PCI vérification), des diagnostics du GPU DCGM et de la connectivité EFA loopback. Cela permet de valider l'état du matériel de chaque nœud.
+ **InstanceConnectivity**— Exécute des tests NCCL (NVIDIA Collective Communications Library) au niveau du cluster sur plusieurs nœuds pour vérifier les performances de communication entre les processeurs graphiques. Cette vérification n'est prise en charge que sur les instances dotées de capacités de communication GPU à nœuds multiples.

## Liste des bilans de santé approfondis effectués par SageMaker HyperPod
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-list"></a>

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

**Instance-level bilans de santé approfondis (InstanceStress)**


| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description | 
| --- | --- | --- | --- | 
| Accélérateur | GPU/NVLink nombre | GPU | Vérifie les GPU/NVLink comptes. | 
| Accélérateur | [Diagnostic DCGM](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) niveau 4 | GPU | Évalue l’intégrité et les fonctionnalités des GPU NVIDIA en exécutant des tests de diagnostic DCGM (NVIDIA Data Center GPU Manager) de niveau 4, y compris des tests de mémoire supplémentaires. Durée typique : environ 45 à 90 minutes selon le nombre de GPU. | 
| Réseau | EFA | GPU | Exécute des tests de bande passante et de latence de boucle EFA sur le périphérique EFA connecté. Durée typique : environ 2 à 5 minutes. | 

**Cluster-level bilans de santé approfondis (InstanceConnectivity)**


| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description | 
| --- | --- | --- | --- | 
| Accélérateur | Test NCCL | GPU | Exécute des tests de all\_reduce performance NCCL sur plusieurs nœuds pour vérifier la bande passante de communication entre les nœuds du processeur graphique. Durée typique : environ 5 à 15 minutes selon le nombre de nœuds. | 

## On-start bilans de santé approfondis
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start"></a>

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](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html). 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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-enabling"></a>

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-process"></a>

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

1. **Provisionnement des nœuds** : de nouvelles instances sont lancées et des scripts de cycle de vie sont exécutés.

1. **Isolation des nœuds** : l'agent de HyperPod cluster place les nouveaux nœuds dans une réservation de maintenance Slurm (`hyperpod-deep-health-check`) et les ajoute à la `hyperpod-system-maintenance` partition. Les nœuds sont marqués avec la fonction Slurm. `SageMakerDeepHealthCheck:InProgress` Cela empêche les tâches d'être planifiées sur ces nœuds pendant les tests.

1. **Exécution des tests** : les tests suivants sont exécutés sur chaque nœud dans le cadre de la `InstanceStress` vérification :
   + **HARDWARE\_CHECK** : s'exécute `stress-ng` pour les tests de stress du processeur, de la mémoire et du disque, suivis de la vérification du nombre de processeurs graphiques et de périphériques PCI. Durée typique : environ 1 à 2 minutes.
   + **DCGM** : exécute les tests de diagnostic NVIDIA DCGM au niveau 4, y compris les tests de mémoire du GPU. Durée typique : environ 45 à 90 minutes selon le nombre de GPU.
   + **EFA** : exécute des tests de bande passante et de latence en boucle EFA. Durée typique : environ 2 à 5 minutes.

   Si cette option `InstanceConnectivity` est également activée, le test supplémentaire suivant est exécuté :
   + **NCCL** : exécute des tests de `all_reduce` performance NCCL sur plusieurs nœuds pour vérifier la bande passante de communication entre les nœuds du processeur graphique. Durée typique : environ 5 à 15 minutes selon le nombre de nœuds.

1. **Gestion des résultats** :
   + **Passe** : le nœud est retiré de la réservation de maintenance, la fonction de vérification approfondie de l'état de santé est supprimée et le nœud devient disponible pour les tâches dans la partition qui lui a été attribuée.
   + **Échec** : le nœud reste isolé. SageMaker HyperPod remplace automatiquement le nœud défaillant et effectue des contrôles de santé approfondis lors du remplacement.

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-monitoring"></a>

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` comme`DeepHealthCheckInProgress`.

**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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-add-nodes"></a>

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand"></a>

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'[StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html)API. Cela est utile pour la validation périodique de l'état de santé ou après des problèmes matériels suspects.

**Note**  
On-demand les contrôles de santé approfondis ne sont pas pris en charge sur les clusters `NodeProvisioningMode` définis sur`Continuous`.

### Exécution de contrôles de santé approfondis à la demande depuis la console
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-console"></a>

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

**Pour exécuter des contrôles de santé approfondis à la demande depuis la console**

1. Ouvrez la console SageMaker AI sur la [console SageMaker AI](https://console.aws.amazon.com/sagemaker).

1. Dans le volet de navigation, sous **HyperPod**, choisissez **Clusters**.

1. Choisissez le nom de votre cluster pour ouvrir la page détaillée du cluster.

1. Dans le tableau **Instances**, sélectionnez une ou plusieurs instances sur lesquelles vous souhaitez effectuer des contrôles de santé approfondis.
**Note**  
Les familles d'instances prises en charge incluent g5, p4 et p5. Non-accelerated les instances sont automatiquement ignorées.

1. Choisissez **Actions**, puis sélectionnez **Exécuter des contrôles de santé approfondis**.

1. Sélectionnez **Contrôle du stress**, **Contrôle de connectivité** ou les deux :
   + **Contrôle de contrainte** — Valide le matériel de l'accélérateur sous charge (correspond à`InstanceStress`).
   + **Contrôle de connectivité** — Valide la communication réseau entre nœuds (correspond à`InstanceConnectivity`).

1. Choisissez **Exécuter des contrôles de santé**.

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-triggering"></a>

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-behavior"></a>

Lorsque des contrôles de santé approfondis à la demande sont déclenchés sur des nœuds exécutant des tâches :
+ Les tâches en cours **ne** sont ni interrompues ni interrompues.
+ Le bilan de santé approfondi est mis en file d'attente et attend que la tâche en cours soit terminée. Si la tâche en cours d'exécution ne se termine pas dans les 10 minutes, le nœud est ignoré du bilan de santé approfondi.
+ Les nœuds sont placés dans la réservation de maintenance pour empêcher la planification de nouvelles tâches pendant les tests.

## Journaux issus des vérifications de surveillance approfondie de l’état
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-logs"></a>

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-auto-resume"></a>

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
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-limitations"></a>
+ Les contrôles de santé approfondis nécessitent la dernière version de l'AMI. Exécutez [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)pour mettre à jour votre cluster avant d'activer des contrôles de santé approfondis.
+ On-demand les contrôles de santé approfondis ne sont pas pris en charge sur les clusters `NodeProvisioningMode` définis sur`Continuous`.
+ Les contrôles de santé approfondis ne sont exécutés que sur les nœuds de travail. Le contrôleur et les nœuds de connexion ne sont pas soumis à des contrôles de santé approfondis.
+ Une seule demande de vérification approfondie de l'état de santé à la demande peut être active par cluster à la fois.
+ Si une vérification à la demande déclenche le redémarrage ou le remplacement d'un nœud, le nœud de remplacement exécute des contrôles de santé approfondis uniquement s'`OnStartDeepHealthChecks`il est activé sur le groupe d'instances. Dans le cas contraire, le nœud rejoint le réseau sans effectuer à nouveau de tests de santé approfondis.