Résilience des clusters

Si vous êtes intéressé par les clusters d'entraînement Vertex AI, contactez votre représentant commercial pour y accéder.

Les clusters d'entraînement Vertex AI intègrent un système complet de vérification de l'état'état pour garantir la fiabilité des nœuds de calcul et la stabilité de vos jobs Slurm. Ce système propose des options de récupération automatiques et manuelles. Un processus automatisé s'exécute pendant l'exécution du job pour surveiller les composants critiques tels que l'état du GPU et l'utilisation du disque, et remplace automatiquement les nœuds défaillants. Pour les situations nécessitant une intervention de l'utilisateur, votre cluster d'entraînement fournit une API reportFaultyNodes qui vous permet de supprimer manuellement un nœud défectueux spécifique ou de signaler une défaillance matérielle suspectée sur son hôte sous-jacent.

Exécuter une charge de travail de test pour vérifier le fonctionnement du GPU

Étape 1 : Se connecter aux nœuds du cluster à l'aide de SSH

Depuis Cloud Shell ou la console Google Cloud , connectez-vous au nœud de connexion à l'aide d'IAP. L'exemple suivant montre la commande pour Cloud Shell :

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

Étape 2 : Exécutez une commande Slurm standard

Après vous être connecté à un nœud de connexion, exécutez quelques commandes Slurm standards pour vérifier que le cluster fonctionne correctement.

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

Envoyez ensuite un job par lot.

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

Vous devriez voir un fichier slurm-job-id.out créé dans votre répertoire d'accueil.

Étape 3 : Exécutez une charge de travail GPU

Enregistrez le contenu suivant en tant que fichier de script nommé test.sh dans votre répertoire personnel.

#!/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

Définissez les autorisations du script sur 755 pour le rendre exécutable, puis envoyez le job Slurm :

~$ sbatch ./test.sh

Slurm enregistre la sortie du script dans un fichier nommé slurm-job-id.out.

Résultat attendu :

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)

Vérification de l'état du cluster

Cette section explique comment tester votre cluster d'entraînement à l'aide de l'outil Cluster Health Scanner (CHS), qui est préinstallé sur l'image du cluster d'entraînement. L'outil CHS vérifie l'état du cluster en exécutant des tests tels que des diagnostics DCGM et des tests NCCL pour s'assurer que le cluster est prêt à exécuter vos charges de travail.

À partir du nœud de connexion du cluster, vous pouvez exécuter le script suivant pour exécuter des tests à l'aide de l'outil CHS.

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

Si le test s'exécute correctement, deux ensembles de résultats sont fournis :

  • Sortie récapitulative : un bref récapitulatif est imprimé dans la console. Il devrait ressembler à l'exemple suivant.
  • Journaux détaillés : pour obtenir un rapport complet, consultez les journaux détaillés enregistrés dans le répertoire ~/results.
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!

Vérifications d'état et récupération automatisées

Pour garantir la fiabilité des nœuds, les clusters d'entraînement surveillent en permanence l'état des nœuds à l'aide de la suite de vérifications automatisées suivante. Les clusters d'entraînement exécutent des vérifications de l'état pendant le prologue Slurm (avant le début d'un job) et l'épilogue (après la fin d'un job).

Suite de vérification de l'état

  • État du GPU : effectue des diagnostics détaillés et individuels des GPU, y compris la surveillance des codes nvidia-smi, dcgmi et xid.
  • Utilisation du disque : vérifie l'utilisation élevée du disque sur les partitions critiques (/, /mnt/localssd, /mnt/localdisk) pour éviter l'échec des tâches en raison du manque d'espace.
  • État du réseau : vérifie que les interfaces réseau principales disposent d'une adresse IPv4. Si un problème est détecté, il tente de se résoudre lui-même en réinitialisant l'interface.
  • Charge du processeur : surveille la charge moyenne du système et enregistre un avertissement si elle dépasse un seuil prédéfini.

Processus de reprise après échec

Si une vérification détecte une erreur grave et irrécupérable, les clusters d'entraînement Vertex AI lancent automatiquement un processus de récupération en cas d'échec. La procédure standard consiste à drainer les nœuds défectueux, à remettre en file d'attente le job Slurm concerné, puis à supprimer et à recréer les nœuds drainés pour les restaurer dans un état sain.

Cette récupération automatisée est soumise aux conditions suivantes :

  • Limite de redémarrage : le processus de récupération est ignoré si le job Slurm concerné a déjà été redémarré un certain nombre de fois.

  • Utilisation du GPU : la suppression et la recréation des nœuds sont également ignorées si le job exécuté sur le nœud n'utilise pas tous les GPU disponibles. Dans ce cas, le nœud est uniquement vidé pour empêcher la planification de nouvelles tâches.

Gérer manuellement les nœuds de calcul défectueux

Les clusters d'entraînement fournissent des API permettant de signaler et de gérer manuellement les nœuds de calcul défectueux, ce qui est particulièrement utile si les vérifications de l'état automatisées ne résolvent pas un problème. Vous ne pouvez exécuter ces opérations que sur un seul nœud à la fois.

Action Description Recommandée
Supprimer le nœud Supprime un nœud défectueux spécifié du cluster. Il s'agit de l'action par défaut. Erreurs générales ou lorsqu'un nœud ne répond pas et doit être recyclé.
Signaler un hôte défectueux Signale que l'hôte physique sous-jacent est défectueux, ce qui déclenche un processus de réparation ou de migration. Défaillances matérielles suspectées sur la machine physique hébergeant le nœud GPU.

Action 1 : Supprimer un nœud défectueux

Cette action supprime le nœud spécifié. Le résultat de cette opération dépend de la classification du nœud par Slurm (statique ou dynamique) :

  • Nœuds statiques : si l'index d'un nœud supprimé est inférieur au nombre minimal de nœuds du pool de nœuds, un nouveau nœud de calcul est recréé avec le même nom et les mêmes spécifications.

  • Nœuds dynamiques : si l'index d'un nœud supprimé est supérieur au nombre minimal de nœuds, il n'est recréé que si une charge de travail en attente est planifiée pour celui-ci. Sinon, elle est supprimée.

Ces exemples utilisent un alias gcurl, qui est un raccourci authentifié pratique pour interagir avec les points de terminaison de l'API. La commande suivante crée un alias pour curl qui inclut les en-têtes d'autorisation requis.

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

Requête API pour supprimer un nœud

Pour supprimer un nœud défectueux, exécutez la requête POST suivante. NODE_ID doit être au format CLUSTER_ID-NODEPOOL_ID-INDEX. 

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

Vérifier l'état de l'opération
Vous pouvez surveiller le résultat de l'action reportFaultyNodes en vérifiant l'état de l'opération. 

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

Action 2 : Signaler un hôte comme défectueux

Vous pouvez signaler l'hôte physique d'un nœud GPU comme défectueux si vous suspectez une défaillance matérielle.

  • VM compatibles : A3 Ultra et A4 High-GPU

  • État du nœud : le nœud cible doit être à l'état RUNNING avant d'appeler l'API. Il passera à REPAIRING en cas d'appel réussi et reviendra à RUNNING une fois l'hôte réparé ou le nœud recréé sur un nouvel hôte. Il s'agit d'une opération effectuée au mieux.

Prérequis : attribuer un rôle IAM

Pour utiliser cette fonctionnalité, vous devez attribuer le rôle Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1) à l'agent de service Vertex AI. 

  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"

Requête API pour signaler un hôte

Exécutez la requête POST suivante pour signaler l'hôte sous-jacent comme défectueux. Pour ce faire, vous devez fournir un ou plusieurs comportements observés et des descriptions pour faultReasons.
Pour le champ behavior, vous devez utiliser l'une des valeurs suivantes :

Comportement Description
PERFORMANCE Les GPU associés à la VM présentent des problèmes de performances par rapport aux autres GPU du cluster, vous ne voyez aucune erreur XID dans les journaux et Compute Engine ne détecte aucun autre schéma d'échec habituel, tel qu'une corruption silencieuse des données.
SILENT_DATA_CORRUPTION Vous constatez une corruption de données dans votre VM, mais celle-ci continue de s'exécuter. Cela peut être dû à des problèmes tels que des défauts de processeur virtuel, des bugs logiciels ou des problèmes de noyau.
UNRECOVERABLE_GPU_ERROR Vous avez identifié une erreur GPU irrécupérable avec un XID.
BEHAVIOR_UNSPECIFIED Vous ne savez pas quel est le problème avec votre VM.

Voici un exemple de requête API. 

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"}]}}]}'

Synthèse

En tirant parti à la fois des vérifications d'état automatisées et des contrôles manuels détaillés sur cette page, vous pouvez maintenir un environnement d'entraînement très résilient. La gestion proactive de l'état de votre cluster en supprimant les nœuds défectueux ou en signalant les problèmes matériels garantit une disponibilité maximale et la réussite de vos tâches d'entraînement. En cas de problèmes persistants ou complexes, pensez toujours à consulter l'équipe d'assistance Google Cloud pour obtenir des diagnostics et une assistance approfondis.

Étapes suivantes

La configuration de votre cluster d'entraînement pour la tolérance aux pannes est une étape clé dans la création d'un workflow MLOps complet et prêt pour la production.