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 del clúster
SageMaker HyperPod mediante la orquestación de Slurm, proporciona las siguientes funciones de resiliencia de clústeres.
**Topics**
+ [Agente de monitorización de la salud](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Recuperación automática de nodos y reanudación automática](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Reemplace o reinicie manualmente un nodo mediante Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agente de monitorización de la salud
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). SageMaker HyperPod el agente de monitorización del estado (HMA) supervisa de forma continua el estado de cada instancia basada en GPU o en Trainium. Cuando detecta algún error en una instancia o en la GPU, el agente marca la instancia como en mal estado.
SageMaker HyperPod HMA realiza las mismas comprobaciones de estado para los orquestadores EKS y Slurm. Para obtener más información sobre HMA, consulte. [Sistema de Monitoreo de Salud](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
# Recuperación automática de nodos y reanudación automática
**nota**
A partir del 11 de septiembre de 2025, la orquestación de Slurm ahora es compatible HyperPod con los agentes de monitorización del estado. Ejecute la versión más reciente de la AMI [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)y actualícela a ella para utilizar esta funcionalidad.
En esta sección se habla de las dos características SageMaker HyperPod de resiliencia complementarias de Amazon: la recuperación automática de nodos, que reemplaza la infraestructura defectuosa sin intervención manual, y la funcionalidad de reanudación automática, que reinicia los trabajos de formación desde el último punto de control tras un fallo de hardware.
## Cómo funciona la recuperación automática de nodos
Durante la creación o actualización del clúster, los usuarios administradores del clúster pueden seleccionar la opción de recuperación de nodos (instancia) entre `Automatic` (recomendado) y `None` en el clúster. Si se establece en`Automatic`, SageMaker HyperPod reinicia o reemplaza automáticamente los nodos defectuosos.
**importante**
Se recomienda configurar la opción `Automatic`. De forma predeterminada, los clústeres se configuran con la recuperación automática de nodos.
La recuperación automática de nodos se ejecuta cuando un agente de supervisión del estado, las comprobaciones de estado básicas y las comprobaciones de estado exhaustivas detectan problemas. Si se establece en `None`, el agente de supervisión del estado etiquetará las instancias cuando se detecte un error, pero no iniciará automáticamente ninguna acción de reparación ni recuperación en los nodos afectados. No recomendamos esta opción.
## Realizar un trabajo de formación con la función de SageMaker HyperPod reanudación automática de Amazon
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.
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. Las siguientes comprobaciones de hardware se ejecutan cada vez que se produce un error en un trabajo al utilizar la reanudación automática:
| Categoría | Nombre de la utilidad | Compatibilidad de los tipos de instancias | Description (Descripción) |
| --- | --- | --- | --- |
| Acelerador | NVIDIA SMI | GPU | [La utilidad nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) 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](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) 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. |
**nota**
Cuando hay [Generic Resources (GRES)](https://slurm.schedmd.com/gres.html) 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. El siguiente procedimiento 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_NODELIST`y, 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 \
"
# 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](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 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.
1. 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](https://slurm.schedmd.com/job_launch.html#step_allocation) 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 funcionan juntas la recuperación automática de nodos y la reanudación automática
Cuando los sistemas de recuperación automática de nodos y de reanudación automática están activos, siguen un enfoque coordinado para gestionar los fallos. Si el HMA detecta un fallo de hardware, el nodo se marca como agotado, independientemente del estado del trabajo. Con la recuperación automática de nodos habilitada, los nodos se sustituyen automáticamente una vez que se cierran todos los trabajos que se están ejecutando en los nodos. En este escenario, para los trabajos con la reanudación automática habilitada, si hay un estado de salida distinto de cero en el paso, la reanudación automática se activa (los trabajos se reanudan una vez que se reemplazan los nodos). Los trabajos que no tengan habilitada la reanudación automática simplemente se cerrarán y los administradores o usuarios deberán volver a enviarlos manualmente.
**nota**
Si utiliza la reanudación automática, los nodos siempre se sustituyen (no se reinician) cuando se detectan fallos de hardware.
# Reemplace o reinicie manualmente un nodo mediante Slurm
En esta sección se explica cuándo se debe reiniciar o reemplazar manualmente un nodo, con instrucciones sobre cómo hacer ambas cosas.
## Cuándo reiniciar o reemplazar un nodo manualmente
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 un nodo permanece atascado o no responde y el proceso de reanudación automática no lo recupera, puede iniciar la recuperación manualmente. La elección entre reiniciar o reemplazar un nodo depende de la naturaleza del problema. Considera la posibilidad de reiniciarlo cuando tengas problemas temporales o relacionados con el software, como bloqueos del sistema, pérdidas de memoria, problemas con los controladores de la GPU, actualizaciones del núcleo o procesos bloqueados. Sin embargo, si te encuentras con problemas persistentes o relacionados con el hardware, como fallos GPUs, fallos en la memoria o la red, fallos repetidos en las comprobaciones de estado o nodos que siguen sin responder tras varios intentos de reinicio, la solución más adecuada es sustituir los nodos.
## Formas de reiniciar o reemplazar los nodos manualmente
SageMaker HyperPod ofrece dos métodos para la recuperación manual de nodos. El enfoque preferido es utilizar el SageMaker HyperPod sistema Reboot and Replace APIs, que proporciona un proceso de recuperación más rápido y transparente que funciona en todos los orquestadores. Como alternativa, puedes usar los comandos tradicionales de Slurm`scontrol update`, aunque este método tradicional requiere acceso directo al nodo controlador del Slurm. Ambos métodos activan los mismos procesos de recuperación. SageMaker HyperPod
## Reinicie manualmente un nodo mediante la API de reinicio
Puede utilizarla **BatchRebootClusterNodes**para reiniciar manualmente un nodo defectuoso SageMaker HyperPod del clúster.
A continuación, se muestra un ejemplo de cómo ejecutar la operación de reinicio en dos instancias de un clúster mediante AWS Command Line Interface:
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Reemplace manualmente un nodo mediante la API de reemplazo
Puede utilizarla **BatchReplaceClusterNodes**para reemplazar manualmente un nodo defectuoso SageMaker HyperPod del clúster.
A continuación, se muestra un ejemplo de cómo ejecutar la operación de reemplazo en dos instancias de un clúster mediante AWS Command Line Interface:
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Reinicie manualmente un nodo mediante Slurm
También puede utilizar los comandos scontrol Slurm para activar la recuperación del nodo. Estos comandos interactúan directamente con el plano de control de Slurm e invocan los mismos mecanismos de recuperación subyacentes. SageMaker HyperPod
En el siguiente comando, sustitúyalo por el nombre del nodo de Slurm (nombre de host) de la instancia defectuosa que deseas reiniciar.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Esto marca el nodo como FALLIDO por el motivo especificado. SageMaker HyperPod lo detecta y reinicia la instancia. Evite cambiar el estado del nodo o reiniciar el controlador Slurm durante la operación.
## Sustituya manualmente un nodo con Slurm
Puede usar el comando scontrol update de la siguiente manera para reemplazar un nodo.
En el siguiente comando, `` sustitúyalo por el nombre del nodo de Slurm (nombre de host) de la instancia defectuosa que deseas reemplazar.
```
scontrol update node= state=fail reason="Action:Replace"
```
Tras ejecutar este comando, el nodo pasará a ese `fail` estado, esperará a que finalicen las tareas que se están ejecutando actualmente, se sustituirá por una instancia en buen estado y se recuperará 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](https://console.aws.amazon.com/support/).
## Forzar el cambio manual de un nodo
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= state=down reason="Action:Replace"
```