Ausfallsicherheit des SageMaker-HyperPod-Clusters - Amazon SageMaker AI
Cluster-ZustandsprüfungAutomatische WiederaufnahmeSo ersetzen Sie einen fehlerhaften Knoten, der nicht automatisch von HyperPod wieder aufgenommen wird

Ausfallsicherheit des SageMaker-HyperPod-Clusters

SageMaker HyperPod bietet die folgenden Ausfallsicherheits-Features.

Cluster-Zustandsprüfung

In diesem Abschnitt werden die Zustandsprüfungen beschrieben, mit denen SageMaker HyperPod regelmäßig den Zustand von Cluster-Instances auf Probleme mit Geräten wie Accelerators (GPU- und Trainium-Kerne) und Netzwerken (EFA) überwacht.

Kategorie Name des Dienstprogramms Kompatibilität von Instance-Typen Beschreibung
Accelerator DCGM-Richtlinien GPU Jede Instance im Cluster überwacht kontinuierlich alle GPU-bezogenen Richtlinien, einschließlich XID-Fehler mit NVIDIA DCGM.
Accelerator NVIDIA SMI GPU Das nvidia-smi-Dienstprogramm ist eine bekannte CLI zur Verwaltung und Überwachung von GPUs. Die integrierte Zustandsprüfung analysiert die Ausgabe von nvidia-smi, um den Zustand der Instance zu ermitteln.
Accelerator Neuron sysfs Trainium Bei Trainium-basierten Instances wird der Zustand der Neuron-Geräte durch Auslesen der Zähler aus Neuron sysfs ermittelt, die direkt vom Neuron-Treiber übertragen werden.
Netzwerk EFA GPU und Trainium Um die Diagnose von Elastic Fabric Adapter (EFA)-Geräten zu unterstützen, führt die EFA-Zustandsprüfung eine Reihe von Verbindungstests mit allen verfügbaren EFA-Karten innerhalb der Instance durch.
Stress DCGM-Diagnose Stufe 2 GPU Die DCGM-Diagnose Stufe 2 wird verwendet, um die GPUs im System zu testen und unter Druck zu setzen, um einen umfassenden Einblick in den Zustand zu erhalten.
Stress CPU stress GPU und Trainium Der Zustand der CPU wird mit dem Linux stress-Tool ermittelt, das mehrere Threads ausführt, um eine CPU-Auslastung von 100 % zu erreichen und E/A-Operationen durchzuführen.

Automatische Wiederaufnahme

In diesem Abschnitt wird beschrieben, wie Sie einen Trainingsjob mit der automatischen Wiederaufnahmefunktion von SageMaker HyperPod ausführen. Diese Funktion bietet eine Zero-Touch-Ausfallsicherheitsinfrastruktur, mit der ein Trainingsjob im Falle eines Hardwarefehlers automatisch vom zuletzt gespeicherten Checkpoint wiederhergestellt wird.

Mit der automatischen Wiederaufnahmefunktion startet SageMaker HyperPod bei einem Jobausfall aufgrund eines Hardwarefehlers oder vorübergehender Probleme während des Trainings automatisch den Workflow zum Austausch des Knotens und startet den Job nach dem Austausch der fehlerhaften Knoten neu.

Anmerkung

Wenn Generic Resources (GRES) an einen Slurm-Knoten angefügt sind, lässt Slurm in der Regel keine Änderungen an der Knotenzuweisung zu, wie z. B. das Ersetzen von Knoten, und erlaubt daher auch nicht die Wiederaufnahme eines fehlgeschlagenen Jobs. Sofern nicht ausdrücklich untersagt, stellt die HyperPod-Funktion zur automatischen Wiederaufnahme fehlerhafte Jobs, die mit GRES-fähigen Knoten verbunden sind, automatisch wieder in die Warteschlange. Dieser Vorgang umfasst das Anhalten des Jobs, das Zurücksetzen in die Job-Warteschlange und das anschließende Neustarten des Jobs von Anfang an.

Verwenden der automatischen Wiederaufnahmefunktion von SageMaker HyperPod mit Slurm

Wenn Sie die automatische Wiederaufnahme von SageMaker HyperPod mit Slurm verwenden, sollten Sie den Job innerhalb einer exklusiven Zuweisung ausführen, die entweder mit salloc oder sbatch erworben wurde. In jedem Fall müssen Sie das Einstiegspunktskript ändern, um sicherzustellen, dass alle Einrichtungsschritte bei der Wiederaufnahme des Jobs in einem einzigen srun-Befehl ausgeführt werden. Über das Eintrittspunktskript ist es wichtig, die Umgebung auf dem ersetzten Knoten so einzurichten, dass sie mit der Umgebung übereinstimmt, in der der Jobschritt vor seiner Unterbrechung ausgeführt wurde. Das folgende Verfahren zeigt, wie Sie ein Eintrittspunktskript vorbereiten, um die Umgebung konsistent zu halten und es als einen einzigen srun-Befehl auszuführen.

Tipp

Wenn Sie sbatch verwenden, können Sie das Batch-Skript einfach halten, indem Sie ein separates Skript zum Einrichten der Umgebung erstellen und einen einzigen srun-Befehl verwenden.

  1. Erstellen Sie mithilfe des folgenden Codebeispiels ein Skript und speichern Sie es unter train_auto_resume.sh. Dieses Skript stellt Trainingsumgebungen bereit, wobei davon ausgegangen wird, dass zuvor keine manuelle Konfiguration für den ersetzten Knoten 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

    Im folgenden Codebeispiel sehen Sie, wie Sie die Slurm-Knotenliste ermitteln, die dem Job zugeordnet ist. Verwenden Sie nicht die von Slurm bereitgestellte $SLURM_JOB_NODELIST-Umgebungsvariable, da ihr Wert möglicherweise veraltet ist, nachdem SageMaker HyperPod den Job automatisch wieder aufgenommen hat. Das folgende Codebeispiel zeigt, wie Sie eine neue NODE_LIST-Variable definieren, um SLURM_JOB_NODELIST zu ersetzen, und dann die Variablen MASTER_NODE und MASTER_ADDR außerhalb der NODE_LIST-Variablen einrichten.

    #!/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, die Skripte zur Installation von Abhängigkeiten in dem Satz von Lebenszyklusskripten zu belassen, 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 zum Aktivieren der virtuellen Umgebung verwenden.

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

    Anmerkung

    Wenn Sie mit sbatch oder salloc eine Ressourcenzuweisung eingerichtet haben, können Sie innerhalb der Zuordnung mehrere srun-Befehle ausführen. Im Falle eines Fehlers funktioniert die automatische Wiederaufnahmefunktion von SageMaker HyperPod nur im aktuellen Jobschritt des srun-Befehls mit dem Flag --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 einige Beispiele für srun-Befehle mit auto-resume aktiviert.

    Verwenden von sbatch

    Da der Großteil der Logik zum Einrichten der Umgebung bereits in train_auto_resume.sh vorhanden ist, sollte das Batch-Skript einfach sein und dem folgenden Codebeispiel ähneln. Gehen Sie davon aus, dass das folgende Batch-Skript unter batch.sh gespeichert ist.

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

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

    sbatch batch.sh

    Verwenden von salloc

    Beginnen Sie mit dem Erwerb einer exklusiven Zuweisung und führen Sie den srun-Befehl mit dem Flag --auto-resume und dem Einstiegspunktskript aus.

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

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

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

Wenn Sie einen Knoten haben, der mit einem Problem feststeckt, das jedoch nicht durch die automatische Wiederaufnahmefunktion von HyperPod behoben wird, empfehlen wir Ihnen, den folgenden Befehl auszuführen, um den Status des Knotens auf fail zu ändern.

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

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

Nach Ausführung dieses Befehls sollte der Knoten in den Status fail wechseln, auf die Fertigstellung der aktuell ausgeführten Jobs warten, durch eine fehlerfreie Instance ersetzt und mit demselben Hostnamen wiederhergestellt werden. 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 Lebenszyklusskripts benötigt wird. Vermeiden Sie es während des Aktualisierungs- und Austauschvorgangs, den Status des Knotens erneut manuell zu ändern oder den Slurm-Controller neu zu starten, da dies dazu führen kann, dass der Austausch fehlschlägt. Wenn der Knoten nicht wiederhergestellt wird oder nach langer Zeit nicht in den Status idle wechselt, wenden Sie sich an den AWS-Support.

Wenn der fehlerhafte Knoten kontinuierlich in diesem Zustand verharrt, besteht als letzte Möglichkeit darin, den Knotenstatus manuell auf fail zu ändern. Dies erfordert Administratorrechte (Sudo-Berechtigungen).

Warnung

Gehen Sie vorsichtig vor, bevor Sie den folgenden Befehl ausführen, da dadurch alle Aufträge beendet werden und Sie möglicherweise alle nicht gespeicherten Arbeiten verlieren.

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