Vertex AI-Trainingscluster enthalten ein umfassendes Systemdiagnosesystem, um die Zuverlässigkeit von Rechenknoten und die Stabilität Ihrer Slurm-Jobs zu gewährleisten. Dieses System bietet sowohl automatisierte als auch manuelle Wiederherstellungsoptionen. Während der Ausführung eines Jobs wird ein automatisierter Prozess ausgeführt, um kritische Komponenten wie den GPU-Zustand und die Festplattennutzung zu überwachen. Fehlerhafte Knoten werden automatisch ersetzt. In Situationen, die eine Nutzeraktion erfordern, 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: 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]
Als Nächstes senden Sie einen Batchjob.
~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"
In Ihrem Basisverzeichnis sollte eine Datei namens „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 Home-Verzeichnis.
#!/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)
Clusterstatus prüfen
In diesem Abschnitt wird beschrieben, wie Sie Ihren Trainingscluster mit dem Tool „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 prüfen, ob der Cluster für die Ausführung Ihrer Arbeitslasten bereit ist.
Auf dem Anmeldeknoten des Clusters 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 einem erfolgreichen Testlauf werden zwei Arten von Ergebnissen ausgegeben:
- Zusammenfassung der Ausgabe: Auf der Konsole wird eine kurze Zusammenfassung ausgegeben, die dem folgenden Beispiel ähneln sollte.
- Detaillierte Protokolle: Einen vollständigen Bericht finden Sie in den detaillierten Protokollen, die im Verzeichnis
~/resultsgespeichert 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 von Knoten zu gewährleisten, wird die Knotenintegrität in Trainingsclustern kontinuierlich mithilfe der folgenden automatisierten Prüfungen überwacht. In Trainingsclustern werden während des Slurm-Prolog (vor Beginn eines Jobs) und des Epilog (nach Abschluss eines Jobs) Systemdiagnosen ausgeführt.
Systemdiagnose
- GPU-Integrität: Führt detaillierte, individuelle GPU-Diagnosen durch, einschließlich der Überwachung von
nvidia-smi-,dcgmi- undxid-Codes. - Laufwerksnutzung: Prüft auf hohe Laufwerksnutzung auf kritischen Partitionen (
/,/mnt/localssd,/mnt/localdisk), um zu verhindern, dass Jobs aufgrund von Platzmangel fehlschlagen. - Netzwerkstatus: Prüft, ob primäre Netzwerkschnittstellen eine IPv4-Adresse haben. Wenn ein Problem gefunden wird, wird versucht, es durch Zurücksetzen der Schnittstelle selbst zu beheben.
- 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 erkannt wird, wird in Vertex AI-Trainingsclustern automatisch ein Prozess zur Fehlerbehebung 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 automatische 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 für den Job, der auf dem Knoten ausgeführt wird, nicht alle verfügbaren GPUs verwendet werden. In diesem Fall wird der Knoten nur geleert, um zu verhindern, dass neue Jobs darauf geplant werden.
Fehlerhafte Rechenknoten manuell verwalten
Trainingscluster bieten APIs zum manuellen Melden und Verwalten fehlerhafter Rechenknoten. Das ist besonders nützlich, wenn Probleme nicht durch automatische 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 angegebenen fehlerhaften Knoten aus dem Cluster. Dies ist die Standardaktion. | Allgemeine Fehler oder wenn ein Knoten nicht reagiert und neu gestartet werden muss. |
| Host als fehlerhaft melden | Meldet den zugrunde liegenden physischen Host als fehlerhaft und löst einen Reparatur- oder Migrationsprozess aus. | Verdacht auf Hardwarefehler auf der physischen Maschine, auf der der GPU-Knoten gehostet wird. |
Aktion 1: Fehlerhaften Knoten löschen
Durch diese Aktion wird der angegebene Knoten gelöscht. Das Ergebnis dieses Vorgangs hängt davon ab, ob der Knoten von Slurm als „statisch“ oder „dynamisch“ eingestuft wird:
Statische Knoten: Wenn der Index eines gelöschten Knotens kleiner als die Mindestanzahl von Knoten des Knotenpools ist, wird ein neuer Rechenknoten mit demselben Namen und denselben Spezifikationen 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 für ihn geplant ist. Andernfalls wird diese Zeile entfernt.
In diesen Beispielen wird ein gcurl-Alias verwendet, der eine praktische, authentifizierte Verknüpfung für die Interaktion mit den API-Endpunkten darstellt. Mit dem folgenden Befehl wird ein Alias für curl erstellt, der 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. NODE_ID sollte das Format CLUSTER_ID-NODEPOOL_ID-INDEX haben.
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 AktionreportFaultyNodes überwachen, 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
an, bevor Sie fortfahren.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
RUNNINGhaben, bevor Sie die API aufrufen. Nach einem erfolgreichen Aufruf wechselt der Status zuREPAIRINGund kehrt zuRUNNINGzurück, nachdem der Host repariert oder der Knoten auf einem neuen Host neu erstellt wurde. Dies ist ein bestmöglicher Versuch.
Voraussetzung: IAM-Rolle zuweisen
Wenn Sie diese Funktion verwenden möchten, müssen Sie dem Vertex AI-Dienst-Agent die Rolle Compute-Instanzadministrator (v1)“ (roles/compute.instanceAdmin.v1) zuweisen.
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. Dazu müssen Sie ein oder mehrere beobachtete Verhaltensweisen und Beschreibungen für die faultReasons angeben.
Für das Feld behavior sollten Sie einen der folgenden Werte verwenden:
| 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 z. B. stille Datenbeschädigung. |
SILENT_DATA_CORRUPTION |
Sie stellen Datenbeschädigungen auf Ihrer VM fest, 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 behebbarer GPU-Fehler mit einer XID identifiziert. |
BEHAVIOR_UNSPECIFIED |
Sie sind sich nicht sicher, was das Problem mit Ihrer VM ist. |
Hier ist 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 hochgradig robuste 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 hartnäckigen 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, produktionsreifen MLOps-Workflows.
- Trainingsjobs überwachen und debuggen: Sie können den Fortschritt, die Ressourcennutzung und den Zustand Ihrer Trainingsjobs verfolgen. Außerdem erfahren Sie, wie Sie erkennen, wann ein Knoten wiederhergestellt oder ein Job aufgrund eines Fehlers neu gestartet wurde.
- Resiliente Jobs mit Vertex AI Pipelines orchestrieren: Verwenden Sie für Produktionsumgebungen Vertex AI Pipelines, um einen automatisierten, wiederholbaren Workflow zu erstellen, mit dem Ihre resilienten Trainingsjobs an Ihren Cluster gesendet werden.
- Modell verwalten und bereitstellen: Nachdem Ihr resilienter Trainingsjob abgeschlossen ist, verwenden Sie Vertex AI Model Registry, um eine Version Ihres Modellartefakts zu erstellen, bevor Sie das Modell auf einem Endpunkt bereitstellen, um Online-Inferenzanfragen zu verarbeiten.