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. # Configurar UltraServer instancias UltraServer Las instancias de NVIDIA conectan varias GPU entre instancias mediante NVLink. GPU-to-GPU la comunicación a través de NVLink requiere que el [ servicio ](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/index.html) NVIDIA IMEX esté configurado con las direcciones IP de todos los nodos de procesamiento de la tarea. En esta página, se muestra cómo crear un script de prólogo de Slurm que configure automáticamente el IMEX para cada trabajo y cómo implementarlo en el clúster de PCS. AWS ## Requisitos previos + Un clúster de AWS PCS con Slurm 25.05 o posterior. + Un grupo de nodos de procesamiento que usa UltraServer instancias con un bloque de capacidad. Para obtener más información, consulte [Configurar un grupo de nodos de cómputo de AWS PCS para usar un bloque de capacidad](capacity-blocks-configure-cng.md). + Una AMI con los paquetes de controlador, CUDA e IMEX de NVIDIA instalados. El servicio IMEX (`nvidia-imex`) debe estar habilitado en la AMI. + El script de prólogo debe estar disponible en todos los nodos de procesamiento de la ruta configurada en la configuración de `Prolog` Slurm del clúster. Puedes usar un sistema de archivos compartido o incluir el script en tu AMI personalizada. ## Selección topológica automática Al crear un clúster AWS PCS con grupos de nodos de UltraServer procesamiento, el sistema inspecciona el bloque de capacidad, identifica el UltraServer tipo y configura Slurm con el complemento de topología adecuado. Este proceso se ejecuta automáticamente y no requiere ninguna configuración. AWS PCS administra la topología a través de un `topology.yaml` archivo generado dinámicamente. A medida que el clúster evoluciona mediante la adición o eliminación de grupos de nodos de procesamiento, AWS PCS reconcilia continuamente la configuración de la topología para reflejar el estado actual del clúster. La topología de bloques modela dominios de comunicación uniformes y de gran ancho de banda en los que todas las GPU participan en un único dominio NVLink de alta velocidad con una latencia casi uniforme. El `topology/block` complemento asigna los nodos en función de la topología de red definida, lo que garantiza que los trabajos se coloquen en la misma red UltraServer y que la GPU-to-GPU comunicación utilice NVLink en lugar de recurrir a redes EFA. ## Uso del complemento topology/block El programador de Slurm coloca automáticamente los trabajos enviados a las UltraServer colas dentro del mismo bloque (UltraServer). Todos los nodos de un bloque se asignan a un trabajo antes de que se utilice el siguiente bloque. Los trabajos deben usar la `--exclusive` marca porque IMEX requiere un dominio IMEX dedicado por trabajo y, si se reinicia el servicio IMEX, se interrumpiría cualquier otro trabajo en ejecución en los mismos nodos. Para obtener más información sobre el topology/block complemento, consulta la guía de [ topología ](https://slurm.schedmd.com/topology.html) y la referencia topology.yaml en la documentación de [ Slurm. ](https://slurm.schedmd.com/topology.yaml.html) Al enviar trabajos, puedes usar el `--segment=N` argumento with `sbatch` y los `srun` comandos para especificar el número de nodos que se van a agrupar dentro del mismo bloque. El tamaño del segmento debe ser menor o igual que el tamaño del bloque de planificación. `--segment`El uso no garantiza que los segmentos se coloquen en bloques diferentes. A continuación se muestran ejemplos de escenarios para asignar bloques en una cola de 18 nodos UltraServers (por ejemplo, una `u-p6e-gb200x72` que tiene 18 `p6e-gb200.36xlarge` instancias): ``` # Allocate a whole block (single UltraServer) sbatch -N18 --exclusive --partition=ultra job.sh # Allocate two full blocks (two UltraServers) sbatch -N36 --exclusive --partition=ultra job.sh # Allocate 24 nodes: full block is filled before 2nd block is used sbatch -N24 --exclusive --partition=ultra job.sh # Allocate 24 nodes as segments of 12, segments can fit on blocks with available space sbatch -N24 --segment=12 --exclusive --partition=ultra job.sh ``` ## Mejores prácticas de topología UltraServer Para un rendimiento óptimo con una UltraServer arquitectura en AWS PCS: + **Utilice los segmentos para mejorar la disponibilidad**: utilice la `--segment` opción con un valor inferior al tamaño total del bloque para poder programar los trabajos en bloques que tengan algunos nodos agotados o no disponibles. Esto cambia la localidad absoluta de NVLink por tiempos de programación de trabajos más rápidos. Para obtener más información, consulta Cómo [ obtener más control sobre la programación de nodos con el Topology/Block complemento](https://slurm.schedmd.com/SLUG24/NVIDIA-Craig_Tierney.pdf). + **Considera el tamaño del trabajo y el tamaño de los bloques**: si`BlockSizes=18`, los trabajos con hasta 18 instancias siempre se ejecutan en una sola instancia UltraServer. Los trabajos que solicitan más de 18 nodos abarcan varios bloques UltraServers, con conectividad NVLink dentro de cada bloque y redes EFA entre bloques. + **Ventajas y desventajas de los segmentos**: su uso `--segment` desactiva la programación de tamaños de bloques de orden superior. `--segment`En caso contrario, se rellena un bloque completo antes de usar el siguiente bloque. Con`--segment`, los segmentos se pueden colocar en cualquier bloque con suficientes nodos disponibles. ## Limitaciones + AWS El PCS requiere que los grupos de nodos de UltraServer cómputos se coloquen en colas dedicadas, separados de los grupos de nodos que no son de UltraServer cómputos. + Cada grupo de nodos de procesamiento solo se puede asociar a un bloque UltraServer de capacidad. + Cuando una cola contiene varios grupos de nodos de UltraServer procesamiento, el recuento de instancias de cada grupo de nodos de procesamiento debe tener una relación de potencia de 2 entre ellos (por ejemplo, 9 y 18, o 2 y 8). + Los trabajos en UltraServer cola deben usar la `--exclusive` marca para garantizar un dominio IMEX dedicado por trabajo. + El dominio IMEX creado por el script prólogo incluye solo los nodos asignados al trabajo. Dado que AWS PCS asigna los nodos a las tareas de forma dinámica, el dominio IMEX no se puede crear previamente y se debe configurar al iniciar la tarea. Los trabajos que abarquen varios nodos no UltraServers dispondrán de conectividad NVLink entre nodos de diferentes ubicaciones, UltraServers ya que el dominio IMEX se basa en direcciones IP y no puede conectar estructuras NVLink independientes. + El IMEX `nodes_config.cfg` no se puede modificar mientras el servicio esté en ejecución. Si se cambia la configuración, IMEX bloquea permanentemente la comunicación con los nodos que no coinciden. La única recuperación es detener el IMEX en todos los nodos y reiniciarlo con una configuración coherente. ## Cree el script de prólogo de IMEX El siguiente `91_nvidia_imex_prolog.sh` script configura NVIDIA IMEX en los nodos de procesamiento cuando se inicia un trabajo de Slurm. El nombre del script usa un `91` prefijo que sigue la convención de nomenclatura de [ SchedMD para el orden de ejecución del prólogo. ](https://slurm.schedmd.com/prolog_epilog.html) El script realiza las siguientes acciones: 1. Comprueba si el trabajo es exclusivo. La configuración de IMEX requiere trabajos exclusivos para evitar interrumpir otros trabajos en ejecución en los mismos nodos. 1. Comprueba si el tipo de instancia es compatible UltraServer (`p6e-gb200`o`p6e-gb300`). 1. Comprueba si el servicio IMEX está activado. 1. Crea el dispositivo de canal predeterminado de IMEX si no existe. 1. Escribe en él las direcciones IP privadas de todos los nodos de trabajo. `/etc/nvidia-imex/nodes_config.cfg` 1. Reinicia el servicio IMEX. **importante** Este script de prólogo requiere que los trabajos se envíen con la marca. `--exclusive` Reiniciar IMEX mientras otros trabajos se están ejecutando en los mismos nodos interrumpirá esos trabajos. **nota** Este script de prólogo admite `p6e-gb200` cualquier tipo de instancia. `p6e-gb300` Para adaptarlo a otros tipos de instancias, actualice el `ALLOWED_INSTANCE_TYPES` patrón del script. Guarde el siguiente script como`91_nvidia_imex_prolog.sh`: ``` #!/usr/bin/env bash # This prolog script configures NVIDIA IMEX on compute nodes involved in the job execution. # # In particular: # - Checks whether the job is executed exclusively. # If not, it exits immediately because it requires jobs to be executed exclusively. # - Checks if it is running on a supported UltraServer instance type. # If not, it exits immediately because IMEX must be configured only on those instance types. # - Checks if the IMEX service is enabled. # If not, it exits immediately because IMEX must be enabled to get configured. # - Creates the IMEX default channel. # For more information about IMEX channels, see # https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/imexchannels.html # - Writes the private IP addresses of compute nodes into /etc/nvidia-imex/nodes_config.cfg. # - Restarts the IMEX system service. # # REQUIREMENTS: # - This prolog assumes to be run only with exclusive jobs. LOG_FILE_PATH="/var/log/nvidia-imex-prolog.log" SCONTROL_CMD="scontrol" IMEX_START_TIMEOUT=60 IMEX_STOP_TIMEOUT=15 ALLOWED_INSTANCE_TYPES="^(p6e-gb200|p6e-gb300)" IMEX_SERVICE="nvidia-imex" IMEX_NODES_CONFIG="/etc/nvidia-imex/nodes_config.cfg" function info() { echo "$(date "+%Y-%m-%dT%H:%M:%S.%3N") [INFO] [PID:$$] [JOB:${SLURM_JOB_ID}] $1" } function warn() { echo "$(date "+%Y-%m-%dT%H:%M:%S.%3N") [WARN] [PID:$$] [JOB:${SLURM_JOB_ID}] $1" } function error() { echo "$(date "+%Y-%m-%dT%H:%M:%S.%3N") [ERROR] [PID:$$] [JOB:${SLURM_JOB_ID}] $1" } function prolog_end() { info "PROLOG End JobId=${SLURM_JOB_ID}: $0" info "----------------" exit 0 } function get_instance_type() { local token=$(curl -X PUT -s "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") curl -s -H "X-aws-ec2-metadata-token: ${token}" http://169.254.169.254/latest/meta-data/instance-type } function return_if_unsupported_instance_type() { local instance_type=$(get_instance_type) if [[ ! ${instance_type} =~ ${ALLOWED_INSTANCE_TYPES} ]]; then info "Skipping IMEX configuration because instance type ${instance_type} does not support it" prolog_end fi } function return_if_imex_disabled() { if ! systemctl is-enabled "${IMEX_SERVICE}" &>/dev/null; then warn "Skipping IMEX configuration because system service ${IMEX_SERVICE} is not enabled" prolog_end fi } function return_if_job_is_not_exclusive() { if [[ "${SLURM_JOB_OVERSUBSCRIBE}" =~ ^(NO|TOPO)$ ]]; then info "Job is exclusive, proceeding with IMEX configuration" else info "Skipping IMEX configuration because the job is not exclusive" prolog_end fi } function get_ips_from_node_names() { local _nodes=$1 ${SCONTROL_CMD} -ao show node "${_nodes}" | sed 's/^.* NodeAddr=\([^ ]*\).*/\1/' } function reload_imex() { info "Stopping IMEX" timeout ${IMEX_STOP_TIMEOUT} systemctl stop ${IMEX_SERVICE} pkill -9 ${IMEX_SERVICE} info "Restarting IMEX" timeout ${IMEX_START_TIMEOUT} systemctl start ${IMEX_SERVICE} } function create_default_imex_channel() { info "Creating IMEX default channel" MAJOR_NUMBER=$(cat /proc/devices | grep nvidia-caps-imex-channels | cut -d' ' -f1) if [ ! -d "/dev/nvidia-caps-imex-channels" ]; then sudo mkdir /dev/nvidia-caps-imex-channels fi # Then check and create device node if [ ! -e "/dev/nvidia-caps-imex-channels/channel0" ]; then sudo mknod /dev/nvidia-caps-imex-channels/channel0 c $MAJOR_NUMBER 0 info "IMEX default channel created" else info "IMEX default channel already exists" fi } { info "PROLOG Start JobId=${SLURM_JOB_ID}: $0" return_if_job_is_not_exclusive return_if_unsupported_instance_type return_if_imex_disabled create_default_imex_channel IPS_FROM_CR=$(get_ips_from_node_names "${SLURM_NODELIST}") info "Node Names: ${SLURM_NODELIST}" info "Node IPs: ${IPS_FROM_CR}" info "IMEX Nodes Config: ${IMEX_NODES_CONFIG}" info "Updating IMEX nodes config ${IMEX_NODES_CONFIG}" echo "${IPS_FROM_CR}" > "${IMEX_NODES_CONFIG}" reload_imex prolog_end } 2>&1 | tee -a "${LOG_FILE_PATH}" | logger -t "91_nvidia_imex_prolog" ``` ## Implemente el script de prólogo Para implementar el script de prólogo, configura los ajustes `PrologFlags` personalizados `Prolog` y de Slurm en tu clúster. Puedes configurarlos cuando crees un clúster o actualices un clúster existente. Para obtener más información sobre cómo configurar los ajustes personalizados de Slurm, consulte. [Ajustes personalizados de Slurm para AWS clústeres PCS](slurm-custom-settings-cluster.md) Para obtener información sobre el procedimiento para actualizar un clúster, consulte. [Actualizar un AWS Clúster PCS](working-with_clusters_update_procedure.md) Establezca la siguiente configuración personalizada de Slurm en el clúster: + `Prolog`- Defina la ruta en la que el script de prólogo está disponible en los nodos de procesamiento, por ejemplo. `/shared/scripts/prolog.d/91_nvidia_imex_prolog.sh` + `PrologFlags`- Establézcalo en. `Alloc,NoHold` El `Alloc` indicador ejecuta el prólogo en cada nodo cuando se asigna por primera vez a un trabajo. La `NoHold` marca evita que la tarea se mantenga en espera si se produce un error en el prólogo. **Example Actualice el clúster con la configuración del prólogo mediante el AWS CLI** ``` aws pcs update-cluster \ --cluster-identifier \ --slurm-configuration '{ "slurmCustomSettings": [ {"parameterName": "Prolog", "parameterValue": "/shared/scripts/prolog.d/91_nvidia_imex_prolog.sh"}, {"parameterName": "PrologFlags", "parameterValue": "Alloc,NoHold"} ] }' ``` ## Valide la configuración de IMEX El script prolog se ejecuta automáticamente cuando envías un trabajo de Slurm. Envía un trabajo de prueba para comprobar que IMEX está configurado correctamente en todos los nodos. Cree un script de trabajo llamado`check-imex.sh`: ``` #!/bin/bash #SBATCH --job-name=nvidia-imex-status #SBATCH --ntasks-per-node=1 #SBATCH --exclusive #SBATCH --output=imex-status-%j.out #SBATCH --error=imex-status-%j.err srun bash -c "/usr/bin/nvidia-imex-ctl -N > imex_result_\${SLURM_JOB_ID}_\$(hostname).out 2>&1" ``` Envía el trabajo a tu UltraServer lista de espera: ``` sbatch -p {{queue-name}} -N {{node-count}} check-imex.sh ``` Compruebe los archivos de salida. Una configuración IMEX correcta muestra todos los nodos en `READY` estado de `C` (Conectados) en la tabla de conectividad y`Domain State: UP`: ``` Connectivity Table Legend: I - Invalid - Node wasn't reachable, no connection status available N - Never Connected R - Recovering - Connection was lost, but clean up has not yet been triggered. D - Disconnected - Connection was lost, and clean up has been triggreed. A - Authenticating - If GSSAPI enabled, client has initiated mutual authentication. !V! - Version mismatch, communication disabled. !M! - Node map mismatch, communication disabled. C - Connected - Ready for operation 5/4/2026 06:08:10.580 Nodes: Node #0 - 172.31.48.81 - READY - Version: 570.172 Node #1 - 172.31.48.98 - READY - Version: 570.172 Node #2 - 172.31.48.221 - READY - Version: 570.172 Node #3 - 172.31.49.228 - READY - Version: 570.172 Node #4 - 172.31.50.39 - READY - Version: 570.172 Node #5 - 172.31.50.44 - READY - Version: 570.172 Node #6 - 172.31.51.66 - READY - Version: 570.172 Node #7 - 172.31.51.157 - READY - Version: 570.172 Node #8 - 172.31.52.239 - READY - Version: 570.172 Node #9 - 172.31.53.80 - READY - Version: 570.172 Node #10 - 172.31.54.95 - READY - Version: 570.172 Node #11 - 172.31.54.183 - READY - Version: 570.172 Node #12 - 172.31.54.203 - READY - Version: 570.172 Node #13 - 172.31.54.241 - READY - Version: 570.172 Node #14 - 172.31.55.59 - READY - Version: 570.172 Node #15 - 172.31.55.187 - READY - Version: 570.172 Node #16 - 172.31.55.197 - READY - Version: 570.172 Node #17 - 172.31.56.47 - READY - Version: 570.172 Nodes From\To 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 0 C C C C C C C C C C C C C C C C C C 1 C C C C C C C C C C C C C C C C C C 2 C C C C C C C C C C C C C C C C C C 3 C C C C C C C C C C C C C C C C C C 4 C C C C C C C C C C C C C C C C C C 5 C C C C C C C C C C C C C C C C C C 6 C C C C C C C C C C C C C C C C C C 7 C C C C C C C C C C C C C C C C C C 8 C C C C C C C C C C C C C C C C C C 9 C C C C C C C C C C C C C C C C C C 10 C C C C C C C C C C C C C C C C C C 11 C C C C C C C C C C C C C C C C C C 12 C C C C C C C C C C C C C C C C C C 13 C C C C C C C C C C C C C C C C C C 14 C C C C C C C C C C C C C C C C C C 15 C C C C C C C C C C C C C C C C C C 16 C C C C C C C C C C C C C C C C C C 17 C C C C C C C C C C C C C C C C C C Domain State: UP ``` ## Resolución de problemas La asignación de la configuración de los nodos no coincide Si ves `!M!` en la tabla de conectividad o `Node configuration mapping mismatch` en los registros de IMEX, el `nodes_config.cfg` archivo no es uniforme en todos los nodos. IMEX bloquea permanentemente la comunicación con los nodos que no coinciden. Compruebe que el script del prólogo se haya ejecutado en todos los nodos y reinicie el trabajo. No se encontró el dispositivo del canal IMEX Si el script de prólogo no puede crear el dispositivo del canal IMEX, compruebe que el controlador NVIDIA esté instalado y que contenga. `/proc/devices` `nvidia-caps-imex-channels` El script Prolog no se está ejecutando Compruebe que los `PrologFlags` parámetros `Prolog` y están configurados en el clúster. Compruebe que el archivo de script existe en los nodos de procesamiento y que tiene permisos de ejecución (`chmod 0755`).