SageMaker HyperPod Preguntas frecuentes

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

P: ¿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 tu cuenta 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

P: ¿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 . La siguiente lista muestra 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.

P: ¿Cómo puedo ejecutar Docker en los nodos de Slurm? HyperPod

Para ayudarlo 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 puede 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 Comience con los scripts básicos del ciclo de vida proporcionados por HyperPod y Ejecute contenedores de Docker en un nodo de cómputo de Slurm en HyperPod.

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

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.

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

2. 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.

3. En el slurm.conf archivo del nodo del controlador, añada una línea que apunte al guion de epilog que creó.

   Epilog="/path/to/epilog.sh"  #For example: /fsx/epilogue/epilog.sh

4. 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

5. Para aplicar todos los cambios, ejecutescontrol reconfigure.

P: ¿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. Ejecute contenedores de Docker en un nodo de cómputo de Slurm en HyperPod

P: ¿Cómo se configuran 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.

P: ¿Cómo puedo monitorizar 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.

P: ¿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.