SageMaker HyperPod résilience du cluster - Amazon SageMaker
Contrôle de santé du clusterReprise automatiqueComment remplacer un nœud défectueux qui n'est pas automatiquement repris par HyperPod

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 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 (GPUet les cœurs Trainium) et le réseau (EFA).

Catégorie Nom de l'utilitaire Compatibilité des types d'instance Description
Accélérateur DCGMpolitiques GPU Chaque instance du cluster surveille en permanence toutes les politiques GPU associées, y compris les XID erreurs liées à NVIDIADCGM.
Accélérateur NVIDIA SMI GPU L'utilitaire nvidia-smi est un outil bien connu CLI pour gérer et surveiller. GPUs Le vérificateur de santé intégré analyse le résultat nvidia-smi pour déterminer l'état de santé de l'instance.
Accélérateur 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 GPUet Trainium Pour faciliter le diagnostic des appareils Elastic Fabric Adaptor (EFA), le vérificateur de EFA santé exécute une série de tests de connectivité en utilisant toutes les EFA cartes disponibles au sein de l'instance.
Stress DCGMdiagnostic niveau 2 GPU DCGMle GPUs niveau de diagnostic 2 est utilisé pour exercer une pression sur le système et le mettre sous pression afin d'obtenir un aperçu complet de son état de santé.
Stress CPUstress GPUet Trainium CPUl'état de santé est déterminé à l'aide de l'outil de stress Linux, qui exécute plusieurs threads pour atteindre 100 % CPU d'utilisation 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.

Note

Lorsque des ressources génériques (GRES) 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 GRES nœuds activés. Ce processus implique d'arrêter le travail, de le replacer dans la file d'attente des travaux, puis de le redémarrer depuis le 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 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 manuellement le changement d'é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"