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.
# Cluster-Resilienzfunktionen für SageMaker HyperPod Cluster-Orchestrierung mit Amazon EKS
SageMaker HyperPod bietet die folgenden Funktionen zur Cluster-Resilienz.
**Topics**
+ [System zur Gesundheitsüberwachung](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
+ [Grundlegende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-basic-health-check.md)
+ [Tiefgreifende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md)
+ [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md)
+ [Kubernetes-Labels im Zusammenhang mit Resilienz von SageMaker HyperPod](sagemaker-hyperpod-eks-resiliency-node-labels.md)
+ [Einen Knoten manuell unter Quarantäne stellen, ersetzen oder neu starten](sagemaker-hyperpod-eks-resiliency-manual.md)
+ [Empfohlene Ausfallsicherheitskonfigurationen](sagemaker-hyperpod-eks-resiliency-config-tips.md)
# System zur Gesundheitsüberwachung
SageMaker HyperPod Das System zur Gesundheitsüberwachung besteht aus zwei Komponenten
1. In Ihren Knoten installierte Monitoring-Agenten, zu denen der Health Monitoring Agent (HMA), der als Systemmonitor auf dem Host dient, und eine Reihe von out-of-node Gesundheitsmonitoren gehören.
1. Node Recovery System, verwaltet von. SageMaker HyperPod Das System zur Zustandsüberwachung überwacht den Zustand des Knotens kontinuierlich über Überwachungsagenten und ergreift dann automatisch Maßnahmen, wenn mithilfe des Node Recovery Systems ein Fehler erkannt wird.
![\[Dieses Bild zeigt, wie das System zur Gesundheitsüberwachung in den HyperPod Cluster integriert ist.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-event.png)
## Gesundheitschecks, die vom SageMaker HyperPod Gesundheitsüberwacher durchgeführt werden
Der Beauftragte für die SageMaker HyperPod Gesundheitsüberwachung überprüft Folgendes.
**NVIDIA GPUs**
+ [Benachrichtigungen bei Verstößen gegen die DCGM-Richtlinien](https://docs.nvidia.com/datacenter/dcgm/3.0/user-guide/feature-overview.html#notifications)
+ Fehler in der Ausgabe `nvidia-smi`
+ Verschiedene Fehler in den Protokollen, die von der Amazon Elastic Compute Cloud (EC2) -Plattform generiert wurden
+ Validierung der GPU-Anzahl — Wenn die erwartete Anzahl von GPUs in einem bestimmten Instance-Typ (zum Beispiel: 8 GPUs im Instance-Typ ml.p5.48xlarge) und der von zurückgegebenen Anzahl nicht übereinstimmt, startet HMA den Knoten neu `nvidia-smi`
**AWS Trainium**
+ Fehler in der Ausgabe des [AWS Neuron-Monitors](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html)
+ Vom Neuron-Knoten-Problemdetektor generierte Ausgaben (Weitere Informationen zum AWS Neuron-Knoten-Problemdetektor finden Sie unter [Erkennung und Wiederherstellung von Knotenproblemen für AWS Neuron-Knoten in Amazon EKS-Clustern](https://aws.amazon.com/blogs/machine-learning/node-problem-detection-and-recovery-for-aws-neuron-nodes-within-amazon-eks-clusters/).)
+ Verschiedene Fehler in den von der Amazon EC2-Plattform generierten Protokollen
+ Überprüfung der Anzahl neuronaler Geräte — Wenn die tatsächliche Anzahl der neuronalen Geräte in einem bestimmten Instance-Typ nicht mit der von `neuron-ls` zurückgegebenen Anzahl übereinstimmt, startet HMA den Knoten neu
Die oben genannten Prüfungen sind passiv. Die Zustandsprüfungen im Hintergrund werden kontinuierlich auf Ihren Knoten HyperPod ausgeführt. Zusätzlich zu diesen Prüfungen werden während der Erstellung und Aktualisierung von HyperPod Clustern gründliche (oder aktive) Zustandsprüfungen durchgeführt. HyperPod Erfahren Sie mehr über [Deep Health Checks](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-resiliency-deep-health-checks.html).
## Erkennung von Fehlern
Wenn ein Fehler SageMaker HyperPod erkannt wird, wird eine vierteilige Reaktion implementiert:
1. **Knotenbeschriftungen**
1. Gesundheitsstatus: `sagemaker.amazonaws.com/node-health-status`
1. Fehlertyp: `sagemaker.amazonaws.com/fault-types` Bezeichnung für eine allgemeine Kategorisierung
1. Fehlergrund: `sagemaker.amazonaws.com/fault-reasons` Etikett für detaillierte Fehlerinformationen
1. **Node Taint**
1. `sagemaker.amazonaws.com/node-health-status=Unschedulable:NoSchedule`
1. **Anmerkung zum Knoten**
1. Einzelheiten zum Fehler: `sagemaker.amazonaws.com/fault-details`
1. Zeichnet bis zu 20 Fehler mit Zeitstempeln auf, die auf dem Knoten aufgetreten sind
1. **Knotenbedingungen** ([Kubernetes-Knotenzustand](https://kubernetes.io/docs/reference/node/node-status/#condition))
1. Spiegelt den aktuellen Gesundheitszustand in den Knotenbedingungen wider:
+ Typ: Entspricht dem Fehlertyp
+ Status: `True`
+ Grund: Entspricht dem Fehlergrund
+ LastTransitionTime: Zeit des Auftretens des Fehlers
![\[Dieses Bild zeigt, wie das System zur Gesundheitsüberwachung funktioniert, wenn ein Fehler erkannt wird.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-workflow.png)
## Vom SageMaker HyperPod Health Monitoring-Agenten generierte Protokolle
Der SageMaker HyperPod Health Monitoring Agent ist eine out-of-the-box Funktion zur Integritätsprüfung und wird kontinuierlich auf allen Clustern ausgeführt. HyperPod Der Health Monitoring Agent veröffentlicht erkannte Integritätsereignisse auf GPU- oder Trn-Instances in der CloudWatch Cluster-Protokollgruppe. `/aws/sagemaker/Clusters/`
Die Erkennungsprotokolle des HyperPod Health Monitoring Agents werden als separate Protokollstreams erstellt, die `SagemakerHealthMonitoringAgent` nach jedem Knoten benannt sind. Sie können die Erkennungsprotokolle mithilfe von CloudWatch Log Insights wie folgt abfragen.
```
fields @timestamp, @message
| filter @message like /HealthMonitoringAgentDetectionEvent/
```
Dies sollte eine Ausgabe ähnlich der folgenden erzeugen.
```
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
```
# Grundlegende Zustandsprüfungen
SageMaker HyperPod führt während der Erstellung und Aktualisierung von Clustern eine Reihe *grundlegender Integritätsprüfungen* für HyperPod Cluster-Instances durch. Diese grundlegenden Zustandsprüfungen sind orchestratorunabhängig, sodass diese Prüfungen unabhängig von den zugrunde liegenden Orchestrierungsplattformen, die von SageMaker HyperPod (Amazon EKS oder Slurm) unterstützt werden, anwendbar sind.
Bei den grundlegenden Zustandsprüfungen werden Cluster-Instances auf Probleme im Zusammenhang mit Geräten wie Beschleunigern (GPU- und Trainium-Kernen) und Netzwerkgeräten (Elastic Fabric Adapter oder EFA) überwacht. [Eine Liste der grundlegenden Cluster-Zustandsprüfungen finden Sie unter Cluster-Zustandsprüfungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html#sagemaker-hyperpod-resiliency-slurm-cluster-health-check)
# Tiefgreifende Zustandsprüfungen
SageMaker HyperPod führt während der Erstellung und Aktualisierung von Clustern *eingehende Integritätsprüfungen* für HyperPod Clusterinstanzen durch. Die umfassenden Integritätsprüfungen stellen die Zuverlässigkeit und Stabilität der SageMaker HyperPod Cluster sicher, indem die zugrunde liegenden Hardware- und Infrastrukturkomponenten gründlich getestet werden, bevor die Cluster für das Training von Modellen für maschinelles Lernen verwendet werden können. Dieser proaktive Ansatz hilft dabei, potenzielle Probleme zu einem frühen Zeitpunkt im Cluster-Lebenszyklus zu erkennen und zu beheben.
## Liste der tiefgreifenden Integritätsprüfungen, die durchgeführt wurden von SageMaker HyperPod
SageMaker HyperPod führt die folgenden umfassenden Integritätsprüfungen durch.
**Umfassende Zustandsprüfungen auf Instance-Ebene**
| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description |
| --- | --- | --- | --- |
| Accelerator | GPU/Anzahl NVLink | GPU | Überprüft die Anzahl GPU/NVLink . |
| Accelerator | [DCGM-Diagnose Stufe](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) 4 | GPU | Beurteilt den Zustand und die Funktionalität von NVIDIA, GPUs indem DCGM-Diagnosen (NVIDIA Data Center GPU Manager) auf Stufe 4 ausgeführt werden, einschließlich zusätzlicher Speichertests. |
| 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. |
| Accelerator | Neuron-Hardwareprüfung | Trainium | Führt einen Trainings-Workload durch und verifiziert die Ergebnisse, um die Hardware zu testen. |
| Accelerator | Lokaler NCCOM-Test | Trainium | Evaluiert die Leistung kollektiver Kommunikationsoperationen auf einzelnen Trainium-Knoten |
| Netzwerk | EFA | GPU und Trainium | Führt einen Latenz- und Bandbreiten-Benchmarking auf dem angeschlossenen EFA-Gerät durch. |
**Tiefgreifende Integritätsprüfungen auf Clusterebene**
| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description |
| --- | --- | --- | --- |
| Accelerator | NCCL-Prüfung | GPU | Überprüft die Leistung kollektiver Kommunikationsvorgänge auf mehreren NVIDIA-Geräten GPUs |
| Accelerator | NCCOM-Clustertest | Trainium | Überprüft die Leistung kollektiver Kommunikationsoperationen auf mehreren Trainium-Knoten |
## Protokolle der umfassenden Gesundheitschecks
Im Folgenden finden Sie Beispielprotokolle aus den SageMaker HyperPod Deep Health Checks.
**Protokolle auf Clusterebene**
Die Protokolle für tiefe Integritätsprüfungen auf Clusterebene werden in Ihrer CloudWatch Protokollgruppe unter gespeichert `/aws/sagemaker/Clusters//`
Die Protokollstream werden unter `DeepHealthCheckResults/` protokolliert.
Als Beispiel unten zeigen die Ausgabeprotokolle für Deep Health Checks die Instance-ID, die die Prüfungen nicht bestanden hat, mit der Ursache des Fehlers.
```
{
"level": "error",
"ts": "2024-06-18T21:15:22Z",
"msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: p4d.24xlarge. ERROR:Bandwidth has less than threshold: Expected minimum threshold :80,NCCL Test output Bw: 30"
}
```
**Protokolle auf Instance-Ebene**
Die Protokolle der umfassenden Zustandsprüfung auf Instance-Ebene werden unter `/var/log/aws/clusters/sagemaker-deep-health-check.log` auf jedem Knoten gespeichert. Stellen Sie eine Verbindung mit SSH auf den Knoten her und öffnen Sie die Protokolldatei, indem Sie den folgenden Befehl ausführen.
```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```
Im Folgenden finden Sie ein Beispiel für die Ausgabe des Hardwarestress, des [NVIDIA DCGM-Stresses](https://developer.nvidia.com/dcgm) und des EFA-Konnektivitätstests.
```
# Hardware Stress Test output
2024-08-20T21:53:58Z info Executing Hardware stress check with command: stress-ng, and args: [--cpu 32 --vm 2 --hdd 1 --fork 8 --switch 4 --timeout 60 --metrics]
2024-08-20T21:54:58Z info stress-ng success
2024-08-20T21:54:58Z info GpuPci Count check success
# DCGM Stress Test
2024-08-20T22:25:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 0 dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01, gpuDeviceIds: [2237] replacementRequired: false rebootRequired:false
# EFA Loopback Test
2024-08-20T22:26:28Z info EFA Loopback check passed for device: rdmap0s29 . Output summary is MaxBw: 58.590000, AvgBw: 32.420000, MaxTypicalLat: 30.870000, MinTypicalLat: 20.080000, AvgLat: 21.630000
```
Im Folgenden finden Sie eine Beispielausgabe des NCCL-Konnektivitätstests.
```
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
8 2 float sum -1 353.9 0.00 0.00 0 304.2 0.00 0.00 0
16 4 float sum -1 352.8 0.00 0.00 0 422.9 0.00 0.00 0
32 8 float sum -1 520.0 0.00 0.00 0 480.3 0.00 0.00 0
64 16 float sum -1 563.0 0.00 0.00 0 416.1 0.00 0.00 0
128 32 float sum -1 245.1 0.00 0.00 0 308.4 0.00 0.00 0
256 64 float sum -1 310.8 0.00 0.00 0 304.9 0.00 0.00 0
512 128 float sum -1 304.9 0.00 0.00 0 300.8 0.00 0.00 0
1024 256 float sum -1 509.3 0.00 0.00 0 495.4 0.00 0.00 0
2048 512 float sum -1 530.3 0.00 0.00 0 420.0 0.00 0.00 0
4096 1024 float sum -1 391.2 0.01 0.01 0 384.5 0.01 0.01 0
8192 2048 float sum -1 328.5 0.02 0.02 0 253.2 0.03 0.03 0
16384 4096 float sum -1 497.6 0.03 0.03 0 490.9 0.03 0.03 0
32768 8192 float sum -1 496.7 0.07 0.07 0 425.0 0.08 0.08 0
65536 16384 float sum -1 448.0 0.15 0.15 0 501.0 0.13 0.13 0
131072 32768 float sum -1 577.4 0.23 0.23 0 593.4 0.22 0.22 0
262144 65536 float sum -1 757.8 0.35 0.35 0 721.6 0.36 0.36 0
524288 131072 float sum -1 1057.1 0.50 0.50 0 1019.1 0.51 0.51 0
1048576 262144 float sum -1 1460.5 0.72 0.72 0 1435.6 0.73 0.73 0
2097152 524288 float sum -1 2450.6 0.86 0.86 0 2583.1 0.81 0.81 0
4194304 1048576 float sum -1 4344.5 0.97 0.97 0 4419.3 0.95 0.95 0
8388608 2097152 float sum -1 8176.5 1.03 1.03 0 8197.8 1.02 1.02 0
16777216 4194304 float sum -1 15312 1.10 1.10 0 15426 1.09 1.09 0
33554432 8388608 float sum -1 30149 1.11 1.11 0 29941 1.12 1.12 0
67108864 16777216 float sum -1 57819 1.16 1.16 0 58635 1.14 1.14 0
134217728 33554432 float sum -1 115699 1.16 1.16 0 115331 1.16 1.16 0
268435456 67108864 float sum -1 227507 1.18 1.18 0 228047 1.18 1.18 0
536870912 134217728 float sum -1 453751 1.18 1.18 0 456595 1.18 1.18 0
1073741824 268435456 float sum -1 911719 1.18 1.18 0 911808 1.18 1.18 0
2147483648 536870912 float sum -1 1804971 1.19 1.19 0 1806895 1.19 1.19 0
2024-08-20T16:22:43.831-07:00
# Out of bounds values : 0 OK
2024-08-20T16:22:43.831-07:00
# Avg bus bandwidth : 0.488398
2024-08-20T23:22:43Z info Nccl test successful. Summary: NcclMaxAlgoBw: 1.190000, NcclAvgAlgoBw: 0.488398, NcclThresholdAlgoBw: 1.180000, NcclOutOfBoundError: OK, NcclOperations: all_reduce_perf, NcclTotalDevices: 2, NcclNodes: 2, NcclClusterMessage:
```
# 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 ist`Automatic`, SageMaker HyperPod werden fehlerhafte Knoten automatisch neu gestartet oder ersetzt.
**Wichtig**
Wir empfehlen, die Option `Automatic` einzustellen.
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. Diese Option wird nicht empfohlen.
# Kubernetes-Labels im Zusammenhang mit Resilienz von SageMaker HyperPod
*Labels* sind Schlüssel-Wert-Paare, die an [Kubernetes-Objekte](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects) angehängt werden. SageMaker HyperPod führt die folgenden Bezeichnungen für die bereitgestellten Zustandsprüfungen ein.
## Zustandsetiketten
Die `node-health-status` Beschriftungen stellen den Status des Knotenzustands dar und können als Teil des Knotenauswahlfilters in fehlerfreien Knoten verwendet werden.
| Label (Bezeichnung) | Description |
| --- | --- |
| sagemaker.amazonaws.com/node-health-status: Schedulable | Der Knoten hat die grundlegenden Integritätsprüfungen bestanden und ist für die Ausführung von Workloads verfügbar. Diese Integritätsprüfung entspricht den [derzeit verfügbaren SageMaker HyperPod Resilienzfunktionen für Slurm-Cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html). |
| sagemaker.amazonaws.com/node-health-status: Unschedulable | Der Knoten führt tiefgreifende Integritätsprüfungen durch und ist nicht für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement | Der Knoten hat die tiefgreifenden Integritätsprüfungen oder die Prüfungen des Integritätsüberwachungs-Agents nicht bestanden und muss ersetzt werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch durch ersetzt. SageMaker HyperPod |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot | Der Knoten hat die gründlichen Integritätsprüfungen oder die Prüfungen durch einen Agenten zur Gesundheitsüberwachung nicht bestanden und muss neu gestartet werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch von neu gestartet. SageMaker HyperPod |
## Deep-Zustandsprüfung
Die `deep-health-check-status` Beschriftungen stellen den Fortschritt der gründlichen Integritätsprüfung auf einem bestimmten Knoten dar. Hilfreich für Kubernetes-Benutzer, um schnell nach dem Fortschritt der allgemeinen Deep Health Checks zu filtern.
| Label (Bezeichnung) | Description |
| --- | --- |
| sagemaker.amazonaws.com/deep-health-check-status: InProgress | Der Knoten führt tiefgreifende Integritätsprüfungen durch und ist nicht für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/deep-health-check-status: Passed | Der Knoten hat eingehende Integritätsprüfungen und Agentenprüfungen zur Gesundheitsüberwachung erfolgreich abgeschlossen und ist für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/deep-health-check-status: Failed | Der Knoten hat die tiefgreifenden Integritätsprüfungen oder die Prüfungen der Systemüberwachungs-Agenten nicht bestanden und muss neu gestartet oder ausgetauscht werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch neu gestartet oder durch ersetzt. SageMaker HyperPod |
## Bezeichnungen für Art und Ursache des Fehlers
Im Folgenden werden die Bezeichnungen `fault-type` und `fault-reason` beschrieben.
+ `fault-type`Beschriftungen stehen für allgemeine Fehlerkategorien, wenn Integritätsprüfungen fehlschlagen. Diese werden für Fehler aufgefüllt, die sowohl bei gründlichen Integritätsprüfungen als auch bei der Integritätsüberwachung der Agenten festgestellt wurden.
+ `fault-reason`-Labels geben den detaillierten Fehlergrund in Verbindung mit einem `fault-type` an.
## Wie SageMaker HyperPod Beschriftungen
In den folgenden Themen wird beschrieben, wie die Etikettierung je nach Fall erfolgt.
**Topics**
+ [Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für die Deep-Health-Überprüfung deaktiviert ist](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-off)
+ [Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für den Deep Health Check aktiviert ist](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-on)
+ [Wenn es Rechenausfälle auf den Knoten gibt](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-node-fails)
### Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für die Deep-Health-Überprüfung deaktiviert ist
Wenn ein neuer Knoten zu einem Cluster hinzugefügt wird und der Deep Health Check für die Instanzgruppe nicht aktiviert ist, SageMaker HyperPod werden dieselben Integritätsprüfungen durchgeführt wie die [derzeit verfügbaren SageMaker HyperPod Zustandsprüfungen für Slurm-Cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html).
Wenn die Zustandsprüfung erfolgreich ist, werden die Knoten mit der folgenden Bezeichnung gekennzeichnet.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
Wenn die Zustandsprüfung nicht bestanden wird, werden die Knoten beendet und ersetzt. Dieses Verhalten entspricht der Funktionsweise der Integritätsprüfung für Slurm-Cluster. SageMaker HyperPod
### Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für den Deep Health Check aktiviert ist
Wenn ein neuer Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird und der Deep Health Check-Test für die Instanzgruppe aktiviert ist, wird HyperPod zuerst der Knoten verunreinigt und der \$12-stündige Deep Health check/stress Test auf dem Knoten gestartet. Es gibt 3 mögliche Ausgaben der Node-Labels nach dem Deep Health Check.
1. Wenn der Deep Health Check-Test bestanden wurde
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
1. Wenn der Deep Health Check-Test fehlschlägt und die Instance ersetzt werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Wenn der Deep Health Check-Test fehlschlägt und die Instance neu gestartet werden muss, um den Deep Health Check erneut auszuführen
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Wenn eine Instance den Deep Health Check-Test nicht besteht, wird die Instance immer ersetzt. Wenn der Deep Health Check-Test erfolgreich ist, wird der Makel auf dem Knoten entfernt.
### Wenn es Rechenausfälle auf den Knoten gibt
Der SageMaker HyperPod Health Monitor Agent überwacht außerdem kontinuierlich den Integritätsstatus jedes Knotens. Wenn der Agent Fehler feststellt (z. B. GPU-Ausfall oder Treiberabsturz), kennzeichnet er den Knoten mit einer der folgenden Bezeichnungen.
1. Wenn der Knoten fehlerhaft ist und ersetzt werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Wenn der Knoten fehlerhaft ist und neu gestartet werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Der Health Monitor-Agent verfälscht den Knoten auch, wenn er Probleme mit dem Zustand des Knotens feststellt.
# Einen Knoten manuell unter Quarantäne stellen, ersetzen oder neu starten
Erfahren Sie, wie Sie einen fehlerhaften Knoten in SageMaker HyperPod Clustern, die mit Amazon EKS orchestriert wurden, manuell unter Quarantäne stellen, ersetzen und neu starten können.
**Um einen Knoten unter Quarantäne zu stellen und das Löschen eines Trainings-Pods zu erzwingen**
```
kubectl cordon
```
Erzwingen Sie nach der Quarantäne das Auswerfen des Pods. Dies ist nützlich, wenn Sie sehen, dass ein Pod länger als 30 Minuten im Terminierungsmodus hängen geblieben ist oder wenn unter Ereignisse die Meldung „Knoten ist nicht bereit“ `kubectl describe pod` angezeigt wird
```
kubectl delete pods --grace-period=0 --force
```
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 kubectl-Befehle verwenden, um Knoten für Neustart- und Ersetzungsvorgänge zu kennzeichnen. Beide Methoden aktivieren dieselben SageMaker HyperPod Wiederherstellungsprozesse.
**Um einen Knoten mithilfe der Reboot-API neu zu starten**
Um einen Knoten neu zu starten, können Sie die BatchRebootClusterNodes API verwenden.
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
```
**Um einen Knoten mithilfe der Replace-API zu ersetzen**
Um einen Knoten zu ersetzen, können Sie die BatchReplaceClusterNodes API wie folgt verwenden
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
```
**Von Karpenter verwaltete Cluster**
Bei SageMaker HyperPod Clustern, die Karpenter für die Knotenbereitstellung verwenden, garantiert die `BatchReplaceClusterNodes` API nicht, dass ein Ersatzknoten erstellt wird. Der angegebene Knoten *wird* beendet, aber der Ersatz hängt vom Bereitstellungsmodell von Karpenter ab. pod-demand-based Karpenter erstellt nur dann neue Knoten, wenn sich Pods in einem `Pending` Zustand befinden, der nicht für bestehende Knoten geplant werden kann.
Wenn die Arbeitslast des gelöschten Knotens auf die verbleibenden Knoten im Cluster verschoben werden kann (z. B. wenn diese Knoten über eine ausreichende Kapazität verfügen), stellt Karpenter keinen Ersatz bereit. Um sicherzustellen, dass ein Ersatzknoten erstellt wird, stellen Sie sicher, dass Ihre Workload-Konfiguration (wie Pod-Anti-Affinitätsregeln oder Ressourcenanforderungen) einen neuen Knoten für die verdrängten Pods erfordert.
Wir sind uns dieser Einschränkung bewusst und arbeiten aktiv an einer Lösung, um den Austausch von Knoten zu erzwingen, wenn dies über die API angefordert wird.
**Um einen Knoten mit kubectl zu ersetzen**
Benennen Sie den Knoten, durch den ersetzt werden soll`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement`, was den auslöst. SageMaker HyperPod [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Beachten Sie, dass Sie auch die automatische Knotenwiederherstellung während der Clustererstellung oder -aktualisierung aktivieren müssen.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement
```
**Um einen Knoten mit kubectl neu zu starten**
Benennen Sie den Knoten, mit dem neu gestartet werden soll`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot`, was den auslöst. SageMaker HyperPod [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Beachten Sie, dass Sie auch die automatische Knotenwiederherstellung während der Clustererstellung oder -aktualisierung aktivieren müssen.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot
```
Nachdem die Labels `UnschedulablePendingReplacement` oder `UnschedulablePendingReboot` hinzugefügt wurden, sollten Sie in wenigen Minuten sehen können, dass der Knoten beendet oder neu gestartet wurde.
# Empfohlene Ausfallsicherheitskonfigurationen
Wenn die Deep Health Checks aktiviert sind und dem Cluster eine neue Instance hinzugefügt wird (entweder während der HyperPod Clustererstellung oder durch automatischen Knotenaustausch), durchläuft die neue Instance für etwa ein paar Stunden den Deep Health Check-Prozess (Stresstests auf Instanzebene). Im Folgenden finden Sie Vorschläge für Kombinationen von Resilienz-Konfigurationen, die von möglichen Fällen abhängen.
1. **Fall**: Wenn Sie zusätzliche Ersatzknoten innerhalb eines Clusters als Backup-Ressourcen haben (ohne die volle Kapazität zu nutzen), oder wenn Sie etwa 2 Stunden warten können, bis der gründliche Integritätscheck durchgeführt wird, um die weniger fehleranfälligen Instances zu finden.
**Empfehlung**: Aktivieren Sie die Konfiguration für die umfassende Integritätsprüfung während des gesamten Cluster-Lebenszyklus. Die Konfiguration für die automatische Wiederherstellung des Knotens ist standardmäßig aktiviert.
1. **Fall**: Wenn Sie keine zusätzlichen Backup-Knoten haben (die Kapazität ist für einen Teil der Trainingslast voll ausgeschöpft). Sie möchten die Ersatzknoten so schnell wie möglich erhalten, um den Trainingsjob wieder aufnehmen zu können.
**Empfehlung**: Aktivieren Sie den Deep Health Check während der Clustererstellung und schalten Sie dann die Konfiguration für den Deep Health Check aus, nachdem der Cluster erstellt wurde. Die Konfiguration für die auto Wiederherstellung des Knotens ist standardmäßig aktiviert.
1. **Fall**: Wenn Sie keine zusätzlichen Backup-Knoten haben und nicht auf den \$12-stündigen umfassenden Zustandstest warten möchten (kleine Cluster).
**Empfehlung**: Deaktivieren Sie die Konfiguration für die umfassende Integritätsprüfung während des gesamten Cluster-Lebenszyklus. Die Konfiguration für die auto Wiederherstellung des Knotens ist standardmäßig aktiviert.
Wenn Sie den Trainingsjob nach einem Ausfall sofort fortsetzen möchten, stellen Sie sicher, dass Sie über zusätzliche Ersatzknoten als Backup-Ressourcen im Cluster verfügen.