SageMaker HyperPod résilience du cluster

SageMaker HyperPod fournit les fonctionnalités de résilience des clusters suivantes.

Contrôle de santé du cluster

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).

Catégorie	Nom de l'utilitaire	Compatibilité des types d'instance	Description
Accélérateur	Politiques de la DCGM	GPU	Chaque instance du cluster surveille en permanence toutes les politiques liées au GPU, y compris les erreurs XID avec NVIDIA DCGM.
	NVIDIA SMI	GPU	L'utilitaire nvidia-smi est une CLI bien connue pour gérer et surveiller les GPU. Le vérificateur de santé intégré analyse le résultat nvidia-smi pour déterminer l'état de santé de l'instance.
	Systèmes neuronaux	Trainium	Pour les instances alimentées par Trainium, l'état des appareils Neuron est déterminé en lisant les compteurs des systèmes Neuron propagés directement par le pilote Neuron.
Réseau	EFA	GPU et Trainium	Pour faciliter le diagnostic des appareils Elastic Fabric Adaptor (EFA), le vérificateur d'état EFA exécute une série de tests de connectivité en utilisant toutes les cartes EFA disponibles au sein de l'instance.
Stress	Diagnostic du DCGM	GPU	Le diagnostic DCGM de niveau 2 est utilisé pour tester les GPU du système et les mettre sous pression afin d'obtenir un aperçu complet de l'état de santé.
	stress du processeur	GPU et Trainium	L'état du processeur est déterminé à l'aide de l'outil de stress Linux, qui exécute plusieurs threads pour atteindre 100 % d'utilisation du processeur et effectuer des opérations d'E/S.

Reprise automatique

Cette section décrit comment exécuter une tâche de formation avec 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 pour les clusters de plus de 16 nœuds.

Grâce à la fonctionnalité de reprise automatique, si une tâche échoue en raison d'une panne matérielle ou de problèmes transitoires 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.

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 du point d'entrée pour vous assurer que toutes les étapes de configuration s'exécutent dans une seule srun commande lors de la reprise du travail. À l'aide du script entrypoint, 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 travail était exécutée avant son arrêt. 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 l'utilisezsbatch, vous pouvez simplifier le script batch en créant un script distinct pour configurer l'environnement et en utilisant une seule srun commande.

1. Créez un script à l'aide de l'exemple de code suivant et enregistrez-le soustrain_auto_resume.sh. Ce script déploie les configurations de l'environnement de formation 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 indépendant du nœud, de sorte que lorsqu'un nœud est remplacé, le même environnement est configuré sur le nœud avant de reprendre le travail.

   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_NODELISTenvironnement 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 NODE_LIST variable à remplacerSLURM_JOB_NODELIST, puis configurer les MASTER_ADDR variables MASTER_NODE et hors de la NODE_LIST variable.

   #!/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 \
                          <your_training_script.py>"
   
   # 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 utilisés lors de la création du cluster. Si vous utilisez un environnement virtuel hébergé dans un répertoire partagé, vous pouvez également utiliser ce script pour activer l'environnement virtuel.

2. 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 à l'aide de sbatch ousalloc, vous pouvez exécuter plusieurs srun commandes 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 en cours de la srun commande avec l'indicateur--auto-resume=1. En d'autres termes, l'activation de la reprise automatique dans une srun commande ne s'applique pas aux autres srun commandes lancées au cours d'une session d'allocation de ressources.

   Vous trouverez ci-dessous des exemples de srun commandes avec auto-resume activé.

   Utilisation de sbatch

   Comme la plus grande partie de la logique de configuration de l'environnement existe déjàtrain_auto_resume.sh, le script batch doit être simple et similaire à l'exemple de code suivant. Supposons que le script batch suivant soit enregistré sous le nombatch.sh.

   #!/bin/bash
   #SBATCH --nodes 2
   #SBATCH --exclusive
   srun --auto-resume=1 train_auto_resume.sh

   Exécutez le script batch précédent à l'aide de la commande suivante.

   sbatch batch.sh

   Utilisation de salloc

   Commencez par acquérir une allocation exclusive, puis exécutez la srun commande avec le --auto-resume drapeau et le script du point d'entrée.

   salloc -N 2 --exclusive
   srun --auto-resume=1 train_auto_resume.sh

Comment remplacer un nœud défectueux qui n'est pas automatiquement repris par HyperPod

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 le problème d'un nœud n'est pas résolu par la fonctionnalité de HyperPod reprise automatique, nous vous recommandons d'exécuter la commande suivante pour modifier l'état du nœud enfail.

scontrol update node=<ip-ipv4> state=fail reason="Action:Replace"

Dans l'exemple de commande précédent, remplacez <ip-ipv4> par le nom du nœud Slurm (nom d'hôte) de l'instance défectueuse que vous souhaitez remplacer.

Après avoir exécuté cette commande, le nœud doit passer à l'failétat, attendre la fin des tâches en cours d'exécution, être remplacé par une instance saine et être 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 une défaillance lors du remplacement. Si le nœud n'est pas rétabli ou ne revient pas à l'idleétat après une longue période, contactez le AWS Support.

Si le nœud défectueux est constamment bloqué dans fail cet état, le dernier recours que vous pouvez essayer est de forcer le changement manuel de l'état du nœuddown. 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 toutes les tâches non enregistrées.

scontrol update node=<ip-ipv4> state=down reason="Action:Replace"