Surveiller les instances Compute Engine et les clusters Slurm

Ce document explique comment surveiller les instances Compute Engine A4X Max, A4X, A4, A3 Ultra ou A3 Mega que vous avez créées à l'aide de la capacité réservée. Plus précisément, ce document explique comment utiliser les tableaux de bord Cloud Monitoring pour identifier et résoudre les problèmes de performances dans vos instances de calcul autonomes ou vos clusters Slurm. Ces tableaux de bord vous aident à minimiser les temps d'arrêt et les problèmes de performances dans vos charges de travail.

Lorsque vous créez ou utilisez des tableaux de bord Monitoring prédéfinis pour surveiller des instances de calcul autonomes ou des clusters Slurm, vous pouvez surveiller les éléments suivants :

  • État des instances de calcul

  • Performances du GPU

  • Efficacité de la transmission réseau

  • Efficacité du réseau entre les blocs et les sous-blocs

  • Efficacité de la charge de travail de machine learning (ML)

  • Détection des retardataires

Avant de commencer

Avant de surveiller votre charge de travail, effectuez les étapes suivantes si vous ne l'avez pas déjà fait :

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

Limites

  • Les métriques de ce document ne sont compatibles qu'avec les charges de travail qui s'exécutent sur des instances de calcul répondant à tous les critères suivants :

    • Les instances de calcul doivent être créées en tant qu'instances Compute Engine autonomes ou dans un cluster Slurm.
    • Les instances de calcul doivent avoir été créées à l'aide de la capacité réservée.
    • Les instances de calcul doivent utiliser les séries de machines A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
      • Toutefois, la détection des retardataires est également compatible avec les instances de machine virtuelle (VM) qui utilisent la série de machines A3 Mega.

  • Pour surveiller les métriques de charge de travail de ML, vous devez configurer la surveillance de votre charge de travail.

  • Les métriques de détection des valeurs aberrantes présentent les limites supplémentaires suivantes :

    • Pour les séries de machines compatibles autres que A3 Mega, la détection des retardataires n'est compatible qu'avec les instances de calcul qui permettent à la bibliothèque Collective Communication Analyzer (CoMMA) d'exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.
    • La détection des données manquantes prend généralement jusqu'à 10 minutes.
    • Contrairement aux autres métriques de ce document, vous ne pouvez pas filtrer les métriques de détection des valeurs aberrantes pour vos projets par cluster, bloc, sous-bloc ou instance de calcul. Toutefois, vous pouvez filtrer les requêtes pour les journaux de détection des retardataires par ID d'une ou plusieurs instances de calcul suspectées d'être des retardataires.

Rôles requis

Pour obtenir les autorisations nécessaires pour surveiller les métriques des charges de travail AI Hypercomputer, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Pour afficher les métriques dans Cloud Monitoring : Éditeur Monitoring (roles/monitoring.editor) sur le projet
  • Pour afficher les journaux de détection des retardataires dans Logging : Lecteur de journaux (roles/logging.viewer) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour surveiller les métriques des charges de travail AI Hypercomputer. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour surveiller les métriques des charges de travail AI Hypercomputer :

  • Pour afficher les tableaux de bord : monitoring.dashboards.get sur le projet
  • Pour créer des tableaux de bord : monitoring.dashboards.create sur le projet
  • Pour afficher les entrées de journal : logging.logEntries.list sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Métriques disponibles

Selon votre cas d'utilisation, les métriques suivantes sont disponibles pour surveiller vos instances de calcul et vos clusters Slurm :

Pour savoir comment afficher ces métriques, consultez Visualiser les métriques dans ce document.

Métriques d'infrastructure

Pour surveiller l'état, les performances et les performances réseau des GPU associés à vos instances de calcul, vous pouvez utiliser les métriques suivantes :

Pour obtenir un aperçu des métriques disponibles dans Compute Engine, consultez MétriquesGoogle Cloud .

Métriques sur l'état du GPU

Pour surveiller l'état de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
État de la machine machine/machine_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si la machine utilisée par l'instance de calcul est opérationnelle ou non et si elle nécessite une réparation.
État de NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si un commutateur NVLink sur un GPU NVIDIA associé à une instance de calcul rencontre des problèmes.
État de l'infrastructure des VM instance/gpu/infra_health A4X, A4, A3 Ultra ou A3 Mega L'état du cluster, du bloc, du sous-bloc et de l'hôte sur lesquels vos instances de calcul sont exécutées. Si cette métrique indique que l'infrastructure d'une instance de calcul n'est pas opérationnelle, elle décrit également le problème.
Score de prédiction des défaillances de VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra ou A3 Mega Probabilité que l'hôte sur lequel l'instance de calcul s'exécute se dégrade dans les cinq prochaines heures. Cette valeur peut être comprise entre 0.0 et 1.0. Plus la valeur reste proche de 1.0 pendant une période donnée, plus il est probable que l'instance de calcul se dégrade. Dans ce cas, nous vous recommandons de déplacer le job vers une autre instance de calcul et, si vous rencontrez des problèmes avec l'instance de calcul, de signaler son hôte comme défectueux.

Métriques de performances du GPU

Pour surveiller les performances de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Utilisation du contexte cumulée instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra ou A3 Mega Durée totale, en secondes, pendant laquelle le GPU est occupé à traiter une charge de travail.
Consommation électrique du GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra ou A3 Mega Puissance en watts (W) et en valeurs décimales consommée par les GPU individuels de l'hôte. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la consommation d'énergie séparément pour chaque GPU de l'hôte.
Utilisation du multiprocesseur de flux instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra ou A3 Mega Une valeur non nulle indique que les multiprocesseurs de flux (SM) de vos GPU sont activement utilisés.
Vitesse de GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra ou A3 Mega Température en degrés Celsius (℃) et en valeurs décimales des GPU individuels de l'hôte. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la température de chaque GPU de l'hôte séparément.
Marge thermique du GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra ou A3 Mega Marge thermique en degrés Celsius (℃) et en valeurs décimales dont disposent les GPU individuels avant de devoir ralentir en raison d'une température élevée. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la marge thermique séparément pour chaque GPU de l'hôte.

Métriques sur les performances réseau des GPU

Pour surveiller les performances réseau de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Modifications des liens vers les opérateurs instance/gpu/link_carrier_changes A4X, A4, A3 Ultra ou A3 Mega Fréquence à laquelle le support de liaison réseau change en une minute.
RTT du réseau instance/gpu/network_rtt A4X, A4, A3 Ultra ou A3 Mega Temps aller-retour, mesuré en microsecondes, nécessaire aux données réseau pour transiter entre une source et une destination.
Trafic réseau au niveau des blocs instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les blocs.
Trafic réseau au niveau des sous-blocs instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les sous-blocs.
Trafic réseau au niveau des sous-blocs instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau dans un sous-bloc unique.
Vitesse active NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra ou A3 Mega Vitesse actuelle du port du lien d'accès, en Gbit/s.
Débit (octets reçus) instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets reçus du trafic réseau.
Débit (octets TX) instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets transmis au trafic réseau.

Métriques sur les erreurs fatales du GPU

Pour surveiller les erreurs rencontrées par vos GPU et qui peuvent forcer l'arrêt de vos instances de calcul ou avoir un impact négatif sur leurs performances, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Erreur d'exécution NVLink instance/gpu/nvlink_runtime_error A4X Max ou A4X Indique si une erreur d'exécution NVLink s'est produite.
Erreurs ECC DRAM non corrigibles instance/gpu/dram_uncorrectable_ecc_error_count A4X Max ou A4X Nombre de codes de correction d'erreurs (ECC) non corrigibles dans une mémoire vive dynamique (DRAM) de GPU.
Nombre de remappages de lignes DRAM non corrigibles instance/gpu/dram_uncorrectable_row_remapping_count A4X Max ou A4X Nombre de remappages de lignes à partir d'erreurs non corrigibles dans les DRAM GPU.
Échec du remappage de la ligne DRAM non corrigible instance/gpu/dram_row_remapping_failed A4X Max ou A4X Indique si le remappage d'une ligne dans les DRAM de GPU a échoué en raison de l'un des problèmes suivants :
  • Une tentative de remappage sur une banque de mémoire a échoué, car la banque de mémoire comporte déjà huit lignes d'erreurs non corrigibles remappées.
  • Une tentative de remappage d'une ligne a échoué, car la ligne avait déjà été remappée.
  • Une tentative de remappage a échoué, car 512 remappages au total ont eu lieu.
Erreurs PCIe non corrigibles instance/gpu/pcie_fatal_error_count A4X Max ou A4X Nombre d'erreurs PCIe (Peripheral Component Interconnect Express) non corrigibles.
Erreurs ECC de cache non corrigibles instance/gpu/cache_uncorrectable_ecc_error_count A4X Max ou A4X Nombre d'erreurs ECC non corrigibles dans la mémoire cache.

Métriques de charge de travail de ML

Pour surveiller la productivité (plus précisément le débit utile) de vos charges de travail de ML, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Temps productif workload/goodput_time A4X, A4, A3 Ultra ou A3 Mega Temps (en secondes) que la charge de travail consacre aux activités de débit utile. Il s'agit de tâches utiles et essentielles, comme un passage en avant ou en arrière lors de l'entraînement du modèle.
Temps non productif workload/badput_time A4X, A4, A3 Ultra ou A3 Mega Temps (en secondes) que la charge de travail consacre aux activités de débit incorrect. Ces activités sont des tâches générales, comme le chargement ou le prétraitement des données pour l'entraînement.

Métriques de détection des retardataires

Les métriques de détection des retardataires vous aident à identifier et à localiser les retardataires potentiels. Les retardataires sont des défaillances ponctuelles qui ne provoquent pas de plantage, mais qui finissent par ralentir l'ensemble de la charge de travail.

Pour surveiller la détection des tâches retardataires pour vos VM, utilisez la métrique suivante :

Nom Type de métrique Séries de machines compatibles Description
Retardataires potentiels instance/gpu/straggler_status A4X, A4, A3 Ultra ou A3 Mega Indique si une VM est suspectée d'être une VM lente qui affecte les performances de la charge de travail. Nous vous recommandons de n'agir sur les retardataires présumés que lorsque d'autres métriques indiquent que la charge de travail rencontre des problèmes.

Vous pouvez également afficher les métriques de détection des retardataires dans les entrées de journal d'une instance A4X, A4, A3 Ultra ou A3 Mega. Par exemple, vous pouvez utiliser les requêtes suivantes :

Description Requête
Journaux avec des retardataires suspects pour des VM spécifiques. Utilisez cette requête pour vérifier s'il existe des tâches lentes suspectes pour une charge de travail spécifique de votre projet. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Remplacez INSTANCE_ID par l'ID d'une VM. Pour chaque VM supplémentaire que vous souhaitez spécifier, ajoutez la condition suivante à la requête :

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Tous les journaux de détection des retardataires pour votre projet. Utilisez cette requête pour vérifier si le service de détection des retardataires est en cours d'exécution lorsqu'aucun retardataire suspect n'est détecté. (En raison des limites, vous ne pouvez pas filtrer les journaux sans retardataires suspects par VM spécifique.) 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Les métriques de détection des tâches retardataires sont particulièrement utiles pour les charges de travail de ML à grande échelle pour les raisons suivantes :

  • Les charges de travail de ML à grande échelle sont très sensibles aux tâches lentes. Les charges de travail de ML à grande échelle utilisent le calcul synchrone et massivement distribué. (En d'autres termes, ils comportent de nombreux composants très interdépendants qui s'exécutent simultanément.) Cette architecture rend les charges de travail de ML à grande échelle très sensibles aux points de défaillance uniques, comme les retardataires.

  • Il est très difficile de repérer et d'identifier les retardataires dans les charges de travail de ML à grande échelle. Pour référence, sachez qu'il existe deux types de points de défaillance uniques :

    • Défaillances d'arrêt : défaillances qui entraînent l'arrêt de l'ensemble du système (par exemple, erreurs d'hôte et événements de maintenance). Elles sont relativement simples à détecter et à résoudre.

    • Échecs lents : échecs qui entraînent une dégradation importante des performances sans plantages. Ils sont très difficiles à identifier et à déboguer.

    En raison de leur nature à échec lent, les retardataires sont intrinsèquement difficiles à remarquer et à identifier, en particulier dans les charges de travail synchrones à grande échelle.

Afficher les métriques

Pour afficher les métriques de vos instances de calcul et de vos clusters Slurm, utilisez les tableaux de bord Monitoring comme suit :

Si vous rencontrez des problèmes lorsque vous utilisez un tableau de bord, consultez Résoudre les problèmes de performances lentes.

Utiliser des tableaux de bord prédéfinis

Vous pouvez utiliser les tableaux de bord Monitoring prédéfinis pour AI Hypercomputer afin d'afficher les métriques de vos instances de calcul et de vos clusters Slurm. Vous pouvez également créer une copie d'un tableau de bord prédéfini et le modifier pour l'adapter à vos besoins.

Pour utiliser un tableau de bord prédéfini pour AI Hypercomputer :

  1. Dans la console Google Cloud , accédez à la page  Tableaux de bord :

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Dans la colonne Nom, cliquez sur le nom de l'un des tableaux de bord suivants en fonction des métriques que vous souhaitez afficher :

    • Pour surveiller l'état des instances de calcul, les performances des GPU et la détection des tâches lentes, utilisez le tableau de bord Surveillance de l'état de Cluster Director.

      Pour savoir comment utiliser ces métriques afin d'identifier et d'analyser les problèmes, utilisez également le tableau de bord du playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

    • Pour surveiller l'efficacité de la transmission réseau, utilisez le tableau de bord Efficacité de la transmission Cluster Director.

    • Pour surveiller l'efficacité du réseau entre les blocs et les sous-blocs, utilisez le tableau de bord Réseau de blocs Cluster Director.

      Pour savoir comment utiliser ces métriques afin d'identifier et d'analyser les problèmes, utilisez également le tableau de bord du playbook Playbook interactif GCE : blocage du réseau Cluster Director.

    La page d'informations du tableau de bord de votre choix s'ouvre. Vous pouvez utiliser le sélecteur de période dans la barre d'outils pour modifier la période des données.

  3. Facultatif : Pour créer une copie d'un tableau de bord et le personnaliser selon vos besoins, cliquez sur Copier le tableau de bord.

Créer des tableaux de bord personnalisés

Pour créer un tableau de bord Monitoring personnalisé :

  1. Choisissez les métriques à surveiller. Si ce n'est pas déjà fait, consultez la section Métriques disponibles de ce document.

  2. Créez et gérez des tableaux de bord personnalisés.

Afficher les journaux de détection des retardataires

Pour afficher les journaux de détection des tâches lentes à l'aide de l'explorateur de journaux, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la pageExplorateur de journaux :

    Accéder à l'explorateur de journaux

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

    Par défaut, la page interroge tous les journaux de votre projet. Cliquez sur Arrêter la requête.

  2. Utilisez le sélecteur de période dans la barre d'outils pour sélectionner la période que vous souhaitez analyser.

  3. Dans le volet Requête, saisissez une requête pour les journaux de détection des valeurs aberrantes.

  4. Cliquez sur Exécuter la requête.

Voici un exemple d'entrée de journal de détection de retardataires.

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }

Cette entrée de journal comprend les champs suivants :

  • numNodes : nombre d'instances de calcul suspectées d'être des retardataires détectées dans le projet. Dans l'exemple, quatre instances de calcul suspectes ont été détectées.
  • instanceId : ID d'une instance de calcul détectée comme un potentiel retardataire.

Étapes suivantes