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.
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 commeUNHEALTHY
, 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ès3
messages d'échec consécutifs.- Accédez à la page "Créer une vérification d'état" dans la console GCP.
- Donnez un nom à la vérification d'état (
example-check
, par exemple). - Vérifiez que l'option HTTP est bien sélectionnée comme Protocole.
- Dans la section Port, saisissez
80
. - 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 instance 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 instance opérationnelle soit marquée comme non opérationnelle. Saisissez
3
pour cet exemple. - 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, notre groupe d'instances géré utilise le réseaudefault
et ses instances é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.- Accédez à la page "Créer une règle de pare-feu" dans la console GCP.
- Dans la section Nom, saisissez le nom de la règle de pare-feu (par exemple,
allow-health-check
). - Dans la section Réseau, sélectionnez le réseau
default
. - Dans la section Filtre source, sélectionnez
IP ranges
(plages d'adresses IP). - Dans la section Plages d'adresses IP sources, saisissez
130.211.0.0/22
et35.191.0.0/16
. - Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, puis saisissez
tcp:80
. - 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.
- Accédez à la page Groupes d'instances dans la console GCP.
- Dans la colonne Nom de la liste, cliquez sur le nom du groupe d'instances auquel vous souhaitez appliquer la vérification d'état.
- Cliquez sur Modifier le groupe pour modifier le groupe d'instances géré.
- Dans la section Autoréparation, sélectionnez la vérification d'état que vous avez créée précédemment.
- 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'étatVERIFYING
. - 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 commeUNHEALTHY
, 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ès3
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
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, notre groupe d'instances géré utilise le réseaudefault
et ses instances é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
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 champcurrentAction
de l'instance passe à l'étatVERIFYING
.Exemple :
gcloud compute instance-groups managed update my-mig \ --health-check example-check \ --initial-delay 300 \ --zone us-east1-b
L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.
API
Pour utiliser les exemples d'API de ce guide, configurez l'accès aux API.
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 commeUNHEALTHY
, 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ès3
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
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, notre groupe d'instances géré utilise le réseaudefault
et ses instances é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://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
ouregionInstanceGroupManager
.Vous pouvez définir une règle d'autoréparation à l'aide des méthodes
insert
oupatch
.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 champcurrentAction
de l'instance passe à l'étatVERIFYING
.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[]
). AvecautoHealingPolicies[]
, le groupe d'instances géré ne recrée que les instances qui ne possèdent pas l'étatRUNNING
.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éthodesstop
etstart
.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 surNONE
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 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.
- 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é.