¿Por qué no puedo encontrar los grupos de registros de mi SageMaker HyperPod clúster en Amazon CloudWatch?¿Qué configuraciones específicas se HyperPod gestionan en los archivos de configuración de Slurm, como slurm.conf y? gres.conf ¿Cómo ejecuto Docker en los nodos de Slurm? HyperPod ¿Por qué mi trabajo de formación en paralelo fracasa cuando utilizo la biblioteca de comunicaciones colectivas de NVIDIA (NCCL) con Slurm en la plataforma? SageMaker HyperPod ¿Cómo uso el NVMe almacén local de instancias P para lanzar contenedores de Docker o Enroot con Slurm?¿Cómo configurar los grupos de seguridad de EFA?¿Cómo superviso los nodos de mi HyperPod clúster? ¿De dónde se exporta alguna CloudWatch métrica HyperPod?¿Puedo añadir almacenamiento adicional a los nodos del HyperPod clúster? Las instancias del clúster tienen un almacén de instancias local limitado.¿Por qué mis nodos de cómputo aparecen como «INACTIVOS» o «AGOTADOS» después de un reinicio?¿Por qué mis nodos se agotan continuamente debido a problemas de falta de memoria (OOM)?¿Cómo puedo asegurarme de que los recursos se limpien adecuadamente una vez finalizados los trabajos?

SageMaker HyperPod FAQs

Utilice las siguientes preguntas frecuentes para solucionar problemas de uso. SageMaker HyperPod

Amazon SageMaker HyperPod FAQs

¿Por qué no puedo encontrar los grupos de registros de mi SageMaker HyperPod clúster en Amazon CloudWatch?
¿Qué configuraciones específicas se HyperPod gestionan en los archivos de configuración de Slurm, como slurm.conf y? gres.conf
¿Cómo ejecuto Docker en los nodos de Slurm? HyperPod
¿Por qué mi trabajo de formación en paralelo fracasa cuando utilizo la biblioteca de comunicaciones colectivas de NVIDIA (NCCL) con Slurm en la plataforma? SageMaker HyperPod
¿Cómo uso el NVMe almacén local de instancias P para lanzar contenedores de Docker o Enroot con Slurm?
¿Cómo configurar los grupos de seguridad de EFA?
¿Cómo superviso los nodos de mi HyperPod clúster? ¿De dónde se exporta alguna CloudWatch métrica HyperPod?
¿Puedo añadir almacenamiento adicional a los nodos del HyperPod clúster? Las instancias del clúster tienen un almacén de instancias local limitado.
¿Por qué mis nodos de cómputo aparecen como «INACTIVOS» o «AGOTADOS» después de un reinicio?
¿Por qué mis nodos se agotan continuamente debido a problemas de falta de memoria (OOM)?
¿Cómo puedo asegurarme de que los recursos se limpien adecuadamente una vez finalizados los trabajos?

¿Por qué no puedo encontrar los grupos de registros de mi SageMaker HyperPod clúster en Amazon CloudWatch?

De forma predeterminada, los registros de los agentes y los registros de inicio de las instancias se envían a la cuenta de la HyperPod plataforma CloudWatch. En el caso de los scripts del ciclo de vida del usuario, los registros de configuración del ciclo de vida se envían a la cuenta de los usuarios CloudWatch.

Si utiliza los ejemplos de scripts de ciclo de vida proporcionados por el equipo de HyperPod servicio, encontrará los registros de configuración del ciclo de vida en los /var/log/provision/provisioning.log que se han escrito y no tendrá este problema.

Sin embargo, si utilizas rutas personalizadas para recopilar los registros del aprovisionamiento del ciclo de vida y no encuentras los grupos de registros que aparecen en la de tu cuenta CloudWatch, es posible que no coincidan las rutas de los archivos de registro especificadas en tus scripts de ciclo de vida y lo que busca el CloudWatch agente que se ejecuta en las instancias del HyperPod clúster. En este caso, significa que debe configurar correctamente los scripts de ciclo de vida para enviar los registros al CloudWatch agente y, además, configurar la configuración del CloudWatch agente en consecuencia. Para resolver el problema, elija una de las siguientes opciones.

Opción 1: actualice los scripts de ciclo de vida para que los registros se escriban en /var/log/provision/provisioning.log.
Opción 2: actualice el CloudWatch agente para buscar sus rutas personalizadas para registrar el aprovisionamiento del ciclo de vida.
1. Cada instancia de HyperPod clúster contiene un archivo de configuración del CloudWatch agente en formato JSON en/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json. En el archivo de configuración, busque el nombre de campo logs.logs_collected.files.collect_list.file_path. Si la configuración predeterminada es de HyperPod, el par clave-valor debería ser "file_path": "/var/log/provision/provisioning.log" como se indica en. Registro SageMaker HyperPod a nivel de instancia El siguiente fragmento de código muestra el aspecto del archivo JSON con la configuración predeterminada. HyperPod
```
"logs": {
    "logs_collected": {
        "files": {
            "collect_list": [
                {
                    "file_path": "/var/log/provision/provisioning.log",
                    "log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]",
                    "log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}",
                    "retention_in_days": -1
                }
            ]
        }
    },
    "force_flush_interval": 3
}
```
2. Sustituya el valor del nombre del campo "file_path" por la ruta personalizada que utilice en los scripts de ciclo de vida. Por ejemplo, si ha configurado los scripts de ciclo de vida para que escriban en /var/log/custom-provision/custom-provisioning.log, actualice el valor para que coincida de la siguiente manera.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
3. Reinicie el CloudWatch agente con el archivo de configuración para terminar de aplicar la ruta personalizada. Por ejemplo, el siguiente CloudWatch comando muestra cómo reiniciar el CloudWatch agente con el archivo de configuración del CloudWatch agente desde el paso 1. Para obtener más información, consulte también Solución de problemas del CloudWatch agente.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
    -a fetch-config -m ec2 -s -c \
    file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
```

¿Qué configuraciones específicas se HyperPod gestionan en los archivos de configuración de Slurm, como `slurm.conf` y? `gres.conf`

Al crear un clúster de Slurm en HyperPod, el HyperPod agente configura los gres.confarchivos slurm.confy /opt/slurm/etc/ para gestionar el clúster de Slurm en función de la solicitud de creación del clúster y de los scripts del ciclo de vida HyperPod . En la siguiente lista se muestran los parámetros específicos que el HyperPod agente gestiona y sobrescribe.

importante

Le recomendamos encarecidamente que NO cambie estos parámetros gestionados por HyperPod.

En slurm.conf, HyperPod configura los siguientes parámetros básicos: ClusterNameSlurmctldHost,PartitionName, yNodeName.

Además, para habilitar la Reanudación automática funcionalidad, HyperPod requiere que los SchedulerParameters parámetros TaskPlugin y estén configurados de la siguiente manera. El HyperPod agente configura estos dos parámetros con los valores necesarios de forma predeterminada.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
En gres.conf, HyperPod gestiona NodeName los nodos de la GPU.

¿Cómo ejecuto Docker en los nodos de Slurm? HyperPod

Para ayudarte a ejecutar Docker en los nodos de Slurm en los que se estén ejecutando HyperPod, el equipo de HyperPod servicio proporciona scripts de configuración que puedes incluir como parte de la configuración del ciclo de vida para la creación de clústeres. Para obtener más información, consulte Los scripts de ciclo de vida básicos proporcionados por HyperPod y Ejecutar contenedores Docker en un nodo de cómputo de Slurm en HyperPod.

¿Por qué mi trabajo de formación en paralelo fracasa cuando utilizo la biblioteca de comunicaciones colectivas de NVIDIA (NCCL) con Slurm en la plataforma? SageMaker HyperPod

De forma predeterminada, el sistema operativo Linux establece la bandera. #RemoveIPC=yes Los trabajos de Slurm y mpirun que utilizan NCCL generan recursos de comunicación entre procesos (IPC) en sesiones de usuarios no root. Es posible que estas sesiones de usuario se cierren durante el proceso de trabajo.

Al ejecutar trabajos con Slurm o mpirun, si systemd detecta que el usuario no ha iniciado sesión, se limpian los recursos del IPC. Los trabajos de Slurm y mpirun se pueden ejecutar sin que el usuario haya iniciado sesión, pero para ello es necesario deshabilitar la limpieza en el nivel systemd y configurarla en el nivel Slurm. Para obtener más información, consulte Systemd en la documentación de la NCCL.

Para deshabilitar la limpieza en el nivel systemd, complete los siguientes pasos.

Defina la marca #RemoveIPC=no en el archivo /etc/systemd/logind.conf si está realizando trabajos de entrenamiento que utilizan Slurm y NCCL.

De forma predeterminada, Slurm no limpia los recursos compartidos. Le recomendamos que configure un script epilog de Slurm para limpiar los recursos compartidos. Esta limpieza resulta útil cuando tiene muchos recursos compartidos y desea limpiarlos después de realizar tareas de formación. A continuación se muestra un ejemplo de script.


#!/bin/bash
: <<'SUMMARY'
Script: epilog.sh

Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.

Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.

SUMMARY

# Define the log directory and create it if it doesn't exist
LOG_DIR="/<PLACEHOLDER>/epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"

# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"

logging() {
    echo "[$(date)] $1" | tee -a "$log_file"
}

# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"

# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
    if ipcrm -m "$seg"; then
        logging "Removed shared memory segment $seg"
    else
        logging "Failed to remove shared memory segment $seg"
    fi
done

# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
    if ipcrm -s "$sem"; then
        logging "Removed semaphore $sem"
    else
        logging "Failed to remove semaphore $sem"
    fi
done

# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
    if [ -e "$file" ]; then
        if rm "$file"; then
            logging "Removed NCCL IPC file $file"
        else
            logging "Failed to remove NCCL IPC file $file"
        fi
    fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0

Para obtener más información sobre el parámetro Epilog, consulte la documentación de Slurm.

En el slurm.conf archivo del nodo del controlador, añada una línea que apunte al guion de epilog que ha creado.
```
Epilog="/path/to/epilog.sh"  #For example: /fsx/epilogue/epilog.sh
```
Ejecute los siguientes comandos para cambiar los permisos del script y hacerlo ejecutable.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x  /path/to/epilog.sh
```
Para aplicar todos los cambios, ejecutescontrol reconfigure.

¿Cómo uso el NVMe almacén local de instancias P para lanzar contenedores de Docker o Enroot con Slurm?

Como el volumen raíz predeterminado del nodo principal suele estar limitado a un volumen de EBS de 100 GB, debe configurar Docker y Enroot para que usen el almacén de instancias local. NVMe Para obtener información sobre cómo configurar la NVMe tienda y usarla para lanzar contenedores de Docker, consulte. Ejecutar contenedores Docker en un nodo de cómputo de Slurm en HyperPod

¿Cómo configurar los grupos de seguridad de EFA?

Si desea crear un HyperPod clúster con instancias habilitadas para EFA, asegúrese de configurar un grupo de seguridad que permita que todo el tráfico entrante y saliente entre y hacia el propio grupo de seguridad. Para obtener más información, consulte el Paso 1: Preparar un grupo de seguridad habilitado para EFA en la Guía del EC2 usuario de Amazon.

¿Cómo superviso los nodos de mi HyperPod clúster? ¿De dónde se exporta alguna CloudWatch métrica HyperPod?

Para poder observar la utilización de los recursos de su HyperPod clúster, le recomendamos que lo integre con Amazon Managed Grafana y Amazon Managed Service for Prometheus. HyperPod Con varios paquetes de exportación y paneles de Grafana de código abierto, puede exportar y visualizar las métricas relacionadas con los recursos del clúster. HyperPod Para obtener más información sobre la configuración SageMaker HyperPod con Amazon Managed Grafana y Amazon Managed Service for Prometheus, consulte. SageMaker HyperPod monitoreo de recursos de clústeres Ten en cuenta que SageMaker HyperPod actualmente no admite la exportación de métricas del sistema a Amazon CloudWatch.

¿Puedo añadir almacenamiento adicional a los nodos del HyperPod clúster? Las instancias del clúster tienen un almacén de instancias local limitado.

Si el almacenamiento de instancias predeterminado no es suficiente para su carga de trabajo, puede configurar un almacenamiento adicional para cada instancia. A partir del lanzamiento del 20 de junio de 2024, puedes añadir un volumen adicional de Amazon Elastic Block Store (EBS) a cada instancia de tu clúster. SageMaker HyperPod Tenga en cuenta que esta capacidad no se puede aplicar a los grupos de instancias de SageMaker HyperPod clústeres existentes creados antes del 20 de junio de 2024. Puedes utilizar esta capacidad parcheando SageMaker HyperPod los clústeres existentes creados antes del 20 de junio de 2024 y añadiéndoles nuevos grupos de instancias. Esta capacidad es totalmente efectiva para cualquier SageMaker HyperPod clúster creado después del 20 de junio de 2024.

¿Por qué mis nodos de cómputo aparecen como «INACTIVOS» o «AGOTADOS» después de un reinicio?

Esto suele ocurrir cuando los nodos se reinician utilizando la interfaz de control de Slurm sudo reboot en lugar de la interfaz de control. Para reiniciar los nodos correctamente, utilice el comando Slurm. scontrol reboot nextstate=resume <list_of_nodes> Esto garantiza que Slurm mantenga un control adecuado del estado del nodo y reanude su funcionamiento normal tras el reinicio.

En el caso de las instancias de GPU (como NVIDIA P5), esto también puede ocurrir si el nodo no puede completar su proceso de arranque dentro del límite de tiempo predeterminado de Slurm (60 segundos). Para resolver este problema, aumenta el TimeToResume parámetro slurm.conf a 300 segundos. Esto proporciona a las instancias de GPU tiempo suficiente para arrancar e inicializar los controladores.

¿Por qué mis nodos se agotan continuamente debido a problemas de falta de memoria (OOM)?

Los problemas de OOM se producen cuando los trabajos superan la capacidad de memoria del nodo. Para evitarlo, impleméntelo cgroups para hacer cumplir los límites de memoria por trabajo. Esto evita que un solo trabajo afecte a todo el nodo y mejora el aislamiento y la estabilidad.

Ejemplo de configuración enslurm.conf:


TaskPlugin=task/cgroup

Ejemplo de configuración encgroup.conf:


CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100

Para obtener más información, consulte Control Group en Slurm, Control de inicio de sesión basado en Cgroup y PAM para los nodos de cómputo de Slurm y Configurar Cgroups para Slurm.

¿Cómo puedo asegurarme de que los recursos se limpien adecuadamente una vez finalizados los trabajos?

Implemente guiones de epílogo para limpiar automáticamente los recursos una vez finalizados los trabajos. Es posible que los recursos no se borren correctamente si los trabajos se bloquean inesperadamente, contienen errores que impiden una limpieza normal o cuando los búferes de memoria compartida (incluidos los que se comparten entre los procesos y los controladores de la GPU) se mantienen asignados.

Los scripts de Epilogue pueden realizar tareas como borrar la memoria de la GPU, eliminar archivos temporales y desmontar sistemas de archivos. Estos scripts tienen limitaciones cuando los recursos no se asignan exclusivamente a una sola tarea. Para obtener instrucciones detalladas y ejemplos de guiones, consulta el segundo bullet point de la pregunta¿Por qué mi trabajo de formación en paralelo fracasa cuando utilizo la biblioteca de comunicaciones colectivas de NVIDIA (NCCL) con Slurm en la plataforma? SageMaker HyperPod . Para obtener más información, consulte Habilitar el script epilog de Slurm.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Administración de clústeres

Orquestación de Amazon EKS