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

---

Ce document explique comment configurer une vérification d'état basée sur l'application pour autoréparation des VM dans un groupe d'instances géré (MIG). Il explique également comment effectuer les opérations suivantes : utiliser une vérification d'état sans autoréparation, supprimer une vérification d'état, afficher les règles d'autoréparation et vérifier l'état de chaque VM.

Vous pouvez configurer une vérification d'état basée sur l'application, pour vérifier que votre application sur une VM répond comme prévu. Si la vérification d'état que vous configurez détecte que votre application sur une VM ne répond pas, le MIG marque cette VM comme non opérationnelle et la répare. La réparation d'une VM basée sur une vérification d'état basée sur l'application s'appelle autoréparation.

Vous pouvez également désactiver les réparations dans un MIG afin de pouvoir utiliser une vérification d'état sans déclencher l'autoréparation.

Pour en savoir plus sur les réparations dans un MIG, consultez la section À propos de la réparation des VM pour la haute disponibilité.

Avant de commencer

• Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes:
  

  Select the tab for how you plan to use the samples on this page:

  Console

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

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

     Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
  2. Set a default region and zone.

  Terraform

  Pour utiliser les exemples Terraform de cette page dans un environnement de développement local, installez et initialisez gcloud CLI, puis configurez le service Identifiants par défaut de l'application à l'aide de vos identifiants utilisateur.

  1. Install the Google Cloud CLI.

  2. To initialize the gcloud CLI, run the following command:

     gcloud init

  3. If you're using a local shell, then create local authentication credentials for your user account:

     gcloud auth application-default login

     You don't need to do this if you're using Cloud Shell.

  Pour en savoir plus, consultez Set up authentication for a local development environment.

  REST

  Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Tarifs

Lorsque vous configurez une vérification d'état basée sur l'application, Compute Engine écrit par défaut une entrée de journal dans Cloud Logging chaque fois que l'état d'une VM change. Cloud Logging fournit un quota mensuel gratuit au-delà duquel la journalisation est facturée en fonction du volume de données. Pour éviter les coûts, vous pouvez désactiver les journaux des changements d'état.

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

Pour configurer une vérification de l'état et l'autoréparation basées sur l'application dans un MIG, vous devez effectuer les opérations suivantes :

1. Créez une vérification de l'état, si ce n'est pas déjà fait.
2. Configurez une règle d'autoréparation dans le MIG pour appliquer la vérification de l'état.

Conseil de pro : Utilisez des vérifications de l’état distinctes pour l’équilibrage de charge et pour l'autoréparation. Les vérifications d'état pour l'équilibrage de charge détectent les VM qui ne répondent pas et détournent le trafic de ces instances. Les vérifications de l'état pour autoréparation, quant à elles, détectent les VM non opérationnelles et les recréent de manière proactive. Elles doivent donc être plus conservatrices que celles destinées à l'équilibrage de charge. Pour plus d'informations, consultez la section Caractéristiques d'une bonne vérification d'état pour autoréparation.

Créer une vérification d'état

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.

L'exemple suivant montre comment créer une vérification de l'état pour l'autoréparation. Vous pouvez créer une vérification de l'état régionale ou globale pour l'autoréparation des MIG. Dans cet exemple, vous créez une vérification de l'état global qui s'attend à une réponse du serveur Web sur le port 80. Pour permettre aux vérifications de l'état d'atteindre le serveur Web, configurez une règle de pare-feu.

Autorisations requises pour cette tâche

Pour effectuer cette tâche, vous devez disposer des autorisations suivantes :

• compute.healthChecks.create sur le projet si vous créez une vérification de l'état.
• compute.healthChecks.use sur la vérification d'état à utiliser.
• compute.firewalls.create sur le projet si vous créez un pare-feu.
• compute.networks.updatePolicy sur le réseau si vous créez un pare-feu.

Les autorisations sont disponibles sur les rôles préconfigurés suivants :

• compute.networkAdmin pour créer des vérifications d'état.
• compute.securityAdmin pour configurer des règles de pare-feu afin d'autoriser la connexion de la vérification d'état.

Console

1. Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état concernant 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 lors que la vérification de l'état aboutit une fois. La VM est marquée comme non opérationnelle si la vérification de l'état renvoie 3 échecs consécutifs.

   1. Dans la console Google Cloud, accédez à la page Créer une vérification de l'é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. Sélectionnez un Champ d'application. Vous pouvez sélectionner Régional ou Global. Pour cet exemple, sélectionnez Global.

   4. Vérifiez que l'option HTTP est bien sélectionnée comme Protocole.

   5. Dans la section Port, saisissez 80.

   6. Dans la section Critères de vérification de l'état, indiquez les valeurs suivantes :

      1. Dans la section Intervalle entre deux tests, saisissez 5.
      2. Dans la section Délai avant expiration, saisissez 5.
      3. 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.
      4. 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.

   7. Cliquez sur Créer pour créer la vérification de l'état.

2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

   Attention : Si les tests de vérification d'état sont bloquées par des règles de pare-feu, ils définissent vos VM sur l'état UNHEALTHY, car ils ne peuvent pas se connecter à l'application. Ce résultat peut entraîner la recréation automatique de VM qui sont peut-être opérationnelles.

   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 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 la console Google Cloud, accédez à la page Règles d'administration.

      Accéder à la page "Stratégies de pare-feu"

   2. Cliquez sur Créer une règle de pare-feu.

   3. Entrez un nom pour la règle de pare-feu. Exemple : allow-health-check.

   4. Pour Réseau, sélectionnez le réseau default.

   5. Pour Cibles, sélectionnez All instances in the network.

   6. Pour Filtre source, sélectionnez IPv4 ranges.

   7. Dans le champ Plages IPv4 sources, saisissez 130.211.0.0/22 et 35.191.0.0/16.

   8. Sous Protocoles et ports, sélectionnez Protocoles et ports spécifiés et procédez comme suit :

      1. Sélectionnez TCP.
      2. Dans le champ Ports, saisissez 80.

   9. Cliquez sur Créer.

gcloud

1. Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification de l'état de l'équilibrage de charge.

   Par exemple, créez une vérification de l'é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. La VM est marquée comme non opérationnelle si elle renvoie 3 échecs consécutifs. La commande suivante crée une vérification de l'état global.

   gcloud compute health-checks create http example-check --port 80 \
      --check-interval 30s \
      --healthy-threshold 1 \
      --timeout 10s \
      --unhealthy-threshold 3 \
      --global
   

   Remarque : Utilisez les vérifications d'état plus récentes, compatibles avec les protocoles HTTP, HTTPS, TCP et SSL (TLS). Les anciennes vérifications d'état HTTP/HTTPS de Compute Engine continuent de fonctionner.

2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

   Attention : Si les tests de vérification d'état sont bloqués par des règles de pare-feu, ils définissent vos VM sur l'état UNHEALTHY, car ils ne peuvent pas se connecter à l'application. Ce résultat peut entraîner la recréation automatique de VM qui sont peut-être opérationnelles.

   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, le 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
   

Terraform

1. Créez une vérification d'état à l'aide de la ressource google_compute_http_health_check.

   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. La VM est marquée comme non opérationnelle si elle renvoie 3 échecs consécutifs. La requête suivante crée une vérification de l'état global.

   resource "google_compute_http_health_check" "default" {
     name                = "example-check"
     timeout_sec         = 10
     check_interval_sec  = 30
     healthy_threshold   = 1
     unhealthy_threshold = 3
     port                = 80
   }

2. Créez un pare-feu à l'aide de la ressource google_compute_firewall.

   Attention : Si les tests de vérification d'état sont bloqués par des règles de pare-feu, ils définissent vos VM sur l'état UNHEALTHY, car ils ne peuvent pas se connecter à l'application. Ce résultat peut entraîner la recréation automatique de VM qui sont peut-être opérationnelles.

   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, le 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.

   resource "google_compute_firewall" "default" {
     name          = "allow-health-check"
     network       = "default"
     source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
     allow {
       protocol = "tcp"
       ports    = [80]
     }
   }

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.

REST

1. Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification de l'état de 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. La VM est marquée comme non opérationnelle si elle renvoie 3 échecs consécutifs. La requête suivante crée une vérification de l'état global.

   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
   }
   

   Remarque : Utilisez les vérifications d'état plus récentes, compatibles avec les protocoles HTTP, HTTPS, TCP et SSL (TLS). Les anciennes vérifications d'état HTTP/HTTPS de Compute Engine continuent de fonctionner.

2. Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

   Attention : Si les tests de vérification de l'état sont bloqués par des règles de pare-feu, ils définissent vos VM sur l'état UNHEALTHY, car ils ne peuvent pas se connecter à l'application. Ce résultat peut entraîner la recréation automatique de VM qui sont peut-être opérationnelles.

   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, le 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"
     }
    ]
   }
   

   Remplacez PROJECT_ID par votre ID de projet.

Configurer une règle d'autoréparation dans un MIG

Dans un MIG, vous ne pouvez configurer qu'une seule règle d'autoréparation pour appliquer une vérification de l'état.

Vous pouvez utiliser une vérification de l'état régionale ou globale pour l'autoréparation des MIG. Les vérifications de l'état régionales réduisent les dépendances interrégionales et aident à mettre en œuvre la résidence des données. Les vérifications d'état globales sont pratiques si vous souhaitez utiliser la même vérification d'état pour les MIG dans plusieurs régions.

Avant de configurer une règle d'autoréparation, procédez comme suit :

• Si vous n'avez pas encore de vérification de l'état, créez-en une.
• Si vous souhaitez éviter les faux déclencheurs de l'autoréparation lors de la configuration d'une nouvelle vérification de l'état, vous devez d'abord désactiver les réparations dans le MIG, puis configurer la règle d'autoréparation.

Autorisations requises pour cette tâche

Pour effectuer cette tâche, vous devez disposer des autorisations suivantes :

• compute.instanceGroupManagers.update sur le MIG.

Les autorisations sont disponibles sur les rôles préconfigurés suivants :

• compute.instanceAdmin.v1 pour créer et mettre à jour des règles d'autoréparation dans des MIG.

Console

1. Dans la console Google Cloud, 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 dans lequel vous souhaitez appliquer la vérification de l'état.

3. Cliquez sur Modifier pour modifier ce MIG.

4. Dans la section Cycle de vie des instances de VM, sous Autoréparation, sélectionnez une vérification de l'état globale ou régionale.

5. Modifiez ou conservez le paramètre Délai initial.

   Le délai initial correspond au nombre de secondes nécessaire à une nouvelle VM pour initialiser et exécuter son script de démarrage. Pendant le délai initial d'une VM, le MIG ignore les vérifications d'état ayant échoué, car la VM peut être en cours de démarrage. Cela empêche le MIG de recréer prématurément une VM. Si la vérification de l'état reçoit une réponse opérationnelle dans le délai initial, cela signifie que le processus de démarrage est terminé et que la VM est prête. Le délai initial commence au moment où le champ currentAction de la VM passe à VERIFYING. La valeur du délai initial doit être comprise entre 0 et 3 600 secondes. Dans la console, la valeur par défaut est de 300 secondes.

6. Cliquez sur Enregistrer pour appliquer les modifications.

gcloud

Remarque : La commande set-autohealing est obsolète et sera à terme supprimée. Utilisez plutôt la commande update pour un MIG existant et la commande create pour un nouveau MIG.

Pour configurer une règle d'autoréparation dans un MIG existant, utilisez la commande update.

Par exemple, utilisez la commande suivante pour configurer la règle d'autoréparation dans un MIG zonal existant :

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Pour configurer une règle d'autoréparation lors de la création d'un MIG, utilisez la commande create.

Par exemple, utilisez la commande suivante pour configurer la règle d'autoréparation lors de la création d'un MIG zonal :

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Remplacez les éléments suivants :

• MIG_NAME : nom du MIG dans lequel vous souhaitez configurer l'autoréparation
• SIZE : nombre de VM du groupe
• INSTANCE_TEMPLATE_URL : URL partielle du modèle d'instance que vous souhaitez utiliser pour créer les VM du groupe Exemple :
  • Modèle d'instance régional : projects/example-project/regions/us-central1/instanceTemplates/example-template
  • Modèle d'instance global : projects/example-project/global/instanceTemplates/example-template
• HEALTH_CHECK_URL : URL partielle de la vérification de l'état que vous souhaitez configurer pour l'autoréparation. Si vous souhaitez utiliser une vérification de l'état régionale, vous devez fournir l'URL partielle de cette vérification. Exemple :
  • Vérification de l'état régionale : projects/example-project/regions/us-central1/healthChecks/example-health-check
  • Vérification de l'état globale : projects/example-project/global/healthChecks/example-health-check
• INITIAL_DELAY : nombre de secondes nécessaire pour initialiser une nouvelle VM et exécuter son script de démarrage. Pendant le délai initial d'une VM, le MIG ignore les vérifications d'état ayant échoué, car la VM peut être en cours de démarrage. Cela empêche le MIG de recréer prématurément une VM. Si la vérification de l'état reçoit une réponse opérationnelle dans le délai initial, cela signifie que le processus de démarrage est terminé et que la VM est prête. Le délai initial commence au moment où le champ currentAction de la VM passe à VERIFYING. La valeur du délai initial doit être comprise entre 0 et 3600 secondes. La valeur par défaut est 0.
• ZONE : zone où se trouve le MIG. Pour un MIG régional, utilisez l'option --region.

Terraform

Pour configurer une règle d'autoréparation dans un MIG, utilisez le bloc auto_healing_policies.

L'exemple suivant configure la règle d'autoréparation dans un MIG zonal. Pour en savoir plus sur la ressource utilisée dans l'exemple, consultez la section consacrée à la ressource google_compute_instance_group_manager. Pour un MIG régional, utilisez la ressource google_compute_region_instance_group_manager.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.

REST

Remarque : Les méthodes instanceGroupManagers.setAutohealingPolicies et regionInstanceGroupManager.setAutohealingPolicies ne font pas partie de l'API accessible au public et sont obsolètes. Utilisez plutôt les méthodes patch ou insert.

Pour configurer une règle d'autoréparation dans un MIG existant, utilisez la méthode patch comme suit :

• Pour un MIG zonal, utilisez la méthode instanceGroupManager.patch.
• Pour un MIG régional, utilisez la méthode regionInstanceGroupManager.patch.

Par exemple, effectuez l'appel suivant pour configurer l'autoréparation dans un MIG zonal existant :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
  {
    "healthCheck": "HEALTH_CHECK_URL",
    "initialDelaySec": INITIAL_DELAY
  }
  ]
}

Pour configurer une règle d'autoréparation lors de la création d'un MIG, utilisez la méthode insert comme suit :

• Pour un MIG zonal, utilisez la méthode instanceGroupManager.insert.
• Pour un MIG régional, utilisez la méthode regionInstanceGroupManager.insert.

Par exemple, effectuez l'appel suivant pour configurer une règle d'autoréparation lors de la création d'un MIG zonal :

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers

{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL"
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
}

Remplacez les éléments suivants :

• PROJECT_ID : ID de votre projet.
• MIG_NAME : nom du MIG dans lequel vous souhaitez configurer l'autoréparation
• SIZE : nombre de VM du groupe
• INSTANCE_TEMPLATE_URL : URL partielle du modèle d'instance que vous souhaitez utiliser pour créer les VM du groupe Exemple :
  • Modèle d'instance régional : projects/example-project/regions/us-central1/instanceTemplates/example-template
  • Modèle d'instance global : projects/example-project/global/instanceTemplates/example-template
• HEALTH_CHECK_URL : URL partielle de la vérification de l'état que vous souhaitez configurer pour l'autoréparation. Exemple :
  • Vérification de l'état régionale : projects/example-project/regions/us-central1/healthChecks/example-health-check
  • Vérification de l'état globale : projects/example-project/global/healthChecks/example-health-check
• INITIAL_DELAY : nombre de secondes nécessaire pour initialiser une nouvelle VM et exécuter son script de démarrage. Pendant le délai initial d'une VM, le MIG ignore les vérifications d'état ayant échoué, car la VM peut être en cours de démarrage. Cela empêche le MIG de recréer prématurément une VM. Si la vérification de l'état reçoit une réponse opérationnelle dans le délai initial, cela signifie que le processus de démarrage est terminé et que la VM est prête. Le délai initial commence au moment où le champ currentAction de la VM passe à VERIFYING. La valeur du délai initial doit être comprise entre 0 et 3600 secondes. La valeur par défaut est 0.
• ZONE : zone où se trouve le MIG. Pour un MIG régional, utilisez regions/REGION dans l'URL.

Une fois la configuration de l'autoréparation terminée, l'autoréparation peut mettre 10 minutes avant de commencer à surveiller les VM du groupe. Une fois la surveillance commencée, Compute Engine commence à marquer les VM comme opérationnelles (ou à défaut 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 10 minutes avant de commencer à surveiller les VM 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)
• = 16 minutes avant que la VM soit marquée comme opérationnelle ou recréée

Si vous avez désactivé les réparations dans le MIG avant de configurer la règle d'autoréparation, vous pouvez surveiller les états de la VM pour vérifier que la vérification de l'état fonctionne comme prévu, puis rétablir l'opération de réparation des VM sur le MIG.

Utiliser une vérification de l'état sans autoréparation

Vous pouvez utiliser la vérification de l'état configurée dans un MIG sans autoréparation en désactivant les réparations dans le MIG. Cela est utile lorsque vous souhaitez utiliser la vérification de l'état uniquement pour surveiller l'état de votre application ou lorsque vous souhaitez mettre en œuvre votre propre logique de réparation basée sur la vérification de l'état.

Attention : Vous devez faire preuve de prudence si vous décidez de désactiver les réparations dans un MIG, car cela désactive également la réparation automatique des VM défaillantes dans le MIG.

Pour rétablir la réparation des VM non opérationnelles dans un MIG, consultez la page Définir un MIG pour réparer les VM défaillantes et non opérationnelles.

Supprimer une vérification de l'état

Vous pouvez supprimer une vérification de l'état configurée dans une règle d'autoréparation comme suit :

Console

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

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

   1. Cliquez sur le nom du MIG dont vous souhaitez supprimer la vérification de l'état.
   2. Cliquez sur Modifier pour modifier ce MIG.
   3. Dans la section Cycle de vie des instances de VM, sous Autoréparation, sélectionnez Aucune vérification de l'état.
   4. Cliquez sur Enregistrer pour appliquer les modifications.

gcloud

Pour supprimer la configuration de vérification de l'état dans une règle d'autoréparation, dans la commande update, utilisez l'option --clear-autohealing comme suit :

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

Remplacez MIG_NAME par le nom d'un MIG.

REST

Pour supprimer la configuration de la vérification de l'état dans une règle d'autoréparation, définissez la règle d'autoréparation sur une valeur vide.

• Pour un MIG zonal, utilisez la méthode instanceGroupManagers.patch.
• Pour un MIG régional, utilisez la méthode regionInstanceGroupManagers.patch.

Par exemple, pour supprimer une vérification de l'état dans un MIG zonal, exécutez la requête suivante :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

Remplacez les éléments suivants :

• PROJECT_ID : ID de votre projet.
• MIG_NAME : nom du MIG dans lequel vous souhaitez configurer l'autoréparation
• ZONE : zone où se trouve le MIG. Pour un MIG régional, utilisez regions/REGION.

Afficher la règle d'autoréparation dans un MIG

Vous pouvez afficher la règle d'autoréparation d'un MIG comme suit :

Console

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

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

2. Cliquez sur le nom du MIG dont vous souhaitez afficher la règle d'autoréparation.

3. Accédez à l'onglet Détails.

4. Dans la section Cycle de vie des instances de VM, le champ Autoréparation affiche la vérification de l'état et le délai initial configuré dans la règle d'autoréparation.

gcloud

Pour afficher la règle d'autoréparation dans un MIG, exécutez la commande suivante :

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

Remplacez MIG_NAME par le nom d'un MIG.

Voici un exemple de résultat :

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

Pour afficher la règle d'autoréparation dans un MIG, utilisez les méthodes REST comme suit :

• Pour un MIG zonal, utilisez la méthode instanceGroupManagers.get.
• Pour un MIG régional, utilisez la méthode regionInstanceGroupManagers.get.

Par exemple, exécutez la requête suivante pour afficher la règle d'autoréparation dans un MIG zonal :

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

Dans le corps de la réponse, recherchez l'objet autoHealingPolicies[].

Voici un exemple de réponse :

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

Remplacez les éléments suivants :

• PROJECT_ID : ID de votre projet.
• MIG_NAME : nom du MIG dans lequel vous souhaitez configurer l'autoréparation
• ZONE : zone où se trouve le MIG. Pour un MIG régional, utilisez regions/REGION.

Vérifier l'état

Une fois que vous avez configuré une vérification de l'état basée sur l'application dans un MIG, vous pouvez vérifier qu'une VM est en cours d'exécution et que son application répond en procédant comme suit :

• Vérifier si les VM sont opérationnelles
• Vérifier les actions en cours sur les VM
• Vérifier si un MIG est stable

Vérifier si les VM sont opérationnelles

Si vous avez configuré une vérification de l'état basée sur l'application dans 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 ré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 de réparation. Le MIG retarde davantage l'autoréparation 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 ou en observant l'intervalle entre l'opération instances.insert et le premier signal sain reçu.

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

Autorisations requises pour cette tâche

Pour effectuer cette tâche, vous devez disposer des autorisations suivantes :

• compute.instanceGroupManagers.get sur le MIG

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.

REST

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 de l'é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 10 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 MIG tente immédiatement de la réparer.
• Lorsqu'une VM possède l'état UNKNOWN, le MIG ne la répare pas immédiatement. 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. Vous pouvez nous faire part de vos commentaires à l'adresse suivante : [e-mail].

Vérifier les actions en cours sur les VM

Lorsqu'un MIG est en cours de création d'une instance de VM, il définit le champ currentAction en lecture seule de cette instance sur CREATING. Si une règle d'autoréparation est associée au groupe, une fois la VM créée et exécutée, le MIG définit l'action en cours de l'instance sur VERIFYING, et le vérificateur d'état commence à contrôler l'application de la VM. Si cette vérification de l'état initiale est concluante dans le délai requis au démarrage de l'application, la VM est vérifiée et le MIG remplace le champ currentAction de la VM par NONE.

Pour vérifier les actions en cours sur les VM, consultez la section Afficher les actions en cours sur les VM.

Vérifier si un MIG est stable

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

Si toutes les VM du groupe sont en cours d'exécution et opérationnelles (c'est-à-dire que le champ currentAction pour chaque instance gérée est défini sur NONE), le MIG définit la valeur du champ status.isStable sur true. N'oubliez pas que la stabilité d'un MIG 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 cours de scaling vertical ou horizontal, le MIG définit le champ status.isStable sur false en raison de l'opération effectuée par l'autoscaler.

Pour vérifier les valeurs du champ status.isStable de votre MIG, consultez la section Vérifier si un MIG est stable.

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

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

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. Par exemple :

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

REST

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

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. Par 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. Lorsqu'une valeur est trop courte, les instances et le réseau peuvent devenir très occupés, étant donné le nombre élevé de tests de vérification de l'état envoyés chaque seconde.

Étapes suivantes

• Essayez le tutoriel Utiliser l'autoréparation pour les applications à disponibilité élevée.
• Surveillez les changements d'état des VM.
• Appliquez les mises à jour de configuration lors des réparations.