Cette page a été traduite par l'API Cloud Translation.

Utiliser l'autoréparation pour les applications à disponibilité élevée

Ce tutoriel interactif montre comment utiliser l'autoréparation pour créer des applications à disponibilité élevée sur Compute Engine.

Les applications à disponibilité élevée sont conçues pour offrir aux clients un service avec des temps de latence et d'arrêt minimaux. La disponibilité est compromise lorsqu'une application plante ou se bloque. Les clients d'une application compromise peuvent rencontrer des temps de latence ou d'arrêt élevés.

L'autoréparation permet de redémarrer automatiquement les applications compromises. Elle détecte rapidement les instances de machine virtuelle (VM) défaillantes et les recrée automatiquement, de sorte que les clients puissent les utiliser à nouveau. Avec l'autoréparation, il n'est plus nécessaire de remettre manuellement une application en service après une défaillance.

Architecture de l'application

L'application inclut les composants Compute Engine ci-dessous.

Vérification de l'état : règle de vérification de l'état de l'état HTTP utilisée par le processus d'autoréparation pour détecter les VM défaillantes.
Règles de pare-feu : les règles de pare-feuGoogle Cloud vous permettent d'autoriser ou de refuser le trafic vers vos VM.
Groupe d'instances géré : groupe de VM exécutant le même service Web de démonstration.
Modèle d'instance : modèle utilisé pour créer chaque VM du groupe d'instances.

Architecture système d'une vérification de l'état et d'un groupe d'instances

Comment la vérification de l'état teste-t-elle le service Web de démonstration ?

Une vérification de l'état envoie des requêtes de vérification à une VM à l'aide d'un protocole spécifié, tel que HTTP(S), SSL ou TCP. Pour en savoir plus, consultez les sections Fonctionnement des vérifications d'état et Catégories, protocoles et ports pour les vérifications d'état.

Dans ce tutoriel, la vérification de l'état fait appel au protocole HTTP et teste le chemin d'accès HTTP /health sur le port 80. Dans le cas d'une vérification de l'état HTTP, la requête de test n'est un succès que si le chemin renvoie une réponse HTTP 200 (OK). Dans le cadre de ce tutoriel, le service Web de démonstration définit le chemin d'accès /health de sorte qu'il renvoie une réponse HTTP 200 (OK) s'il est opérationnel ou une réponse HTTP 500 (Internal Server Error) dans le cas contraire. Pour plus d'informations, consultez la section Critères de réussite pour HTTP, HTTPS et HTTP/2.

Créer la vérification de l'état

Pour configurer l'autoréparation, créez une vérification de l'état personnalisée et configurez le pare-feu réseau de sorte qu'il autorise les tests de vérification de l'état.

Dans ce tutoriel, vous allez créer une vérification de l'état régionale. Pour l'autoréparation, vous pouvez utiliser une vérification de l'état régionale ou globale. Les vérifications d'é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.

Conseil de pro : Utilisez des vérifications d'é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 d'état pour autoréparation, quant à elles, détectent et recréent les VM en échec. Elles doivent donc être moins agressives que les vérifications d'état pour l'équilibrage de charge. L'utilisation de la même vérification de l'état d'état pour ces services supprime la distinction entre les VM qui ne répondent pas et les VM en échec, ce qui entraîne une latence inutile et/ou une indisponibilité pour vos utilisateurs.
Pour en savoir plus, consultez Caractéristiques d'une bonne vérification d'état pour autoréparation.

Console

Créez une vérification d'état.
1. Dans la console Google Cloud , accédez à la page Créer une vérification d'état.
  
  Accéder à la page "Créer une vérification d'état"
2. Dans le champ Nom, saisissez autohealer-check.
3. Définissez le champ d'application sur Regional.
4. Dans le menu déroulant Région, sélectionnez europe-west1.
5. Pour Protocole, sélectionnez HTTP.
6. Définissez Chemin de requête sur /health. Ce champ indique le chemin HTTP que la vérification de l'état utilise. Dans le cadre de ce tutoriel, le service Web de démonstration définit le chemin d'accès /health de sorte qu'il renvoie une réponse HTTP 200 (OK) s'il est opérationnel ou une réponse HTTP 500 (Internal Server Error) dans le cas contraire.
7. Définissez les critères de vérification d'état :
  1. Définissez Intervalle entre deux tests sur 10. Ce champ définit la durée entre le début d'un test et le début du suivant.
  2. Définissez Délai avant expiration sur 5. Ce champ définit la durée pendant laquelleGoogle Cloud attend une réponse à une vérification. Cette valeur doit être inférieure ou égale à l'intervalle entre deux tests.
  3. Définissez Seuil sanitaire sur 2. Ce champ définit le nombre de tests séquentiels qui doivent réussir pour que la VM soit considérée comme opérationnelle.
  4. Définissez Seuil non sanitaire sur 3. Ce champ définit le nombre de tests séquentiels qui doivent échouer pour que la VM soit considérée comme non opérationnelle.
8. Conservez les valeurs par défaut des autres options.
9. Cliquez sur Créer en bas de la page.
Créez une règle de pare-feu permettant aux tests de vérification de l'état d'effectuer des requêtes HTTP.
1. Dans la console Google Cloud , accédez à la page Créer une règle de pare-feu.
  
  Accéder à la page "Créer une règle de pare-feu"
2. Dans le champ Nom, saisissez default-allow-http-health-check.
3. Pour Réseau, sélectionnez default.
4. Pour Cibles, sélectionnez All instances in the network.
5. Pour Filtre source, sélectionnez IPv4 ranges.
6. Dans le champ Plages IPv4 sources, saisissez 130.211.0.0/22, 35.191.0.0/16.
  
  Remarque : Les tests de vérification de l'état proviennent d'adresses IP situées dans les plages 130.211.0.0/22 et 35.191.0.0/16. Dans le cadre de ce tutoriel, la vérification de l'état utilise le protocole HTTP. Par conséquent, assurez-vous que la règle de pare-feu autorise les connexions au port 80. Pour plus d'informations, consultez la page Configurer la vérification de l'état et l'autoréparation des groupes d'instances gérés.
7. Dans Protocoles et ports, sélectionnez TCP et saisissez 80.
8. Conservez les valeurs par défaut des autres options.
9. Cliquez sur Créer.

gcloud

Créez une vérification d'état à l'aide de la commande health-checks create http.
```
gcloud compute health-checks create http autohealer-check \
    --region europe-west1 \
    --check-interval 10 \
    --timeout 5 \
    --healthy-threshold 2 \
    --unhealthy-threshold 3 \
    --request-path "/health"
```
- check-interval définit la durée écoulée entre le début d'un test et le début du suivant.
- timeout définit la durée pendant laquelle Google Cloudattend une réponse à une vérification. Cette valeur doit être inférieure ou égale à l'intervalle entre deux tests.
- healthy-threshold définit le nombre de vérifications séquentielles qui doivent réussir pour que la VM soit considérée comme opérationnelle.
- unhealthy-threshold définit le nombre de tests séquentiels qui doivent échouer pour que la VM soit considérée comme non opérationnelle.
- request-path indique le chemin HTTP que la vérification de l'état utilise. Dans le cadre de ce tutoriel, le service Web de démonstration définit le chemin d'accès /health de sorte qu'il renvoie une réponse HTTP 200 (OK) s'il est opérationnel ou une réponse HTTP 500 (Internal Server Error) dans le cas contraire.
Créez une règle de pare-feu permettant aux tests de vérification de l'état d'effectuer des requêtes HTTP.
```
gcloud compute firewall-rules create default-allow-http-health-check \
    --network default \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16
```
Remarque : Les tests de vérification de l'état proviennent d'adresses IP situées dans les plages 130.211.0.0/22 and 35.191.0.0/16. Dans le cadre de ce tutoriel, la vérification de l'état utilise le protocole HTTP. Par conséquent, assurez-vous que la règle de pare-feu autorise les connexions au port 80. Pour en savoir plus, consultez Configurer la vérification de l'état et l'autoréparation des groupes d'instances gérés.

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.

Configurer le service Web

Ce tutoriel utilise une application Web stockée sur GitHub. Si vous souhaitez en savoir plus sur la mise en œuvre de l'application, consultez le dépôt GitHub GoogleCloudPlatform/python-docs-samples.

Pour configurer le service Web de démonstration, créez un modèle d'instance qui lance le serveur Web de démonstration au démarrage. Utilisez ensuite ce modèle d'instance pour déployer un groupe d'instances géré et activer l'autoréparation.

Console

Créez un modèle d'instance. Incluez un script de démarrage qui lance le serveur Web de démonstration.
1. Dans la console Google Cloud , accédez à la page Créer un modèle d'instance.
  
  Accéder à la page Créer un modèle d'instance
2. Définissez le paramètre Nom sur webserver-template.
3. Dans la section Emplacement, dans le menu déroulant Région, sélectionnez europe-west1.
4. Dans la section Configuration de la machine, sélectionnez e2-medium dans le menu déroulant Type de machine.
5. Dans la section Pare-feu, cochez la case Autoriser le trafic HTTP.
6. Développez la section Options avancées pour afficher les paramètres avancés. Plusieurs sous-sections s'affichent.
7. Dans la section Gestion, recherchez Automatisation et saisissez le script de démarrage suivant :
```
apt-get update
apt-get -y install git python3-pip python3-venv
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
python3 -m venv venv
./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
./venv/bin/pip3 install gunicorn
./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo
```
8. Conservez les valeurs par défaut des autres options.
9. Cliquez sur Créer.
Déployez le serveur Web en tant que groupe d'instances géré.
1. Dans la console Google Cloud , accédez à la page Créer un groupe d'instances.
  
  Accéder à la page Créer un groupe d'instances
2. Définissez le paramètre Nom sur webserver-group.
3. Pour Modèle d'instance, sélectionnez webserver-template.
4. Pour Région, sélectionnez europe-west1.
5. Pour Zone, sélectionnez europe-west1-b.
6. Dans la section Autoscaling, pour Mode autoscaling, sélectionnez Désactivé : ne pas effectuer d'autoscaling.
7. Revenez au champ Nombre d'instances et définissez-le sur 3.
8. Dans la section Réparation automatique, procédez comme suit :
  1. Dans le menu déroulant Vérification de l'état, sélectionnez autohealer-check.
  2. Définissez Délai initial sur 300.
    
    Remarque : 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. 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.
9. Conservez les valeurs par défaut des autres options.
10. Cliquez sur Créer.
Créez une règle de pare-feu qui autorise l'envoi de requêtes HTTP aux serveurs Web.
1. Dans la console Google Cloud , accédez à la page Créer une règle de pare-feu.
  
  Accéder à la page "Créer une règle de pare-feu"
2. Dans le champ Nom, saisissez default-allow-http.
3. Pour Réseau, sélectionnez default.
4. Pour Cibles, sélectionnez Specified target tags.
5. Pour Tags cibles, saisissez http-server.
6. Pour Filtre source, sélectionnez IPv4 ranges.
7. Dans le champ Plages IPv4 sources, saisissez 0.0.0.0/0 pour autoriser l'accès pour toutes les adresses IP.
8. Dans Protocoles et ports, sélectionnez TCP et saisissez 80.
9. Conservez les valeurs par défaut des autres options.
10. Cliquez sur Créer.

gcloud

Créez un modèle d'instance. Incluez un script de démarrage qui lance le serveur Web de démonstration.

gcloud compute instance-templates create webserver-template \
    --instance-template-region europe-west1 \
    --machine-type e2-medium \
    --tags http-server \
    --metadata startup-script='
  apt-get update
  apt-get -y install git python3-pip python3-venv
  git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
  python3 -m venv venv
  ./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
  ./venv/bin/pip3 install gunicorn
  ./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo'

Créez un groupe d'instances géré.
```
gcloud compute instance-groups managed create webserver-group \
    --zone europe-west1-b \
    --template projects/PROJECT_ID/regions/europe-west1/instanceTemplates/webserver-template \
    --size 3 \
    --health-check projects/PROJECT_ID/regions/europe-west1/healthChecks/autohealer-check \
    --initial-delay 300
```
Remarque : 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 MIG remplace le champ currentAction de la VM par VERIFYING. La valeur du délai initial doit être comprise entre 0 et 3 600 secondes. La valeur par défaut est 0.

Créez une règle de pare-feu qui autorise l'envoi de requêtes HTTP aux serveurs Web.

gcloud compute firewall-rules create default-allow-http \
    --network default \
    --allow tcp:80 \
    --target-tags http-server

Attendez quelques minutes que le groupe d'instances géré crée et valide ses VM.

Simuler des échecs de la vérification de l'état

Pour simuler des échecs de la vérification de l'état, le serveur Web de démonstration vous permet d'en forcer un.

Console

Accédez à une VM de serveur Web.
1. Dans la console Google Cloud , accédez à la page Instances de VM.
  
  Accéder à la page Instances de VM
2. Pour n'importe quelle VM webserver-group, sous la colonne Adresse IP externe, cliquez sur l'adresse IP. Un nouvel onglet s'ouvre dans votre navigateur Web. Si la requête dépasse le délai ou si la page Web n'est pas disponible, attendez une minute que la configuration du serveur se termine et réessayez.
Le serveur Web de démonstration affiche une page semblable à celle-ci :
Sur la page Web de démonstration, cliquez sur Rendre non opérationnel.

Cela entraîne l'échec de la vérification de l'état du serveur Web. Plus précisément, le serveur Web fait en sorte que le chemin d'accès /health renvoie une réponse HTTP 500 (Internal Server Error). Vous pouvez le vérifier par vous-même en cliquant sur le bouton Vérifier l'état. Cette méthode cesse de fonctionner une fois que le processus d'autoréparation a lancé le redémarrage de la VM.
Attendez que le processus d'autoréparation effectue une action.
1. Dans la console Google Cloud , accédez à la page Instances de VM.
  
  Accéder à la page Instances de VM
2. Attendez que l'état de la VM du serveur Web change. La coche verte en regard du nom de la VM devrait se transformer en un carré gris, vous indiquant que le processus d'autoréparation a lancé le redémarrage de la VM non opérationnelle.
3. Cliquez régulièrement sur Actualiser en haut de la page pour obtenir l'état le plus récent.
4. Le processus d'autoréparation est terminé lorsque le carré gris redevient une coche verte, indiquant ainsi que la VM est de nouveau opérationnelle.

gcloud

Surveillez l'état du groupe d'instances géré. (Lorsque vous avez terminé, appuyez sur Ctrl+C pour quitter).

while : ; do
  gcloud compute instance-groups managed list-instances webserver-group \
  --zone europe-west1-b
  sleep 5  # Wait for 5 seconds
done

  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-4qbx
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-m5v5
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

Toutes les VM du groupe doivent afficher STATUS: RUNNING et ACTION: NONE. Si ce n'est pas le cas, attendez quelques minutes que la configuration des VM se termine, puis réessayez.

Ouvrez une nouvelle session Cloud Shell avec Google Cloud CLI installée.
Remarque : Si vous utilisez Cloud Shell, vous pouvez ouvrir plusieurs sessions.
Obtenez l'adresse d'une VM de serveur Web.
```
gcloud compute instances list --filter webserver-group
```
Sous la colonne EXTERNAL_IP, copiez l'adresse IP de n'importe quelle VM de serveur Web et enregistrez-la en tant que variable bash locale.
```
export IP_ADDRESS=EXTERNAL_IP_ADDRESS
```
Vérifiez que la configuration du serveur Web est terminée. Le serveur renvoie une réponse HTTP 200 OK.
```
curl --head $IP_ADDRESS/health
```
```
HTTP/1.1 200 OK
Server: gunicorn
...
```
Si vous obtenez une erreur Connection refused, attendez une minute que la configuration du serveur se termine et réessayez.
Rendez le serveur Web non opérationnel.
```
curl $IP_ADDRESS/makeUnhealthy > /dev/null
```
Cela entraîne l'échec de la vérification de l'état du serveur Web. Plus précisément, le serveur Web fait en sorte que le chemin d'accès /health renvoie une réponse HTTP 500 INTERNAL SERVER ERROR. Vous pouvez le vérifier par vous-même en envoyant rapidement une requête à /health. Cette méthode cesse de fonctionner une fois que le processus d'autoréparation a lancé le redémarrage de la VM.
```
curl --head $IP_ADDRESS/health
```
```
HTTP/1.1 500 INTERNAL SERVER ERROR
Server: gunicorn
...
```
Revenez à votre première session de shell pour surveiller le groupe d'instances géré et attendez que le processus d'autoréparation effectue une action.
1. Une fois que le processus d'autoréparation a démarré, les colonnes STATUS et ACTION sont mises à jour, indiquant ainsi qu'il a lancé le redémarrage de la VM non opérationnelle.
```
  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: STOPPING
  HEALTH_STATE: UNHEALTHY
  ACTION: RECREATING
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...
```
2. Le processus d'autoréparation a terminé lorsque la VM affiche à nouveau la valeur RUNNING pour STATUS et la valeur NONE pour ACTION, indiquant ainsi que la VM a bien été redémarrée.
```
  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...
```
3. Lorsque vous avez terminé de surveiller le groupe d'instances géré, appuyez sur Ctrl+C pour quitter.
Remarque : Pour en savoir plus sur les états et actions VM;instances possibles, consultez la page Cycle de vie des instances et la section Actions en cours sur les instances.

N'hésitez pas à répéter cet exercice. Voici quelques idées :

Que se passe-t-il si vous rendez toutes les VM non opérationnelles en même temps ? Pour plus d'informations sur le comportement de l'autoréparation lors d'échecs simultanés, consultez la section Comportement de l'autoréparation.
Pouvez-vous mettre à jour la configuration de la vérification de l'état;état pour réparer les VM aussi rapidement que possible ? En pratique, vous devez définir les paramètres de vérification de l'état de façon à utiliser des valeurs conservatrices, comme expliqué dans ce tutoriel. Sinon, des VM risquent d'être supprimées par erreur et d'être redémarrées alors qu'il n'y a pas de réel problème.
Le groupe d'instances géré a un paramètre de configuration initial delay. Pouvez-vous déterminer le délai minimal requis pour ce serveur Web de démonstration ? En pratique, vous devez définir le délai sur une durée un peu plus longue (de l'ordre de 10 à 20 %) qu'il ne faut à une VM pour démarrer et commencer à diffuser des requêtes d'application. Sinon, la VM risque d'être bloquée dans une boucle de démarrage d'autoréparation.

Afficher l'historique du processus d'autoréparation (facultatif)

Pour afficher l'historique des opérations d'autoréparation, utilisez la commande gcloud suivante :

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

Pour en savoir plus, consultez la section Afficher l'historique des opérations d'autoréparation.