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 gérée interrompt son exécution, mais que le changement d'état n'a pas été initié par le MIG, le MIG recrée automatiquement cette instance. Toutefois, si le MIG arrête intentionnellement une instance à l'état RUNNING (par exemple, lorsqu'un autoscaler supprime une instance), il ne recrée pas cette instance.

Parmi les modifications de l'état d'une instance qui ne sont pas générées par le MIG, citons :

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, telles que le gel, la surcharge ou le plantage.

Pour améliorer davantage la disponibilité de votre application et vérifier qu'elle répond, vous pouvez configurer une règle d'autoréparation pour votre 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 la réactivité d'une application constitue une méthode plus précise que simplement s'assurer qu'une VM présente l'état RUNNING.

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

Comportement de l'autoréparation

L'autoréparation recrée les VM non opérationnelles à l'aide du modèle d'instance utilisé à l'origine pour créer la VM (il ne s'agit pas nécessairement du modèle d'instance actuel dans le MIG). Par exemple, si une VM a été créée à l'aide du modèle instance-template-a et que vous mettez ensuite à jour le MIG de façon à ce qu'il utilise le modèle instance-template-b en mode OPPORTUNISTIC, l'autoréparation recréera quand même la VM 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 la 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é.

À tout moment, le nombre de VM autoréparées simultanément est inférieur à la taille du MIG. Cela garantit que le groupe continue à exécuter un sous-ensemble de VM 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 VM 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 MIG zonal ne comporte qu'une seule VM ou si un MIG régional ne compte qu'une seule VM par zone, l'autoréparation recréera ces VM si elles ne sont plus opérationnelles.

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

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'à 30 minutes.

Autoréparation et disques

Lors de la recréation d'une VM à 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 VM, 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 sa VM sont recréés.
Nouveau disque persistant false Le disque est conservé et réassocié lorsque le processus d'autoréparation recrée la VM.
Disque persistant existant true L'ancien disque est supprimé. La recréation de VM échoue, car Compute Engine ne peut pas réassocier un disque supprimé à la VM.
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 MIG ne peut contenir qu'une seule VM, car un même disque persistant ne peut pas être associé à plusieurs VM 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 VM.

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 :

Si vous souhaitez conserver des paramètres importants pour vos VM, nous vous recommandons é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 MIG recrée les VM à 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 MIG.

Vous pouvez appliquer une même vérification d'état à un maximum de 50 MIG. 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 vous montre comment effectuer une vérification d'état sur un MIG. 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 MIG en définissant la règle d'autoréparation du groupe.

Console

  1. Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état destinée à l'équilibrage 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 VM comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une VM 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 VM 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 VM 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, notre MIG utilise le réseau default et ses VM é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 Créer.

  3. Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre MIG 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 MIG auquel vous souhaitez appliquer la vérification d'état.
    3. Cliquez sur Modifier le groupe pour modifier ce MIG.
    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 la VM si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de la VM est défini sur VERIFYING.
    6. Cliquez sur Enregistrer pour appliquer les modifications.

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 d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état destinée à l'équilibrage 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 VM comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une VM 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 MIG utilise le réseau default et ses VM é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 MIG régional ou zonal.

    Pour appliquer la vérification d'état au MIG, 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 la VM si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de la VM 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

API

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

  1. Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état destinée à l'équilibrage 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 VM comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une VM 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 MIG utilise le réseau default et ses VM é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://www.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 MIG 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 la VM si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de la VM est défini sur VERIFYING.

    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 MIG ne recrée que les VM qui ne possèdent pas l'état RUNNING.

    Vous pouvez obtenir la règle d'autoréparation d'un MIG en lisant le champ instanceGroupManagers.autoHealingPolicies. Pour obtenir une ressource de MIG, utilisez l'une des méthodes suivantes :

Une fois le groupe créé ou la vérification d'état configurée, l'autoréparation peut mettre 30 minutes avant de commencer à surveiller les instances du groupe. Une fois que la surveillance commence, Compute Engine marque progressivement les instances comme opérationnelles (ou les recrée) en fonction de votre configuration d'autoréparation. Par exemple, si vous configurez un délai initial de cinq minutes, un intervalle de vérification d'état d'une minute et un seuil sanitaire d'une seule vérification, la chronologie se présente comme suit :

  • Délai de 30 minutes avant de commencer à surveiller les instances du groupe
  • + 5 minutes pour le délai initial configuré
  • + 1 minute pour l'intervalle de vérification x le seuil sanitaire (60 s x 1)
  • = 36 minutes avant que l'instance soit marquée comme opérationnelle ou recréée

Vérifier l'état

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

Vérifier si les VM sont opérationnelles

Si vous avez configuré l'autoréparation de votre MIG, vous pouvez vérifier l'état de chaque instance gérée.

Inspectez les états de votre instance gérée pour effectuer les opérations suivantes :

  • Identifier les VM non opérationnelles qui ne font pas l'objet d'une autoréparation. Dans les cas suivants, une VM peut ne pas être immédiatement réparée, même si elle a été diagnostiquée comme 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 MIG que vous souhaitez examiner. La page qui s'ouvre affiche les propriétés du groupe d'instances ainsi que la liste des VM qui en font partie.

  3. Lorsqu'une VM n'est pas opérationnelle, son état s'affiche dans la colonne État de la vérification.

gcloud

Utilisez la sous-commande list-instances.

gcloud 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 VM.

API

Dans le cas d'un MIG régional, envoyez une requête POST à la méthode listManagedInstances :

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

Pour un MIG zonal, utilisez la méthode listManagedInstances :

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

États

Les états de VM suivants sont disponibles :

  • HEALTHY : la VM 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 : la VM est en cours de drainage. Les connexions à la VM existantes ont le temps d'aboutir, mais les nouvelles connexions sont refusées.
  • UNHEALTHY : la VM est accessible, mais elle ne respecte pas les exigences définies par la vérification d'état.
  • TIMEOUT : la VM 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 VM ne répond pas dans le délai imparti. Cela peut être dû, par exemple, à des règles de pare-feu mal configurées ou à une surcharge de l'application de serveur sur une VM.
  • UNKNOWN : le système de vérification d'état n'a pas connaissance de la VM ou l'état de celle-ci n'est pas connu pour le moment. La surveillance des nouvelles VM d'un MIG peut mettre 30 minutes avant de commencer.

Les nouvelles VM renvoient 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 VM dépend de son état :

  • Lorsqu'une VM 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 VM possède l'état UNKNOWN, elle ne sera pas immédiatement réparée. Cela permet d'éviter la réparation inutile d'une VM 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 VM n'est toujours pas opérationnelle après plusieurs réparations consécutives.
  • Il existe une partie importante de VM 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 VM. Nous vous invitons à nous faire part de vos commentaires à l'adresse suivante : mig-discuss@google.com.

Afficher les actions en cours sur les VM

Lorsqu'une VM est en cours de création, son champ currentAction est défini sur CREATING. Si une règle d'autoréparation est associée au groupe, une fois que la VM 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 la VM. Si cette vérification d'état initiale est concluante dans le délai requis pour le démarrage de l'application, la VM est vérifiée, et le champ currentAction bascule sur NONE.

Vous pouvez voir currentAction en cours de réalisation et status de chaque instance dans un groupe d'instances géré avec l'outil de ligne de commande gcloud ou 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://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.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 VM du groupe sont en cours d'exécution et opérationnelles (c'est-à-dire que le champ currentAction de chaque instance gérée est défini sur NONE), alors status.isStable==true. N'oubliez pas que la stabilité d'un MIG dépend de sa propre configuration au-delà de la règle d'autoréparation. Par exemple, si votre groupe est soumis à l'autoscaling et qu'il est en train de subir un scaling à la hausse ou à la baisse, l'état renvoyé est isStable==false en raison de l'opération effectuée par l'autoscaler.

Vous pouvez vérifier si un 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 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 MIG 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 MIG 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 en savoir plus sur une opération de réparation spécifique, envoyez une requête GET pour 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