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. # Automatische Knotenwiederherstellung und automatische Wiederaufnahme **Anmerkung** Seit dem 11. September 2025 unterstützt die Orchestrierung HyperPod mit Slurm nun Agenten zur Gesundheitsüberwachung. Führen Sie das AMI aus [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)und aktualisieren Sie es auf die neueste Version, um diese Funktionalität nutzen zu können. In diesem Abschnitt werden die beiden sich ergänzenden Resilienzfunktionen SageMaker HyperPod von Amazon behandelt: die automatische Wiederherstellung von Knoten, die fehlerhafte Infrastruktur ohne manuelles Eingreifen ersetzt, und die Funktion zur automatischen Wiederaufnahme, mit der Trainingsjobs nach Hardwareausfällen vom letzten Checkpoint aus neu gestartet werden. ## So funktioniert die automatische Wiederherstellung von Knoten Während der Clustererstellung oder -aktualisierung können Clusteradministratoren die Wiederherstellungsoption für Knoten (Instance) zwischen `Automatic` (empfohlen) und `None` auf Clusterebene wählen. Wenn diese Option auf gesetzt `Automatic` ist, SageMaker HyperPod werden fehlerhafte Knoten automatisch neu gestartet oder ersetzt. **Wichtig** Wir empfehlen, die Option `Automatic` einzustellen. Standardmäßig sind die Cluster mit automatischer Knotenwiederherstellung eingerichtet. Die automatische Knotenwiederherstellung wird ausgeführt, wenn Probleme beim Health Monitoring Agent, bei grundlegenden Zustandsprüfungen und bei umfassenden Integritätsprüfungen festgestellt werden. Wenn diese Option auf gesetzt ist`None`, kennzeichnet der Health Monitoring Agent die Instances, wenn ein Fehler erkannt wird, leitet aber nicht automatisch Reparatur- oder Wiederherstellungsaktionen an den betroffenen Knoten ein. Wir empfehlen diese Option nicht. ## Einen Trainingsjob mit der SageMaker HyperPod Amazon-Funktion zur automatischen Wiederaufnahme ausführen 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 bietet, mit der ein Trainingsjob bei einem Hardwarefehler automatisch vom zuletzt gespeicherten Checkpoint wiederhergestellt werden kann. 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. Die folgenden Hardwareprüfungen werden immer dann ausgeführt, wenn ein Job bei Verwendung der automatischen Wiederaufnahme fehlschlägt: | Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description | | --- | --- | --- | --- | | Accelerator | NVIDIA SMI | GPU | Das [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) Utility ist eine bekannte CLI zur Verwaltung und Überwachung. 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](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) 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. | **Anmerkung** Wenn [Generic Resources (GRES)](https://slurm.schedmd.com/gres.html) 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 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. Dieser Vorgang umfasst das Anhalten des Jobs, das Zurücksetzen in die Job-Warteschlange und das anschließende Neustarten des Jobs von Anfang an. **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 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 Entrypoint-Skript vorbereiten, um die Umgebung konsistent zu halten und es als einen einzigen Befehl auszuführen. `srun` **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 nach der SageMaker HyperPod automatischen Wiederaufnahme des Jobs veraltet sein könnte. 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 \ " # 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](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 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. 1. 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 `salloc` eine Ressourcenzuweisung eingerichtet haben, 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](https://slurm.schedmd.com/job_launch.html#step_allocation) 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 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 arbeiten automatische Node Recovery und Auto-Resume zusammen Wenn sowohl automatische Node-Recovery- als auch Auto-Resume-Systeme aktiv sind, verfolgen sie einen koordinierten Ansatz zur Behandlung von Ausfällen. Wenn das HMA einen Hardwarefehler feststellt, wird der Knoten unabhängig vom Status auf Jobebene als leer markiert. Wenn die automatische Wiederherstellung des Knotens aktiviert ist, werden die Knoten automatisch ersetzt, sobald alle auf den Knoten ausgeführten Jobs beendet sind. In diesem Szenario wird bei Jobs mit aktivierter automatischer Wiederaufnahme ein Exit-Status ungleich Null in dem Schritt aktiviert (die Jobs werden fortgesetzt, sobald die Knoten ersetzt wurden). Jobs, bei denen die automatische Wiederaufnahme nicht aktiviert ist, werden einfach beendet und erfordern eine manuelle erneute Einreichung durch Administratoren oder Benutzer. **Anmerkung** Wenn Sie die automatische Wiederaufnahme verwenden, werden die Knoten immer ersetzt (keine Neustarts), wenn Hardwarefehler erkannt werden.