SageMaker HyperPod Cluster-Resilienz - Amazon SageMaker KI
Prüfung des Cluster-ZustandsAutomatische WiederaufnahmeSo ersetzen Sie einen fehlerhaften Knoten, der nicht automatisch wieder aufgenommen wird durch HyperPod

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.

SageMaker HyperPod Cluster-Resilienz

SageMaker HyperPod bietet die folgenden Funktionen zur Cluster-Resilienz.

Prüfung des Cluster-Zustands

In diesem Abschnitt werden die Integritätsprüfungen beschrieben, mit denen SageMaker HyperPod der Zustand der Cluster-Instance regelmäßig auf Probleme mit Geräten wie Beschleunigern (GPU- und Trainium-Kerne) und Netzwerken (EFA) überwacht wird.

Kategorie Name des Dienstprogramms Kompatibilität von Instance-Typen Beschreibung
Accelerator DCGM-Richtlinien GPU Jede Instanz im Cluster überwacht kontinuierlich alle GPU-bezogenen Richtlinien, einschließlich XID-Fehler mit NVIDIA DCGM.
Accelerator NVIDIA SMI GPU Das nvidia-smi Utility ist eine bekannte CLI zur Verwaltung und Überwachung. GPUs Die integrierte Integritätsprüfung analysiert die Ausgabe von, um den Zustand der Instanz nvidia-smi zu ermitteln.
Accelerator Neuronensysteme Trainium Bei Instances, die mit Trainium betrieben werden, wird der Zustand der Neuron-Geräte durch das Lesen von Zählern aus Neuron-Sysfs bestimmt, die direkt vom Neuron-Treiber weitergegeben werden.
Netzwerk EFA GPU und Trainium Um die Diagnose von Elastic Fabric Adaptor (EFA) -Geräten zu erleichtern, führt der EFA Health Checker eine Reihe von Konnektivitätstests mit allen verfügbaren EFA-Karten innerhalb der Instance durch.
Stress DCGM-Diagnose Stufe 2 GPU Die DCGM-Diagnostik Stufe 2 dient dazu, das System zu trainieren und unter Druck zu setzen, um einen gründlichen Einblick GPUs in die Gesundheit zu erhalten.
Stress CPU-Belastung GPU und Trainium Der CPU-Zustand wird mit dem Linux-Stress-Tool bestimmt, das mehrere Threads ausführt, um eine 100-prozentige CPU-Auslastung zu erreichen und I/O-Operationen durchzuführen.

Automatische Wiederaufnahme

In diesem Abschnitt wird beschrieben, wie Sie einen Trainingsjob mit der Funktion zur SageMaker HyperPod automatischen Wiederaufnahme ausführen, die eine Zero-Touch-Resilienz-Infrastruktur bereitstellt, um bei einem Hardwarefehler bei Clustern mit mehr als 16 Knoten automatisch einen Trainingsjob vom zuletzt gespeicherten Checkpoint wiederherzustellen.

Wenn mit der Funktion zur automatischen Wiederaufnahme ein Job aufgrund eines Hardwarefehlers oder vorübergehender Probleme zwischen den Schulungen fehlschlägt, startet die SageMaker HyperPod automatische Wiederaufnahme den Knotenaustausch-Workflow und startet den Job neu, nachdem die fehlerhaften Knoten ersetzt wurden.

Anmerkung

Wenn Generic Resources (GRES) an einen Slurm-Knoten angehängt werden, erlaubt Slurm in der Regel keine Änderungen an der Knotenzuweisung, wie z. B. das Ersetzen von Knoten, und ermöglicht somit nicht, einen fehlgeschlagenen Job wieder aufzunehmen. Sofern nicht ausdrücklich verboten, setzt die Funktion zur HyperPod automatischen Wiederaufnahme automatisch alle fehlerhaften Jobs, die mit den GRES-fähigen Knoten verknüpft sind, erneut in die Warteschlange. Bei diesem Vorgang wird der Job gestoppt, wieder in die Auftragswarteschlange gestellt und der Job dann von vorne neu gestartet.

Verwendung der SageMaker HyperPod Auto-Resume-Funktion mit Slurm

Wenn Sie die SageMaker HyperPod automatische Wiederaufnahme mit Slurm verwenden, sollten Sie den Job innerhalb einer exklusiven Zuordnung ausführen, die Sie entweder mit salloc oder erhalten haben. sbatch In jedem Fall müssen Sie das Entrypoint-Skript ändern, um sicherzustellen, dass alle Einrichtungsschritte bei der Wiederaufnahme des Jobs in einem einzigen srun Befehl ausgeführt werden. Mithilfe des Entrypoint-Skripts ist es wichtig, die Umgebung auf dem ersetzten Knoten so einzurichten, dass sie mit der Umgebung konsistent ist, in der der Auftragsschritt ausgeführt wurde, bevor er gestoppt wurde. Das folgende Verfahren zeigt, wie Sie ein Entrypoint-Skript vorbereiten, um die Umgebung konsistent zu halten und es als einen einzigen Befehl auszuführen. srun

Tipp

Wenn Sie das Batch-Skript verwendensbatch, können Sie es einfach halten, indem Sie ein separates Skript für die Einrichtung der Umgebung erstellen und einen einzigen Befehl verwenden. srun

  1. Erstellen Sie mithilfe des folgenden Codebeispiels ein Skript und speichern Sie es untertrain_auto_resume.sh. Dieses Skript stellt die Einstellungen der Trainingsumgebung bereit und geht davon aus, dass für den ersetzten Knoten zuvor keine manuelle Konfiguration vorgenommen wurde. Dadurch wird sichergestellt, dass die Umgebung knotenunabhängig ist, sodass beim Austausch eines Knotens dieselbe Umgebung auf dem Knoten bereitgestellt wird, bevor der Job wieder aufgenommen wird.

    Anmerkung

    Das folgende Codebeispiel zeigt, wie Sie die dem Job zugeordnete Slurm-Knotenliste ermitteln können. Verwenden Sie nicht die von Slurm bereitgestellte $SLURM_JOB_NODELIST Umgebungsvariable, da ihr Wert nach der SageMaker HyperPod automatischen Wiederaufnahme des Jobs veraltet sein könnte. Das folgende Codebeispiel zeigt, wie Sie eine neue NODE_LIST Variable definieren, die ersetzt werden sollSLURM_JOB_NODELIST, und dann die MASTER_ADDR Variablen MASTER_NODE und außerhalb der Variablen einrichten. NODE_LIST

    #!/bin/bash

# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.

# Place your training environment setup here. 
# Example: Install conda, docker, activate virtual env, etc.

# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
            awk -F= '/NodeList=/{print $2}' | \  # Extract NodeList field
            grep -v Exc)                         # Exclude nodes marked as excluded

# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
              head -n 1)                            # Select the first hostname as master node

# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
              awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
              awk '{print $1}')                   # Print the first part of NodeAddr


# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
                       --nproc_per_node=1 \
                       --node_rank=$SLURM_NODE \
                       --master-addr=$MASTER_ADDR \
                       --master_port=1234 \
                       <your_training_script.py>"

# Execute the torchrun command in the 'pytorch' Conda environment, 
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
    Tipp

    Sie können das vorherige Skript verwenden, um weitere Befehle für die Installation zusätzlicher Abhängigkeiten für Ihren Job hinzuzufügen. Wir empfehlen jedoch, dass Sie die Installationsskripten für Abhängigkeiten auf die Gruppe der Lebenszyklusskripts beschränken, die bei der Clustererstellung verwendet werden. Wenn Sie eine virtuelle Umgebung verwenden, die in einem gemeinsam genutzten Verzeichnis gehostet wird, können Sie dieses Skript auch verwenden, um die virtuelle Umgebung zu aktivieren.

  2. Starten Sie den Job mit aktivierter SageMaker HyperPod automatischer Wiederaufnahme, indem Sie das Kennzeichen --auto-resume=1 hinzufügen, das angibt, dass der srun Befehl bei einem Hardwarefehler automatisch wiederholt werden soll.

    Anmerkung

    Wenn Sie mit sbatch oder eine Ressourcenzuweisung eingerichtet habensalloc, können Sie innerhalb der Zuordnung mehrere srun Befehle ausführen. Im Falle eines Fehlers funktioniert die Funktion zur SageMaker HyperPod automatischen Wiederaufnahme nur im aktuellen Jobschritt des srun Befehls mit der Markierung--auto-resume=1. Mit anderen Worten, die Aktivierung der automatischen Wiederaufnahme in einem srun Befehl gilt nicht für andere srun Befehle, die innerhalb einer Ressourcenzuweisungssitzung gestartet werden.

    Im Folgenden finden Sie Beispiele für srun Befehle mit auto-resume aktivierter Option.

    Verwenden von sbatch

    Da der Großteil der Logik für die Einrichtung der Umgebung bereits vorhanden isttrain_auto_resume.sh, sollte das Batch-Skript einfach sein und dem folgenden Codebeispiel ähneln. Gehen Sie davon aus, dass das folgende Batch-Skript unter gespeichert istbatch.sh.

    #!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh

    Führen Sie das vorherige Batch-Skript mit dem folgenden Befehl aus.

    sbatch batch.sh

    Verwenden Sie salloc

    Erwerben Sie zunächst eine exklusive Zuteilung und führen Sie den srun Befehl mit dem --auto-resume Flag und dem Entrypoint-Skript aus.

    salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh

So ersetzen Sie einen fehlerhaften Knoten, der nicht automatisch wieder aufgenommen wird durch HyperPod

Die HyperPod Auto-Resume-Funktion überwacht, ob der Status Ihrer Slurm-Knoten auf fail oder wechselt. down Sie können den Status der Slurm-Knoten überprüfen, indem Sie den Befehl ausführen. sinfo

Wenn bei einem Knoten ein Problem auftritt, das aber nicht durch die HyperPod automatische Wiederaufnahmefunktion behoben wurde, empfehlen wir Ihnen, den folgenden Befehl auszuführen, um den Status des Knotens auf zu fail ändern.

scontrol update node=<ip-ipv4> state=fail reason="Action:Replace"

Ersetzen Sie im vorherigen Befehlsbeispiel <ip-ipv4> durch den Slurm-Knotennamen (Hostnamen) der fehlerhaften Instanz, die Sie ersetzen möchten.

Nach der Ausführung dieses Befehls sollte der Knoten in den fail Status wechseln, wartet, bis die aktuell ausgeführten Jobs abgeschlossen sind, wird durch eine fehlerfreie Instanz ersetzt und mit demselben Hostnamen wiederhergestellt. Dieser Vorgang benötigt Zeit, abhängig von den verfügbaren Instances in Ihrer Availability Zone und der Zeit, die für die Ausführung Ihrer Lifecycle-Skripts benötigt wird. Vermeiden Sie es, während der Aktualisierungs- und Austauschprozesse den Status des Nodes erneut manuell zu ändern oder den Slurm-Controller neu zu starten. Andernfalls kann der Austausch ausfallen. Wenn der Knoten nicht wiederhergestellt wird oder nach langer Zeit nicht in den idle Status wechselt, wenden Sie sich an den AWS Support.

Wenn der fehlerhafte Knoten ständig in diesem fail Zustand feststeckt, besteht der letzte Ausweg darin, die Änderung des Knotenstatus manuell zu erzwingendown. Dies erfordert Administratorrechte (Sudo-Berechtigungen).

Warnung

Gehen Sie vorsichtig vor, bevor Sie den folgenden Befehl ausführen, da er das Abbrechen aller Jobs erzwingt und Sie möglicherweise alle nicht gespeicherten Arbeiten verlieren.

scontrol update node=<ip-ipv4> state=down reason="Action:Replace"