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 facturables de Google Cloud, dont :- Compute Engine
Avant de commencer
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine API.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine API.
Si vous préférez travailler à partir de la ligne de commande, installez Google Cloud CLI.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
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 Google Cloud 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.
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 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. Vous pouvez utiliser une vérification d'é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. Dans ce tutoriel, vous allez créer une vérification d'état globale.
Console
Créez une vérification d'état.
Dans Google Cloud Console, accédez à la page Vérifications d'état.
Cliquez sur Créer une vérification d'état.
Dans le champ Nom, saisissez
autohealer-check
.Définissez le champ d'application sur
Global
. Pour l'autoréparation, vous pouvez utiliser une vérification d'état régionale ou globale.Pour Protocole, sélectionnez
HTTP
.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éponseHTTP 200 (OK)
s'il est opérationnel ou une réponseHTTP 500 (Internal Server Error)
dans le cas contraire.Définissez les critères de vérification d'état :
- 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. - Définissez Délai avant expiration sur
5
. Ceci définit la durée pendant laquelle Google Cloud attend une réponse à une vérification. Cette valeur doit être inférieure ou égale à l'intervalle entre deux tests. - 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. - 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.
- Définissez Intervalle entre deux tests sur
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.
Dans la console Google Cloud, accédez à la page Créer une règle de pare-feu.
Dans le champ Nom, saisissez
default-allow-http-health-check
.Pour Réseau, sélectionnez
default
.Pour Cibles, sélectionnez
All instances in the network
.Pour Filtre source, sélectionnez
IP ranges
.Pour Plages d'adresses IP sources, saisissez
130.211.0.0/22
et35.191.0.0/16
.Dans Protocoles et ports, sélectionnez tcp et saisissez
80
.Cliquez sur Créer.
gcloud
Créez une vérification d'état globale à l'aide de la commande
health-checks create http
.gcloud compute health-checks create http autohealer-check \ --global \ --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 Cloud attend 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 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 d'accès/health
de sorte qu'il renvoie une réponseHTTP 200 (OK)
s'il est opérationnel ou une réponseHTTP 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
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. 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.
Dans Google Cloud Console, accédez à la page Modèles d'instances.
Cliquez sur Create instance template (Créer un modèle d'instance).
Définissez le paramètre Nom sur
webserver-template
.Pour Configuration de la machine, sélectionnez
micro
(e2-micro).Sous Pare-feu, cochez la case Autoriser le trafic HTTP.
Cliquez sur Gestion, sécurité, disques, réseau et location unique pour afficher les paramètres avancés. Plusieurs onglets apparaissent.
Sous l'onglet Gestion, recherchez Automatisation et saisissez le script de démarrage suivant :
sudo apt update && sudo apt -y install git gunicorn3 python3-pip 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
Cliquez sur Créer.
Déployez le serveur Web en tant que groupe d'instances géré.
Dans Google Cloud Console, accédez à la page Groupes d'instances.
Cliquez sur Créer un groupe d'instances.
Définissez le paramètre Nom sur
webserver-group
.Pour Région, sélectionnez
europe-west1
.Pour Zone, sélectionnez
europe-west1-b
.Pour Modèle d'instance, sélectionnez
webserver-template
.Pour Autoscaling, sélectionnez Ne pas procéder à un autoscaling.
Définissez Nombre d'instances sur
3
.Pour Vérification d'état, sélectionnez
autohealer-check
.Définissez Délai initial sur
90
.Cliquez sur Créer.
Créez une règle de pare-feu qui autorise l'envoi de requêtes HTTP aux serveurs Web.
Dans la console Google Cloud, accédez à la page Créer une règle de pare-feu.
Dans le champ Nom, saisissez
default-allow-http
.Pour Réseau, sélectionnez
default
.Pour Cibles, sélectionnez
Specified target tags
.Pour Tags cibles, saisissez
http-server
.Pour Filtre source, sélectionnez
IP ranges
.Dans le champ Plages d'adresses IP sources, saisissez
0.0.0.0/0
.Dans Protocoles et ports, sélectionnez tcp et saisissez
80
.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 \ --machine-type e2-micro \ --tags http-server \ --metadata startup-script=' sudo apt update && sudo apt -y install git gunicorn3 python3-pip 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'
Créer 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
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
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 instance de serveur Web.
Dans Google Cloud Console, accédez à la page Instances de VM.
Sous la colonne Adresse IP externe, cliquez sur l'adresse IP de n'importe quelle instance
webserver-group
. 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éponseHTTP 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 l'instance.Attendez que le processus d'autoréparation effectue une action.
Dans Google Cloud Console, accédez à la page Instances de VM.
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.
Cliquez régulièrement sur Actualiser en haut de la page pour obtenir l'état le plus récent.
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
Surveillez l'état du groupe d'instances. (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 \ ; 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 queSTAGING
, attendez une minute que la configuration de l'instance se termine et réessayez.Ouvrez une nouvelle session Cloud Shell avec Google Cloud CLI installée.
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
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/19.6.0 ...
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éponseHTTP 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 ...
Revenez à votre première session de shell pour surveiller le groupe d'instances et attendez que le processus d'autoréparation effectue une action.
Une fois que le processus d'autoréparation a démarré, les colonnes
STATUS
etACTION
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
Le processus d'autoréparation a terminé lorsque l'instance affiche à nouveau la valeur
RUNNING
pourSTATUS
et la valeurNONE
pourACTION
, 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
Lorsque vous avez terminé de surveiller le groupe d'instances, appuyez sur
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 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 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.
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.
Nettoyer
Une fois le tutoriel terminé, vous pouvez procéder au nettoyage des ressources que vous avez créées 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
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
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
- In the Google Cloud console, go to the Instance groups page.
-
Select the checkbox for
your
webserver-group
instance group. - To delete the instance group, click Delete.
gcloud
gcloud compute instance-groups managed delete webserver-group --zone europe-west1-b -q
Supprimer le modèle d'instance
Console
Dans Google Cloud Console, accédez à la page Modèles d'instances.
Cochez la case en regard du modèle d'instance.
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
Dans Google Cloud Console, accédez à la page Vérifications d'état.
Cochez la case en regard de la vérification de l'état.
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
Dans Google Cloud Console, accédez à la page Règles de pare-feu.
Cochez les cases en regard des règles de pare-feu nommées
default-allow-http
etdefault-allow-http-health-check
.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
- Essayez un autre tutoriel
- Apprenez-en plus sur les groupes d'instances gérés.
- Apprenez-en plus sur la conception de systèmes robustes.
- Apprenez-en plus sur la création d'applications Web fiables et évolutives sur Google Cloud.