Configurer la vérification d'état et l'autoréparation

Les groupes d'instances gérés (MIG) maintiennent la haute disponibilité de vos applications en s'assurant de manière proactive que vos instances de machine virtuelle (VM) restent disponibles, c'est-à-dire dotées de l'état RUNNING. Si une instance s'arrête et perd l'état RUNNING, mais que ce changement d'état n'a pas été initié par le MIG (par exemple, en raison d'une défaillance matérielle plutôt qu'en réponse à la décision d'un autoscaler), le MIG recrée automatiquement cette instance. Toutefois, il peut s'avérer insuffisant de se baser sur l'état d'une instance pour déterminer celui de l'application. Par exemple, le fait de vérifier si l'état d'une instance est défini sur RUNNING ne permet pas de détecter les défaillances d'application, tels que le gel, la surcharge ou le plantage.

Pour améliorer la disponibilité de votre application et vérifier qu'elle répond, vous pouvez configurer une règle d'autoréparation pour votre groupe d'instances géré (MIG).

Une règle d'autoréparation repose sur une vérification de l'état basée sur l'application pour vérifier qu'une application répond comme prévu. Vérifier qu'une application répond est une méthode plus précise que de simplement vérifier si une instance se trouve à l'état RUNNING.

Si l'autoréparation détermine qu'une application ne répond pas, le groupe d'instances géré recrée automatiquement cette instance. Dans le cas d'une instance préemptive, le groupe recrée l'instance lorsque les ressources nécessaires sont à nouveau disponibles.

Comportement de l'autoréparation

L'autoréparation recrée les instances non opérationnelles à l'aide du modèle d'instance utilisé à l'origine pour créer l'instance de VM (il ne s'agit pas nécessairement du modèle d'instance actuel dans le groupe d'instances géré). Par exemple, si une instance de VM a été créée à l'aide du modèle instance-template-a et que vous mettez ensuite à jour le groupe d'instances géré de façon à ce qu'il utilise le modèle instance-template-b en mode OPPORTUNISTIC, l'autoréparation recréera quand même l'instance avec instance-template-a. En effet, comme les recréations liées à l'autoréparation ne sont pas initiées par l'utilisateur, Compute Engine ne suppose pas que l'instance de VM doit utiliser le nouveau modèle. Si vous souhaitez appliquer un nouveau modèle, consultez la section Modifier le modèle d'instance d'un groupe d'instances géré.

Le nombre d'instances faisant simultanément l'objet d'une autoréparation est toujours inférieur à la taille du groupe d'instances géré. Cela garantit que le groupe continue à exécuter un sous-ensemble d'instances même si, par exemple, la règle d'autoréparation ne correspond pas à la charge de travail, si les règles de pare-feu sont mal configurées, ou si une instance opérationnelle est identifiée comme étant non opérationnelle en raison de problèmes de connectivité réseau ou d'infrastructure. Toutefois, si un groupe d'instances géré zonal ne comporte qu'une seule instance ou si un groupe d'instances géré régional ne compte qu'une seule instance par zone, l'autoréparation recréera ces instances si elles ne sont plus opérationnelles.

L'autoréparation ne recrée pas une instance au cours de la période d'initialisation de celle-ci. Pour plus d'informations, consultez la propriété autoHealingPolicies[].initialDelaySec. Cela permet de retarder la vérification et l'éventuelle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance est défini sur VERIFYING.

Autoréparation et disques

Lors de la recréation d'une instance à partir de son modèle, le processus d'autoréparation traite les divers types de disques différemment. En cas de tentative de recréation d'une instance gérée, certaines configurations de disque peuvent entraîner l'échec de l'autoréparation.

Type de disque autodelete Comportement lors d'une opération d'autoréparation
Nouveau disque persistant true Le disque est recréé comme spécifié dans le modèle de l'instance. Toutes les données écrites sur ce disque sont perdues lorsque le disque et son instance sont recréés.
Nouveau disque persistant false Le disque est conservé et réassocié lorsque le processus d'autoréparation recrée l'instance.
Disque persistant existant true L'ancien disque est supprimé. La recréation d'instances de VM échoue, car Compute Engine ne peut pas réassocier un disque supprimé à l'instance.
Disque persistant existant false L'ancien disque est réassocié comme spécifié dans le modèle de l'instance. Les données figurant sur le disque sont conservées. Toutefois, pour les disques en lecture-écriture existants, un groupe d'instances géré ne peut contenir qu'une seule VM, car un même disque persistant ne peut pas être associé à plusieurs instances en mode lecture-écriture.
Nouveau disque SSD local ND Le disque est recréé comme spécifié dans le modèle de l'instance. Les données figurant sur un disque SSD local sont perdues en cas de recréation ou de suppression d'une instance.

Le processus d'autoréparation ne réassocie pas les disques qui ne sont pas spécifiés dans le modèle de l'instance, tels que les disques que vous avez associés manuellement à une VM après sa création.

Pour conserver les données importantes écrites sur le disque, vous devez prendre des précautions, par exemple :

  • Prendre des instantanés réguliers des disques persistants.

  • Exporter des données vers une autre source, telle que Cloud Storage.

Si vos instances comportent des paramètres importants que vous souhaitez conserver, Google recommande également d'utiliser une image personnalisée dans votre modèle d'instance. Une image personnalisée contient tous les paramètres personnalisés dont vous avez besoin. Lorsque vous spécifiez une image personnalisée dans votre modèle d'instance, le groupe d'instances géré recrée les instances à l'aide de l'image personnalisée qui contient les paramètres personnalisés dont vous avez besoin.

Configurer une vérification d'état et une règle d'autoréparation

Vous pouvez configurer au maximum une règle d'autoréparation par groupe d'instances géré.

Vous pouvez appliquer une même vérification d'état à un maximum de 50 groupes d'instances gérés. Si vous avez plus de 50 groupes, créez plusieurs vérifications d'état.

Exemple de configuration d'une vérification d'état

L'exemple suivant montre comment utiliser une vérification d'état sur un groupe d'instances géré. Dans cet exemple, vous créez une vérification d'état qui s'attend à une réponse du serveur Web sur le port 80. Pour permettre aux vérifications d'état d'atteindre chaque serveur Web, vous configurez une règle de pare-feu. Enfin, vous appliquez la vérification d'état au groupe d'instances géré en définissant la règle d'autoréparation du groupe.

Console

  1. Créez une vérification de l'état pour l'autoréparation plus conservatrice que les vérifications de l'état destinées aux équilibreurs de charge.

    Par exemple, créez une vérification d'état qui recherche une réponse sur le port 80 et dispose d'une marge d'erreur avant de marquer des instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.

    1. Dans Google Cloud Console, accédez à la page Créer une vérification d'état.

      Accéder à la page Créer une vérification d'état

    2. Donnez un nom à la vérification d'état (example-check, par exemple).
    3. Vérifiez que l'option HTTP est bien sélectionnée comme Protocole.
    4. Dans la section Port, saisissez 80.
    5. Dans la section Intervalle entre deux tests, saisissez 5.
    6. Dans la section Délai avant expiration, saisissez 5.
    7. Définissez un Seuil sanitaire pour déterminer combien de vérifications d'état consécutives réussies doivent s'afficher avant qu'une instance défaillante soit marquée comme opérationnelle. Saisissez 1 pour cet exemple.
    8. Définissez un Seuil non sanitaire pour déterminer combien de vérifications d'état consécutives non réussies doivent s'afficher avant qu'une instance opérationnelle soit marquée comme non opérationnelle. Saisissez 3 pour cet exemple.
    9. Cliquez sur Créer pour créer la vérification d'état.
  2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

    Les tests de vérification d'état proviennent des adresses des plages 130.211.0.0/22 et 35.191.0.0/16. Assurez-vous donc que les règles de pare-feu de votre réseau autorisent la vérification d'état à se connecter. Dans cet exemple, le groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.

    1. Dans Google Cloud Console, accédez à la page Créer une règle de pare-feu.

      Accéder à la page Créer une règle de pare-feu

    2. Dans le champ Nom, définissez un nom pour la règle de pare-feu (par exemple, allow-health-check).
    3. Pour Réseau, sélectionnez le réseau default.
    4. Pour Filtre source, sélectionnez IP ranges.
    5. Pour Plages d'adresses IP sources, saisissez 130.211.0.0/22 et 35.191.0.0/16.
    6. Sous Protocoles et ports, sélectionnez Protocoles et ports spécifiés , puis saisissez tcp:80.
    7. Cliquez sur Create (Créer).
  3. Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.

    1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

      Accéder à la page Groupes d'instances

    2. Dans la colonne Nom de la liste, cliquez sur le nom du groupe d'instances auquel vous souhaitez appliquer la vérification d'état.
    3. Cliquez sur Modifier le groupe pour modifier le groupe d'instances géré.
    4. Dans la section Autoréparation, sélectionnez la vérification d'état que vous avez créée précédemment.
    5. Modifiez ou conservez le paramètre Délai initial. Il permet de retarder l'autoréparation et la potentielle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance est défini sur VERIFYING.
    6. Cliquez sur Enregistrer pour appliquer les modifications.

    L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

gcloud

Pour utiliser les exemples de ligne de commande de ce guide, installez l'outil de ligne de commande gcloud ou utilisez Cloud Shell.

  1. Créez une vérification de l'état pour l'autoréparation plus conservatrice que les vérifications de l'état destinées aux équilibreurs de charge.

    Par exemple, créez une vérification d'état qui recherche une réponse sur le port 80 et dispose d'une marge d'erreur avant de marquer des instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.

    gcloud compute health-checks create http example-check --port 80 \
           --check-interval 30s \
           --healthy-threshold 1 \
           --timeout 10s \
           --unhealthy-threshold 3
  2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

    Les tests de vérification d'état proviennent des adresses des plages 130.211.0.0/22 et 35.191.0.0/16. Assurez-vous donc que vos règles de pare-feu autorisent la vérification d'état à se connecter. Dans cet exemple, notre groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.

    gcloud compute firewall-rules create allow-health-check \
            --allow tcp:80 \
            --source-ranges 130.211.0.0/22,35.191.0.0/16 \
            --network default
  3. Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.

    Pour appliquer la vérification d'état au groupe d'instances géré, exécutez la commande update.

    Le paramètre initial-delay permet de retarder l'autoréparation et la potentielle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance est défini sur VERIFYING.

    Exemple :

    gcloud compute instance-groups managed update my-mig \
            --health-check example-check \
            --initial-delay 300 \
            --zone us-east1-b

    L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

API

Pour utiliser les exemples d'API de ce guide, configurez l'accès aux API.

  1. Créez une vérification de l'état pour l'autoréparation plus conservatrice que les vérifications de l'état destinées aux équilibreurs de charge.

    Par exemple, créez une vérification d'état qui recherche une réponse sur le port 80 et dispose d'une marge d'erreur avant de marquer des instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.

    POST https://compute.googleapis.com/compute/v1/projects/project-id/global/healthChecks
    
    {
     "name": "example-check",
     "type": "http",
     "port": 80,
     "checkIntervalSec": 30,
     "healthyThreshold": 1,
     "timeoutSec": 10,
     "unhealthyThreshold": 3
    }
    
  2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

    Les tests de vérification d'état proviennent des adresses des plages 130.211.0.0/22 et 35.191.0.0/16. Assurez-vous donc que vos règles de pare-feu autorisent la vérification d'état à se connecter. Dans cet exemple, notre groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
     "sourceRanges": [
      "130.211.0.0/22",
      "35.191.0.0/16"
     ],
     "allowed": [
      {
       "ports": [
        "80"
       ],
       "IPProtocol": "tcp"
      }
     ]
    }
    
  3. Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.

    Une règle d'autoréparation fait partie d'une ressource instanceGroupManager ou d'une ressource regionInstanceGroupManager.

    Vous pouvez définir une règle d'autoréparation à l'aide des méthodes insert ou patch.

    L'exemple suivant définit une règle d'autoréparation à l'aide de la méthode instanceGroupManagers.patch.

    PATCH https://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    Le paramètre initialDelaySec permet de retarder l'autoréparation et la potentielle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance est défini sur VERIFYING.

    L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

    Pour désactiver l'autoréparation basée sur l'application, définissez la règle d'autoréparation sur une valeur vide (autoHealingPolicies[]). Avec autoHealingPolicies[], le groupe d'instances géré ne recrée que les instances qui ne possèdent pas l'état RUNNING.

    Vous pouvez obtenir la règle d'autoréparation d'un groupe d'instances géré en lisant le champ instanceGroupManagers.autoHealingPolicies. Vous pouvez obtenir une ressource de groupe d'instances géré à l'aide de l'une des méthodes suivantes :

Vérifier l'état

Vous pouvez vérifier qu'une instance est créée et que son application répond en inspectant l'état actuel de chaque instance, en vérifiant l'action en cours sur chaque instance ou en vérifiant l'état du groupe.

Lorsque vous associez une vérification d'état à un groupe d'instances géré pour la première fois, le déclenchement de la surveillance peut prendre jusqu'à 15 minutes.

Vérifier si les instances sont opérationnelles

Si vous avez configuré l'autoréparation sur votre groupe d'instances géré, vous pouvez examiner l'état de chaque instance.

Inspectez les états de vos instances gérées pour effectuer les opérations suivantes :

  • Identifier les VM non opérationnelles qui ne font pas l'objet d'une autoréparation. Dans les situations suivantes, il est possible qu'une instance de VM ne soit pas réparée immédiatement, même si elle a été diagnostiquée comme étant non opérationnelle :
    • La VM est toujours en cours de démarrage et son délai initial n'a pas été dépassé.
    • Une partie importante des instances non opérationnelles est en cours d'autoréparation. Le processus d'autoréparation retarde davantage l'opération afin de s'assurer que le groupe continue d'exécuter un sous-ensemble d'instances.
  • Détectez des erreurs de configuration de la vérification d'état. Par exemple, vous pouvez détecter des règles de pare-feu mal configurées ou un point de terminaison de la vérification d'état de l'application non valide si l'état de l'instance est défini sur TIMEOUT.
  • Pour déterminer le délai initial à configurer, mesurez la durée entre la transition de la VM vers l'état RUNNING et la transition de la VM vers l'état HEALTHY. Vous pouvez mesurer cet écart en interrogeant la méthode list-instances.

Utilisez la console, l'outil de ligne de commande gcloud ou l'API pour afficher les états.

Console

  1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Dans la colonne Nom de la liste, cliquez sur le nom du groupe d'instances que vous souhaitez examiner. La page qui s'ouvre affiche les propriétés du groupe ainsi que la liste des instances qui en font partie.

  3. Lorsqu'une instance n'est pas opérationnelle, son état s'affiche dans la colonne Problèmes concernant l'état.

gcloud

Utilisez la sous-commande list-instances.

gcloud beta compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

La colonne HEALTH_STATE indique l'état de chaque instance.

API

Pour un groupe d'instances géré régional, envoyez une requête POST à la méthode listManagedInstances :

POST https://compute.googleapis.com/compute/beta/projects/project-id/regions/region/instanceGroupManagers/instance-group/listManagedInstances

Pour un groupe d'instances géré zonal, utilisez la méthode listManagedInstances qui lui est associée :

POST https://compute.googleapis.com/compute/beta/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances

La requête renvoie une réponse semblable à la suivante, qui inclut un champ instanceHealth pour chaque instance gérée.

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

États

Les états d'instance suivants sont disponibles :

  • HEALTHY : l'instance est accessible, une connexion au point de terminaison de la vérification d'état de l'application peut être établie et la réponse est conforme aux exigences définies par la vérification d'état.
  • DRAINING : l'instance est en cours de drainage. Les connexions à l'instance existantes ont abouti, mais les nouvelles connexions sont refusées.
  • UNHEALTHY : l'instance est accessible, mais elle ne respecte pas les exigences définies par la vérification d'état.
  • TIMEOUT : l'instance est inaccessible. Il est impossible d'établir une connexion avec le point de terminaison de la vérification d'état de l'application ou le serveur d'une instance de VM ne répond pas dans le délai imparti. Cette réponse peut être due, par exemple, à des règles de pare-feu mal configurées ou à une surcharge de l'application de serveur sur une instance de VM.
  • UNKNOWN : le système de vérification d'état n'a pas connaissance de l'instance ou l'état de celle-ci n'est pas connu pour le moment. Monitoring peut mettre 15 minutes avant de commencer à surveiller les nouvelles instances d'un MIG.

Les nouvelles instances renverront l'état UNHEALTHY jusqu'à ce qu'elles soient validées par le système de vérification d'état.

Le processus de réparation d'une instance dépend de son état :

  • Lorsqu'une instance possède l'état UNHEALTHY ou TIMEOUT, et que sa période d'initialisation a expiré, le service d'autoréparation tente immédiatement de la réparer.
  • Lorsqu'une instance possède l'état UNKNOWN, elle ne sera pas immédiatement réparée. Cela permet d'éviter la réparation inutile d'une instance pour laquelle le signal de vérification d'état est momentanément indisponible.

Les tentatives d'autoréparation peuvent être retardées dans les situations suivantes :

  • Une instance n'est toujours pas opérationnelle après plusieurs réparations consécutives.
  • Il existe une partie importante d'instances non opérationnelles dans le groupe.

Nous souhaitons en savoir plus sur vos cas d'utilisation, les défis que vous rencontrez ou vos impressions sur les valeurs d'état des instances de VM. Nous vous invitons à nous faire part de vos commentaires à l'adresse suivante : mig-discuss@google.com.

Afficher les actions en cours sur les instances

Lorsqu'une instance gérée est en cours de création, le champ currentAction est défini sur CREATING. Si une règle d'autoréparation est associée, une fois que l'instance gérée est créée et en cours d'exécution, le champ currentAction de l'instance bascule sur VERIFYING, et le vérificateur d'état commence à contrôler l'application de l'instance. Si cette vérification d'état initiale est concluante dans le délai requis pour le démarrage de l'application, l'instance est vérifiée, et le champ currentAction bascule sur NONE.

Vous pouvez voir l'action en cours d'exécution (currentAction) et consulter l'état (status) de chaque instance d'un groupe d'instances géré à l'aide de l'outil de ligne de commande gcloud ou de l'API.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud renvoie une liste des instances présentes dans le groupe, avec leurs états et actions en cours. Exemple :

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

Dans l'API, envoyez une requête GET à la méthode regionInstanceGroupManagers.listManagedInstances. Pour un groupe d'instances géré zonal, utilisez la méthode instanceGroupManagers.listManagedInstances.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

L'API renvoie une liste des instances présentes dans le groupe, y compris les champs instanceStatus et currentAction de chaque instance.

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  }
 ]
}

Vous pouvez consulter l'état de chaque instance d'un groupe d'instances géré à l'aide du champ instanceStatus. Pour afficher la liste des valeurs valides du champ instanceStatus, reportez-vous à la section Consulter l'état d'une instance.

Si l'instance subit une quelconque modification, l'une des actions suivantes est insérée dans le champ currentAction pour vous aider à suivre l'évolution de cette modification. Dans le cas contraire, le champ currentAction est défini sur NONE.

Les valeurs possibles du champ currentAction sont les suivantes :

  • ABANDONING : l'instance est en cours de suppression du groupe d'instances géré.
  • CREATING : l'instance est en cours de création.
  • CREATING_WITHOUT_RETRIES : l'instance est en cours de création sans nouvelle tentative. Si l'instance n'est pas créée lors de la première tentative, le groupe d'instances géré n'essaie pas de remplacer à nouveau l'instance.
  • DELETING : l'instance est en cours de suppression.
  • RECREATING : l'instance est en cours de remplacement.
  • REFRESHING : l'instance est supprimée de ses pools cibles actuels et rajoutée dans la liste des pools cibles actuels (cette liste peut être identique ou différente des pools cibles existants).
  • RESTARTING : l'instance est en cours de redémarrage à l'aide des méthodes stop et start.
  • VERIFYING : l'instance a été créée et est en cours de vérification.
  • NONE : aucune action n'est effectuée sur l'instance.

Vérifier si un groupe d'instance géré est stable

Au niveau du groupe, Compute Engine insère un champ en lecture seule appelé status qui comprend un indicateur isStable.

Si toutes les instances du groupe sont en cours d'exécution et opérationnelles (c'est-à-dire que le champcurrentAction de chaque instance gérée est défini sur NONE), alors status.isStable==true. N'oubliez pas que la stabilité d'un groupe d'instances géré dépend de la configuration du groupe au-delà de la règle d'autoréparation. Par exemple, si votre groupe est soumis à l'autoscaling et qu'il est en train d'évoluer, l'état renvoyé est isStable==false en raison de l'opération effectuée par l'autoscaler.

Vous pouvez vérifier si groupe d'instances géré est en cours d'exécution et opérationnel en consultant la valeur du champ status.isStable.

gcloud

Utilisez la commande describe du groupe d'instances :

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

L'outil gcloud renvoie des informations détaillées sur le groupe d'instances, y compris le champ status.isStable.

Pour mettre un script en attente jusqu'à ce que le groupe soit stable, utilisez la commande wait-until avec l'option --stable. Exemple :

gcloud beta compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

Une fois le champ status.isStable défini sur true pour le groupe, la commande est renvoyée.

API

Pour un MIG zonal, envoyez une requête POST à la méthode instanceGroupManagers.get :

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

Pour un groupe d'instances géré régional, remplacez zones/zone par regions/region :

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/get

L'API renvoie des informations détaillées sur le groupe d'instances, y compris le champ status.isStable.

Si le champ status.isStable est défini sur false, cela signifie que les modifications sont actives, en attente ou que le groupe d'instances géré est lui-même en cours de modification.

Si le champ status.isStable est défini sur true, on peut en déduire les éléments suivants :

  • Aucune des instances du groupe d'instances géré n'est en cours de modification, et le champ currentAction est défini sur NONE pour toutes les instances.
  • Aucune modification n'est en attente pour les instances du groupe d'instances géré.
  • Le groupe d'instances géré n'est pas en cours de modification.

Les groupes d'instances gérés peuvent être modifiés de différentes façons. Exemple :

  • Vous pouvez demander le déploiement d'un nouveau modèle d'instance.
  • Vous pouvez demander à créer, supprimer, redimensionner ou mettre à jour des instances du groupe.
  • Un autoscaler peut demander le redimensionnement du groupe.
  • Une ressource d'autoréparation peut remplacer une ou plusieurs instances non opérationnelles dans le groupe d'instances géré.
  • Des instances d'un groupe d'instances géré régional peuvent être redistribuées.

Une fois toutes les actions terminées, le champ status.isStable est à nouveau défini sur true pour ce groupe d'instances géré.

Afficher l'historique des opérations d'autoréparation

Vous pouvez afficher les événements d'autoréparation passés à l'aide de l'outil gcloud ou de l'API.

gcloud

Exécutez la commande gcloud compute operations list avec un filtre pour n'afficher que les événements d'autoréparation compris dans votre projet.

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

Pour obtenir plus d'informations sur une opération de réparation spécifique, exécutez la commande describe. Exemple :

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

API

Pour les groupes d'instances gérés régionaux, envoyez une requête GET à la ressource regionOperations et incluez un filtre pour étendre la liste de sortie aux événements compute.instances.repair.*.

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Pour les groupes d'instances gérés zonaux, utilisez la ressource zoneOoperations.

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Pour obtenir plus d'informations sur une opération de réparation spécifique, envoyez une requête GET ciblant cette opération. Exemple :

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

Caractéristiques d'une bonne vérification d'état pour autoréparation

Les vérifications d'état pour autoréparation doivent être configurées de manière raisonnable afin que les instances ne soient pas supprimées et recréées de façon préemptive. Lorsqu'une vérification d'état pour autoréparation est trop agressive, le processus d'autoréparation peut confondre des instances occupées avec des instances défaillantes et les redémarrer inutilement, réduisant ainsi la disponibilité.

  • unhealthy-threshold : doit être supérieur à 1. Idéalement, définissez cette valeur sur 3 ou plus. Cela constitue une protection contre les défaillances rares comme une perte de paquets sur le réseau.
  • healthy-threshold : définir cette valeur sur 2 est suffisant pour la plupart des applications.
  • timeout : définissez cette valeur temporelle sur une valeur élevée (au moins cinq fois plus que le temps de réponse attendu). Cela constitue une protection contre les retards inattendus occasionnés par exemple par une instance occupée ou une connexion réseau lente.
  • check-interval : cette valeur doit être comprise entre une seconde et deux fois le délai d'attente (ni trop long ni trop court). Si cette valeur est trop élevée, une instance en échec n'est pas interceptée à temps. Si cette valeur est trop faible, les instances et le réseau peuvent se voir surchargés par le nombre élevé de tests de vérification d'état envoyés chaque seconde.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine