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.
# Fonctionnalités de résilience des clusters pour l'orchestration des SageMaker HyperPod clusters avec Amazon EKS
SageMaker HyperPod fournit les fonctionnalités de résilience des clusters suivantes.
**Topics**
+ [Système de surveillance de la santé](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
+ [Vérifications de surveillance de l’état de base](sagemaker-hyperpod-eks-resiliency-basic-health-check.md)
+ [Vérifications de surveillance approfondie de l’état](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md)
+ [Récupération automatique des nœuds](sagemaker-hyperpod-eks-resiliency-node-recovery.md)
+ [Étiquettes Kubernetes liées à la résilience par SageMaker HyperPod](sagemaker-hyperpod-eks-resiliency-node-labels.md)
+ [Mise en quarantaine, remplacement ou redémarrage manuels d’un nœud](sagemaker-hyperpod-eks-resiliency-manual.md)
+ [Configurations de résilience suggérées](sagemaker-hyperpod-eks-resiliency-config-tips.md)
# Système de surveillance de la santé
SageMaker HyperPod le système de surveillance de la santé comprend deux composants
1. Les agents de surveillance installés sur vos nœuds, notamment le Health Monitoring Agent (HMA) qui sert de moniteur de santé sur l'hôte et un ensemble de moniteurs de out-of-node santé.
1. Système de restauration des nœuds géré par SageMaker HyperPod. Le système de surveillance de l'état de santé surveillera en permanence l'état de santé du nœud via des agents de surveillance, puis prendra des mesures automatiquement en cas de détection d'un défaut à l'aide du système de restauration des nœuds.
![\[Cette image montre comment le système de surveillance de la santé s'est intégré à HyperPod Cluster.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-event.png)
## Contrôles de santé effectués par l'agent de SageMaker HyperPod surveillance de la santé
L'agent de SageMaker HyperPod surveillance de la santé vérifie les points suivants.
**NVIDIA GPUs**
+ [Notifications de violation des politiques DCGM](https://docs.nvidia.com/datacenter/dcgm/3.0/user-guide/feature-overview.html#notifications)
+ Erreurs dans la sortie `nvidia-smi`
+ Diverses erreurs dans les journaux générés par la plateforme Amazon Elastic Cloud (EC2)
+ Validation du nombre de GPU : s'il existe un décalage entre le nombre attendu de processeurs GPUs dans un type d'instance particulier (par exemple : 8 GPUs dans le type d'instance ml.p5.48xlarge) et le nombre renvoyé par, HMA redémarre le nœud `nvidia-smi`
**AWS Trainium**
+ Erreurs dans la sortie du [moniteur AWS Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html)
+ Sorties générées par le détecteur de problèmes de nœuds neuronaux (pour plus d'informations sur le détecteur de problèmes de nœuds AWS neuronaux, consultez la section [Détection et restauration des problèmes de nœuds pour les nœuds AWS neuronaux au sein de clusters Amazon EKS](https://aws.amazon.com/blogs/machine-learning/node-problem-detection-and-recovery-for-aws-neuron-nodes-within-amazon-eks-clusters/).)
+ Diverses erreurs dans les journaux générés par la plateforme Amazon EC2
+ Validation du nombre de dispositifs neuronaux : s'il existe un décalage entre le nombre réel de dispositifs neuronaux dans un type d'instance particulier et le nombre renvoyé par`neuron-ls`, HMA redémarre le nœud
Les vérifications ci-dessus sont passives, les vérifications de santé des antécédents HyperPod s'exécutent en permanence sur vos nœuds. Outre ces contrôles, effectue HyperPod également des contrôles de santé approfondis (ou actifs) lors de la création et de la mise à jour des HyperPod clusters. En savoir plus sur les [bilans de santé approfondis](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-resiliency-deep-health-checks.html).
## Détection de défauts
Lorsqu'il SageMaker HyperPod détecte un défaut, il met en œuvre une réponse en quatre parties :
1. **Étiquettes de nœuds**
1. État de santé : `sagemaker.amazonaws.com/node-health-status`
1. Type de défaut : `sagemaker.amazonaws.com/fault-types` étiquette pour une catégorisation de haut niveau
1. Motif du défaut : `sagemaker.amazonaws.com/fault-reasons` étiquette contenant des informations détaillées sur le défaut
1. **Nœud Taint**
1. `sagemaker.amazonaws.com/node-health-status=Unschedulable:NoSchedule`
1. **Annotation des nœuds**
1. Détails du défaut : `sagemaker.amazonaws.com/fault-details`
1. Enregistre jusqu'à 20 défauts avec horodatage survenus sur le nœud
1. **Conditions du nœud (condition** du nœud [Kubernetes](https://kubernetes.io/docs/reference/node/node-status/#condition))
1. Reflète l'état de santé actuel dans l'état des nœuds :
+ Type : identique au type de défaut
+ État : `True`
+ Raison : Identique à la raison de l'erreur
+ LastTransitionTime: heure de survenue de la panne
![\[Cette image illustre le fonctionnement du système de surveillance de l'état de santé en cas de détection d'un défaut.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-workflow.png)
## Journaux générés par l'agent de SageMaker HyperPod surveillance de l'état
L'agent SageMaker HyperPod de surveillance de l'état est une fonctionnalité out-of-the-box de vérification de l'état qui s'exécute en permanence sur tous les HyperPod clusters. L'agent de surveillance de l'état publie les événements de santé détectés sur les instances GPU ou Trn dans CloudWatch le groupe `/aws/sagemaker/Clusters/` de journaux du cluster.
Les journaux de détection de l'agent de surveillance de l' HyperPod état sont créés sous forme de flux de journaux distincts nommés `SagemakerHealthMonitoringAgent` pour chaque nœud. Vous pouvez interroger les journaux de détection à l'aide des informations des CloudWatch journaux comme suit.
```
fields @timestamp, @message
| filter @message like /HealthMonitoringAgentDetectionEvent/
```
Cela devrait retourner une sortie semblable à ce qui suit.
```
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
```
# Vérifications de surveillance de l’état de base
SageMaker HyperPod effectue un ensemble de *contrôles de santé de base sur les* instances de cluster lors de la création et de la mise à jour des HyperPod clusters. Ces contrôles de santé de base sont indépendants de l'orchestrateur. Ils sont donc applicables quelles que soient les plateformes d'orchestration sous-jacentes prises en charge par ( SageMaker HyperPod Amazon EKS ou Slurm).
Les vérifications de surveillance de l’état de base surveillent les instances de cluster pour détecter les problèmes liés aux appareils tels que les accélérateurs (GPU et cœurs Trainium) et les périphériques réseau (Elastic Fabric Adapter ou EFA). Pour trouver la liste des vérifications de surveillance de l’état de base du cluster, consultez [Vérifications de surveillance de l’état du cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html#sagemaker-hyperpod-resiliency-slurm-cluster-health-check).
# Vérifications de surveillance approfondie de l’état
SageMaker HyperPod effectue des *contrôles de santé approfondis* sur les instances de cluster lors de la création et de la mise à jour des HyperPod clusters. Les contrôles de santé approfondis garantissent la fiabilité et la stabilité des SageMaker HyperPod clusters en testant minutieusement le matériel sous-jacent et les composants de l'infrastructure avant d'autoriser l'utilisation des clusters pour l'entraînement de modèles d'apprentissage automatique. Cette approche proactive permet d’identifier et d’atténuer les problèmes potentiels dès le début du cycle de vie du cluster.
## Liste des bilans de santé approfondis effectués par SageMaker HyperPod
SageMaker HyperPod exécute les contrôles de santé approfondis suivants.
**Vérifications de surveillance approfondie de l’état au niveau de l’instance**
| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description |
| --- | --- | --- | --- |
| Accélérateur | GPU/ nombre NVLink | 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'état et les fonctionnalités de NVIDIA GPUs 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. |
| Accélérateur | Neuron sysfs | Trainium | Pour les instances alimentées par Trainium, l’état des appareils Neuron est déterminé en lisant les compteurs de [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) propagés directement par le pilote Neuron. |
| Accélérateur | Vérification du matériel neuronal | Trainium | Exécute une charge de travail de formation et vérifie les résultats pour tester le matériel. |
| Accélérateur | Test local NCCOM | Trainium | Évalue les performances des opérations de communication collective sur des nœuds Trainium individuels. |
| Réseau | EFA | GPU et Trainium | Exécute une analyse comparative de la latence et de la bande passante sur le périphérique EFA attaché. |
**Surveillance approfondie de l’état au niveau du cluster**
| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description |
| --- | --- | --- | --- |
| Accélérateur | Test NCCL | GPU | Vérifie les performances des opérations de communication collective sur plusieurs cartes NVIDIA GPUs |
| Accélérateur | Test du cluster NCCOM | Trainium | Vérifie les performances des opérations de communication collective sur plusieurs nœuds Trainium. |
## 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.
**Journaux au niveau du cluster**
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//`
Les flux de journaux sont consignés dans `DeepHealthCheckResults/`.
À titre d’exemple illustré ci-dessous, les journaux de sortie de surveillance approfondie de l’état indiquent l’ID de l’instance qui a échoué aux vérifications avec la cause de l’échec.
```
{
"level": "error",
"ts": "2024-06-18T21:15:22Z",
"msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: p4d.24xlarge. ERROR:Bandwidth has less than threshold: Expected minimum threshold :80,NCCL Test output Bw: 30"
}
```
**Journaux au niveau de l’instance**
Les journaux de surveillance approfondie de l’état au niveau de l’instance sont stockés dans `/var/log/aws/clusters/sagemaker-deep-health-check.log` sur chaque nœud. Connectez-vous via SSH au nœud et ouvrez le fichier journal en exécutant la commande suivante.
```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```
Voici un exemple de sortie du test de stress matériel, de stress [NVIDIA DCGM](https://developer.nvidia.com/dcgm) et de connectivité EFA.
```
# Hardware Stress Test output
2024-08-20T21:53:58Z info Executing Hardware stress check with command: stress-ng, and args: [--cpu 32 --vm 2 --hdd 1 --fork 8 --switch 4 --timeout 60 --metrics]
2024-08-20T21:54:58Z info stress-ng success
2024-08-20T21:54:58Z info GpuPci Count check success
# DCGM Stress Test
2024-08-20T22:25:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 0 dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01, gpuDeviceIds: [2237] replacementRequired: false rebootRequired:false
# EFA Loopback Test
2024-08-20T22:26:28Z info EFA Loopback check passed for device: rdmap0s29 . Output summary is MaxBw: 58.590000, AvgBw: 32.420000, MaxTypicalLat: 30.870000, MinTypicalLat: 20.080000, AvgLat: 21.630000
```
Voici un exemple de résultat du test de connectivité NCCL.
```
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
8 2 float sum -1 353.9 0.00 0.00 0 304.2 0.00 0.00 0
16 4 float sum -1 352.8 0.00 0.00 0 422.9 0.00 0.00 0
32 8 float sum -1 520.0 0.00 0.00 0 480.3 0.00 0.00 0
64 16 float sum -1 563.0 0.00 0.00 0 416.1 0.00 0.00 0
128 32 float sum -1 245.1 0.00 0.00 0 308.4 0.00 0.00 0
256 64 float sum -1 310.8 0.00 0.00 0 304.9 0.00 0.00 0
512 128 float sum -1 304.9 0.00 0.00 0 300.8 0.00 0.00 0
1024 256 float sum -1 509.3 0.00 0.00 0 495.4 0.00 0.00 0
2048 512 float sum -1 530.3 0.00 0.00 0 420.0 0.00 0.00 0
4096 1024 float sum -1 391.2 0.01 0.01 0 384.5 0.01 0.01 0
8192 2048 float sum -1 328.5 0.02 0.02 0 253.2 0.03 0.03 0
16384 4096 float sum -1 497.6 0.03 0.03 0 490.9 0.03 0.03 0
32768 8192 float sum -1 496.7 0.07 0.07 0 425.0 0.08 0.08 0
65536 16384 float sum -1 448.0 0.15 0.15 0 501.0 0.13 0.13 0
131072 32768 float sum -1 577.4 0.23 0.23 0 593.4 0.22 0.22 0
262144 65536 float sum -1 757.8 0.35 0.35 0 721.6 0.36 0.36 0
524288 131072 float sum -1 1057.1 0.50 0.50 0 1019.1 0.51 0.51 0
1048576 262144 float sum -1 1460.5 0.72 0.72 0 1435.6 0.73 0.73 0
2097152 524288 float sum -1 2450.6 0.86 0.86 0 2583.1 0.81 0.81 0
4194304 1048576 float sum -1 4344.5 0.97 0.97 0 4419.3 0.95 0.95 0
8388608 2097152 float sum -1 8176.5 1.03 1.03 0 8197.8 1.02 1.02 0
16777216 4194304 float sum -1 15312 1.10 1.10 0 15426 1.09 1.09 0
33554432 8388608 float sum -1 30149 1.11 1.11 0 29941 1.12 1.12 0
67108864 16777216 float sum -1 57819 1.16 1.16 0 58635 1.14 1.14 0
134217728 33554432 float sum -1 115699 1.16 1.16 0 115331 1.16 1.16 0
268435456 67108864 float sum -1 227507 1.18 1.18 0 228047 1.18 1.18 0
536870912 134217728 float sum -1 453751 1.18 1.18 0 456595 1.18 1.18 0
1073741824 268435456 float sum -1 911719 1.18 1.18 0 911808 1.18 1.18 0
2147483648 536870912 float sum -1 1804971 1.19 1.19 0 1806895 1.19 1.19 0
2024-08-20T16:22:43.831-07:00
# Out of bounds values : 0 OK
2024-08-20T16:22:43.831-07:00
# Avg bus bandwidth : 0.488398
2024-08-20T23:22:43Z info Nccl test successful. Summary: NcclMaxAlgoBw: 1.190000, NcclAvgAlgoBw: 0.488398, NcclThresholdAlgoBw: 1.180000, NcclOutOfBoundError: OK, NcclOperations: all_reduce_perf, NcclTotalDevices: 2, NcclNodes: 2, NcclClusterMessage:
```
# Récupération automatique des nœuds
Lors de la création ou de la mise à jour du cluster, les utilisateurs administrateurs du cluster peuvent sélectionner l’option de récupération des nœuds (instances) entre `Automatic` (recommandé) et `None` au niveau du cluster. S'il est défini sur`Automatic`, SageMaker HyperPod redémarre ou remplace automatiquement les nœuds défectueux.
**Important**
Nous vous recommandons de définir l’option `Automatic`.
La récupération automatique des nœuds s’exécute lorsque des problèmes sont détectés via un agent de surveillance de l’état, des vérifications de surveillance de l’état de base et des vérifications de surveillance approfondie de l’état. Si elle est définie sur `None`, l’agent de surveillance de l’état étiquette les instances lorsqu’une défaillance est détectée, mais il ne lance aucune action de réparation ou de récupération automatique sur les nœuds affectés. Cette option n’est pas recommandée.
# Étiquettes Kubernetes liées à la résilience par SageMaker HyperPod
Les *étiquettes* sont des paires clé-valeur associées aux objets [Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects). SageMaker HyperPod introduit les étiquettes suivantes pour les bilans de santé qu'il fournit.
## Étiquettes de statut d’intégrité des nœuds
Les étiquettes `node-health-status` représentent le statut de l’intégrité des nœuds et doivent être utilisées dans le cadre du filtre de sélection des nœuds dans les nœuds sains.
| Étiquette | Description |
| --- | --- |
| sagemaker.amazonaws.com/node-health-status: Schedulable | Le nœud a passé les vérifications de surveillance de l’état de base et il est disponible pour l’exécution des charges de travail. Ce bilan de santé est identique aux [fonctionnalités de SageMaker HyperPod résilience actuellement disponibles pour les clusters Slurm](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html). |
| sagemaker.amazonaws.com/node-health-status: Unschedulable | Le nœud fait l’objet de vérifications de surveillance approfondie de l’état et il n’est pas disponible pour exécuter les charges de travail. |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement | Le nœud a échoué aux vérifications de surveillance approfondie de l’état ou aux vérifications de l’agent de surveillance de l’état et il a besoin d’être remplacé. Si la restauration automatique des nœuds est activée, le nœud sera automatiquement remplacé par SageMaker HyperPod. |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot | Le nœud a échoué aux vérifications de surveillance approfondie de l’état ou aux vérifications de l’agent de surveillance de l’état et il a besoin d’être redémarré. Si la restauration automatique du nœud est activée, le nœud sera automatiquement redémarré par. SageMaker HyperPod |
## Étiquettes de surveillance approfondie de l’état
Les étiquettes `deep-health-check-status` représentent la progression de la surveillance approfondie de l’état sur un nœud spécifique. Utile pour les utilisateurs Kubernetes qui souhaitent filtrer rapidement la progression des vérifications de surveillance approfondie de l’état.
| Étiquette | Description |
| --- | --- |
| sagemaker.amazonaws.com/deep-health-check-status: InProgress | Le nœud fait l’objet de vérifications de surveillance approfondie de l’état et il n’est pas disponible pour exécuter les charges de travail. |
| sagemaker.amazonaws.com/deep-health-check-status: Passed | Le nœud a effectué avec succès les vérifications de surveillance approfondie de l’état et les vérifications des agents de surveillance de l’état, et il est disponible pour exécuter des charges de travail. |
| sagemaker.amazonaws.com/deep-health-check-status: Failed | Le nœud a échoué aux vérifications de surveillance approfondie de l’état ou aux vérifications de l’agent de surveillance de l’état et il a besoin d’être redémarré ou remplacé. Si la restauration automatique du nœud est activée, le nœud sera automatiquement redémarré ou remplacé par. SageMaker HyperPod |
## Étiquettes relatives au type et à la raison de la défaillance
Ce qui suit décrit les `fault-reason` étiquettes `fault-type` et.
+ Les étiquettes `fault-type` représentent des catégories de défaillances de haut niveau lorsque les vérifications de surveillance de l’état échouent. Elles sont renseignées pour les défaillances identifiées à la fois lors des vérifications de surveillance approfondie de l’état et des agents de surveillance de l’état.
+ Les étiquettes `fault-reason` représentent la raison détaillée de la défaillance associée à un `fault-type`.
## Comment les SageMaker HyperPod étiquettes
Les rubriques suivantes traitent de la manière dont l’étiquetage est effectué en fonction des cas.
**Topics**
+ [Lorsqu'un nœud est ajouté à un SageMaker HyperPod cluster avec la configuration de vérification approfondie de l'état désactivée](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-off)
+ [Lorsqu'un nœud est ajouté à un SageMaker HyperPod cluster avec la configuration de vérification approfondie de l'état activée](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-on)
+ [En cas de panne de calcul sur les nœuds](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-node-fails)
### Lorsqu'un nœud est ajouté à un SageMaker HyperPod cluster avec la configuration de vérification approfondie de l'état désactivée
Lorsqu'un nouveau nœud est ajouté à un cluster, et si le contrôle de santé approfondi n'est pas activé pour le groupe d'instances, SageMaker HyperPod exécute les mêmes contrôles de santé que ceux [actuellement disponibles SageMaker HyperPod pour les clusters Slurm](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html).
Si la surveillance de l’état réussit, les nœuds sont marqués avec l’étiquette suivante.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
Si la surveillance de l’état n’aboutit pas, les nœuds sont résiliés et remplacés. Ce comportement est identique au fonctionnement du bilan de SageMaker HyperPod santé pour les clusters Slurm.
### Lorsqu'un nœud est ajouté à un SageMaker HyperPod cluster avec la configuration de vérification approfondie de l'état activée
Lorsqu'un nouveau nœud est ajouté à un SageMaker HyperPod cluster et si le test de santé approfondi est activé pour le groupe d'instances, HyperPod commencez par souiller le nœud et commencez le check/stress test de santé approfondi d'environ 2 heures sur le nœud. Il existe 3 sorties possibles des étiquettes des nœuds après la surveillance approfondie de l’état.
1. Quand le test de surveillance approfondie de l’état réussit
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
1. Quand le test de surveillance approfondie de l’état échoue et que l’instance doit être remplacée
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Quand le test de surveillance approfondie de l’état échoue et que l’instance doit être redémarrée pour réexécuter la surveillance approfondie de l’état
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Si une instance échoue au test de surveillance approfondie de l’état, elle sera toujours remplacée. Si le test de surveillance approfondie de l’état réussit, le rejet du nœud sera supprimé.
### En cas de panne de calcul sur les nœuds
L'agent SageMaker HyperPod de surveillance de l'état de santé surveille également en permanence l'état de santé de chaque nœud. Lorsqu’il détecte une défaillance (telle qu’une défaillance GPU ou un blocage du pilote), l’agent marque le nœud avec l’une des étiquettes suivantes.
1. Lorsque le nœud est défectueux et doit être remplacé
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Lorsque le nœud est défectueux et doit être redémarré
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
L’agent de surveillance de l’état rejette également le nœud lorsqu’il détecte des problèmes d’intégrité du nœud.
# Mise en quarantaine, remplacement ou redémarrage manuels d’un nœud
Découvrez comment mettre en quarantaine, remplacer et redémarrer manuellement un nœud défectueux dans des SageMaker HyperPod clusters orchestrés avec Amazon EKS.
**Pour mettre un nœud en quarantaine et forcer la suppression d’un pod d’entraînement**
```
kubectl cordon
```
Après la quarantaine, expulsez de force le pod. Ceci est utile lorsque vous constatez qu’un pod est bloqué en phase de résiliation pendant plus de 30 minutes ou que `kubectl describe pod` affiche « Le nœud n’est pas prêt » dans Événements
```
kubectl delete pods --grace-period=0 --force
```
SageMaker HyperPod propose deux méthodes pour la restauration manuelle des nœuds. L'approche préférée consiste à utiliser le SageMaker HyperPod redémarrage et le remplacement APIs, qui fournissent un processus de restauration plus rapide et plus transparent qui fonctionne sur tous les orchestrateurs. Vous pouvez également utiliser les commandes kubectl pour étiqueter les nœuds pour les opérations de redémarrage et de remplacement. Les deux méthodes activent les mêmes processus SageMaker HyperPod de restauration.
**Pour redémarrer un nœud à l'aide de l'API de redémarrage**
Pour redémarrer un nœud, vous pouvez utiliser l' BatchRebootClusterNodes API.
Voici un exemple d'exécution de l'opération de redémarrage sur deux instances d'un cluster à l'aide de AWS Command Line Interface :
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
**Pour remplacer un nœud à l'aide de l'API Replace**
Pour remplacer un nœud, vous pouvez utiliser l' BatchReplaceClusterNodes API comme suit
Voici un exemple d'exécution de l'opération de remplacement sur deux instances d'un cluster à l'aide de AWS Command Line Interface :
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
**Clusters gérés par Karpenter**
Pour les SageMaker HyperPod clusters utilisant Karpenter pour le provisionnement des nœuds, l'`BatchReplaceClusterNodes`API ne garantit pas la création d'un nœud de remplacement. Le nœud spécifié *sera* résilié, mais son remplacement dépend du modèle de pod-demand-based provisionnement de Karpenter. Karpenter ne crée de nouveaux nœuds que lorsqu'il existe des pods dans un `Pending` état qui ne peut pas être planifié sur des nœuds existants.
Si la charge de travail du nœud supprimé peut être replanifiée sur les nœuds restants du cluster (par exemple, si ces nœuds ont une capacité suffisante), Karpenter ne fournit pas de solution de remplacement. Pour garantir la création d'un nœud de remplacement, vérifiez que la configuration de votre charge de travail (telle que les règles anti-affinité des pods ou les demandes de ressources) nécessite un nouveau nœud pour les pods déplacés.
Nous sommes conscients de cette limitation et travaillons activement sur une solution permettant d'imposer le remplacement des nœuds lorsque cela est demandé via l'API.
**Pour remplacer un nœud à l'aide de kubectl**
Étiquetez le nœud à remplacer`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement`, ce qui déclenche le SageMaker HyperPod [Récupération automatique des nœuds](sagemaker-hyperpod-eks-resiliency-node-recovery.md). Notez que vous devez également activer la récupération automatique des nœuds lors de la création ou de la mise à jour du cluster.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement
```
**Pour redémarrer un nœud à l'aide de kubectl**
Étiquetez le nœud avec lequel redémarrer`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot`, ce qui déclenche le SageMaker HyperPod [Récupération automatique des nœuds](sagemaker-hyperpod-eks-resiliency-node-recovery.md). Notez que vous devez également activer la récupération automatique des nœuds lors de la création ou de la mise à jour du cluster.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot
```
Une fois les étiquettes `UnschedulablePendingReplacement` `UnschedulablePendingReboot` appliquées, vous devriez être en mesure de voir que le nœud est arrêté ou redémarré dans quelques minutes.
# Configurations de résilience suggérées
Lorsque les contrôles de santé approfondis sont activés, chaque fois qu'une nouvelle instance est ajoutée au HyperPod cluster (soit lors de la création du cluster, soit lors du remplacement automatique des nœuds), la nouvelle instance est soumise au processus de contrôle de santé approfondi (tests de stress au niveau de l'instance) pendant environ deux heures. Voici des combinaisons de configuration de résilience suggérées en fonction des cas possibles.
1. **Cas** : lorsque vous disposez de nœuds de réserve supplémentaires au sein d’un cluster en tant que ressources de sauvegarde (sans utiliser la pleine capacité), ou si vous pouvez attendre environ 2 heures pour effectuer le processus de surveillance approfondie de l’état afin d’obtenir les instances les moins sujettes aux erreurs.
**Recommandation** : activez la configuration de la surveillance approfondie de l’état tout au long du cycle de vie du cluster. La configuration de récupération automatique du nœud est activée par défaut.
1. **Cas** : lorsque vous ne disposez pas de nœuds de sauvegarde supplémentaires (la capacité est entièrement utilisée pour une partie de la charge d’entraînement). Vous souhaitez obtenir les nœuds de remplacement le plus rapidement possible pour reprendre la tâche d’entraînement.
**Recommandation** : activez la surveillance approfondie de l’état lors de la création du cluster, puis désactivez la configuration de la surveillance approfondie de l’état une fois le cluster créé. La configuration de récupération automatique du nœud est activée par défaut.
1. **Cas** : lorsque vous ne disposez pas de nœuds de sauvegarde supplémentaires et que vous ne souhaitez pas attendre le processus de surveillance approfondie de l’état de l’état d’environ 2 heures (petits clusters).
**Recommandation** : désactivez la configuration de la surveillance approfondie de l’état tout au long du cycle de vie du cluster. La configuration de récupération automatique du nœud est activée par défaut.
Si vous souhaitez reprendre immédiatement la tâche d’entraînement après un échec, assurez-vous de disposer de nœuds de réserve supplémentaires en tant que ressources de sauvegarde dans le cluster.