Déployer un serveur Web récupérable à froid avec des disques persistants régionaux

Last reviewed 2021-08-04 UTC

---

Ce document explique comment déployer une topologie de basculement à froid pour un serveur Web à l'aide d'un groupe d'instances géré avec des disques persistants régionaux. Ce document est destiné aux architectes et aux personnes travaillant dans les équipes opérationnelles et administratives.

Vous créez un groupe d'instances géré qui exécute une VM unique avec un disque persistant régional qui stocke des données. Un équilibreur de charge d'application externe dirige les utilisateurs vers la VM qui s'exécute dans le groupe d'instances géré, comme illustré dans l'image suivante :

En cas de défaillance d'une instance, le groupe d'instances géré tente de recréer la VM dans la même zone. Si la défaillance est au niveau de la zone, Cloud Monitoring ou un autre outil similaire peut vous informer d'un problème auquel cas vous devez créer manuellement un autre groupe d'instances géré dans une autre zone de travail. Dans les deux scénarios de basculement, la plate-forme associe le disque persistant régional à la nouvelle VM dans le groupe d'instances.

Dans ce document, vous utilisez l'adresse IP externe de la VM ou de l'équilibreur de charge pour afficher une page de base sur le serveur Web. Cette approche vous permet de tester le modèle de basculement à froid si vous n'avez pas de nom de domaine enregistré, sans aucun changement DNS. Dans un environnement de production, créez et configurez une zone et un enregistrement Cloud DNS associés à l'adresse IP externe attribuée à l'équilibreur de charge.

Ce scénario équilibre le coût d'exécution de plusieurs VM avec un certain niveau de protection des données. Vos coûts sont plus élevés lorsque vous exécutez un disque persistant régional qui fournit une réplication continue des données entre deux zones d'une région, mais vous minimisez le risque de perte de données en cas de défaillance au niveau de la zone. Pour réduire vos coûts de stockage, envisagez plutôt de déployer un serveur Web récupérable à froid à l'aide d'instantanés de disque persistant.

Le tableau suivant souligne les principales différences entre les options de protection des données des approches de récupération à froid utilisant des disques persistants régionaux ou des instantanés de disques persistants. Pour plus d'informations, consultez la section Options de haute disponibilité avec des disques persistants.

	Disques persistants régionaux	Instantanés de disque persistant
Perte de données : objectif de point de récupération (RPO)	Zéro pour une seule défaillance, telle qu'une interruption continue dans une zone ou une déconnexion du réseau.	Toutes les données depuis la dernière prise d'instantané, soit généralement une heure ou plus. La perte potentielle de données dépend de votre programmation d'instantanés, qui contrôle la fréquence à laquelle les instantanés sont pris.
Objectif de temps de récupération (RTO)	Temps de déploiement d'une nouvelle VM, plus quelques secondes pour la réinstallation du disque persistant régional.	Temps de déploiement d'une nouvelle VM, plus temps de création d'un disque persistant à partir du dernier instantané. Le temps de création du disque dépend de la taille de l'instantané et peut durer plusieurs dizaines de minutes, voire plusieurs heures.
Coût	Les coûts de stockage sont doublés, car le disque persistant régional est répliqué en continu dans une autre zone.	Vous ne payez que le montant pour l'espace d'instantané utilisé.
	Pour en savoir plus, consultez la section Tarifs des disques et des images.

Objectifs

• Créer un groupe d'instances géré pour exécuter une VM avec un disque persistant régional.
• Créer un modèle d'instance et un script de démarrage.
• Créer et configurer un équilibreur de charge d'application externe
• Tester le basculement du serveur Web à froid avec un groupe d'instances géré de remplacement.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• Compute Engine
• Mise en réseau
• Persistent Disk

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   Accéder au sélecteur de projet

3. Vérifiez que la facturation est activée pour votre projet Google Cloud.

4. Activez l'API Compute Engine

   Activer l'API

5. Installez Google Cloud CLI.

6. Pour initialiser gcloudCLI, exécutez la commande suivante :

   gcloud init

7. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   Accéder au sélecteur de projet

8. Vérifiez que la facturation est activée pour votre projet Google Cloud.

9. Activez l'API Compute Engine

   Activer l'API

10. Installez Google Cloud CLI.

11. Pour initialiser gcloudCLI, exécutez la commande suivante :

    gcloud init

Vous pouvez exécuter Google Cloud CLI dans la console Google Cloud sans avoir à installer Google Cloud CLI. Pour exécuter gcloud CLI dans la console Google Cloud, utilisez Cloud Shell.

Préparer l'environnement

Dans cette section, vous allez définir des variables pour les noms et les emplacements de vos ressources. Ces variables sont utilisées par les commandes de Google Cloud CLI lors du déploiement des ressources.

Tout au long de ce tutoriel, sauf indication contraire, vous devez saisir les commandes dans Cloud Shell ou dans votre environnement de développement local.

1. Remplacez PROJECT_ID par votre ID de projet : Si nécessaire, indiquez votre propre suffixe de nom pour les ressources, par exemple app.

   Spécifiez une région, telle que us-central1, et deux zones de cette région, telles que us-central1-a et us-central1-f. Ces zones définissent l'emplacement où le disque persistant régional et le groupe d'instances géré initial sont déployés, et où vous pouvez basculer manuellement si nécessaire.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION=us-central1
   ZONE1=us-central1-a
   ZONE2=us-central1-f
   

Créer un VPC et un sous-réseau

Pour fournir un accès réseau aux VM, créez un cloud privé virtuel (VPC) et un sous-réseau. Étant donné que le groupe d'instances géré fonctionne dans les zones d'une même région, un seul sous-réseau est créé. Pour en savoir plus sur les avantages du mode de sous-réseau personnalisé afin de gérer les plages d'adresses IP utilisées dans votre environnement, consultez la section Utiliser des réseaux VPC en mode personnalisé.

1. Créez le VPC avec un mode de sous-réseau personnalisé :

   gcloud compute networks create network-$NAME_SUFFIX \
       --subnet-mode=custom
   

   Si une invite Cloud Shell s'affiche, autorisez cette première requête à effectuer des appels d'API.

2. Créez un sous-réseau dans le nouveau VPC. Définissez votre propre plage d'adresses, telle que 10.1.0.0/20, en fonction de votre plage réseau :

   gcloud compute networks subnets create subnet-$NAME_SUFFIX-$REGION \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION
   

Créer des règles de pare-feu

1. Créez des règles de pare-feu pour autoriser le trafic Web et les vérifications d'état pour l'équilibreur de charge et les groupes d'instances gérés :

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   La règle HTTP suivante autorise le trafic vers toutes les VM sur lesquelles l'option http-server est appliquée, et depuis n'importe quelle source utilisant la plage 0.0.0.0/0. Concernant la règle de vérification de l'état, les plages par défaut de Google Cloud sont définies pour permettre à la plate-forme de vérifier correctement l'état des ressources.

2. Afin d'autoriser le trafic SSH pour la configuration initiale d'une image de VM de base, définissez le champ d'application de la règle de pare-feu dans votre environnement à l'aide du paramètre --source-range. Vous devrez peut-être collaborer avec votre équipe réseau pour déterminer les plages sources utilisées par votre organisation.

   Important : Nous vous déconseillons d'utiliser une large plage de 0.0.0.0/0 qui pourrait autoriser tout le trafic. Pour acheminer le trafic vers une seule adresse IP, utilisez un masque de réseau /32, tel que 35.230.62.163/32.

   Remplacez IP_ADDRESS_SCOPE par vos propres champs d'application d'adresses IP :

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. Après avoir créé les règles de pare-feu, vérifiez que les trois règles ont bien été ajoutées :

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   L'exemple de résultat suivant montre que les trois règles ont été correctement créées :

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

Créer un disque persistant régional et une VM

Un disque persistant régional permet une réplication continue des données entre deux zones d'une même région. Les groupes d'instances gérés, qui s'exécutent dans les deux mêmes zones que le disque persistant régional, peuvent ensuite associer le disque à une VM.

Remarque : Dans ce document, vous créez et configurez manuellement la VM de base et les images. Dans les déploiements de production, utilisez vos outils et pipelines de déploiement existants pour automatiser ce processus autant que possible. Pour en savoir plus, consultez la page Gérer une Infrastructure as Code avec Terraform, Cloud Build et GitOps.

1. Créez un disque SSD de 10 Gio. Déterminez vos besoins de stockage et les coûts associés au paiement de l'espace provisionné, et non de l'espace utilisé. Pour en savoir plus, consultez la section Tarifs des disques persistants.

   gcloud compute disks create disk-$NAME_SUFFIX \
       --region $REGION \
       --replica-zones $ZONE1,$ZONE2 \
       --size=10 \
       --type=pd-ssd
   

2. Créez une VM de base en lui associant le disque persistant régional :

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE1 \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=debian-10-buster-v20210721 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --disk=mode=rw,name=disk-$NAME_SUFFIX,device-name=disk-$NAME_SUFFIX,scope=regional
   

   Vous utilisez les paramètres définis au début de ce document pour nommer la VM et vous connecter au sous-réseau approprié. Les noms sont également attribués à partir des paramètres du disque de démarrage et du disque de données.

3. Pour installer et configurer le site Web simple, connectez-vous d'abord à la VM de base via SSH :

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE1
   

4. Dans votre session SSH vers la VM, créez un script pour configurer la VM dans l'éditeur de votre choix. L'exemple suivant utilise Nano en tant qu'éditeur :

   nano configure-vm.sh
   

   Collez le script suivant dans le fichier. Mettez à jour la variable NAME_SUFFIX pour qu'elle corresponde à la valeur définie au début de ce document, par exemple app :

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

5. Écrivez le fichier et quittez votre éditeur. Par exemple, dans Nano, vous utilisez Ctrl-O pour écrire le fichier, puis vous quittez avec Ctrl-X.

6. Rendez le script de configuration exécutable, puis exécutez-le :

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

7. Quittez la session SSH sur la VM :

   exit
   

8. Obtenez l'adresse IP de la VM et utilisez curl pour afficher la page Web de base :

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE1 \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

   Cette étape confirme qu'Apache est configuré correctement et que la page est chargée à partir du disque persistant associé. Au cours des étapes suivantes, vous allez créer une image à l'aide de cette VM de base et configurer un modèle d'instance avec un script de démarrage.

Créer une image de VM et un modèle d'instance

Pour créer des VM identiques qui peuvent être déployées automatiquement sans configuration supplémentaire, vous devez utiliser une image de VM personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache. Chaque VM créée dans le groupe d'instances géré lors des étapes suivantes utilisera cette image.

1. Avant de pouvoir créer une image, vous devez arrêter la VM :

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE1
   

2. Créez une image de la VM de base configurée dans la section précédente :

   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE1 \
       --storage-location=$REGION
   

3. Créez un modèle d'instance qui définit la configuration de chaque VM :

   gcloud compute instance-templates create template-$NAME_SUFFIX \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION/subnetworks/subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=image-$NAME_SUFFIX \
       --region=$REGION \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a
   

   L'image créée à l'étape précédente est définie comme source pour chaque VM, et un script de démarrage est également défini pour installer le disque persistant régional.

Créer un groupe d'instances géré

Un groupe d'instances géré exécute les VM. Le groupe d'instances géré s'exécute dans une zone définie et surveille l'état des VM. En cas de défaillance d'une instance et si la VM cesse de s'exécuter, le groupe d'instances géré tente de recréer une VM dans la même zone et associe le disque persistant régional. Si la défaillance se produit au niveau d'une zone, vous devez effectuer manuellement le basculement à froid et créer un autre groupe d'instances géré dans une zone différente. La même image personnalisée et le même modèle d'instance sont alors utilisés pour configurer automatiquement la VM de la même manière.

1. Créez une vérification d'état pour surveiller les VM du groupe d'instances géré. Cette vérification d'état garantit que la VM répond sur le port 80. Pour vos propres applications, surveillez les ports adéquats pour vérifier l'état de la VM.

   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX --port 80
   

2. Créez un groupe d'instances géré, initialement sans aucune VM, qui utilise le modèle d'instance créé à l'étape précédente.

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE1 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

3. Créez une VM unique dans le groupe d'instances géré et associez-lui le disque persistant régional. En cas de défaillance de cette VM, le groupe d'instances géré tente de la recréer dans la même zone et de réassocier le disque persistant.

   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE1\
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   Remarque : Vous ne pouvez pas exécuter simultanément plusieurs VM dans le groupe d'instances géré. Le disque persistant régional ne peut être connecté qu'à une seule VM à la fois.

Pour ce scénario d'application récupérable à froid, ne créez pas de règles d'autoscaling pour augmenter le nombre de VM exécutées dans le groupe d'instances géré.

Créer et configurer un équilibreur de charge

Pour que les utilisateurs puissent accéder à votre site Web, vous devez autoriser le trafic vers les VM exécutées dans le groupe d'instances géré. Vous souhaitez également rediriger automatiquement le trafic vers de nouvelles VM en cas de défaillance d'une zone dans un groupe d'instances géré.

Dans la section suivante, vous allez créer un équilibreur de charge externe avec un service de backend pour le trafic HTTP sur le port 80, utiliser la vérification d'état créée lors des étapes précédentes et effectuer le mappage d'une adresse IP externe vers le service de backend.

Pour en savoir plus, consultez la section Configurer un simple équilibreur de charge HTTP externe.

1. Créez et configurez l'équilibreur de charge de votre application :

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$ZONE1 \
       --named-ports http:80 \
       --zone $ZONE1
   
   # Create a backend service and add the managed instance group to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. Obtenez l'adresse IP de la règle de transfert pour le trafic Web :

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. Utilisez curl ou ouvrez votre navigateur Web pour afficher le site Web à l'aide de l'adresse IP de l'équilibreur de charge de l'étape précédente :

   curl $IP_ADDRESS
   

   Quelques minutes sont nécessaires pour que le déploiement de l'équilibreur de charge s'achève et que le trafic soit correctement dirigé vers votre backend. Une erreur HTTP 404 ou 502 est renvoyée si l'équilibreur de charge est toujours en cours de déploiement. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

   Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

Simuler une défaillance de zone et une récupération

Examinez les déploiements de ressources avant de simuler une défaillance au niveau de la zone. Toutes les ressources ont été créées pour prendre en charge l'environnement, comme illustré dans l'image suivante :

• Une VM qui s'exécute dans un groupe d'instances géré, avec un disque persistant régional associé sur lequel est stocké un site Web de base.
• Un script de démarrage est appliqué à un modèle d'instance. Ainsi, toutes les VM créées dans le groupe d'instances géré installent le disque persistant régional.
• Une vérification d'état surveille l'état de la VM au sein du groupe d'instances géré.
• L'équilibreur de charge d'application externe dirige les utilisateurs vers la VM exécutée dans le groupe d'instances géré.
• En cas de défaillance de la VM, le groupe d'instances géré tente de recréer une VM dans la même zone. Si la défaillance est au niveau de la zone, vous devez créer manuellement un groupe d'instances géré de remplacement dans une autre zone de travail.

Dans un environnement de production, vous pouvez recevoir une alerte provenant de Cloud Monitoring ou d'une autre solution de surveillance en cas de problème. Cette alerte invite l'utilisateur à comprendre l'étendue de la défaillance avant de créer manuellement un groupe d'instances géré de remplacement dans une autre zone de travail. Une autre approche consiste à utiliser votre solution de surveillance pour répondre automatiquement aux interruptions avec le groupe d'instances géré.

Lorsque vous ou votre solution de surveillance déterminez que l'action la plus appropriée est un basculement, créez un groupe d'instances géré de remplacement. Dans ce document, vous créez manuellement cette ressource de remplacement.

1. Pour simuler une défaillance au niveau de la zone, supprimez le backend de l'équilibreur de charge et le groupe d'instances géré :

   gcloud compute backend-services remove-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --global
   
   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE1 \
         --zone=$ZONE1
   

   Lorsque vous y êtes invité, confirmez la demande de suppression du groupe d'instances géré.

   Dans un environnement de production, votre système de surveillance génère une alerte vous invitant à demander une action de basculement à froid.

2. Utilisez de nouveau curl ou votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :

   curl $IP_ADDRESS --max-time 5
   

   La requête curl échoue, car il n'existe aucune cible opérationnelle pour l'équilibreur de charge.

3. Pour simuler le basculement à froid, créez un groupe d'instances géré dans une zone différente :

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE2 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE2 \
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   L'image de VM, le modèle d'instance et le disque persistant régional conservent la configuration de l'instance d'application.

4. Mettez à jour l'équilibreur de charge pour ajouter le nouveau groupe d'instances géré et la nouvelle VM :

   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$ZONE2 \
       --named-ports http:80 \
       --zone $ZONE2
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance-group-zone=$ZONE2 \
       --global
   

5. Utilisez à nouveau curl ou votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge qui dirige le trafic vers la VM exécutée dans le groupe d'instances géré :

   curl $IP_ADDRESS
   

   Le déploiement et l'association du disque persistant régional peuvent prendre quelques minutes. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

   L'exemple de réponse suivant montre que la page Web s'exécute correctement sur la VM :

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Pour supprimer les ressources individuelles créées dans ce document, procédez comme suit :

1. Supprimez la configuration de l'équilibreur de charge :

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   

2. Supprimez le groupe d'instances géré et la vérification d'état :

   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE2 \
       --zone=$ZONE2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

3. Supprimez le modèle d'instance, l'image, la VM de base et le disque persistant :

   gcloud compute instance-templates delete template-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX --zone=$ZONE1 --quiet
   
   gcloud compute disks delete disk-$NAME_SUFFIX --region=$REGION --quiet
   

4. Supprimez les règles de pare-feu :

   gcloud compute firewall-rules delete allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete allow-http-$NAME_SUFFIX --quiet
   

5. Supprimez l'adresse IP externe statique, le sous-réseau et le VPC :

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION --region=$REGION --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

Étapes suivantes

• Pour découvrir une autre approche permettant de réduire les coûts de stockage, consultez la page Déployer un serveur Web récupérable à froid à l'aide d'instantanés de disque persistant.
• Pour apprendre à déterminer la meilleure approche pour vos propres applications et la méthode de récupération à utiliser, consultez le guide de planification de reprise après sinistre.
• Pour découvrir d'autres modèles d'applications, tels que le basculement à froid et à chaud, consultez la section Scénarios de reprise après sinistre pour les applications.
• Pour découvrir d'autres façons de gérer l'évolutivité et la disponibilité, consultez la page Modèles d'applications évolutives et résilientes.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.