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 proporciona las siguientes funciones de resiliencia del clúster.
Temas
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-sminvidia-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 |
| 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 |
GPU | El diagnóstico por DCGM |
| Esfuerzo | Esfuerzo de la CPU | GPU y Trainium | El estado de la CPU se determina mediante la herramienta de esfuerzo de Linux |
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)
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.
-
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_NODELISTentorno 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 variableNODE_LISTpara reemplazarSLURM_JOB_NODELISTy, a continuación, configurar las variablesMASTER_NODEyMASTER_ADDRa partir de la variableNODE_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_cmdsugerencia
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.
-
Inicie el trabajo con la SageMaker HyperPod reanudación automática habilitada añadiendo la marca
--auto-resume=1para indicar que elsruncomando debe volver a intentarse automáticamente en caso de fallo de hardware.nota
Si ha configurado una asignación de recursos mediante
sbatchosalloc, puede ejecutar varios comandossrundentro de la asignación. En caso de error, la funcionalidad de SageMaker HyperPod reanudación automática solo funciona en el paso de trabajoactual del sruncomando con el indicador--auto-resume=1. En otras palabras, la activación de la reanudación automática en un comandosrunno se aplica a otros comandossruninicializados en una sesión de asignación de recursos.A continuación, se muestran ejemplos del comando
sruncon la funciónauto-resumehabilitada.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 comobatch.sh.#!/bin/bash #SBATCH --nodes 2 #SBATCH --exclusive srun --auto-resume=1train_auto_resume.shEjecute el script por lotes anteriores mediante el siguiente comando.
sbatchbatch.shUso de salloc
Comience por adquirir una asignación exclusiva y ejecute el comando
sruncon la marca--auto-resumey el script de punto de entrada.salloc -N 2 --exclusive srun --auto-resume=1train_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>
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"