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: Über SSH eine Verbindung zu den Clusterknoten herstellen

Stellen Sie über Cloud Shell oder die Google Cloud Console 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: Standardmäßigen Slurm-Befehl ausführen

Nachdem Sie eine Verbindung zu einem Anmeldeknoten hergestellt haben, führen Sie einige standardmäßige 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 Batchjob.

~$ 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 ausführbar ist, 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)

Automatisierte Systemdiagnosen und Wiederherstellung

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

Suite für Systemdiagnosen

  • GPU-Zustand: Führt detaillierte, individuelle GPU-Diagnosen durch, einschließlich der Überwachung von nvidia-smi-, dcgmi- und xid-Code.
  • Festplattennutzung: Prüft die 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 Systemdiagnose 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.

Für diese automatisierte Wiederherstellung gelten die 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.

Jede Wiederherstellungsaktion wird in den Logs Ihres Projekts als Resilienzereignis aufgezeichnet. Informationen zum Vergleichen dieser Ereignisse mit dem Slurm-Status Ihrer Knoten finden Sie unter Resilienzereignisse mit einem Dashboard überwachen.

Fehlerhafte Compute-Knoten manuell verwalten

Trainingscluster bieten APIs zum manuellen Melden und Verwalten fehlerhafter Compute-Knoten. Das 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. Das 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 er entfernt.

In diesen Beispielen wird ein gcurl-Alias verwendet. Das 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 aufrufen. 

  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. Das ist ein bestmöglicher Versuch.

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 ein oder mehrere beobachtete Verhaltensweisen und Beschreibungen für die faultReasons 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. Das kann an Problemen wie vCPU-Defekten, Softwarefehlern oder Kernelproblemen liegen.
UNRECOVERABLE_GPU_ERROR Sie haben einen nicht behebaren GPU-Fehler mit einer XID festgestellt.
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 Verfügbarkeit und den erfolgreichen Abschluss Ihrer Trainingsjobs. Bei wiederkehrenden oder komplexen Problemen sollten Sie sich immer an das Google Cloud Supportteam wenden, um eine detaillierte Diagnose und 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.