View a markdown version of this page

UltraServer Instanzen konfigurieren - AWS STCK
VoraussetzungenAutomatische Topologieauswahltopology/block Das Plugin verwendenBewährte Methoden für die Topologie UltraServerEinschränkungenErstellen Sie das IMEX-Prolog-SkriptStellen Sie das Prolog-Skript bereitValidieren Sie das IMEX-SetupFehlerbehebung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

UltraServer Instanzen konfigurieren

UltraServer NVIDIA-Instanzen verbinden mithilfe von NVLink mehrere GPUs über Instanzen hinweg. GPU-to-GPU Für die Kommunikation über NVLink muss der NVIDIA IMEX-Dienst mit den IP-Adressen aller Rechenknoten im Job konfiguriert werden. Auf dieser Seite erfahren Sie, wie Sie ein Slurm-Prolog-Skript erstellen, das IMEX automatisch für jeden Job konfiguriert, und wie Sie es in Ihrem PCS-Cluster bereitstellen. AWS

Voraussetzungen

  • Ein AWS PCS-Cluster mit Slurm 25.05 oder höher.

  • Eine Rechenknotengruppe, die UltraServer Instanzen mit einem Kapazitätsblock verwendet. Weitere Informationen finden Sie unter Konfigurieren Sie eine AWS PCS-Rechenknotengruppe für die Verwendung eines Kapazitätsblocks.

  • Ein AMI mit den installierten NVIDIA-Treiber-, CUDA- und IMEX-Paketen. Der IMEX-Dienst (nvidia-imex) muss auf dem AMI aktiviert sein.

  • Das Prolog-Skript muss auf allen Rechenknoten unter dem Pfad verfügbar sein, der in der Prolog Slurm-Einstellung des Clusters konfiguriert ist. Sie können ein gemeinsam verwendetes Dateisystem verwenden oder das Skript in Ihr benutzerdefiniertes AMI aufnehmen.

Automatische Topologieauswahl

Wenn Sie einen AWS PCS-Cluster mit UltraServer Rechenknotengruppen erstellen, überprüft das System den Kapazitätsblock, identifiziert den UltraServer Typ und konfiguriert Slurm mit dem entsprechenden Topologie-Plugin. Dieser Prozess läuft automatisch und erfordert keine Konfiguration.

AWS PCS verwaltet die Topologie über eine dynamisch generierte topology.yaml Datei. Während sich der Cluster durch Hinzufügen oder Entfernen von Rechenknotengruppen weiterentwickelt, gleicht AWS PCS die Topologiekonfiguration kontinuierlich ab, um den aktuellen Cluster-Status widerzuspiegeln.

Die Blocktopologie modelliert einheitliche Kommunikationsdomänen mit hoher Bandbreite, in denen alle GPUs an einer einzigen Hochgeschwindigkeits-NVLink-Domäne mit nahezu einheitlicher Latenz beteiligt sind. Das topology/block Plugin weist Knoten auf der Grundlage der definierten Netzwerktopologie zu und stellt so sicher, dass die Jobs innerhalb derselben Topologie platziert werden UltraServer und die GPU-to-GPU Kommunikation NVLink verwendet, anstatt auf das EFA-Netzwerk zurückzugreifen.

topology/block Das Plugin verwenden

Jobs, die an UltraServer Warteschlangen gesendet werden, werden vom Slurm-Scheduler automatisch innerhalb desselben Blocks (UltraServer) platziert. Alle Knoten in einem Block werden einem Job zugewiesen, bevor der nächste Block verwendet wird. Jobs müssen das --exclusive Flag verwenden, da IMEX pro Auftrag eine dedizierte IMEX-Domain benötigt und ein Neustart des IMEX-Dienstes alle anderen laufenden Jobs auf denselben Knoten stören würde. Weitere Informationen zum topology/block Plugin finden Sie im Topology-Handbuch und in der Referenz topology.yaml in der Slurm-Dokumentation.

Beim Senden von Aufträgen können Sie das --segment=N Argument with sbatch und die srun Befehle verwenden, um die Anzahl der Knoten anzugeben, die innerhalb desselben Blocks gruppiert werden sollen. Die Größe des Segments muss kleiner oder gleich der Größe des Planungsblocks sein. Die Verwendung garantiert --segment nicht, dass Segmente auf verschiedenen Blöcken platziert werden.

Im Folgenden finden Sie Beispielszenarien für die Zuweisung von Blöcken in einer Warteschlange mit 18 Knoten UltraServers (z. B. eine u-p6e-gb200x72 mit 18 p6e-gb200.36xlarge Instanzen):

# 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

Bewährte Methoden für die Topologie UltraServer

Für eine optimale Leistung mit einer UltraServer Architektur in AWS PCS:

  • Verwenden Sie Segmente für eine bessere Verfügbarkeit: Verwenden Sie die --segment Option mit einem Wert, der kleiner als die volle Blockgröße ist, damit Jobs auf Blöcken geplant werden können, die einige überlastete oder nicht verfügbare Knoten haben. Dabei wird die absolute NVLink-Lokalität gegen eine schnellere Auftragsplanung eingetauscht. Weitere Informationen finden Sie unter Mehr Kontrolle über die Knotenplanung mit dem Topology/Block Plugin.

  • Berücksichtigen Sie die Auftragsgröße und die Blockgröße: WennBlockSizes=18, werden Jobs mit bis zu 18 Instanzen immer auf einer einzigen Instanz ausgeführt UltraServer. Jobs, die mehr als 18 Knoten erfordern, erstrecken sich über mehrere UltraServers, wobei NVLink-Konnektivität innerhalb jedes Blocks und EFA-Netzwerke zwischen den Blöcken vorhanden sind.

  • Kompromisse bei Segmenten: Bei Verwendung der Option wird die Planung höherer Blockgrößen --segment deaktiviert. Ohne diese Option wird ein ganzer Block gefüllt--segment, bevor der nächste Block verwendet wird. Mit --segment können Segmente auf jedem Block mit ausreichend verfügbaren Knoten platziert werden.

Einschränkungen

  • AWS PCS erfordert, dass UltraServer Rechenknotengruppen in dedizierten Warteschlangen platziert werden, getrennt von Gruppen, die keine UltraServer Rechenknoten sind.

  • Jede Rechenknotengruppe kann nur einem UltraServer Kapazitätsblock zugeordnet werden.

  • Wenn eine Warteschlange mehrere UltraServer Rechenknotengruppen enthält, muss die Instanzanzahl jeder Rechenknotengruppe ein Verhältnis von Zweierpotenzen aufweisen (z. B. 9 und 18 oder 2 und 8).

  • Jobs in UltraServer Warteschlangen müssen das --exclusive Flag verwenden, um sicherzustellen, dass pro Auftrag eine dedizierte IMEX-Domain vorhanden ist.

  • Die vom Prolog-Skript erstellte IMEX-Domäne umfasst nur die Knoten, die dem Job zugewiesen sind. Da AWS PCS den Aufträgen dynamisch Knoten zuweist, kann die IMEX-Domäne nicht vorab erstellt werden und muss zum Zeitpunkt des Auftragsstarts konfiguriert werden. Jobs, die sich über mehrere Bereiche UltraServers erstrecken, verfügen nicht über NVLink-Konnektivität zwischen Knoten in verschiedenen Knoten, UltraServers da die IMEX-Domäne auf IP-Adressen basiert und keine Brücke über separate NVLink-Fabrics herstellen kann.

  • Die IMEX nodes_config.cfg kann nicht geändert werden, während der Dienst ausgeführt wird. Wenn die Konfiguration geändert wird, blockiert IMEX dauerhaft die Kommunikation zu Knoten, die nicht übereinstimmen. Die einzige Wiederherstellung besteht darin, IMEX auf allen Knoten zu stoppen und mit einer konsistenten Konfiguration neu zu starten.

Erstellen Sie das IMEX-Prolog-Skript

Das folgende 91_nvidia_imex_prolog.sh Skript konfiguriert NVIDIA IMEX auf Rechenknoten, wenn ein Slurm-Job gestartet wird. Der Skriptname verwendet ein 91 Präfix, das der Benennungskonvention von SchedMD für die Reihenfolge der Prolog-Ausführung entspricht.

Das Skript führt die folgenden Aktionen aus:

  1. Prüft, ob der Job exklusiv ist. Die IMEX-Konfiguration erfordert exklusive Jobs, um zu verhindern, dass andere laufende Jobs auf denselben Knoten unterbrochen werden.

  2. Prüft, ob der Instanztyp ein unterstützter UltraServer Typ ist (p6e-gb200oderp6e-gb300).

  3. Prüft, ob der IMEX-Dienst aktiviert ist.

  4. Erstellt das IMEX-Standardkanalgerät, falls es nicht existiert.

  5. Schreibt die privaten IP-Adressen aller Job-Nodes in/etc/nvidia-imex/nodes_config.cfg.

  6. Startet den IMEX-Dienst neu.

Wichtig

Für dieses Prolog-Skript müssen Jobs mit dem Flag eingereicht werden. --exclusive Wenn Sie IMEX neu starten, während andere Jobs auf denselben Knoten ausgeführt werden, werden diese Jobs unterbrochen.

Anmerkung

Dieses Prolog-Skript unterstützt p6e-gb200 und Instanztypen. p6e-gb300 Um es an andere Instanztypen anzupassen, aktualisieren Sie das ALLOWED_INSTANCE_TYPES Muster im Skript.

Speichern Sie das folgende Skript unter91_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"

Stellen Sie das Prolog-Skript bereit

Um das Prolog-Skript bereitzustellen, konfigurieren Sie den Slurm Prolog und die PrologFlags benutzerdefinierten Einstellungen in Ihrem Cluster. Sie können diese festlegen, wenn Sie einen Cluster erstellen oder einen vorhandenen Cluster aktualisieren.

Weitere Informationen zur Konfiguration benutzerdefinierter Slurm-Einstellungen finden Sie unterBenutzerdefinierte Slurm-Einstellungen für AWS PCS-Cluster. Das Verfahren zum Aktualisieren eines Clusters finden Sie unterAktualisiere ein AWS PCS-Cluster.

Legen Sie die folgenden benutzerdefinierten Slurm-Einstellungen auf dem Cluster fest:

  • Prolog— Stellen Sie den Pfad ein, in dem das Prolog-Skript beispielsweise auf Rechenknoten verfügbar ist. /shared/scripts/prolog.d/91_nvidia_imex_prolog.sh

  • PrologFlags- Auf setzen. Alloc,NoHold Das Alloc Flag führt das Prolog auf jedem Knoten aus, wenn dieser zum ersten Mal einem Job zugewiesen wird. Das NoHold Flag verhindert, dass der Job angehalten wird, wenn der Prolog fehlschlägt.

Beispiel Aktualisieren Sie den Cluster mit den Prolog-Einstellungen mithilfe der 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"}
    ]
  }'

Validieren Sie das IMEX-Setup

Das Prolog-Skript wird automatisch ausgeführt, wenn Sie einen Slurm-Job einreichen. Senden Sie einen Testjob, um zu überprüfen, ob IMEX auf allen Knoten korrekt konfiguriert ist.

Erstellen Sie ein Job-Skript mit dem Namencheck-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"

Reichen Sie den Job in Ihre UltraServer Warteschlange ein:

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

Überprüfen Sie die Ausgabedateien. Eine erfolgreiche IMEX-Konfiguration zeigt in der Konnektivitätstabelle alle Knoten im READY Status C (Verbunden) an undDomain 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

Fehlerbehebung

Die Zuordnung der Knotenkonfiguration stimmt nicht überein

Wenn Sie !M! in der Konnektivitätstabelle oder Node configuration mapping mismatch in den IMEX-Protokollen feststellen, ist die nodes_config.cfg Datei nicht auf allen Knoten konsistent. IMEX blockiert dauerhaft die Kommunikation mit Knoten, die nicht übereinstimmen. Stellen Sie sicher, dass das Prolog-Skript auf allen Knoten ausgeführt wurde, und starten Sie den Job neu.

Das IMEX-Kanalgerät wurde nicht gefunden

Wenn das Prolog-Skript das IMEX-Kanalgerät nicht erstellen kann, überprüfen Sie, ob der NVIDIA-Treiber installiert ist und Folgendes enthält. /proc/devices nvidia-caps-imex-channels

Das Prolog-Skript wird nicht ausgeführt

Stellen Sie sicher, dass die PrologFlags Einstellungen Prolog und auf dem Cluster konfiguriert sind. Stellen Sie sicher, dass die Skriptdatei auf den Rechenknoten vorhanden ist und über Ausführungsberechtigungen verfügt (chmod 0755).