Basculements multirégionaux pour les points de terminaison externes régionaux à l'aide des vérifications de l'état Cloud DNS

1. Introduction

Le service Cloud DNS offre une solution de système de noms de domaine (DNS) globale, résiliente et offrant de hautes performances. Il vous permet de publier des zones et des enregistrements sans avoir besoin d'une infrastructure DNS autogérée.

Tout d'abord, Cloud DNS est compatible avec les fonctionnalités de vérification de l'état et de basculement automatique dans ses règles de routage pour les points de terminaison externes. Toutefois, veuillez noter que les vérifications de l'état de ces points de terminaison externes ne sont disponibles que dans les zones publiques, et que les points de terminaison eux-mêmes doivent être accessibles publiquement via Internet.

Points abordés

Découvrez comment créer un équilibreur de charge d'application externe régional avec un groupe d'instances non géré.
Comment configurer les vérifications de l'état Cloud DNS pour le routage DNS externe.
Découvrez comment créer une règle de routage de basculement.

Prérequis

Connaissances de base du DNS.
Connaissances de base sur Google Compute Engine
Connaissances de base de l'équilibreur de charge d'application.
Un projet Google Cloud avec des autorisations de propriétaire
Un domaine public dont vous êtes propriétaire et pour lequel vous pouvez créer une zone publique Cloud DNS.
Les règles d'administration suivantes ne sont pas appliquées dans le projet Google Cloud : VM protégées et Groupes de points de terminaison du réseau Internet.

2. Topologie de l'atelier de programmation

Dans cet atelier de programmation, vous allez utiliser les vérifications d'état Cloud DNS pour les points de terminaison externes afin de rediriger le trafic vers un équilibreur de charge d'application externe régional de secours si le backend de l'équilibreur de charge principal devient non opérationnel.

Vous allez créer un site Web dans deux régions, chacune étant associée à un équilibreur de charge d'application externe. Vous configurerez ensuite les vérifications de l'état Cloud DNS avec une règle de routage de basculement.

3. Préparation

Configuration de l'environnement au rythme de chacun

Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

Activer Cloud Shell

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Capture d'écran du terminal Google Cloud Shell montrant que l'environnement est connecté

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

4. Avant de commencer

Activer les API

Dans Cloud Shell, assurez-vous que votre projet est configuré et configurez les variables.

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

Activez tous les services nécessaires.

gcloud services enable compute.googleapis.com 
gcloud services enable dns.googleapis.com

5. Créer une infrastructure Cloud Load Balancing

Dans cette section, vous allez créer le VPC, les sous-réseaux, les règles de pare-feu, les VM et les groupes d'instances non gérés nécessaires dans deux régions différentes pour prendre en charge les équilibreurs de charge principal et de secours.

Réseau VPC

Depuis Cloud Shell

gcloud compute networks create external-lb-vpc --subnet-mode=custom

Créez deux sous-réseaux dans REGION_A (principal) et REGION_B (sauvegarde) pour héberger les serveurs Web de backend.

Créer des sous-réseaux

Depuis Cloud Shell

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

Créez des sous-réseaux proxy réservés dans chaque région pour l'équilibreur de charge d'application externe régional correspondant qui sera créé ultérieurement.

Ce sous-réseau proxy réservé est obligatoire pour tous les équilibreurs de charge régionaux basés sur Envoy déployés dans la même région que le réseau VPC external-lb-vpc. Ces proxys interrompent efficacement la connexion du client et établissent ensuite de nouvelles connexions aux services de backend.

Depuis Cloud Shell

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

Créer des règles de pare-feu réseau

fw-allow-health-check. Règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

fw-allow-proxies Règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur le port 80 à partir des proxys gérés de l'équilibreur de charge d'application externe régional. Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

Depuis Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

Pour permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu qui :

S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.

Depuis Cloud Shell

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. Créer Cloud NAT et des routeurs Cloud

Vous avez besoin de passerelles Cloud NAT dans les deux régions pour que les VM privées puissent télécharger et installer des packages depuis Internet.

Nos VM de serveur Web devront télécharger et installer le serveur Web Apache.
La VM cliente devra télécharger et installer le package dnsutils que nous utiliserons pour nos tests.

Chaque passerelle Cloud NAT est associée à un seul réseau VPC, une seule région et un seul routeur Cloud Router. Avant de créer les passerelles NAT, nous devons donc créer des routeurs Cloud Router dans chaque région.

Créer des routeurs cloud

Depuis Cloud Shell

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

Créer des passerelles NAT

Depuis Cloud Shell

gcloud compute routers nats create "$REGION_A-nat-gw" \
--router="$REGION_A-cloudrouter" \
--router-region=$REGION_A \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

gcloud compute routers nats create "$REGION_B-nat-gw" \
--router="$REGION_B-cloudrouter" \
--router-region=$REGION_B \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

Créer des VM de backend et des groupes d'instances non gérés

Créez une VM dans chaque région et installez un serveur Web (Apache, par exemple) :

Depuis Cloud Shell

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

Créez un groupe d'instances non géré et ajoutez-y l'instance de VM pour chaque région :

Depuis Cloud Shell

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. Configurer des équilibreurs de charge d'application externes régionaux

Vous allez configurer un équilibreur de charge d'application externe régional complet dans REGION_A (principal) et REGION_B (sauvegarde).

Créer des vérifications de l'état et des services de backend

Les équilibreurs de charge d'application externes régionaux sont basés sur Envoy et nécessitent la configuration de vérifications d'état régionales.

Créez une vérification d'état HTTP (utilisée par les équilibreurs de charge pour vérifier l'état des instances) :

Dans Cloud Shell

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

Créez un service de backend régional et associez-y le groupe d'instances dans chaque région.

Dans Cloud Shell

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

Créer des composants d'interface

Créez des mappages d'URL et des proxys HTTP cibles dans les deux régions :

Dans Cloud Shell

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

Réservez des adresses IP statiques (externes) pour les règles de transfert :

Dans Cloud Shell

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

Créez les règles de transfert pour les deux équilibreurs de charge :

Dans Cloud Shell

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

Configurer Cloud DNS pour le basculement

Créer une vérification de l'état Cloud DNS pour les points de terminaison externes

Vous devez créer une vérification d'état globale dédiée pour les adresses IP publiques de l'équilibreur de charge. Elle est différente de la vérification de l'état interne de l'équilibreur de charge.

Commençons par déterminer les adresses IP externes des équilibreurs de charge pour configurer la règle de basculement et les exporter en tant que variable.

Dans Cloud Shell

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

Créez la vérification d'état DNS globale (nécessite trois régions sources) :

Dans Cloud Shell

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

Créez une zone gérée publique et une règle de routage avec basculement.

Créez une zone publique gérée (utilisez le domaine DNS dont vous êtes propriétaire) :

Dans Cloud Shell

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

Créez l'enregistrement A avec une règle de routage avec basculement. Cette règle pointe vers l'adresse IP principale et utilise la vérification de l'état pour déterminer quand basculer vers l'adresse IP de sauvegarde.

La commande ci-dessous utilise les noms des règles de transfert de l'équilibreur de charge pour référencer les adresses IP de la règle de routage.

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. Tester le basculement régional

Validation initiale : utilisez un outil (comme dig ou un navigateur Web) pour interroger votre domaine. Elle doit résoudre l'adresse IP principale ($PRIMARY_IP) et renvoyer la page "Région A – Backend principal".

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

Sortie du navigateur

Simuler un basculement : connectez-vous à la VM principale (vm-a) et arrêtez Apache pour simuler une panne :

Dans Cloud Shell

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

Vérifiez l'état non opérationnel : attendez deux à trois minutes que la vérification de l'état du DNS marque le point de terminaison principal comme non opérationnel.

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

Valider le basculement : interrogez à nouveau votre domaine. Il devrait maintenant être résolu en adresse IP de sauvegarde ($BACKUP_IP) et renvoyer la page "Région B – Backend de sauvegarde".

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

Sortie du navigateur

Simuler un retour à l'état initial (facultatif) : connectez-vous en SSH et démarrez Apache sur la VM principale, puis attendez que la vérification d'état DNS marque le point de terminaison principal comme opérationnel. Le trafic devrait être automatiquement redirigé vers l'adresse IP principale.
Facultatif : Vous pouvez analyser la journalisation des vérifications de l'état Cloud DNS en exécutant la commande ci-dessous dans Cloud Shell.

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. Étapes de nettoyage

Supprimez tous les composants pour éviter des frais supplémentaires.

Depuis Cloud Shell

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

gcloud compute routers nats delete $REGION_B-nat-gw \
--router=$REGION_B-cloudrouter --region=$REGION_B --quiet

gcloud compute routers delete $REGION_A-cloudrouter \
--region=$REGION_A --quiet

gcloud compute routers delete $REGION_B-cloudrouter \
--region=$REGION_B --quiet


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. Félicitations !

Bravo ! Vous avez terminé cet atelier de programmation.

Vous avez configuré et validé avec succès un basculement actif-passif multirégional à l'aide des vérifications d'état Cloud DNS et de l'équilibreur de charge d'application externe régional.