Conditions préalables Sélection automatique de la topologie Utilisation du topology/block plugin Meilleures pratiques en matière de UltraServer topologie Limitations Création du script de prologue IMEX Déployez le script de prolog Validez la configuration IMEX Résolution des problèmes

Configuration UltraServer des instances

UltraServer Les instances NVIDIA connectent plusieurs GPU entre les instances à l'aide de NVLink. GPU-to-GPU la communication via NVLink nécessite que le service NVIDIA IMEX soit configuré avec les adresses IP de tous les nœuds de calcul de la tâche. Cette page explique comment créer un script de prologue Slurm qui configure automatiquement IMEX pour chaque tâche, et comment le déployer dans votre cluster PCS. AWS

Conditions préalables

Un cluster AWS PCS avec Slurm 25.05 ou version ultérieure.
Un groupe de nœuds de calcul utilisant UltraServer des instances dotées d'un bloc de capacité. Pour plus d’informations, consultez Configuration d'un groupe de nœuds de calcul AWS PCS pour utiliser un bloc de capacité.
Une AMI avec le pilote NVIDIA, les packages CUDA et IMEX installés. Le service IMEX (nvidia-imex) doit être activé sur l'AMI.
Le script prolog doit être disponible sur tous les nœuds de calcul au chemin configuré dans le paramètre Prolog Slurm du cluster. Vous pouvez utiliser un système de fichiers partagé ou inclure le script dans votre AMI personnalisée.

Sélection automatique de la topologie

Lorsque vous créez un cluster AWS PCS avec des groupes de nœuds de UltraServer calcul, le système inspecte le bloc de capacité, identifie le UltraServer type et configure Slurm avec le plug-in de topologie approprié. Ce processus s'exécute automatiquement et ne nécessite aucune configuration.

AWS PCS gère la topologie via un topology.yaml fichier généré dynamiquement. Au fur et à mesure que le cluster évolue grâce à l'ajout ou à la suppression de groupes de nœuds de calcul, AWS PCS réconcilie en permanence la configuration topologique pour refléter l'état actuel du cluster.

La topologie par blocs modélise des domaines de communication uniformes à bande passante élevée où tous les GPU participent à un seul domaine NVLink haut débit avec une latence quasi uniforme. Le topology/block plug-in alloue les nœuds en fonction de la topologie de réseau définie, garantissant que les tâches sont placées dans la même zone UltraServer et que la GPU-to-GPU communication utilise NVLink au lieu de revenir au réseau EFA.

Utilisation du topology/block plugin

Les tâches soumises aux UltraServer files d'attente sont automatiquement placées dans le même bloc (UltraServer) par le planificateur Slurm. Tous les nœuds d'un bloc sont affectés à une tâche avant que le bloc suivant ne soit utilisé. Les tâches doivent utiliser cet --exclusive indicateur car IMEX nécessite un domaine IMEX dédié par tâche, et le redémarrage du service IMEX perturberait toutes les autres tâches en cours d'exécution sur les mêmes nœuds. Pour plus d'informations sur le topology/block plugin, consultez le guide de topologie et la référence https://slurm.schedmd.com/topology.yaml.html topology.yaml dans la documentation de Slurm.

Lorsque vous soumettez des tâches, vous pouvez utiliser l'--segment=Nargument with sbatch et srun les commandes pour spécifier le nombre de nœuds à regrouper au sein d'un même bloc. La taille du segment doit être inférieure ou égale à la taille du bloc de planification. L'utilisation --segment ne garantit pas que les segments seront placés sur des blocs différents.

Voici des exemples de scénarios pour allouer des blocs sur une file d'attente de 18 nœuds UltraServers (par exemple, une file u-p6e-gb200x72 qui compte 18 p6e-gb200.36xlarge instances) :


# 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

Meilleures pratiques en matière de UltraServer topologie

Pour des performances optimales avec une UltraServer architecture en AWS PCS :

Utilisez des segments pour une meilleure disponibilité : utilisez l'--segmentoption dont la valeur est inférieure à la taille totale du bloc pour permettre de planifier des tâches sur des blocs dont certains nœuds sont épuisés ou indisponibles. Cela permet d'échanger la localité absolue de NVLink pour des délais de planification des tâches plus rapides. Pour plus d'informations, voir Obtenir un meilleur contrôle sur la planification des nœuds avec le Topology/Block plug-in.
Tenez compte de la taille des tâches et de la taille des blocs : siBlockSizes=18, les tâches comportant jusqu'à 18 instances sont toujours exécutées sur une seule instance UltraServer. Les tâches nécessitant plus de 18 nœuds s'étendent sur plusieurs nœuds UltraServers, avec une connectivité NVLink au sein de chaque bloc et une mise en réseau EFA entre les blocs.
Compromis entre les segments : l'utilisation --segment désactive la planification de la taille des blocs d'ordre supérieur. Dans --segment le cas contraire, un bloc complet est rempli avant que le bloc suivant ne soit utilisé. Avec--segment, les segments peuvent être placés sur n'importe quel bloc avec suffisamment de nœuds disponibles.

Limitations

AWS Le PCS exige que les groupes de nœuds de UltraServer calcul soient placés dans des files d'attente dédiées, distinctes des groupes de nœuds non UltraServer informatiques.
Chaque groupe de nœuds de calcul ne peut être associé qu'à un seul bloc UltraServer de capacité.
Lorsqu'une file d'attente contient plusieurs groupes de nœuds de UltraServer calcul, le nombre d'instances de chaque groupe de nœuds de calcul doit avoir des rapports de puissance de 2 entre eux (par exemple, 9 et 18, ou 2 et 8).
Les tâches en UltraServer file d'attente doivent utiliser l'--exclusiveindicateur pour garantir un domaine IMEX dédié par tâche.
Le domaine IMEX créé par le script prolog inclut uniquement les nœuds affectés à la tâche. Étant donné que AWS PCS alloue dynamiquement des nœuds aux tâches, le domaine IMEX ne peut pas être pré-créé et doit être configuré au début de la tâche. Les tâches qui s'étendent sur plusieurs ne UltraServers disposeront pas de connectivité NVLink entre des nœuds de différents nœuds, UltraServers car le domaine IMEX est basé sur des adresses IP et ne peut pas relier des structures NVLink distinctes.
L'IMEX nodes_config.cfg ne peut pas être modifié pendant que le service est en cours d'exécution. Si la configuration est modifiée, IMEX bloque définitivement la communication avec les nœuds incompatibles. La seule solution consiste à arrêter IMEX sur tous les nœuds et à redémarrer avec une configuration cohérente.

Création du script de prologue IMEX

Le 91_nvidia_imex_prolog.sh script suivant configure NVIDIA IMEX sur les nœuds de calcul lorsqu'une tâche Slurm démarre. Le nom du script utilise un 91 préfixe conforme à la convention de dénomination de SchedMD pour l'ordre d'exécution des prologues.

Le script effectue les actions suivantes :

Vérifie si la tâche est exclusive. La configuration IMEX nécessite des tâches exclusives pour ne pas perturber les autres tâches en cours d'exécution sur les mêmes nœuds.
Vérifie si le type d'instance est un UltraServer type pris en charge (p6e-gb200oup6e-gb300).
Vérifie si le service IMEX est activé.
Crée le périphérique de canal par défaut IMEX s'il n'existe pas.
Ecrit les adresses IP privées de tous les nœuds de travail dans/etc/nvidia-imex/nodes_config.cfg.
Redémarre le service IMEX.

Important

Ce script de prologue nécessite que les tâches soient soumises avec le --exclusive drapeau. Le redémarrage d'IMEX alors que d'autres tâches s'exécutent sur les mêmes nœuds perturbera ces tâches.

Note

Ce script de prolog prend en charge p6e-gb200 et les types d'p6e-gb300instances. Pour l'adapter à d'autres types d'instances, mettez à jour le ALLOWED_INSTANCE_TYPES modèle dans le script.

Enregistrez le script suivant sous le nom 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"

Déployez le script de prolog

Pour déployer le script prolog, configurez le Slurm Prolog et les paramètres PrologFlags personnalisés de votre cluster. Vous pouvez les définir lorsque vous créez un cluster ou mettez à jour un cluster existant.

Pour plus d'informations sur la configuration des paramètres personnalisés de Slurm, consultez. Paramètres Slurm personnalisés pour AWS Clusters PCS Pour la procédure de mise à jour d'un cluster, consultezMettre à jour un AWS Cluster PCS.

Définissez les paramètres Slurm personnalisés suivants sur le cluster :

Prolog- Définissez le chemin où le script de prolog est disponible sur les nœuds de calcul, par exemple/shared/scripts/prolog.d/91_nvidia_imex_prolog.sh.
PrologFlags- Réglez surAlloc,NoHold. Le Alloc drapeau exécute le prologue sur chaque nœud lorsqu'il est attribué pour la première fois à une tâche. Le NoHold drapeau empêche la mise en attente de la tâche en cas d'échec du prologue.

Exemple Mettez à jour le cluster avec les paramètres de prolog à l'aide du AWS INTERFACE DE LIGNE DE COMMANDE (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"}
    ]
  }'

Validez la configuration IMEX

Le script prolog s'exécute automatiquement lorsque vous soumettez une tâche Slurm. Soumettez une tâche de test pour vérifier qu'IMEX est correctement configuré sur tous les nœuds.

Créez un script de tâche nommé 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"

Soumettez la tâche à votre UltraServer file d'attente :


sbatch -p queue-name -N node-count check-imex.sh

Vérifiez les fichiers de sortie. Une configuration IMEX réussie affiche tous les nœuds dont READY l'état est C (Connecté) dans le tableau de connectivité et 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

Résolution des problèmes

Incompatibilité de mappage de configuration des nœuds: Si vous le !M! constatez dans le tableau de connectivité ou Node configuration mapping mismatch dans les journaux IMEX, le nodes_config.cfg fichier n'est pas cohérent sur tous les nœuds. IMEX bloque définitivement la communication avec les nœuds incompatibles. Vérifiez que le script de prolog s'est exécuté sur tous les nœuds et redémarrez la tâche.
Appareil de canal IMEX introuvable: Si le script prolog ne parvient pas à créer le périphérique du canal IMEX, vérifiez que le pilote NVIDIA est installé et qu'/proc/devicesil contient. nvidia-caps-imex-channels
Le script Prolog ne s'exécute pas: Vérifiez que les PrologFlags paramètres Prolog et sont configurés sur le cluster. Vérifiez que le fichier de script existe sur les nœuds de calcul et qu'il dispose des autorisations d'exécution (chmod 0755).

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configuration d'un groupe de nœuds de calcul pour utiliser un bloc de capacité

FAQ sur les blocs de capacité avec AWS PCS