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 durch Slurm-Orchestrierung werden die folgenden Funktionen zur Cluster-Resilienz bereitgestellt. **Topics** + [Beauftragter für Gesundheitsüberwachung](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md) + [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) + [Ersetzen Sie einen Knoten manuell mit Slurm oder starten Sie ihn neu](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md) # Beauftragter für Gesundheitsüberwachung 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. SageMaker HyperPod Der Health Monitoring Agent (HMA) überwacht kontinuierlich den Integritätsstatus jeder GPU-basierten oder Trainium-basierten Instanz. Wenn er Instance- oder GPU-Ausfälle erkennt, markiert der Agent die Instance als fehlerhaft. SageMaker HyperPod HMA führt dieselben Integritätsprüfungen für EKS- und Slurm-Orchestratoren durch. Weitere Informationen zu HMA finden Sie unter. [System zur Gesundheitsüberwachung](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md) # 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. # Ersetzen Sie einen Knoten manuell mit Slurm oder starten Sie ihn neu In diesem Abschnitt geht es darum, wann Sie einen Knoten manuell neu starten oder ersetzen sollten, und es gibt Anleitungen, wie Sie beides tun können. ## Wann muss ein Knoten manuell neu gestartet oder ersetzt werden 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 `sinfo` ausführen. Wenn ein Knoten feststeckt oder nicht reagiert und der automatische Wiederaufnahmeprozess ihn nicht wiederherstellt, können Sie die Wiederherstellung manuell einleiten. Die Wahl zwischen dem Neustart und dem Ersetzen eines Knotens hängt von der Art des Problems ab. Ziehen Sie einen Neustart in Betracht, wenn temporäre oder softwarebezogene Probleme auftreten, wie z. B. Systemabstürze, Speicherlecks, Probleme mit GPU-Treibern, Kernel-Updates oder abgestürzte Prozesse. Wenn Sie jedoch auf anhaltende oder hardwarebezogene Probleme wie Ausfälle GPUs, Speicher- oder Netzwerkfehler, wiederholte Fehler bei der Integritätsprüfung oder Knoten stoßen, die nach mehreren Neustartversuchen nicht mehr reagieren, ist der Austausch von Knoten die geeignetere Lösung. ## Möglichkeiten, Knoten manuell neu zu starten oder zu ersetzen SageMaker HyperPod bietet zwei Methoden für die manuelle Wiederherstellung von Knoten. Der bevorzugte Ansatz ist die Verwendung von SageMaker HyperPod Reboot and Replace APIs, das einen schnelleren und transparenteren Wiederherstellungsprozess ermöglicht, der für alle Orchestratoren funktioniert. Alternativ können Sie herkömmliche Slurm-Befehle wie verwenden`scontrol update`, obwohl diese ältere Methode direkten Zugriff auf den Controller-Knoten des Slurms erfordert. Beide Methoden aktivieren dieselben SageMaker HyperPod Wiederherstellungsprozesse. ## Starten Sie einen Knoten mithilfe der Reboot-API manuell neu Sie können den verwenden **BatchRebootClusterNodes**, um einen fehlerhaften Knoten in Ihrem SageMaker HyperPod Cluster manuell neu zu starten. Hier ist ein Beispiel für die Ausführung des Neustartvorgangs auf zwei Instanzen eines Clusters mithilfe von AWS Command Line Interface: ``` aws sagemaker batch-reboot-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## Manuelles Ersetzen eines Knotens mithilfe der Replace-API Sie können den verwenden **BatchReplaceClusterNodes**, um einen fehlerhaften Knoten in Ihrem SageMaker HyperPod Cluster manuell zu ersetzen. Hier ist ein Beispiel für die Ausführung des Ersetzungsvorgangs auf zwei Instanzen eines Clusters mithilfe von AWS Command Line Interface: ``` aws sagemaker batch-replace-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## Starten Sie einen Knoten manuell mit Slurm neu Sie können auch die Slurm-Befehle von scontrol verwenden, um die Wiederherstellung des Knotens auszulösen. Diese Befehle interagieren direkt mit der Slurm-Steuerebene und rufen dieselben zugrunde liegenden Wiederherstellungsmechanismen auf. SageMaker HyperPod Ersetzen Sie den Befehl im folgenden Befehl durch den Slurm-Knotennamen (Hostnamen) der fehlerhaften Instanz, die Sie neu starten möchten. ``` scontrol update node= state=fail reason="Action:Reboot" ``` Dadurch wird der Knoten mit dem angegebenen Grund als FAIL markiert. SageMaker HyperPod erkennt dies und startet die Instanz neu. Vermeiden Sie es, während des Vorgangs den Knotenstatus zu ändern oder den Slurm-Controller neu zu starten. ## Ersetzen Sie einen Knoten manuell mithilfe von Slurm Sie können den Befehl scontrol update wie folgt verwenden, um einen Knoten zu ersetzen. Ersetzen Sie den Befehl im folgenden Befehl `` durch den Slurm-Knotennamen (Hostnamen) der fehlerhaften Instanz, die Sie ersetzen möchten. ``` scontrol update node= state=fail reason="Action:Replace" ``` Nach der Ausführung dieses Befehls wechselt der Knoten in den `fail` Status, 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 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](https://console.aws.amazon.com/support/). ## Manuell die Änderung eines Knotens erzwingen 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= state=down reason="Action:Replace" ```