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

Objectifs

  • Configurer une vérification de l'état et une règle d'autoréparation
  • Configurer un service Web de démonstration sur un groupe d'instances géré
  • Simuler des échecs de la vérification de l'état et assister au processus de récupération de l'autoréparation

Coûts

Ce tutoriel fait appel à des composants payants de GCP tels que :

  • Compute Engine

Avant de commencer

    Connectez-vous à votre compte Google.

    Si vous n'en possédez pas déjà un, vous devez en créer un.

    Sélectionnez ou créez un projet Google Cloud Platform.

    Accéder à la page "Gérer les ressources"

    Assurez-vous que la facturation est activée pour votre projet Google Cloud Platform.

    Découvrir comment activer la facturation

    Activez Compute Enginel'API requise.

    Activer l'API.

Si vous préférez travailler à partir de la ligne de commande, installez l'outil de ligne de commande gcloud.

Architecture de l'application

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

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

Schéma de l'architecture système montrant une vérification de l'état et 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 instance à l'aide d'un protocole spécifié, tel que HTTP(S), SSL ou TCP. Pour en savoir plus, consultez la documentation sur le fonctionnement des vérifications d'état et sur les ports, les protocoles et les catégories de vérification de l'état.

Dans ce tutoriel, la vérification de l'état fait appel au protocole HTTP et teste le chemin 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 /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 en savoir plus, consultez la documentation sur les 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 du réseau de sorte qu'il autorise les tests de vérification de l'état.

Console

  1. Créez une vérification d'état.

    1. Accédez à la page Vérifications d'état dans la console GCP.
      Accéder à la page Vérifications d'état
    2. Cliquez sur Créer une vérification d'état.
    3. Définissez Nom sur autohealer-check.
    4. Pour Protocole, sélectionnez HTTP.
    5. 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 /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.
    6. 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 le temps pendant lequel GCP attend une réponse à un test. Sa 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 l'instance 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 l'instance soit considérée comme non opérationnelle.
    7. Cliquez sur Créer en bas de la page.
  2. Créez une règle de pare-feu permettant aux tests de vérification de l'état d'effectuer des requêtes HTTP.

    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. Pour 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 IP ranges.
    6. Pour Plages d'adresses IP sources, saisissez 130.211.0.0/22 et 35.191.0.0/16.
    7. Dans Protocoles et ports, sélectionnez tcp et saisissez 80.
    8. Cliquez sur Créer.

gcloud

  1. Créez une vérification d'état.

    gcloud compute health-checks create http autohealer-check \
        --check-interval 10 \
        --timeout 5 \
        --healthy-threshold 2 \
        --unhealthy-threshold 3 \
        --request-path "/health"
    
    • check-interval définit la durée entre le début d'un test et le début du suivant.
    • timeout définit le temps pendant lequel GCP attend une réponse à un test. Sa valeur doit être inférieure ou égale à l'intervalle entre deux tests.
    • healthy-threshold définit le nombre de tests séquentiels qui doivent réussir pour que l'instance soit considérée comme opérationnelle.
    • unhealthy-threshold définit le nombre de tests séquentiels qui doivent échouer pour que l'instance 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 /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.
  2. 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
    

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). Lorsqu'une valeur est trop longue, 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 la documentation sur le dépôt GitHub de Google Cloud Platform.

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

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

    1. Accédez à la page Modèles d'instances dans la console GCP.
      Accéder à la page "Modèles d'instance"
    2. Cliquez sur Créer un modèle d'instance.
    3. Définissez Nom sur webserver-template.
    4. Pour Configuration de la machine, sélectionnez micro (f1-micro).
    5. Sous Pare-feu, cochez la case Autoriser le trafic HTTP.
    6. Cliquez sur Gestion, sécurité, disques, réseau et location unique pour faire apparaître les paramètres avancés. Divers onglets doivent s'afficher.
    7. Sous l'onglet Gestion, recherchez Automatisation et saisissez le script de démarrage suivant :
      sudo apt-get update && sudo apt-get install git gunicorn3 python3-pip -y
      git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
      cd python-docs-samples/compute/managed-instances/demo
      sudo pip3 install -r requirements.txt
      sudo gunicorn3 --bind 0.0.0.0:80 app:app --daemon
      
    8. Cliquez sur Créer en bas de la page.
  2. Déployez le serveur Web en tant que groupe d'instances géré.

    1. Accédez à la page Groupes d'instances dans la console GCP.
      Accéder à la page Groupes d'instances
    2. Cliquez sur Créer un groupe d'instances.
    3. Définissez Nom sur webserver-group.
    4. Pour Région, sélectionnez europe-west1.
    5. Pour Zone, sélectionnez europe-west1-b.
    6. Pour Modèle d'instance, sélectionnez webserver-template.
    7. Pour Autoscaling, sélectionnez Désactivé.
    8. Définissez Nombre d'instances sur 3.
    9. Pour Vérification d'état, sélectionnez autohealer-check.
    10. Définissez Délai initial sur 90.
    11. Cliquez sur Créer.
  3. Créez une règle de pare-feu qui autorisera l'envoi de requêtes HTTP aux serveurs Web.

    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. Pour 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 IP ranges.
    7. Pour Plages d'adresses IP sources, saisissez 0.0.0.0/0.
    8. Dans Protocoles et ports, sélectionnez tcp et saisissez 80.
    9. Cliquez sur Créer.

gcloud

  1. 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 \
        --machine-type f1-micro \
        --tags http-server \
        --metadata startup-script='
      sudo apt-get update && sudo apt-get install git gunicorn3 python3-pip -y
      git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
      cd python-docs-samples/compute/managed-instances/demo
      sudo pip3 install -r requirements.txt
      sudo gunicorn3 --bind 0.0.0.0:80 app:app --daemon'
    
  2. Créez ensuite un groupe d'instances.

    gcloud compute instance-groups managed create webserver-group \
        --zone europe-west1-b \
        --template webserver-template \
        --size 3 \
        --health-check autohealer-check \
        --initial-delay 90
    
  3. Créez une règle de pare-feu qui autorisera 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
    

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

  1. Accédez à une instance de serveur Web.

    1. Accédez à la page Instances de VM dans la console GCP.
      Accéder à la page Instances de VM
    2. Sous la colonne Adresse IP externe, cliquez sur l'adresse IP de n'importe quelle instance webserver-group. Un nouvel onglet doit s'ouvrir 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 :

    Page Web de démonstration simple présentant des boutons d'état verts et des boutons d'action bleus

  2. Sur la page Web de démonstration, cliquez sur Make unhealthy (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 /health renvoie une réponse HTTP 500 (Internal Server Error). Vous pouvez le vérifier par vous-même en cliquant sur le bouton Check health (Vérifier l'état). Cette méthode cesse de fonctionner une fois que le processus d'autoréparation a lancé le redémarrage de l'instance.

  3. Attendez que le processus d'autoréparation effectue une action.

    1. Accédez à la page Instances de VM dans la console GCP.
      Accéder à la page Instances de VM
    2. Attendez que l'état de l'instance de serveur Web change. La coche verte en regard du nom de l'instance devrait se transformer en un carré gris, vous indiquant que le processus d'autoréparation a lancé le redémarrage de l'instance 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 l'instance est de nouveau opérationnelle.

gcloud

  1. Surveillez l'état du groupe d'instances. (Utilisez Ctrl-C pour arrêter lorsque vous avez terminé.)

    while : ; do \
        gcloud compute instance-groups managed list-instances webserver-group \
        --zone europe-west1-b \
        ; done
    
    NAME                 ZONE            STATUS   ACTION  INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
    webserver-group-d5tz  europe-west1-b  RUNNING  NONE    webserver-template
    webserver-group-q6t9  europe-west1-b  RUNNING  NONE    webserver-template
    webserver-group-tbpj  europe-west1-b  RUNNING  NONE    webserver-template
    

    Si des instances affichent un état différent de RUNNING, tel que STAGING, attendez une minute que la configuration de l'instance se termine et réessayez.

  2. Démarrez une nouvelle session de shell où gcloud est installé.

  3. Obtenez l'adresse d'une instance de serveur Web.

    gcloud compute instances list --filter webserver-group
    

    Sous la colonne EXTERNAL_IP, copiez l'adresse IP de n'importe quelle instance de serveur Web et enregistrez-la en tant que variable bash locale.

    export IP_ADDRESS=EXTERNAL_IP_ADDRESS
    
  4. Vérifiez que la configuration du serveur Web est terminée. Le serveur doit renvoyer une réponse HTTP 200 OK.

    curl --head $IP_ADDRESS/health
    
    HTTP/1.1 200 OK
    Server: gunicorn/19.6.0
    ...
    

    Si vous obtenez une erreur Connection refused, attendez une minute que la configuration du serveur se termine et réessayez.

  5. 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 /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 l'instance.

    curl --head $IP_ADDRESS/health
    
    HTTP/1.1 500 INTERNAL SERVER ERROR
    Server: gunicorn/19.6.0
    ...
    
  6. Revenez à votre première session de shell pour surveiller le groupe d'instances 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 l'instance non opérationnelle.

      NAME                 ZONE            STATUS    ACTION      INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
      webserver-group-d5tz  europe-west1-b  RUNNING   NONE        webserver-template
      webserver-group-q6t9  europe-west1-b  RUNNING   NONE        webserver-template
      webserver-group-tbpj  europe-west1-b  STOPPING  RECREATING  webserver-template
      
    2. Le processus d'autoréparation a terminé lorsque l'instance affiche à nouveau la valeur RUNNING pour STATUS et la valeur NONE pour ACTION, indiquant ainsi que l'instance a bien été redémarrée.

      NAME                 ZONE            STATUS   ACTION  INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
      webserver-group-d5tz  europe-west1-b  RUNNING  NONE    webserver-template
      webserver-group-q6t9  europe-west1-b  RUNNING  NONE    webserver-template
      webserver-group-tbpj  europe-west1-b  RUNNING  NONE    webserver-template
      
    3. Lorsque vous avez terminé de surveiller le groupe d'instances, utilisez Ctrl-C pour quitter.

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

  • Que se passe-t-il si vous rendez toutes les instances non opérationnelles en même temps ? Pour en savoir plus sur le comportement de l'autoréparation en cas de défaillances simultanées, consultez la documentation sur le comportement de l'autoréparation.

  • Pouvez-vous mettre à jour la configuration de la vérification de l'état pour réparer les instances 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 instances 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 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 instance pour démarrer et commencer à diffuser des requêtes d'application. Sinon, l'instance risque d'être bloquée dans une boucle de démarrage d'autoréparation.

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

Vous pouvez afficher un historique des opérations d'autoréparation avec la commande gcloud.

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

Pour en savoir plus, consultez la documentation sur l'affichage de l'historique des opérations d'autoréparation

Nettoyer

Une fois que vous avez terminé le tutoriel sur l'autoréparation, vous pouvez procéder au nettoyage des ressources que vous avez créées sur GCP afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées. Dans les sections suivantes, nous allons voir comment supprimer ou désactiver ces ressources.

Si vous avez créé un projet distinct pour ce tutoriel, supprimez-le entièrement. Sinon, si le projet contient des ressources que vous souhaitez conserver, ne supprimez que les ressources créées spécifiquement pour ce tutoriel.

Supprimer le projet

  1. Dans la console GCP, accédez à la page "Projets".

    Accéder à la page Projets

  2. Dans la liste des projets, sélectionnez celui que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer des ressources spécifiques

Si vous ne pouvez pas supprimer le projet utilisé pour ce tutoriel, supprimez les ressources de ce dernier individuellement.

Supprimer le groupe d'instances

Console

  1. Dans la console GCP, accédez à la page "Groupes d'instances".

    Accéder à la page Groupes d'instances

  2. Cochez la case à côté de votre groupe d'instances webserver-group.
  3. Cliquez sur le bouton Supprimer en haut de la page pour supprimer le groupe d'instances.

gcloud

gcloud compute instance-groups managed delete webserver-group --zone europe-west1-b -q

Supprimer le modèle d'instance

Console

  1. Accédez à la page Modèles d'instances dans la console GCP.

    Accéder à la page Modèles d'instance

  2. Cochez la case en regard du modèle d'instance.

  3. Cliquez sur Supprimer en haut de la page. Dans la nouvelle fenêtre, cliquez sur Supprimer pour confirmer la suppression.

gcloud

gcloud compute instance-templates delete webserver-template -q

Supprimer la vérification de l'état

Console

  1. Accédez à la page Vérifications d'état dans la console GCP.

    Accéder à la page "Vérifications d'état"

  2. Cochez la case en regard de la vérification de l'état.

  3. Cliquez sur Supprimer en haut de la page. Dans la nouvelle fenêtre, cliquez sur Supprimer pour confirmer la suppression.

gcloud

gcloud compute health-checks delete autohealer-check -q

Supprimer les règles de pare-feu

Console

  1. Accédez à la page Règles de pare-feu de la console GCP.

    Accéder à la page Règles de pare-feu

  2. Cochez les cases en regard des règles de pare-feu nommées default-allow-http et default-allow-http-health-check.

  3. Cliquez sur Supprimer en haut de la page. Dans la nouvelle fenêtre, cliquez sur Supprimer pour confirmer la suppression.

gcloud

gcloud compute firewall-rules delete default-allow-http default-allow-http-health-check -q

Étapes suivantes

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

Envoyer des commentaires concernant…

Documentation Compute Engine