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 de l'état que vous configurez détecte que votre application sur une VM ne répond pas, le MIG signale 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 d'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 d'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 comme suit :
Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :
Console
Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Définissez une région et une zone par défaut.
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
-
Tarification
Lorsque vous configurez une vérification d'état basée sur l'application, chaque fois que l'état d'une VM change, par défaut, Compute Engine écrit une entrée de journal dans Cloud Logging. 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 :
- Créez une vérification de l'état, si ce n'est pas déjà fait.
- Configurez une règle d'autoréparation dans le MIG pour appliquer la vérification de l'état.
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.
Console
Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état relative à 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 commeUNHEALTHY
, 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 renvoie3
échecs consécutifs.Dans la console Google Cloud, accédez à la page Créer une vérification de l'état.
Donnez un nom à la vérification d'état (
example-check
, par exemple).Sélectionnez un Champ d'application. Vous pouvez sélectionner l'option Régional ou Global. Pour cet exemple, sélectionnez Global.
Vérifiez que l'option HTTP est bien sélectionnée comme Protocole.
Dans la section Port, saisissez
80
.Dans la section Critères de vérification de l'état, indiquez les valeurs suivantes :
- Dans la section Intervalle entre deux tests, saisissez
5
. - Dans la section Délai avant expiration, saisissez
5
. - 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. - 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.
- Dans la section Intervalle entre deux tests, saisissez
Cliquez sur Créer pour créer la vérification d'état.
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
et35.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éseaudefault
et ses VM écoutent le port80
. Si le port80
n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.Dans la console Google Cloud, accédez à la page Règles d'administration.
Cliquez sur Créer une règle de pare-feu.
Entrez un nom pour la règle de pare-feu. Exemple :
allow-health-check
.Pour Réseau, sélectionnez le réseau
default
.Pour Cibles, sélectionnez
All instances in the network
.Pour Filtre source, sélectionnez
IPv4 ranges
.Dans le champ Plages IPv4 sources, saisissez
130.211.0.0/22
et35.191.0.0/16
.Sous Protocoles et ports, sélectionnez Protocoles et ports spécifiés et procédez comme suit :
- Sélectionnez TCP.
- Dans le champ Ports, saisissez
80
.
Cliquez sur Créer.
gcloud
Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état relative à 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 commeUNHEALTHY
, 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 après3
messages d'échec 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
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
et35.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éseaudefault
et ses VM écoutent le port80
. Si le port80
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
REST
Créez une vérification d'état pour l'autoréparation qui soit plus conservatrice qu'une vérification d'état relative à 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 commeUNHEALTHY
, 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 après3
messages d'échec 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 }
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
et35.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éseaudefault
et ses VM écoutent le port80
. Si le port80
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.
Console
Dans la console Google Cloud, accédez à la page Groupes d'instances.
Dans la colonne Nom de la liste, cliquez sur le nom du MIG dans lequel vous souhaitez appliquer la vérification de l'état.
Cliquez sur Modifier pour modifier ce MIG.
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.
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 lors du 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.Cliquez sur Enregistrer pour appliquer les modifications.
gcloud
Pour configurer une règle d'autoréparation dans un MIG existant, exécutez 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 la 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éparationSIZE
: nombre de VM du groupeINSTANCE_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
- Modèle d'instance régional :
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
- Vérification de l'état régionale :
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 pendant 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 champcurrentAction
de la VM passe àVERIFYING
. La valeur du délai initial doit être comprise entre0
et3600
secondes. La valeur par défaut est0
.ZONE
: zone où se trouve le MIG. Pour un MIG régional, utilisez l'option--region
.
REST
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éparationSIZE
: nombre de VM du groupeINSTANCE_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
- Modèle d'instance régional :
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
- Vérification de l'état régionale :
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 pendant 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 champcurrentAction
de la VM passe àVERIFYING
. La valeur du délai initial doit être comprise entre0
et3600
secondes. La valeur par défaut est0
.ZONE
: zone où se trouve le MIG. Pour un MIG régional, utilisezregions/REGION
dans l'URL.
Une fois la configuration de l'autoréparation terminée, l'autoréparation peut mettre 30 minutes avant de commencer à surveiller les VM du groupe. Une fois que la surveillance commence, Compute Engine marque progressivement les VM 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 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)
- = 36 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.
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
Dans la console Google Cloud, accédez à la page Groupes d'instances.
Accéder à la page "Groupes d'instances"
- Cliquez sur le nom du MIG dont vous souhaitez supprimer la vérification de l'état.
- Cliquez sur Modifier pour modifier ce MIG.
- Dans la section Cycle de vie des instances de VM, sous Autoréparation, sélectionnez Aucune vérification de l'état.
- 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éparationZONE
: zone où se trouve le MIG. Pour un MIG régional, utilisezregions/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
Dans la console Google Cloud, accédez à la page Groupes d'instances.
Cliquez sur le nom du MIG pour lequel vous souhaitez afficher la règle d'autoréparation.
Accédez à l'onglet Détails.
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éparationZONE
: zone où se trouve le MIG. Pour un MIG régional, utilisezregions/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'étatHEALTHY
. Vous pouvez mesurer cet écart en interrogeant la méthodelist-instances
ou en observant l'intervalle entre l'opérationinstances.insert
et le premier signal sain reçu.
Utilisez la console, l'outil de ligne de commande gcloud
ou REST pour afficher les états.
Console
Dans Google Cloud Console, accédez à la page Groupes d'instances.
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.
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 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
ouTIMEOUT
, 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 corrige 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 : mig-discuss@google.com.
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 connaître les actions en cours sur les VM, consultez la page 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 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
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. 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 sur3
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 sur2
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
- 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.