View a markdown version of this page

Configurar UltraServer instancias - AWS PIEZAS
Requisitos previosSelección topológica automáticaUso del complemento topology/blockMejores prácticas de topología UltraServerLimitacionesCree el script de prólogo de IMEXImplemente el script de prólogoValide la configuración de IMEXResolución de problemas

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

  • 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 y la referencia topology.yaml en la documentación de Slurm.

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

  • Considera el tamaño del trabajo y el tamaño de los bloques: siBlockSizes=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. --segmentEn 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.

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.

  2. Comprueba si el tipo de instancia es compatible UltraServer (p6e-gb200op6e-gb300).

  3. Comprueba si el servicio IMEX está activado.

  4. Crea el dispositivo de canal predeterminado de IMEX si no existe.

  5. Escribe en él las direcciones IP privadas de todos los nodos de trabajo. /etc/nvidia-imex/nodes_config.cfg

  6. 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 como91_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 Para obtener información sobre el procedimiento para actualizar un clúster, consulte. Actualizar un AWS Clúster PCS

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.

ejemplo Actualice el clúster con la configuración del prólogo mediante el AWS CLI
aws pcs update-cluster \
  --cluster-identifier <cluster-id> \
  --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 llamadocheck-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 yDomain 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).