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.
# SageMaker HyperPod résilience du cluster
SageMaker HyperPod via Slurm Orchestration fournit les fonctionnalités de résilience des clusters suivantes.
**Topics**
+ [Agent de surveillance de la santé](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Remplacez ou redémarrez manuellement un nœud à l'aide de Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agent de surveillance de la santé
Cette section décrit l'ensemble des contrôles de santé SageMaker HyperPod utilisés pour surveiller régulièrement l'état des instances de cluster afin de détecter des problèmes liés à des appareils tels que les accélérateurs (GPU et cœurs Trainium) et le réseau (EFA). SageMaker HyperPod un agent de surveillance de l'état de santé (HMA) surveille en permanence l'état de santé de chaque instance basée sur un GPU ou Trainium. Lorsqu’il détecte une défaillance d’instance ou de GPU, l’agent marque l’instance comme étant défectueuse.
SageMaker HyperPod HMA effectue les mêmes contrôles de santé pour les orchestrateurs EKS et Slurm. Pour plus d'informations sur le HMA, consultez[Système de surveillance de la santé](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
# Restauration automatique des nœuds et reprise automatique
**Note**
Depuis le 11 septembre 2025, HyperPod avec Slurm, l'orchestration prend désormais en charge les agents de surveillance de la santé. Exécutez [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)et mettez à jour la dernière version de l'AMI afin d'utiliser cette fonctionnalité.
Cette section décrit les deux fonctionnalités SageMaker HyperPod de résilience complémentaires d'Amazon : la restauration automatique des nœuds qui remplace l'infrastructure défectueuse sans intervention manuelle, et la fonctionnalité de reprise automatique qui redémarre les tâches de formation depuis le dernier point de contrôle après une panne matérielle.
## Comment fonctionne la restauration 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`. Par défaut, les clusters sont configurés avec la restauration automatique des nœuds.
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. Nous ne recommandons pas cette option.
## Exécution d'une tâche de formation avec la fonctionnalité de SageMaker HyperPod reprise automatique d'Amazon
Cette section décrit comment exécuter une tâche de formation à l'aide de la fonctionnalité de SageMaker HyperPod reprise automatique, qui fournit une infrastructure de résilience sans intervention permettant de récupérer automatiquement une tâche de formation depuis le dernier point de contrôle enregistré en cas de panne matérielle.
Grâce à la fonctionnalité de reprise automatique, si une tâche échoue en raison d'une panne matérielle ou d'un problème temporaire entre les sessions de formation, la SageMaker HyperPod reprise automatique lance le flux de travail de remplacement des nœuds et redémarre la tâche une fois les nœuds défectueux remplacés. Les vérifications matérielles suivantes sont exécutées chaque fois qu'une tâche échoue lors de l'utilisation de la reprise automatique :
| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description |
| --- | --- | --- | --- |
| Accélérateur | NVIDIA SMI | GPU | [L'utilitaire nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) est une CLI bien connue pour gérer et surveiller. GPUs L’outil intégré de surveillance de l’état analyse la sortie de nvidia-smi pour déterminer l’intégrité de l’instance. |
| 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. |
| Réseau | EFA | GPU et Trainium | Pour faciliter le diagnostic des appareils Elastic Fabric Adaptor (EFA), l’outil de surveillance de l’état EFA exécute une série de tests de connectivité en utilisant toutes les cartes EFA disponibles au sein de l’instance. |
**Note**
Lorsque des [ressources génériques (GRES)](https://slurm.schedmd.com/gres.html) sont attachées à un nœud Slurm, Slurm n’autorise généralement pas les modifications de l’allocation des nœuds, telles que le remplacement de nœuds, et n’autorise donc pas la reprise d’une tâche ayant échoué. Sauf interdiction explicite, la fonctionnalité de HyperPod reprise automatique met automatiquement en file d'attente toute tâche défectueuse associée aux nœuds compatibles GRES. Ce processus implique d’arrêter la tâche, de la replacer dans la file d’attente des tâches, puis de la redémarrer au début.
**Utilisation de la fonctionnalité de SageMaker HyperPod reprise automatique avec Slurm**
Lorsque vous utilisez la SageMaker HyperPod reprise automatique avec Slurm, vous devez exécuter le travail dans le cadre d'une allocation exclusive acquise soit en utilisant soit. `salloc` `sbatch` Dans tous les cas, vous devez modifier le script de point d’entrée pour vous assurer que toutes les étapes de configuration s’exécutent dans une seule commande `srun` lors de la reprise de la tâche. À l’aide du script de point d’entrée, il est important de configurer l’environnement sur le nœud remplacé de manière à ce qu’il soit cohérent avec l’environnement dans lequel l’étape de la tâche s’exécutait avant d’être arrêtée. La procédure suivante montre comment préparer un script de point d'entrée pour garantir la cohérence de l'environnement et l'exécuter en tant que commande unique`srun`.
**Astuce**
Si vous utilisez `sbatch`, vous pouvez simplifier le script de commande en créant un script distinct pour configurer l’environnement et en utilisant une seule commande `srun`.
1. Créez un script à l’aide de l’exemple de code suivant et enregistrez-le sous `train_auto_resume.sh`. Ce script déploie les configurations de l’environnement d’entraînement en supposant qu’aucune configuration manuelle n’a été précédemment effectuée sur le nœud remplacé. Cela garantit que l’environnement est ignorant du nœud, de sorte que lorsqu’un nœud est remplacé, le même environnement est provisionné sur le nœud avant de reprendre la tâche.
**Note**
L’exemple de code suivant montre comment découvrir la liste des nœuds Slurm associée à la tâche. N'utilisez pas la variable d'`$SLURM_JOB_NODELIST`environnement fournie par Slurm, car sa valeur risque d'être obsolète après la SageMaker HyperPod reprise automatique du travail. L’exemple de code suivant montre comment définir une nouvelle variable `NODE_LIST` pour remplacer `SLURM_JOB_NODELIST`, puis configurer les variables `MASTER_NODE` et `MASTER_ADDR` hors de la variable `NODE_LIST`.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**Astuce**
Vous pouvez utiliser le script précédent pour ajouter des commandes supplémentaires afin d’installer des dépendances supplémentaires pour votre tâche. Toutefois, nous vous recommandons de limiter les scripts d’installation des dépendances à l’[ensemble des scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) utilisés lors de la création du cluster. Si vous utilisez un environnement virtuel hébergé sur un répertoire partagé, vous pouvez également utiliser ce script pour activer l’environnement virtuel.
1. Lancez la tâche avec la SageMaker HyperPod reprise automatique activée en ajoutant l'indicateur `--auto-resume=1` indiquant que la `srun` commande doit être réessayée automatiquement en cas de panne matérielle.
**Note**
Si vous avez configuré une allocation de ressources en utilisant `sbatch` ou `salloc`, vous pouvez exécuter plusieurs commandes `srun` dans le cadre de l’allocation. En cas d'échec, la fonctionnalité de SageMaker HyperPod reprise automatique ne fonctionne que dans l'[étape de travail](https://slurm.schedmd.com/job_launch.html#step_allocation) en cours de la `srun` commande avec l'indicateur`--auto-resume=1`. En d’autres termes, l’activation de la reprise automatique dans une commande `srun` ne s’applique pas aux autres commandes `srun` lancées au cours d’une session d’allocation de ressources.
Voici des exemples de commande `srun` avec `auto-resume` activé.
**Utilisation de sbatch**
Comme la plus grande partie de la logique de configuration de l’environnement existe déjà dans `train_auto_resume.sh`, le script de commande doit être simple et similaire à l’exemple de code suivant. Supposons que le script de commande suivant soit enregistré sous `batch.sh`.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
Exécutez le script de commande précédent à l’aide de la commande suivante.
```
sbatch batch.sh
```
**Utilisation de salloc**
Commencez par acquérir une allocation exclusive et exécutez la commande `srun` avec l’indicateur `--auto-resume` et le script de point d’entrée.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## Comment la restauration automatique des nœuds et la reprise automatique des nœuds fonctionnent ensemble
Lorsque les systèmes de restauration automatique des nœuds et de reprise automatique sont actifs, ils suivent une approche coordonnée pour gérer les défaillances. Si le HMA détecte une défaillance matérielle, le nœud est marqué comme étant épuisé quel que soit l'état de la tâche. Lorsque la restauration automatique des nœuds est activée, les nœuds sont automatiquement remplacés une fois que toutes les tâches exécutées sur les nœuds sont terminées. Dans ce scénario, pour les tâches pour lesquelles la reprise automatique est activée, si le statut de sortie de l'étape est différent de zéro, la reprise automatique démarre (les tâches reprennent une fois les nœuds remplacés). Les tâches pour lesquelles la reprise automatique n'est pas activée seront simplement abandonnées, ce qui nécessitera une nouvelle soumission manuelle par les administrateurs ou les utilisateurs.
**Note**
Si vous utilisez la reprise automatique, les nœuds sont toujours remplacés (aucun redémarrage) lorsque des défaillances matérielles sont détectées.
# Remplacez ou redémarrez manuellement un nœud à l'aide de Slurm
Cette section explique à quel moment vous devez redémarrer ou remplacer manuellement un nœud, avec des instructions sur la façon de procéder dans les deux cas.
## Quand redémarrer ou remplacer manuellement un nœud
La fonctionnalité de HyperPod reprise automatique surveille si l'état de vos nœuds Slurm passe à ou. `fail` `down` Vous pouvez vérifier l’état des nœuds Slurm en exécutant `sinfo`.
Si un nœud reste bloqué ou ne répond pas et que le processus de reprise automatique ne le rétablit pas, vous pouvez lancer la restauration manuellement. Le choix entre le redémarrage et le remplacement d'un nœud dépend de la nature du problème. Envisagez de redémarrer en cas de problèmes temporaires ou liés au logiciel, tels que des blocages du système, des fuites de mémoire, des problèmes liés au pilote du processeur graphique, des mises à jour du noyau ou des processus bloqués. Toutefois, si vous rencontrez des problèmes persistants ou liés au matériel, tels que des défaillances GPUs, des défaillances de mémoire ou de réseau, des échecs répétés liés aux tests de santé ou des nœuds qui ne répondent toujours pas après plusieurs tentatives de redémarrage, le remplacement des nœuds est la solution la plus appropriée.
## Méthodes de redémarrage ou de remplacement manuel des nœuds
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 des commandes Slurm traditionnelles`scontrol update`, bien que cette ancienne méthode nécessite un accès direct au nœud de contrôleur du Slurm. Les deux méthodes activent les mêmes processus SageMaker HyperPod de restauration.
## Redémarrer manuellement un nœud à l'aide de l'API de redémarrage
Vous pouvez utiliser le **BatchRebootClusterNodes**pour redémarrer manuellement un nœud défectueux de votre SageMaker HyperPod cluster.
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
```
## Remplacer manuellement un nœud à l'aide de l'API de remplacement
Vous pouvez utiliser le **BatchReplaceClusterNodes**pour remplacer manuellement un nœud défectueux dans votre SageMaker HyperPod cluster.
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
```
## Redémarrer manuellement un nœud à l'aide de Slurm
Vous pouvez également utiliser les commandes scontrol Slurm pour déclencher la restauration des nœuds. Ces commandes interagissent directement avec le plan de contrôle Slurm et invoquent les mêmes mécanismes de SageMaker HyperPod restauration sous-jacents.
Dans la commande suivante, remplacez-le par le nom du nœud Slurm (nom d'hôte) de l'instance défectueuse que vous souhaitez redémarrer.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Cela marque le nœud comme FAIL avec la raison spécifiée. SageMaker HyperPod détecte cela et redémarre l'instance. Évitez de modifier l'état du nœud ou de redémarrer le contrôleur Slurm pendant l'opération.
## Remplacer manuellement un nœud à l'aide de Slurm
Vous pouvez utiliser la commande scontrol update comme suit pour remplacer un nœud.
Dans la commande suivante, remplacez `` par le nom du nœud Slurm (nom d'hôte) de l'instance défectueuse que vous souhaitez remplacer.
```
scontrol update node= state=fail reason="Action:Replace"
```
Après avoir exécuté cette commande, le nœud passe à l'`fail`état, attend la fin des tâches en cours d'exécution, est remplacé par une instance saine et est restauré avec le même nom d'hôte. Ce processus prend du temps en fonction des instances disponibles dans votre zone de disponibilité et du temps nécessaire pour exécuter vos scripts de cycle de vie. Pendant les processus de mise à jour et de remplacement, évitez de modifier à nouveau l’état du nœud manuellement ou de redémarrer le contrôleur Slurm. Cela peut entraîner un échec de remplacement. Si le nœud n’est pas rétabli ou ne revient pas à l’état `idle` après une longue période, contactez [AWS Support](https://console.aws.amazon.com/support/).
## Forcer le changement manuel d'un nœud
Si le nœud défaillant est constamment bloqué dans l’état `fail`, le dernier recours que vous pouvez essayer est de forcer manuellement le remplacement de l’état du nœud par `down`. Cela nécessite des privilèges d’administrateur (autorisations sudo).
**Avertissement**
Procédez avec prudence avant d’exécuter la commande suivante, car elle force l’arrêt de toutes les tâches et vous risquez de perdre tout votre travail non enregistré.
```
scontrol update node= state=down reason="Action:Replace"
```