

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.

# Tiefgreifende Zustandsprüfungen
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks"></a>

SageMaker HyperPod führt * gründliche Zustandsprüfungen * für Slurm-orchestrated Cluster-Instances durch, um die Zuverlässigkeit und Stabilität der zugrunde liegenden Hardware und Infrastruktur sicherzustellen. Tiefgehende Zustandsprüfungen können automatisch ausgeführt werden, wenn Instanzen erstellt oder einem Cluster hinzugefügt * werden (beim Start*), oder Sie können sie jederzeit manuell (bei * Bedarf*) mithilfe der [ StartClusterHealthCheck ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html) API auslösen. Dieser proaktive Ansatz hilft dabei, potenzielle Probleme während des gesamten Cluster-Lebenszyklus zu identifizieren und zu beheben.

Bei gründlichen Zustandsprüfungen werden die betroffenen Knoten einer Slurm-Wartungsreservierung zugeordnet, um zu verhindern, dass Jobs auf ihnen geplant werden. Sobald alle Checks bestanden sind, werden die Knoten aus der Reservierung entlassen und stehen für Workloads zur Verfügung.

**Wichtig**  
Um Deep Health Checks verwenden zu können, müssen Sie auf die neueste AMI-Version aktualisieren. Führen Sie aus [ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html), um das AMI auf die neueste Version zu aktualisieren. Wenn Sie eine ältere AMI-Version verwenden, funktionieren Deep Health Checks möglicherweise nicht wie erwartet.

## Arten von gründlichen Zustandsprüfungen
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-types"></a>

SageMaker HyperPod unterstützt zwei Kategorien von tiefgreifenden Zustandsprüfungen für Slurm-Cluster:
+ **InstanceStress**— Führt Tests auf Instanzebene durch, darunter Hardware-Stresstests (CPU, Speicher, Festplatte, GPU/PCI Überprüfung), DCGM-GPU-Diagnosen und EFA-Loopback-Konnektivität. Dadurch wird der Zustand der einzelnen Knotenhardware überprüft.
+ **InstanceConnectivity**— Führt NCCL-Tests (NVIDIA Collective Communications Library) auf Clusterebene auf mehreren Knoten durch, um die GPU-Kommunikationsleistung zwischen den Knoten zu überprüfen. Diese Prüfung wird nur auf Instanzen mit GPU-Kommunikationsfunktionen mit mehreren Knoten unterstützt.

## Liste der gründlichen Gesundheitschecks, durchgeführt von SageMaker HyperPod
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-list"></a>

SageMaker HyperPod führt die folgenden gründlichen Gesundheitschecks durch.

**Instance-level gründliche Gesundheitschecks (InstanceStress) **


| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description | 
| --- | --- | --- | --- | 
| Accelerator | GPU/NVLink count | GPU | Überprüft die GPU/NVLink Anzahl. | 
| 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. Typische Dauer: \~45-90 Minuten, abhängig von der GPU-Anzahl. | 
| Netzwerk | EFA | GPU | Führt EFA-Loopback-Bandbreiten- und Latenztests auf dem angeschlossenen EFA-Gerät durch. Typische Dauer: \~2-5 Minuten. | 

**Cluster-level gründliche Gesundheitschecks () InstanceConnectivity **


| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description | 
| --- | --- | --- | --- | 
| Accelerator | NCCL-Prüfung | GPU | Führt all\_reduce NCCL-Leistungstests auf mehreren Knoten aus, um die GPU-Kommunikationsbandbreite zwischen den Knoten zu überprüfen. Typische Dauer: \~5-15 Minuten, abhängig von der Anzahl der Knoten. | 

## On-start gründliche Gesundheitschecks
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start"></a>

On-start Deep Health Checks werden automatisch ausgeführt, wenn Instanzen zum ersten Mal bereitgestellt werden — bei der Clustererstellung oder beim Hinzufügen neuer Instanzen über [ UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html). Dadurch wird sichergestellt, dass jeder Knoten die Hardwarevalidierung besteht, bevor Workloads akzeptiert werden.

### Ermöglicht gründliche Zustandsprüfungen beim Start
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-enabling"></a>

Um gründliche Zustandsprüfungen beim Start zu aktivieren, geben Sie den `OnStartDeepHealthChecks` Parameter in der Instanzgruppenkonfiguration an, wenn Sie einen Cluster erstellen oder aktualisieren.

**Beispiel: Erstellen Sie einen Cluster mit gründlichen Zustandsprüfungen beim Start **

```
aws sagemaker create-cluster \
  --cluster-name {{my-slurm-cluster}} \
  --instance-groups '[
    {
      "InstanceGroupName": "controller-group",
      "InstanceType": "ml.m5.xlarge",
      "InstanceCount": 1,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group",
      "InstanceType": "ml.p4d.24xlarge",
      "InstanceCount": 4,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
      "ThreadsPerCore": 1,
      "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]' \
  --vpc-config '{"SecurityGroupIds":["{{sg-12345678}}"],"Subnets":["{{subnet-12345678}}"]}'
```

### Was passiert bei gründlichen Zustandsprüfungen während des Starts
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-process"></a>

Wenn gründliche Zustandsprüfungen beim Start aktiviert sind, läuft der folgende Prozess ab:

1. **Knotenbereitstellung**: Neue Instances werden gestartet und Lifecycle-Skripts werden ausgeführt.

1. **Knotenisolierung**: Der HyperPod Cluster-Agent platziert neue Knoten in einer Slurm-Wartungsreservierung (`hyperpod-deep-health-check`) und fügt sie der `hyperpod-system-maintenance` Partition hinzu. Knoten sind mit der Slurm-Funktion markiert. `SageMakerDeepHealthCheck:InProgress` Dadurch wird verhindert, dass während des Testens Jobs auf diesen Knoten geplant werden.

1. **Testausführung**: Die folgenden Tests werden im Rahmen der `InstanceStress` Prüfung auf jedem Knoten ausgeführt:
   + **HARDWARE\_CHECK**: Wird `stress-ng` für CPU-, Speicher- und Festplatten-Stresstests ausgeführt, gefolgt von der Überprüfung der GPU- und PCI-Geräteanzahl. Typische Dauer: \~1-2 Minuten.
   + **DCGM**: Führt die NVIDIA DCGM-Diagnose auf Stufe 4 aus, einschließlich GPU-Speichertests. Typische Dauer: \~45-90 Minuten, abhängig von der GPU-Anzahl.
   + **EFA**: Führt EFA-Loopback-Bandbreiten- und Latenztests durch. Typische Dauer: \~2-5 Minuten.

   Wenn diese Option ebenfalls aktiviert `InstanceConnectivity` ist, wird der folgende zusätzliche Test ausgeführt:
   + **NCCL**: Führt `all_reduce` NCCL-Leistungstests auf mehreren Knoten durch, um die GPU-Kommunikationsbandbreite zwischen den Knoten zu überprüfen. Typische Dauer: \~5-15 Minuten, abhängig von der Anzahl der Knoten.

1. **Behandlung der Ergebnisse: **
   + ****Bestanden: Der Knoten wird aus der Wartungsreservierung entfernt, die Funktion „Deep Health Check“ wird deaktiviert und der Knoten wird für Jobs in der ihm zugewiesenen Partition verfügbar.
   + ****Fehlgeschlagen: Der Knoten bleibt isoliert. SageMaker HyperPod ersetzt automatisch den ausgefallenen Knoten und führt gründliche Integritätsprüfungen für den Ersatzknoten durch.

Der Cluster wechselt zu einem Zeitpunkt`InService`, an dem mindestens der Controller-Knoten läuft. Worker-Knoten zeigen während des Tests `DeepHealthCheckInProgress` den Status an und wechseln `Running` nach bestandenem Test zum Status.

### Überwachung gründlicher Gesundheitschecks während des Starts
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-monitoring"></a>

Sie können den Status gründlicher Zustandsprüfungen beim Start mithilfe der Amazon SageMaker AI-API oder der Slurm-Befehle überwachen.

**Überprüfen Sie den Knotenstatus mit dem AWS Command Line Interface**

```
aws sagemaker list-cluster-nodes \
  --cluster-name {{my-slurm-cluster}}
```

Knoten, die gründlichen Zustandsprüfungen unterzogen werden, `InstanceStatus.Status` werden als angezeigt`DeepHealthCheckInProgress`.

**Überprüfen Sie den Slurm-Status über SSM auf dem Controller-Knoten **

```
# View node states
sinfo -a -N -l

# View maintenance reservation
scontrol show reservations

# View running DHC jobs
squeue -a
```

Knoten, die einer gründlichen Integritätsprüfung unterzogen werden, erscheinen in der `hyperpod-deep-health-check` Reservierung und in der `hyperpod-system-maintenance` Partition.

### Hinzufügen von Knoten zu einem Cluster, bei dem die gründlichen Zustandsprüfungen beim Start aktiviert sind
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-start-add-nodes"></a>

Wenn Sie einen bereits `OnStartDeepHealthChecks` konfigurierten Cluster hochskalieren, werden neue Knoten automatisch einer gründlichen Zustandsprüfung unterzogen, bevor sie Workloads annehmen. Bestehende Knoten und laufende Jobs sind nicht betroffen.

```
aws sagemaker update-cluster \
  --cluster-name {{my-slurm-cluster}} \
  --instance-groups '[
    {
      "InstanceGroupName": "controller-group",
      "InstanceType": "ml.m5.xlarge",
      "InstanceCount": 1,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group",
      "InstanceType": "ml.p4d.24xlarge",
      "InstanceCount": 8,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}",
      "ThreadsPerCore": 1,
      "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]'
```

Die neuen Knoten werden in der Wartungsreservierung isoliert, während gründliche Zustandsprüfungen durchgeführt werden. Jobs, die die zusätzliche Kapazität der neuen Knoten benötigen, warten, bis diese Knoten gründliche Zustandsprüfungen bestanden haben und verfügbar sind. Jobs, die von vorhandenen verfügbaren Knoten erledigt werden können, sind nicht betroffen.

## On-demand gründliche Gesundheitschecks
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand"></a>

On-demand Mit tiefgreifenden Zustandsprüfungen können Sie mithilfe der [ StartClusterHealthCheck ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html) API jederzeit eine Hardwarevalidierung auf vorhandenen Clusterknoten auslösen. Dies ist nützlich für die regelmäßige Integritätsprüfung oder bei vermuteten Hardwareproblemen.

### Durchführung umfassender Zustandsprüfungen auf Abruf von der Konsole aus
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-console"></a>

Sie können tiefgreifende Integritätsprüfungen für HyperPod Cluster-Instances direkt von der SageMaker AI-Konsole aus durchführen.

**Um tiefgreifende Zustandsprüfungen auf Abruf von der Konsole aus durchzuführen**

1. Öffnen Sie die SageMaker AI-Konsole unter [ SageMaker AI Console](https://console.aws.amazon.com/sagemaker).

1. Wählen Sie im Navigationsbereich unter ** HyperPod ** ** Clusters aus**.

1. Wählen Sie den Namen Ihres Clusters aus, um die Cluster-Detailseite zu öffnen.

1. Wählen Sie in der ** ** Instanzentabelle eine oder mehrere Instances aus, für die Sie gründliche Zustandsprüfungen durchführen möchten.
**Anmerkung**  
Zu den unterstützten Instance-Familien gehören g5, p4 und p5. Non-accelerated Instanzen werden automatisch übersprungen.

1. Wählen Sie „**Aktionen“ ** und dann „Deep Health Checks ** ** ausführen“ aus.

1. Wählen Sie ** Belastungsprüfung**, ** Konnektivitätsprüfung ** oder beides aus:
   + **Belastungsprüfung ** — Validiert die Beschleuniger-Hardware unter Last (entspricht`InstanceStress`).
   + **Konnektivitätsprüfung ** — Validiert die Netzwerkkommunikation zwischen Knoten (entspricht). `InstanceConnectivity`

1. Wählen Sie ** Systemdiagnosen ausführen aus. **

Ein Erfolgsbanner bestätigt, dass die Prüfungen eingeleitet wurden. Für Workloads während der Prüfungen, die über eine Stunde dauern können, sind keine Instanzen verfügbar. Überwachen Sie den Instanzstatus in der ** ** Instanzentabelle — dort wird angezeigt, dass ** während der Ausführung eine ** Deep Health Check durchgeführt wird. Wenn Probleme gefunden werden und die automatische Wiederherstellung aktiviert ist, SageMaker HyperPod werden fehlerhafte Instances automatisch neu gestartet oder ersetzt.

### Auslösen umfassender Zustandschecks auf Abruf mithilfe der AWS Command Line Interface
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-triggering"></a>

Sie können angeben, welche Instanzgruppen und welche Prüfungen ausgeführt werden sollen. Pro Cluster kann jeweils nur eine Anforderung zur gründlichen Zustandsprüfung auf Abruf aktiv sein.

```
aws sagemaker start-cluster-health-check \
  --cluster-name {{my-slurm-cluster}} \
  --deep-health-check-configurations '[
    {
      "InstanceGroupName": "worker-group",
      "DeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]'
```

### Verhalten bei laufenden Workloads
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-on-demand-behavior"></a>

Wenn tiefgreifende Zustandsprüfungen auf Abruf auf Knoten ausgelöst werden, auf denen Jobs ausgeführt werden:
+ Laufende Jobs werden ** nicht ** unterbrochen oder beendet.
+ Der Deep Health Check befindet sich in der Warteschlange und wartet darauf, dass der aktuelle Job abgeschlossen ist. Wenn der ausgeführte Job nicht innerhalb von 10 Minuten abgeschlossen wird, wird der Knoten bei der gründlichen Zustandsprüfung übersprungen.
+ Die Knoten werden in die Wartungsreservierung aufgenommen, um zu verhindern, dass während der Tests neue Jobs geplant werden.

## Protokolle der umfassenden Gesundheitschecks
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-logs"></a>

Im Folgenden finden Sie Beispielprotokolle aus den SageMaker HyperPod tiefgreifenden Zustandsprüfungen.

**Cluster-level logs**

Die Protokolle für tiefgreifende Integritätsprüfungen auf Clusterebene werden in Ihrer CloudWatch Protokollgruppe unter gespeichert. `/aws/sagemaker/Clusters/<cluster_name>/<cluster_id>`

Die Protokollstream werden unter `DeepHealthCheckResults/<log_stream_id>` protokolliert.

**Instance-level logs**

Auf jedem Knoten werden tiefgreifende Integritätsprüfungsprotokolle unter gespeichert. `/var/log/aws/clusters/sagemaker-deep-health-check.log`

Sie können über SSM auf das Protokoll zugreifen:

```
aws ssm start-session \
  --target "sagemaker-cluster:{{<cluster_id>}}_{{<instance_group>}}-{{<instance_id>}}"
```

Dann sieh dir das Protokoll an:

```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```

**Beispiel für eine HARDWARE\_CHECK-Ausgabe **

```
2026-03-29T18:03:14Z  info  Executing Hardware stress check with command: stress-ng
2026-03-29T18:04:20Z  info  stress-ng success
2026-03-29T18:04:20Z  info  GpuPci Count check success
```

**Beispiel für eine DCGM-Ausgabe **

```
2026-03-29T18:35:02Z  info  DCGM diagnostic health summary: dcgmCheckLevel: 4
  dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01
  gpuDeviceIds: [2237] replacementRequired: false rebootRequired: false
```

**Beispiel für eine EFA-Ausgabe **

```
2026-03-29T18:36:28Z  info  EFA Loopback check passed for device: rdmap0s29
  MaxBw: 58.59, AvgBw: 32.42, MaxTypicalLat: 30.87, AvgLat: 21.63
```

**Beispiel für eine Ausgabe eines Deep-Health-Checks **

```
{
    "level": "error",
    "ts": "2026-03-29T19:15:22Z",
    "msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: ml.g5.8xlarge. ERROR: Bandwidth has less than threshold: Expected minimum threshold: 80, NCCL Test output Bw: 30"
}
```

## Auto-resume Verhalten bei gründlichen Gesundheitschecks
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-auto-resume"></a>

Wenn ein Knoten während der automatischen Wiederaufnahme ersetzt wird, wird der Ersatzknoten sofort zum Cluster hinzugefügt, ohne dass tiefgreifende Zustandsprüfungen aktiviert sind, und die automatische Wiederaufnahme des Jobs kann sofort auf diesem Knoten geplant werden.

Wenn tiefgreifende Zustandsprüfungen aktiviert sind, muss der Ersatzknoten alle konfigurierten umfassenden Zustandsprüfungen bestehen, bevor er verfügbar ist. Der automatisch wiederaufgenommene Job muss jedoch nicht auf den Ersatzknoten warten — er kann auf jedem anderen verfügbaren Knoten im Cluster geplant werden. Der Job wartet nur, wenn keine anderen Knoten verfügbar sind.

## Weitere Überlegungen
<a name="sagemaker-hyperpod-resiliency-slurm-deep-health-checks-limitations"></a>
+ Für gründliche Zustandsprüfungen ist die neueste AMI-Version erforderlich. Führen Sie aus [ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html), um Ihren Cluster zu aktualisieren, bevor Sie tiefgreifende Zustandsprüfungen aktivieren.
+ Tiefgehende Zustandsprüfungen werden nur auf Worker-Knoten ausgeführt. Controller- und Login-Nodes werden keinen gründlichen Zustandsprüfungen unterzogen.
+ Pro Cluster kann jeweils nur eine tiefgreifende Integritätsprüfungsanforderung auf Abruf aktiv sein.
+ Wenn eine On-Demand-Überprüfung einen Neustart oder einen Austausch des Knotens auslöst, führt der Ersatzknoten nur dann tiefgreifende Zustandsprüfungen durch, wenn er für die Instanzgruppe aktiviert `OnStartDeepHealthChecks` ist. Andernfalls tritt der Knoten wieder bei, ohne erneut gründliche Zustandsprüfungen durchzuführen.