SageMaker HyperPod resiliencia de clústeres - Amazon SageMaker AI
Comprobación de estado del clústerReanudación automáticaCómo reemplazar un nodo defectuoso que no se reanuda automáticamente mediante HyperPod

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

SageMaker HyperPod resiliencia de clústeres

SageMaker HyperPod proporciona las siguientes funciones de resiliencia del clúster.

Comprobación de estado del clúster

En esta sección se describe el conjunto de comprobaciones de estado que se SageMaker HyperPod utilizan para supervisar periódicamente el estado de las instancias del clúster para detectar problemas con dispositivos como los aceleradores (núcleos de GPU y Trainium) y las redes (EFA).

Categoría Nombre de la utilidad Compatibilidad de los tipos de instancias Descripción
Acelerador Políticas de DCGM GPU Cada instancia del clúster supervisa de forma continua todas las políticas relacionadas con la GPU, incluidos los errores XID, con NVIDIA DCGM.
Acelerador NVIDIA SMI GPU La utilidad nvidia-smi es una CLI muy conocida para administrar y monitorear. GPUs El comprobador de estado integrado analiza el resultado de nvidia-smi para determinar el estado de la instancia.
Acelerador Neuron sysfs Trainium En las instancias impulsadas por Trainium, el estado de los dispositivos de Neuron se determina mediante la lectura de los contadores de Neuron sysfs propagada directamente por el controlador de Neuron.
Network EFA GPU y Trainium Para facilitar el diagnóstico de los dispositivos Elastic Fabric Adaptor (EFA), el comprobador de estado de EFA realiza una serie de pruebas de conectividad con todas las tarjetas EFA disponibles en la instancia.
Esfuerzo Diagnóstico de DCGM de nivel 2 GPU El diagnóstico por DCGM de nivel 2 se utiliza para ejercitar GPUs el sistema y presionarlo para obtener una visión completa del estado de salud.
Esfuerzo Esfuerzo de la CPU GPU y Trainium El estado de la CPU se determina mediante la herramienta de esfuerzo de Linux, que ejecuta varios subprocesos para lograr el 100 % de utilización de la CPU y realizar operaciones de E/S.

Reanudación automática

En esta sección, se describe cómo ejecutar un trabajo de formación con la función de SageMaker HyperPod reanudación automática, que proporciona una infraestructura de resiliencia sin intervención para recuperar automáticamente un trabajo de formación del último punto de control guardado en caso de que se produzca un fallo de hardware en clústeres con más de 16 nodos.

Con la función de reanudación automática, si un trabajo falla debido a un fallo de hardware o a algún problema transitorio entre el entrenamiento, la SageMaker HyperPod reanudación automática inicia el flujo de trabajo de reemplazo de nodos y reinicia el trabajo después de reemplazar los nodos defectuosos.

nota

Cuando hay Generic Resources (GRES) asociados a un nodo de Slurm, Slurm no suele permitir cambios en la asignación de nodos, como la sustitución de nodos, y, por tanto, no permite reanudar un trabajo fallido. A menos que se prohíba explícitamente, la función de HyperPod reanudación automática vuelve a poner en cola automáticamente cualquier trabajo defectuoso asociado a los nodos habilitados para GRES. Este proceso implica detener el trabajo, volver a ponerlo en la cola de trabajos y, a continuación, reiniciarlo desde el principio.

Uso de la SageMaker HyperPod función de reanudación automática con Slurm

Cuando utilices la SageMaker HyperPod reanudación automática con Slurm, debes ejecutar el trabajo dentro de una asignación exclusiva adquirida mediante el uso de o. salloc sbatch En cualquier caso, debe modificar el script de punto de entrada para asegurarse de que todos los pasos de configuración se ejecutan en un solo comando srun al reanudar el trabajo. Mediante el script de punto de entrada, es importante configurar el entorno del nodo sustituido para que sea coherente con el entorno en el que se ejecutaba el paso del trabajo antes de detenerse. En el siguiente procedimiento, se muestra cómo preparar un script de punto de entrada para mantener la coherencia del entorno y ejecutarlo como un solo comando srun.

sugerencia

Si utiliza sbatch, puede simplificar el script por lotes creando un script independiente para configurar el entorno y usar un solo comando srun.

  1. Cree un script con el siguiente ejemplo de código y guárdelo como train_auto_resume.sh. Este script implementa configuraciones de entorno de entrenamiento suponiendo que anteriormente no se haya realizado ninguna configuración manual en el nodo reemplazado. Esto garantiza que el entorno sea independiente de los nodos, de forma que cuando se reemplaza un nodo, se aprovisiona el mismo entorno en el nodo antes de reanudar el trabajo.

    nota

    En el siguiente ejemplo de código, se muestra cómo descubrir la lista de nodos de Slurm asociada a la tarea. No utilice la variable de $SLURM_JOB_NODELIST entorno proporcionada por Slurm, ya que su valor podría estar desactualizado una vez que se SageMaker HyperPod reanude automáticamente el trabajo. En el siguiente ejemplo de código, se muestra cómo definir una nueva variable NODE_LIST para reemplazar SLURM_JOB_NODELISTy, a continuación, configurar las variables MASTER_NODE y MASTER_ADDR a partir 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 \
                       <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
    sugerencia

    Puede usar el script anterior para añadir más comandos e instalar cualquier dependencia adicional para su trabajo. Sin embargo, le recomendamos que mantenga los scripts de instalación de dependencias en el conjunto de scripts de ciclo de vida que se utilizan durante la creación del clúster. Si utiliza un entorno virtual alojado en un directorio compartido, también puede utilizar este script para activar el entorno virtual.

  2. Inicie el trabajo con la SageMaker HyperPod reanudación automática habilitada añadiendo la marca --auto-resume=1 para indicar que el srun comando debe volver a intentarse automáticamente en caso de fallo de hardware.

    nota

    Si ha configurado una asignación de recursos mediante sbatch o salloc, puede ejecutar varios comandos srun dentro de la asignación. En caso de error, la funcionalidad de SageMaker HyperPod reanudación automática solo funciona en el paso de trabajo actual del srun comando con el indicador--auto-resume=1. En otras palabras, la activación de la reanudación automática en un comando srun no se aplica a otros comandos srun inicializados en una sesión de asignación de recursos.

    A continuación, se muestran ejemplos del comando srun con la función auto-resume habilitada.

    Uso de sbatch

    Dado que la mayor parte de la lógica para configurar el entorno ya está en train_auto_resume.sh, el script por lotes debe ser simple y similar al siguiente ejemplo de código. Supongamos que el siguiente script por lotes está guardado como batch.sh.

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

    Ejecute el script por lotes anteriores mediante el siguiente comando.

    sbatch batch.sh

    Uso de salloc

    Comience por adquirir una asignación exclusiva y ejecute el comando srun con la marca --auto-resume y el script de punto de entrada.

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

Cómo reemplazar un nodo defectuoso que no se reanuda automáticamente mediante HyperPod

La HyperPod función de reanudación automática monitorea si el estado de los nodos de Slurm cambia a o. fail down Puede comprobar el estado de los nodos de Slurm ejecutando sinfo.

Si tienes un nodo atascado por un problema pero la función de HyperPod reanudación automática no lo ha solucionado, te recomendamos que ejecutes el siguiente comando para cambiar el estado del nodo afail.

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

En el ejemplo del comando anterior, sustituya <ip-ipv4> por el nombre del nodo de Slurm (nombre de host) de la instancia defectuosa que desea reemplazar.

Tras ejecutar este comando, el nodo debería entrar en el estado fail, esperar a que finalicen los trabajos que se estén ejecutando actualmente, ser reemplazado por una instancia en buen estado y recuperarse con el mismo nombre de host. Este proceso lleva tiempo en función de las instancias disponibles en la zona de disponibilidad y del tiempo que se tarda en ejecutar los scripts de ciclo de vida. Durante los procesos de actualización y reemplazo, evite volver a cambiar el estado del nodo manualmente o reiniciar el controlador de Slurm; de lo contrario, podría producirse un error de reemplazo. Si el nodo no se recupera ni pasa al estado idle después de un periodo de tiempo prolongado, póngase en contacto con el Soporte de AWS.

Si el nodo defectuoso se mantiene atascado en el estado fail, el último recurso que puede intentar es forzar manualmente el cambio de estado del nodo a down. Esto requiere privilegios de administrador (permisos sudo).

aviso

Proceda con cuidado antes de ejecutar el siguiente comando, ya que provocará la eliminación de todos los trabajos y podría perder todo el trabajo no guardado.

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