Surveiller les instances Compute Engine et les clusters Slurm

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

En créant des tableaux de bord personnalisés ou en utilisant des tableaux de bord Monitoring prédéfinis, vous pouvez surveiller les éléments suivants :

  • État d'une instance de calcul

  • Performances du GPU

  • Efficacité de la transmission réseau

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

  • Efficacité des charges de travail de machine learning (ML)

  • Détection des retardataires

  • Détection des charges de travail non réactives

Pour surveiller les clusters Cluster Director, consultez Surveiller les performances des clusters avec des tableaux de bord prédéfinis.

Avant de commencer

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

Lorsque vous utilisez la console Google Cloud pour accéder aux services Google Cloud et aux API, vous n'avez pas besoin de configurer l'authentification.

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.

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

Limites de la détection des retardataires

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 retardataires 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 retardataires 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 retardataires.

Limites de la détection des charges de travail non réactives

Les métriques de détection des charges de travail non réactives ne sont compatibles qu'avec les instances de calcul qui utilisent la bibliothèque Collective Communication Analyzer (CoMMA) pour exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.

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 de l'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 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 de 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é 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 d'énergie 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
Lier les modifications de l'opérateur 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 Délai 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 du port du lien d'accès actuel, 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 transmis) 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'erreur (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 calcul au plus tôt ou au plus tard 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 badput. 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 consulter 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 si des tâches lentes sont suspectées 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 de défaillance lente, les retardataires sont intrinsèquement difficiles à remarquer et à identifier, en particulier dans les charges de travail synchrones à grande échelle.

Métriques de détection des charges de travail qui ne répondent pas

Les métriques de détection des charges de travail non réactives vous aident à effectuer les opérations suivantes :

  • Remarquez quand une charge de travail entière est bloquée (parfois appelée blocage NCCL).
  • Comprendre pourquoi la charge de travail est bloquée, par exemple si cela est dû à un plantage de processus ou à un réseau bloqué

Pour détecter et diagnostiquer les charges de travail qui ne répondent pas pour vos instances de calcul, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Événements de charge de travail non réactifs détectés à l'aide de la télémétrie NCCL instance/gpu/nccl_hang A4X Max, A4X, A4 et A3 Ultra Nombre d'événements de charge de travail non réactive détectés, sous forme de série temporelle.

Activer la détection des charges de travail qui ne répondent pas

Pour activer la détection des charges de travail qui ne répondent pas, vous devez activer CoMMA avec la télémétrie heartbeat, un signal ping périodique qui indique qu'une charge de travail est en cours d'exécution. Pour les versions récentes de CoMMA, cette option est activée par défaut. Toutefois, si vous utilisez la version de CoMMA à partir de la version 1.1.1 du bundle NICCL/gIB, vous devez activer manuellement la télémétrie heartbeat. Pour vérifier la version du bundle NICCL/gIB que vous utilisez, consultez Vérifier la version de NCCL et gIB.

Pour activer manuellement la télémétrie heartbeat pour CoMMA, spécifiez les variables d'environnement suivantes dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Utilisez NCCL_PROFILER_HEARTBEAT pour activer ou désactiver la télémétrie de fréquence cardiaque, et NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL pour spécifier la fréquence de la télémétrie de fréquence cardiaque. Pour en savoir plus, consultez Variables d'environnement CoMMA.

Désactiver la détection des charges de travail qui ne répondent pas

Pour désactiver la détection des charges de travail qui ne répondent pas, désactivez la télémétrie heartbeat dans CoMMA en spécifiant la variable d'environnement suivante dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=false

Comprendre pourquoi les charges de travail ne répondent pas

Pour comprendre pourquoi une charge de travail ne répond pas, vérifiez la valeur du libellé hang_reason en procédant comme suit :

  1. Dans la console Google Cloud , accédez à la page  Explorateur de métriques.

    Accéder à l'Explorateur de métriques

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

  2. Recherchez la métrique suivante :

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Utilisez la fonctionnalité Agrégation et sélectionnez les libellés suivants :

    • instance_id
    • hang_reason

Le tableau suivant liste les valeurs possibles pour le libellé, ce qu'elles signifient concernant vos charges de travail et les prochaines étapes recommandées.

Valeur de l'étiquette Description Procédure recommandée
MissingHeartbeatIssue La télémétrie Heartbeat s'est arrêtée pour un ou plusieurs rangs, ce qui indique généralement un plantage fatal du processus ou du nœud.
  • Vérifiez si l'instance est toujours accessible.
  • Vérifiez si les processus de charge de travail ont planté.
  • Recherchez les événements de mémoire insuffisante (OOM), tels que dmesg, dans les journaux système.
  • Recherchez les défaillances matérielles ou les erreurs NVIDIA XID.
StalledRankIssue Les données de télémétrie Heartbeat sont toujours reçues, mais les rangs ne progressent pas sur les opérations NCCL.
  • Examinez les éventuels blocages dans les opérations au niveau de l'application.
  • Vérifiez si le processus d'application est bloqué dans une opération qui l'empêche de communiquer avec d'autres, comme le calcul ou le point de contrôle.
MissingCommunicatorIssue Tous les rangs appartenant à un communicateur NCCL ont cessé de progresser.
  • Votre charge de travail a peut-être été interrompue ou ses communicateurs NCCL ont peut-être été fermés de manière inattendue. Si vous vous attendez à ce qu'une charge de travail s'exécute sans interruption sur cette instance de VM, vérifiez si elle a été interrompue ou arrêtée de manière anormale.
NoHangIssue Valeur par défaut. Aucun problème n'a été détecté.
  • Aucune action n'est requise.

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 retardataires, 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 tâches lentes

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 données tardives.

  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",
    ...
  }

L'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 retardataire potentiel.

Étapes suivantes