Ce document est destiné aux architectes et aux personnes travaillant dans les équipes opérationnelles et administratives. Ce document décrit un exemple de modèle que vous pouvez utiliser pour vos propres déploiements dans Google Cloud.
Dans cette architecture, un équilibreur de charge dirige le trafic vers des instances Compute Engine dans des groupes d'instances gérés qui diffusent le contenu. En cas de panne, vous mettez à jour la configuration de l'équilibreur de charge d'application externe et basculez vers un site statique dans Cloud Storage.
Pour déployer cette solution, vous avez besoin d'un nom de domaine enregistré que vous contrôlez et souhaitez utiliser avec ce document.
Dans les déploiements de production, votre site Web inclut probablement beaucoup plus de fichiers et de code d'application supplémentaire sur vos machines virtuelles (VM) de groupes d'instances gérés que ce qui est indiqué dans ce document. Cloud Storage héberge ensuite une version statique plus limitée qui offre un minimum de fonctionnalités. Dans un scénario de basculement tiède, les utilisateurs voient ce site Web limité jusqu'à ce que les groupes d'instances gérés puissent récupérer et peuvent diffuser le trafic vers l'ensemble de l'interface.
Architecture
Dans cette architecture, vous allez déployer des ressources pour créer un environnement, comme indiqué dans l'image suivante :
Lorsque vous devez basculer, vous mettez à jour la configuration de l'équilibreur de charge pour diriger le trafic vers Cloud Storage, comme indiqué dans l'image suivante :
Ce modèle de basculement tiède équilibre le coût d'exécution d'un autre groupe d'instances géré dans une autre région que celle utilisée en cas de défaillance des régions principales. Le coût d'un site statique utilisant Cloud Storage est inférieur à l'exécution d'un autre groupe d'instances géré, mais il existe un court délai lorsque vous mettez à jour la configuration de l'équilibreur de charge entre les options d'hébergement. L'expérience limitée sur le site Web dans Cloud Storage est préférable à un site Web non disponible et une expérience client médiocre.
Pour découvrir une autre approche qui utilise Cloud DNS au lieu de l'équilibreur de charge d'application externe pour contrôler le basculement, consultez la page Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage. Ce modèle est utile si vous avez ou souhaitez utiliser Cloud DNS.
Pour exécuter des applications fiables dans Google Cloud, nous vous recommandons de concevoir votre infrastructure d'application de façon à gérer les interruptions. En fonction des besoins de votre application et de votre activité, vous aurez peut-être besoin d'un modèle de basculement à froid, tiède ou à chaud. Pour déterminer la meilleure approche pour vos propres applications, consultez le Guide de planification de reprise après sinistre.
Ce document utilise un serveur Web Apache de base, mais la même approche de déploiement d'infrastructure s'applique aux autres environnements d'application que vous devez créer.
Objectifs
- Créez des groupes d'instances gérés régionaux avec une image de VM personnalisée.
- Créer un bucket Cloud Storage
- Créer et configurer un équilibreur de charge d'application externe
- Tester le basculement tiède du serveur Web avec une configuration d'équilibreur de charge mise à jour.
- Tester la récupération et la restauration après avoir mis à jour la configuration d'un équilibreur de charge.
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Avant de commencer
- 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.
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activez l'API Compute Engine
- Installez Google Cloud CLI.
-
Pour initialiser gcloudCLI, exécutez la commande suivante :
gcloud init
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activez l'API Compute Engine
- Installez Google Cloud CLI.
-
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.
Remplacez
PROJECT_ID
par votre ID de projet : Si vous le souhaitez, fournissez votre propre suffixe de nom pour les ressources permettant de les rechercher et de les identifier, par exempleapp
.Spécifiez deux régions, telles que
us-west1
etus-west2
, et une zone de l'une de ces régions, telle queus-west1-a
. Cette zone définit l'endroit où la VM de base initiale est créée, utilisée pour créer une image pour le groupe d'instances géré.Enfin, définissez un domaine utilisé pour votre site Web statique, tel que
example.com
.PROJECT_ID=PROJECT_ID NAME_SUFFIX=app REGION1=us-west1 REGION2=us-west2 ZONE=us-west1-a DOMAIN=example.com
Créer un VPC et un sous-réseau
Pour fournir un accès réseau aux VM, créez des clouds privés virtuels (VPC) et des sous-réseaux. Étant donné que vous avez besoin de groupes d'instances gérés dans deux régions, vous créez un sous-réseau dans chaque région. 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é.
Créez le VPC avec un mode de sous-réseau personnalisé :
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
Créez maintenant deux sous-réseaux dans le nouveau VPC, un pour chaque région. Définissez vos propres plages d'adresses, telles que
10.1.0.0/20
et10.2.0.0/20
, qui correspondent à votre plage réseau :gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=10.1.0.0/20 \ --region=$REGION1 gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range=10.2.0.0/20 \ --region=$REGION2
Créer des règles de pare-feu
Pour que le trafic réseau circule correctement dans le VPC, utilisez des règles de pare-feu.
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 plage0.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.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.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
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 et configurer une image de VM de base
Pour créer des VM identiques que vous déployez sans configuration supplémentaire, utilisez une image de VM personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache et permet de créer chaque VM dans le groupe d'instances géré lors des étapes suivantes.
Sur la VM, créez un fichier index.html
de base sur le disque persistant et installez-le sur /var/www/example.com
. Un fichier de configuration Apache sous /etc/apache2/sites-available/example.com.conf
diffuse le contenu Web à partir de l'emplacement de disque persistant installé.
Le schéma suivant illustre la page HTML de base diffusée par Apache, stockée sur le disque persistant.
Pour créer cet environnement, procédez comme suit :
Créez une VM de base à laquelle un disque persistant est associé :
gcloud compute instances create vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ --image=debian-10-buster-v20210420 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk-device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
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.
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=$ZONE
Dans votre session SSH sur 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 de configuration suivant dans le fichier.
#!/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-base-$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 Compute Engine website with warm failover to Cloud Storage!</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
Mettez à jour la variable
NAME_SUFFIX
pour qu'elle corresponde à la valeur définie au début de ce document, par exemple app.Écrivez le fichier et quittez votre éditeur. Par exemple, dans Nano, vous utilisez
Ctrl-O
pour écrire le fichier, puis vous quittez avecCtrl-X
.Rendez le script de configuration exécutable, puis exécutez-le :
chmod +x configure-vm.sh ./configure-vm.sh
Quittez la session SSH sur la VM :
exit
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 $ZONE \ --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 Compute Engine website with warm failover to Cloud Storage!</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.
Déployer les ressources Compute Engine
Ce modèle de basculement tiède utilise des groupes d'instances gérés pour exécuter les VM. Les groupes d'instances gérés s'exécutent dans deux régions, et chaque groupe surveille l'état des VM. En cas de panne et l'une des VM échoue, le groupe d'instances géré recrée la VM. Cette configuration crée une application à haute disponibilité, même sans basculement tiède vers un site statique dans Cloud Storage.
Avant de pouvoir créer une image, vous devez arrêter la VM :
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
Exécutez l'ensemble de commandes suivant pour créer les images de VM, les modèles d'instance et les groupes d'instances gérés :
# Create the base VM images gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute images create image-disk-$NAME_SUFFIX \ --source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Create instance templates gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --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 \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine-type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server \ --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 \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Create a health check for VM instances gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Create the managed instance groups gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
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 les groupes d'instances gérés. 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.
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-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Create a backend service and add the managed instance groups 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-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --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
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)")
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 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 Compute Engine website with warm failover to Cloud Storage!</p> </body> </html>
Créer et configurer un bucket de stockage
Cloud Storage est utilisé pour stocker les fichiers de sites Web statiques. Dans cet exemple de base, vous créez un seul fichier avec un texte légèrement différent de celui des VM.
Dans les déploiements de production, votre site Web inclut probablement beaucoup plus de fichiers et de code d'application supplémentaire sur vos VM de groupe d'instances géré que ce qui est indiqué dans ce document. La version statique hébergée dans Cloud Storage est souvent une version plus limitée qui offre un minimum de fonctionnalités. Dans un scénario de basculement tiède, ce site Web limité de Cloud Storage s'affiche jusqu'à ce que les groupes d'instances gérés soient récupérés et qu'ils puissent diffuser du trafic pour l'ensemble de l'expérience du site Web.
Validez le domaine que vous souhaitez utiliser avec le bucket Cloud Storage.
Créez un bucket Cloud Storage correspondant au nom du domaine que vous souhaitez utiliser :
gsutil mb gs://static-web.$DOMAIN
La variable
DOMAIN
définie au début de ce document, par exempleexample.com
, est utilisée. Cet exemple stocke les fichiers statiques dansstatic-web.example.com
.Créez un fichier local que vous copiez dans le bucket Cloud Storage à l'étape suivante :
cat <<EOF > index.html <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a test static web server with warm failover from Cloud Storage!</p> </body> </html> EOF
Importez le fichier HTML de base dans le bucket Cloud Storage :
gsutil cp index.html gs://static-web.$DOMAIN
Pour permettre aux utilisateurs d'afficher le contenu Web statique, définissez les autorisations appropriées sur le bucket Cloud Storage :
gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
Configurez le bucket Cloud Storage pour diffuser le fichier
index.html
en tant que page Web par défaut :gsutil web set -m index.html gs://static-web.$DOMAIN
Ajouter le bucket Cloud Storage à l'équilibreur de charge
Une fois le bucket Cloud Storage créé et configuré pour héberger du contenu Web statique, l'équilibreur de charge a besoin d'informations sur la manière de diriger le trafic vers celui-ci.
Dans la section Créer et configurer un équilibreur de charge, vous avez créé un service de backend pour les groupes d'instances gérés. Le service de backend dispose d'un mappage d'URL, et un proxy cible HTTP permet de diriger les utilisateurs via l'équilibreur de charge vers les VM.
Pour être prêt à diriger le trafic vers le bucket Cloud Storage, configurez l'équilibreur de charge avec un nouveau backend et un nouveau mappage d'URL pour le bucket de stockage. Lorsque vous devez effectuer un basculement, vous mettez à jour l'équilibreur de charge pour utiliser cette configuration.
Ajoutez un backend pour le bucket Cloud Storage :
gcloud compute backend-buckets create \ web-bucket-$NAME_SUFFIX \ --gcs-bucket-name=static-web.$DOMAIN
Créez un mappage d'URL qui permet au trafic de circuler vers le backend :
gcloud compute url-maps create \ web-map-http-bucket-$NAME_SUFFIX \ --default-backend-bucket=web-bucket-$NAME_SUFFIX
Examinez les déploiements de ressources avant de simuler une défaillance de zone. Toutes les ressources ont été créées pour prendre en charge l'environnement, comme illustré dans l'image suivante :
- Un équilibreur de charge dirige le trafic vers deux groupes d'instances gérés. Les groupes d'instances gérés contiennent chacun deux VM qui exécutent un site Web de base.
- Un bucket Cloud Storage est configuré pour héberger des pages statiques en cas de panne avec les groupes d'instances gérés.
- L'équilibreur de charge est configuré pour utiliser le site statique dans Cloud Storage, mais ne dirige actuellement pas le trafic vers le bucket de stockage.
Basculer vers le bucket Cloud Storage
Dans un environnement réel, vous pouvez recevoir une alerte à l'aide de Cloud Monitoring ou d'une autre solution de surveillance en cas de problème avec les groupes d'instances gérés. Cette alerte invite l'utilisateur à comprendre l'étendue de la défaillance avant de mettre à jour l'équilibreur de charge afin de rediriger le trafic vers le site Web statique hébergé par Cloud Storage. Vous pouvez également utiliser votre solution de surveillance pour répondre automatiquement aux pannes avec les groupes d'instances gérés.
Lorsque vous effectuez le basculement, l'équilibreur de charge d'application externe dirige le trafic vers le site Web statique hébergé par Cloud Storage, comme indiqué dans l'image suivante :
Lorsque vous ou votre solution de surveillance déterminez que l'action la plus appropriée consiste à mettre à jour l'équilibreur de charge pour diriger le trafic vers le bucket de stockage, mettez à jour la cible du proxy HTTP pour utiliser le mappage d'URL que vous avez créé dans la section précédente. Dans ce document, vous mettez à jour manuellement l'équilibreur de charge pour rediriger le trafic vers le site Web statique hébergé par Cloud Storage.
Mettez à jour la cible HTTP pour utiliser le mappage d'URL pour le bucket Cloud Storage :
gcloud compute target-http-proxies update \ http-lb-proxy-$NAME_SUFFIX \ --url-map=web-map-http-bucket-$NAME_SUFFIX
Utilisez maintenant
curl
ou ouvrez votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :curl $IP_ADDRESS
Le site Web statique de Cloud Storage 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 static web server with warm failover from Cloud Storage!</p> </body> </html>
La mise à jour de la configuration et le transfert correct du trafic vers votre bucket Cloud Storage peuvent prendre quelques minutes. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.
Revenir aux groupes d'instances gérés
Une fois les problèmes liés aux groupes d'instances gérés résolus, vous pouvez revenir au contenu des groupes d'instances gérés à équilibrage de charge en effectuant à nouveau la mise à jour de la configuration de mappage d'URL. Là encore, l'opération doit être effectuée manuellement à l'aide des informations de Cloud Monitoring sur l'état des groupes d'instances gérés. Vous pouvez également utiliser l'automatisation pour répondre à l'état restauré du groupe d'instances géré. Dans ce document, vous allez mettre à jour manuellement la configuration de l'équilibreur de charge.
Mettez à jour la cible du proxy HTTP pour utiliser à nouveau le mappage d'URL pour les groupes d'instances gérés :
gcloud compute target-http-proxies update \ http-lb-proxy-$NAME_SUFFIX \ --url-map=web-map-http-$NAME_SUFFIX
Utilisez à nouveau
curl
ou ouvrez votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :curl $IP_ADDRESS
La mise à jour de la configuration et la redirection correcte du trafic vers vos groupes d'instances gérés peuvent prendre quelques minutes. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.
Le site Web principal des groupes d'instances gérés est renvoyé, comme indiqué 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 Compute Engine website with warm failover to Cloud Storage!</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 :
Supprimez le bucket Cloud Storage :
gsutil rm -r gs://static-web.$DOMAIN
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 url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
Supprimez le groupe d'instances géré et la vérification d'état :
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Supprimez les modèles d'instance, les images, la VM de base et les disques persistants :
gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION2 --quiet gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute images delete image-disk-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX \ --zone=$ZONE --quiet
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
Supprimez le sous-réseau et le réseau VPC :
gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
Étapes suivantes
- Pour découvrir une autre approche qui utilise Cloud DNS au lieu de l'équilibreur de charge d'application externe pour contrôler le basculement, consultez la page Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage. Ce modèle est utile si vous avez ou souhaitez utiliser Cloud DNS.
- 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.