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

Resiliencia del clúster de SageMaker HyperPod

SageMaker HyperPod proporciona las siguientes características de resiliencia de clústeres.

Comprobación de estado del clúster

En esta sección, se describe el conjunto de comprobaciones de estado que utiliza SageMaker HyperPod para supervisar periódicamente el estado de las instancias del clúster para detectar problemas con dispositivos como aceleradores (núcleos de GPU y Trainium) y 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 supervisar GPU. 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 de DCGM de nivel 2 se utiliza para ejercitar las GPU del sistema y presionarlas para obtener una visión exhaustiva del estado de las mismas.
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 entrenamiento con la función de reanudación automática de SageMaker HyperPod, que proporciona una infraestructura de resiliencia sin intervención para recuperar automáticamente un trabajo de entrenamiento desde el último punto de comprobación guardado en caso de que se produzca un fallo de hardware.

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 los entrenamientos, la reanudación automática de SageMaker HyperPod inicia el flujo de trabajo de reemplazo de nodos y reinicia el trabajo una vez que se sustituyen 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 reanudación automática de HyperPod vuelve a poner en cola automáticamente cualquier trabajo defectuoso asociado a 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 función de reanudación automática de SageMaker HyperPod con Slurm

Cuando utilice la reanudación automática de SageMaker HyperPod con Slurm, debe ejecutar el trabajo dentro de una asignación exclusiva adquirida mediante el uso de salloc o 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 entorno $SLURM_JOB_NODELIST proporcionada por Slurm, ya que su valor podría estar desactualizado después de que 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 reanudación automática de SageMaker HyperPod habilitada añadiendo la marca --auto-resume=1 para indicar que el comando srun debe reintentarse 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 fallo, la función de reanudación automática de SageMaker HyperPod solo funciona en el paso de trabajo actual del comando srun con la marca --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 HyperPod no reanuda automáticamente

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

Si tiene un nodo atascado por un problema, pero no se soluciona con la función de reanudación automática de HyperPod, le recomendamos que ejecute el siguiente comando para cambiar el estado del nodo a fail.

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"