Les clusters d'entraînement Gemini Enterprise Agent Platform intègrent un système complet de vérification de l'état pour garantir la fiabilité des nœuds de calcul et la stabilité de vos tâches Slurm. Ce système propose des options de récupération automatiques et manuelles. Un processus automatisé s'exécute pendant l'exécution de la tâche pour surveiller les composants critiques tels que l'état du GPU et l'utilisation du disque, en remplaçant automatiquement les nœuds défaillants. Dans 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éfaillant 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
À partir de Cloud Shell ou de la Google Cloud console, 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écuter 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écuter une charge de travail GPU
Enregistrez le contenu suivant dans un fichier de script nommé test.sh dans votre répertoire d'accueil.
#!/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 la tâche 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érifications d'état et récupération automatiques
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 d'état pendant le prologue Slurm (avant le début d'une tâche) et l'épilogue (après la fin d'une tâche).
Suite de vérifications d'état
- État du GPU : effectue des diagnostics détaillés et individuels du GPU, y compris la surveillance du code
nvidia-smi,dcgmietxid. - Utilisation du disque : vérifie l'utilisation élevée du disque sur les partitions critiques
(
/,/mnt/localssd,/mnt/localdisk) pour éviter que les tâches échouent par 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 s'autoréparer 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 Gemini Enterprise Agent Platform lancent automatiquement un processus de reprise après échec. Le processus standard consiste à drainer les nœuds défaillants, à remettre en file d'attente la tâche Slurm concernée, 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 la tâche Slurm concernée a déjà été redémarrée un certain nombre de fois.
Utilisation du GPU : la suppression et la recréation du nœud sont également ignorées si la tâche exécutée sur le nœud n'utilise pas tous les GPU disponibles. Dans ce cas, le nœud n'est drainé que pour empêcher la planification de nouvelles tâches.
Chaque action de récupération est enregistrée dans les journaux de votre projet en tant qu'événement de résilience. Pour représenter graphiquement ces événements par rapport à l'état Slurm de vos nœuds, consultez Surveiller les événements de résilience avec un tableau de bord.
Gérer manuellement les nœuds de calcul défaillants
Les clusters d'entraînement fournissent des API pour signaler et gérer manuellement les nœuds de calcul défaillants, ce qui est particulièrement utile si les vérifications d'é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 | Application idéale |
|---|---|---|
| Supprimer un nœud | Supprime un nœud défaillant 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 comme défaillant | Signale l'hôte physique sous-jacent comme défaillant, 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éfaillant
Cette action supprime le nœud spécifié. Le résultat de cette opération dépend du fait que le nœud est classé comme "statique" ou "dynamique" par Slurm :
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 s'il existe une charge de travail en attente planifiée pour celui-ci. Sinon, il est supprimé.
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éfaillant, exécutez la requête POST suivante. Le 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'actionreportFaultyNodes 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éfaillant
Vous pouvez signaler l'hôte physique d'un nœud GPU comme défaillant 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
RUNNINGavant d'appeler l'API. Il passera à l'étatREPAIRINGen cas d'appel réussi et reviendra à l'étatRUNNINGune fois l'hôte réparé ou le nœud recréé sur un nouvel hôte. Il s'agit d'une opération 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 plate-forme d'agent.
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éfaillant. Pour ce faire,
vous devez fournir un ou plusieurs comportements et descriptions observés pour les 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, aucune erreur XID n'est visible dans les journaux et Compute Engine ne détecte aucun autre schéma de défaillance habituel, tel que la corruption silencieuse des données. |
SILENT_DATA_CORRUPTION |
Vous constatez une corruption des données dans votre VM, mais la VM continue de s'exécuter. Cela peut être dû à des problèmes tels que des défauts de vCPU, 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 n'êtes pas sûr du problème rencontré par 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 commandes manuelles décrites sur cette page, vous pouvez maintenir un environnement d'entraînement hautement résilient. La gestion proactive de l'état de votre cluster en supprimant les nœuds défaillants 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, envisagez toujours de consulter l'équipe d'assistance Google Cloud pour obtenir des diagnostics et une assistance.
Étape suivante
La configuration de votre cluster d'entraînement pour la tolérance aux pannes est une étape clé de la création d'un workflow MLOps complet et prêt pour la production.
- Surveiller et déboguer vos tâches d'entraînement : suivez la progression, l'utilisation des ressources et l'état de vos tâches d'entraînement, y compris comment identifier quand un nœud a été récupéré ou qu'une tâche a été redémarrée en raison d'un échec.
- Orchestrer vos tâches résilientes avec Gemini Enterprise Agent Platform Pipelines : pour les environnements de production, utilisez Gemini Enterprise Agent Platform Pipelines pour créer un workflow automatisé et reproductible qui envoie vos tâches d'entraînement résilientes à votre cluster.
- Gérer et déployer votre modèle : une fois votre tâche d'entraînement résiliente terminée, utilisez Gemini Enterprise Agent Platform Model Registry pour versionner votre artefact de modèle avant de déployer le modèle sur un point de terminaison afin de traiter les requêtes d'inférence en ligne.