Cluster-Resilienz

Wenn Sie sich für Trainingscluster der Gemini Enterprise Agent Platform interessieren, wenden Sie sich an Ihren Vertriebsmitarbeiter, um Zugriff zu erhalten.

In Trainingscluster der Gemini Enterprise Agent Platform ist ein umfassendes System zur Systemdiagnose integriert, um die Zuverlässigkeit von Compute-Knoten und die Stabilität Ihrer Slurm-Jobs zu gewährleisten. Dieses System bietet sowohl automatisierte als auch manuelle Wiederherstellungsoptionen. Während der Jobausführung wird ein automatisierter Prozess ausgeführt, um kritische Komponenten wie den GPU- Zustand und die Festplattennutzung zu überwachen und fehlerhafte Knoten automatisch zu ersetzen. In Situationen, in denen eine Nutzerintervention erforderlich ist, bietet Ihr Trainingscluster eine reportFaultyNodes-API, mit der Sie einen bestimmten fehlerhaften Knoten manuell löschen oder einen vermuteten Hardwarefehler auf dem zugrunde liegenden Host melden können.

Testarbeitslast ausführen, um die GPU-Funktionalität zu prüfen

Schritt 1: SSH-Verbindung zu den Clusterknoten herstellen

Stellen Sie über Cloud Shell oder die Google Cloud Konsole mit IAP eine Verbindung zum Anmeldeknoten her. Das folgende Beispiel zeigt den Befehl für Cloud Shell:

gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID

Schritt 2: Standard-Slurm-Befehl ausführen

Nachdem Sie eine Verbindung zu einem Anmeldeknoten hergestellt haben, führen Sie einige Standard-Slurm-Befehle aus, um zu prüfen, ob der Cluster ordnungsgemäß funktioniert.

~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
partition1*    up   infinite      2   idle hcsa3m1236-a3mnodeset-[0-1]

Senden Sie als Nächstes einen Batch-Job.

~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"

In Ihrem Basisverzeichnis sollte eine Datei mit dem Namen „slurm-job-id.out“ erstellt worden sein.

Schritt 3: GPU-Arbeitslast ausführen

Speichern Sie den folgenden Inhalt als Skriptdatei mit dem Namen test.sh in Ihrem Basisverzeichnis.

#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi

srun nvidia-smi -L

Legen Sie die Berechtigungen des Skripts auf 755 fest, damit es ausgeführt werden kann, und senden Sie dann den Slurm-Job:

~$ sbatch ./test.sh

Slurm speichert die Ausgabe des Skripts in einer Datei mit dem Namen „slurm-job-id.out“.

Erwartete Ausgabe:

GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)

Clusterzustand prüfen

In diesem Abschnitt wird beschrieben, wie Sie Ihren Trainingscluster mit dem Cluster Health Scanner (CHS) testen. Dieses Tool ist im Image des Trainingsclusters vorinstalliert. Das CHS-Tool prüft den Zustand des Clusters und führt Tests wie DCGM-Diagnosen und NCCL-Tests aus, um zu bestätigen, dass der Cluster bereit ist, Ihre Arbeitslasten auszuführen.

Vom Anmeldeknoten des Clusters aus können Sie das folgende Skript ausführen, um Tests mit dem CHS-Tool auszuführen.

export CLUSTER_ID=<your_cluster_id>
export PARTITION=a3u
export MACHINE_TYPE=a3-ultragpu-8g
cd ~
/opt/cluster-health-scanner/deploy/slurm/cluster-validation.sh \
--nodelist=${CLUSTER_ID}-${PARTITION}-[0-1] \
--nodes=2 \
--partition=${PARTITION} \
--machine-type=${MACHINE_TYPE} \
--relative-exec-path=../../opt/cluster-health-scanner/deploy/slurm \
--results-dir=results

Bei einer erfolgreichen Testausführung werden zwei Ergebnissätze bereitgestellt:

  • Zusammenfassung: Auf der Konsole wird eine kurze Zusammenfassung ausgegeben, die dem folgenden Beispiel ähneln sollte.
  • Detaillierte Logs: Einen vollständigen Bericht finden Sie in den detaillierten Logs, die im Verzeichnis ~/results gespeichert sind.
Starting DCGM Diagnostics...
DCGM diagnostics passing on all nodes!
Starting NCCL all_reduce_perf...
CURR_NODES:  cluster-id-0
cluster-id-1
NCCL test passing on all nodes!

Automatisierte Systemdiagnosen und Wiederherstellung

Um die Zuverlässigkeit der Knoten zu gewährleisten, wird der Zustand der Knoten in Trainingsclustern kontinuierlich mit der folgenden Suite automatisierter Prüfungen überwacht. In Trainingsclustern werden Systemdiagnosen während des Slurm-Prologs (vor dem Start eines Jobs) und des Slurm-Epilogs (nach Abschluss eines Jobs) ausgeführt.

Suite für Systemdiagnosen

  • GPU-Zustand: Führt detaillierte, individuelle GPU-Diagnosen durch, einschließlich der Codeüberwachung von nvidia-smi, dcgmi und xid.
  • Festplattennutzung: Prüft die hohe Festplattennutzung auf kritischen Partitionen (/, /mnt/localssd, /mnt/localdisk), um zu verhindern, dass Jobs aufgrund von Platzmangel fehlschlagen.
  • Netzwerkzustand: Prüft, ob primäre Netzwerkschnittstellen eine IPv4-Adresse haben. Wenn ein Problem gefunden wird, wird versucht, es selbst zu beheben, indem die Schnittstelle zurückgesetzt wird.
  • CPU-Auslastung: Überwacht die durchschnittliche Systemauslastung und protokolliert eine Warnung, wenn ein vordefinierter Grenzwert überschritten wird.

Prozess zur Wiederherstellung nach Fehlern

Wenn bei einer Prüfung ein schwerwiegender, nicht behebbarer Fehler festgestellt wird, wird in Trainingsclustern der Gemini Enterprise Agent Platform automatisch ein Prozess zur Wiederherstellung nach Fehlern gestartet. Der Standardprozess umfasst das Entleeren der fehlerhaften Knoten, das erneute Einreihen des betroffenen Slurm-Jobs und das anschließende Löschen und Neuerstellen der entleerten Knoten, um sie wieder in einen fehlerfreien Zustand zu versetzen.

Diese automatisierte Wiederherstellung unterliegt den folgenden Bedingungen:

  • Neustartlimit: Der Wiederherstellungsprozess wird übersprungen, wenn der betroffene Slurm-Job bereits eine bestimmte Anzahl von Malen neu gestartet wurde.

  • GPU-Auslastung: Das Löschen und Neuerstellen von Knoten wird auch übersprungen, wenn der auf dem Knoten ausgeführte Job nicht alle verfügbaren GPUs verwendet. In diesem Fall wird der Knoten nur entleert, um zu verhindern, dass neue Jobs darauf geplant werden.

Fehlerhafte Compute-Knoten manuell verwalten

Trainingscluster bieten APIs zum manuellen Melden und Verwalten fehlerhafter Compute-Knoten. Dies ist besonders nützlich, wenn Probleme nicht durch automatisierte Systemdiagnosen behoben werden können. Sie können diese Vorgänge jeweils nur auf einem Knoten ausführen.

Aktion Beschreibung Optimal für
Knoten löschen Entfernt einen bestimmten fehlerhaften Knoten aus dem Cluster. Dies ist die Standardaktion. Allgemeine Fehler oder wenn ein Knoten nicht reagiert und wiederverwendet werden muss.
Host als fehlerhaft melden Meldet den zugrunde liegenden physischen Host als fehlerhaft und löst einen Reparatur- oder Migrationsprozess aus. Vermutete Hardwarefehler auf dem physischen Computer, auf dem der GPU-Knoten gehostet wird.

Aktion 1: Fehlerhaften Knoten löschen

Mit dieser Aktion wird der angegebene Knoten gelöscht. Das Ergebnis dieses Vorgangs hängt davon ab, ob der Knoten von Slurm als „statisch“ oder „dynamisch“ klassifiziert wird:

  • Statische Knoten: Wenn der Index eines gelöschten Knotens kleiner als die Mindestanzahl von Knoten des Knotenpools ist, wird ein neuer Compute-Knoten mit demselben Namen und denselben Spezifikationen neu erstellt.

  • Dynamische Knoten: Wenn der Index eines gelöschten Knotens größer als die Mindestanzahl von Knoten ist, wird er nur neu erstellt, wenn eine ausstehende Arbeitslast dafür geplant ist. Andernfalls wird dieser Knoten entfernt.

In diesen Beispielen wird ein gcurl-Alias verwendet. Dies ist eine praktische, authentifizierte Verknüpfung für die Interaktion mit den API- Endpunkten. Mit dem folgenden Befehl wird ein Alias für curl erstellt, das die erforderlichen Autorisierungsheader enthält.

alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'

API-Anfrage zum Löschen eines Knotens

Führen Sie die folgende POST-Anfrage aus, um einen fehlerhaften Knoten zu löschen. Die NODE_ID muss das Format CLUSTER_ID-NODEPOOL_ID-INDEXhaben. 

  gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'

Vorgangsstatus prüfen
Sie können das Ergebnis der Aktion reportFaultyNodes prüfen, indem Sie den Vorgangsstatus prüfen. 

  gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

Aktion 2: Host als fehlerhaft melden

Sie können den physischen Host eines GPU-Knotens als fehlerhaft melden, wenn Sie einen Hardwarefehler vermuten.

  • Unterstützte VMs: A3 Ultra und A4 High-GPU

  • Knotenstatus: Der Zielknoten muss den Status RUNNING haben, bevor Sie die API aufrufen. Nach einem erfolgreichen Aufruf ändert sich der Status in REPAIRING und kehrt zu RUNNING zurück, nachdem der Host repariert oder der Knoten auf einem neuen Host neu erstellt wurde. Dies ist ein bestmöglicher Vorgang.

Voraussetzung: IAM-Rolle gewähren

Um diese Funktion zu verwenden, müssen Sie dem Agent Platform Service Agent die Rolle Compute-Instanzadministrator (v1)“ (roles/compute.instanceAdmin.v1) gewähren. 

  PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

  gcloud projects add-iam-policy-binding PROJECT_ID\
  --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.iam.gserviceaccount.com" \
  --role="roles/compute.instanceAdmin.v1"

API-Anfrage zum Melden eines Hosts

Führen Sie die folgende POST-Anfrage aus, um den zugrunde liegenden Host als fehlerhaft zu melden. Dabei müssen Sie für faultReasons ein oder mehrere beobachtete Verhaltensweisen und Beschreibungen angeben.
Verwenden Sie für das Feld behavior einen der folgenden Werte:

Verhalten Beschreibung
PERFORMANCE Die an die VM angehängten GPUs haben Leistungsprobleme im Vergleich zu anderen GPUs im Cluster, in den Logs sind keine XID-Fehler zu sehen und Compute Engine erkennt keine anderen üblichen Fehlermuster wie stille Datenbeschädigung.
SILENT_DATA_CORRUPTION In Ihrer VM ist eine Datenbeschädigung zu sehen, aber die VM wird weiter ausgeführt. Dies kann an Problemen wie vCPU-Defekten, Softwarefehlern oder Kernelproblemen liegen.
UNRECOVERABLE_GPU_ERROR Sie haben einen nicht behebaren GPU-Fehler mit einer XID identifiziert.
BEHAVIOR_UNSPECIFIED Sie sind sich nicht sicher, was das Problem mit Ihrer VM ist.

Hier ein Beispiel für die API-Anfrage: 

gcurl -X POST \
  https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
  -d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'

Zusammenfassung

Durch die Nutzung sowohl automatisierter Systemdiagnosen als auch der auf dieser Seite beschriebenen manuellen Steuerelemente können Sie eine hochverfügbare Trainingsumgebung aufrechterhalten. Wenn Sie den Zustand Ihres Clusters proaktiv verwalten, indem Sie fehlerhafte Knoten löschen oder Hardwareprobleme melden, sorgen Sie für maximale Betriebszeit und den erfolgreichen Abschluss Ihrer Trainingsjobs. Bei anhaltenden oder komplexen Problemen sollten Sie sich immer an das Supportteam wenden, um detaillierte Diagnosen und Google Cloud Unterstützung zu erhalten.

Nächste Schritte

Das Konfigurieren Ihres Trainingsclusters für Fehlertoleranz ist ein wichtiger Schritt beim Erstellen eines vollständigen, produktionsbereiten MLOps-Workflows.

  • Trainingsjobs überwachen und Fehler beheben: Verfolgen Sie den Fortschritt, die Ressourcennutzung und den Zustand Ihrer Trainingsjobs. Außerdem erfahren Sie, wie Sie feststellen können, wann ein Knoten wiederhergestellt oder ein Job aufgrund eines Fehlers neu gestartet wurde.
  • Robuste Jobs mit Gemini Enterprise Agent Platform Pipelines orchestrieren: Verwenden Sie für Produktionsumgebungen Gemini Enterprise Agent Platform Pipelines, um einen automatisierten, wiederholbaren Workflow zu erstellen, mit dem Ihre robusten Trainingsjobs an Ihren Cluster gesendet werden.
  • Modell verwalten und bereitstellen: Nachdem Ihr robuster Trainingsjob abgeschlossen ist, verwenden Sie die Gemini Enterprise Agent Platform Model Registry, um eine Version Ihres Modellartefakts zu erstellen, bevor Sie das Modell auf einem Endpunkt bereitstellen, um Onlinevorhersageanfragen zu verarbeiten.