Configurer la vérification d'état et l'autoréparation des groupes d'instances gérés

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

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

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

Comportement de l'autoréparation

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

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

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

Autoréparation et disques

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

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

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

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

prendre des instantanés réguliers des disques persistants ;
exporter des données vers une autre source, telle que Cloud Storage.

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

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

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

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

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

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

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 d'é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
compute.instanceGroupManagers.update sur le groupe d'instances géré

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
compute.instanceAdmin.v1 : pour créer et mettre à jour des règles d'autoréparation dans des groupes d'instances gérés

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 instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.
1. Accédez à la page "Créer une vérification d'état" dans la console GCP.
  Accéder à la page "Créer une vérification d'état"
2. Donnez un nom à la vérification d'état (example-check, par exemple).
3. Vérifiez que l'option HTTP est bien sélectionnée comme Protocole.
4. Dans la section Port, saisissez 80.
5. Dans la section Intervalle entre deux tests, saisissez 5.
6. Dans la section Délai avant expiration, saisissez 5.
7. Définissez un Seuil sanitaire pour déterminer combien de vérifications d'état consécutives réussies doivent s'afficher avant qu'une instance défaillante soit marquée comme opérationnelle. Saisissez 1 pour cet exemple.
8. Définissez un Seuil non sanitaire pour déterminer combien de vérifications d'état consécutives non réussies doivent s'afficher avant qu'une instance opérationnelle soit marquée comme non opérationnelle. Saisissez 3 pour cet exemple.
9. Cliquez sur Créer pour créer la vérification d'état.
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 feront apparaître vos instances comme UNHEALTHY, car ils ne peuvent pas se connecter à l'application. Ce résultat peut entraîner la recréation automatique d'instances 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, notre groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.
1. Accédez à la page "Créer une règle de pare-feu" dans la console GCP.
  Accéder à la page "Créer une règle de pare-feu"
2. Dans la section Nom, saisissez le nom de la règle de pare-feu (par exemple, allow-health-check).
3. Dans la section Réseau, sélectionnez le réseau default.
4. Dans la section Filtre source, sélectionnez IP ranges (plages d'adresses IP).
5. Dans la section Plages d'adresses IP sources, saisissez 130.211.0.0/22 et 35.191.0.0/16.
6. Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, puis saisissez tcp:80.
7. Cliquez sur Créer.
Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.
1. Accédez à la page Groupes d'instances dans la console GCP.
  Accéder à la page Groupes d'instances
2. Dans la colonne Nom de la liste, cliquez sur le nom du groupe d'instances auquel vous souhaitez appliquer la vérification d'état.
3. Cliquez sur Modifier le groupe pour modifier le groupe d'instances géré.
4. Dans la section Autoréparation, sélectionnez la vérification d'état que vous avez créée précédemment.
5. Modifiez ou conservez le paramètre Délai initial. Il permet de retarder l'autoréparation et la potentielle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance passe à l'état VERIFYING.
6. Cliquez sur Enregistrer pour appliquer les modifications.
L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

gcloud

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

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 instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.
```
gcloud compute health-checks create http example-check --port 80 \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3
```
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 continueront de fonctionner.
Créez une règle de pare-feu permettant aux tests de vérification d'état de se connecter à votre application.

Les tests de vérification d'état proviennent des adresses des plages 130.211.0.0/22 et 35.191.0.0/16. Assurez-vous donc que vos règles de pare-feu autorisent la vérification d'état à se connecter. Dans cet exemple, notre groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.
```
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default
```
Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.

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

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

Exemple :
```
gcloud compute instance-groups managed update my-mig \
    --health-check example-check \
    --initial-delay 300 \
    --zone us-east1-b
```
L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

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

API

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

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 instances comme UNHEALTHY, entraînant ainsi leur recréation. Dans cet exemple, une instance est marquée comme opérationnelle dès qu'un message de réussite s'affiche. Elle est marquée comme non opérationnelle après 3 messages d'échec consécutifs.
```
POST https://www.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 et 35.191.0.0/16. Assurez-vous donc que vos règles de pare-feu autorisent la vérification d'état à se connecter. Dans cet exemple, notre groupe d'instances géré utilise le réseau default et ses instances écoutent le port 80. Si le port 80 n'est pas déjà ouvert sur le réseau par défaut, créez une règle de pare-feu.
```
POST https://www.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"
  }
 ]
}
```
Appliquez la vérification d'état en configurant une règle d'autoréparation pour votre groupe d'instances géré régional ou zonal.

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

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

Avertissement : Les méthodes instanceGroupManagers.setAutohealingPolicies et regionInstanceGroupManager.setAutohealingPolicies ne font pas partie de l'API accessible à tous et sont appelées à devenir obsolètes. Utilisez plutôt les méthodes insert et patch.

L'exemple suivant définit une règle d'autoréparation à l'aide de la méthode instanceGroupManagers.patch.
```
PATCH https://www.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
{
  "autoHealingPolicies": [
    {
      "healthCheck": "global/healthChecks/example-check",
      "initialDelaySec": 300
    }
  ],
}
```
Le paramètre initialDelaySec permet de retarder l'autoréparation et la potentielle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance passe à l'état VERIFYING.

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

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

Vous pouvez obtenir la règle d'autoréparation d'un groupe d'instances géré en lisant le champ instanceGroupManagers.autoHealingPolicies. Vous pouvez obtenir une ressource de groupe d'instances géré à l'aide de l'une des méthodes suivantes :
- instanceGroupManagers.get : affiche la ressource spécifiée du groupe d'instances géré zonal.
- instanceGroupManagers.list : affiche tous les groupes d'instances gérés zonaux dans un projet et une zone spécifiés.
- regionInstanceGroupManagers.get : affiche la ressource spécifiée du groupe d'instances géré régional.
- regionInstanceGroupManagers.list : affiche tous les groupes d'instances gérés régionaux dans un projet et une région spécifiés.

Vérifier l'état

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

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

Actions en cours sur les instances

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

Pour afficher l'action en cours (currentAction) et l'état (status) de chaque instance d'un groupe d'instances géré, vous pouvez utiliser 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 la liste des instances dans le groupe d'instances, ainsi que leurs états et actions en cours respectifs. 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           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 POST à la méthode regionInstanceGroupManagers.listManagedInstances. Pour un groupe d'instances géré zonal, utilisez la méthode instanceGroupManagers.listManagedInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

L'API renvoie une liste d'instances pour 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 de champ instanceStatus valides, consultez la section Consulter l'état d'une instance.

Si l'instance subit un certain type de 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 a la valeur NONE.

Les valeurs possibles de 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 a été supprimée et 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.

Lorsque l'instance a bien été mise à jour, le champ instanceStatus reflète son état actuel.

État du groupe

Au niveau du groupe, Compute Engine insère un champ en lecture seule appelé status, qui inclut un indicateur isStable. Pour accéder à cet indicateur, utilisez l'outil gcloud ou l'API.

Si toutes les instances 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 groupe d'instances géré dépend de la configuration du groupe au-delà de la règle d'autoréparation. Par exemple, si votre groupe est soumis à l'autoscaling et qu'il est en train d'évoluer, l'état renvoyé est isStable==false en raison de l'opération effectuée par l'autoscaler.

Vous pouvez vérifier qu'un groupe d'instances géré est en cours d'exécution et opérationnel en consultant la valeur du champ status.isStable de la ressource instanceGroupManagers ou regionInstanceGroupManagers associée.

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

Vous pouvez également utiliser la commande gcloud beta compute instance-groups managed wait-until avec l'indicateur --stable pour attendre que l'indicateur status.isStable soit défini sur true pour le groupe :

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

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 afficher plus d'informations sur une opération de réparation spécifique, exécutez la commande describe. Exemple :

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

API

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

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

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

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

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

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/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

Essayez le tutoriel Utiliser l'autoréparation pour les applications à disponibilité élevée.
Apprenez-en plus sur les groupes d'instances.
Activez l'autoscaling pour votre groupe d'instances géré.
Activez l'équilibrage de charge pour votre groupe d'instances géré.

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Dernière mise à jour : septembre 25, 2019

Configurer la vérification d'état et l'autoréparation des groupes d'instances gérés

Comportement de l'autoréparation

Autoréparation et disques

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

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

Autorisations requises pour cette tâche

Console

gcloud

API

Vérifier l'état

Actions en cours sur les instances

gcloud

API

État du groupe

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

gcloud

API

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

Étapes suivantes

Envoyer des commentaires concernant…