Conmutación por error multirregional para extremos externos regionales con verificaciones de estado de Cloud DNS

1. Introducción

El servicio Cloud DNS ofrece una solución de sistema de nombres de dominio (DNS) global, resiliente y de alto rendimiento que te permite publicar zonas y registros sin necesidad de una infraestructura de DNS autoadministrada.

En primer lugar, Cloud DNS incorpora compatibilidad con las capacidades de verificación de estado y conmutación por error automatizada en sus políticas de enrutamiento para extremos externos. Sin embargo, ten en cuenta que las verificaciones de estado para estos extremos externos solo están disponibles en las zonas públicas, y se debe poder acceder a los extremos de forma pública a través de Internet.

Qué aprenderás

• Cómo crear un balanceador de cargas de aplicaciones externo regional con un grupo de instancias no administrado
• Cómo configurar las verificaciones de estado de Cloud DNS para el enrutamiento de DNS externo
• Cómo crear una política de enrutamiento de conmutación por error

Requisitos

• Conocimientos básicos de DNS
• Tener conocimientos básicos de Google Compute Engine
• Conocimientos básicos sobre el balanceador de cargas de aplicaciones
• Un proyecto de Google Cloud con permisos de propietario
• Un dominio público de tu propiedad, para el que puedes crear una zona pública de Cloud DNS
• Actualmente, las siguientes políticas de la organización no se aplican en el proyecto de Google Cloud: VMs protegidas y Grupos de extremos de red de Internet.

NOTA: Deberás actualizar los servidores de nombres de la zona pública que crearás en este lab con tu proveedor de DNS que administra tu dominio.

2. Topología del codelab

En este codelab, usarás las verificaciones de estado de Cloud DNS para los extremos externos y, así, redireccionar el tráfico a un balanceador de cargas de aplicaciones externo regional de copia de seguridad si el backend del balanceador de cargas principal deja de estar en buen estado.

Compilarás un sitio web en dos regiones, cada una con un balanceador de cargas de aplicaciones externo como frontend. Luego, configurarás las verificaciones de estado de Cloud DNS con una política de enrutamiento de conmutación por error.

3. Configuración y requisitos

Configuración del entorno de autoaprendizaje

1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID del proyecto es único a nivel global y no lo puede usar nadie más después de que lo hayas seleccionado. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes dejar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

4. Antes de comenzar

Habilita las APIs

En Cloud Shell, asegúrate de que tu proyecto esté configurado y configura las 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

Habilita todos los servicios necesarios

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

5. Crea la infraestructura de Cloud Load Balancing

En esta sección, crearás la VPC, las subredes, las reglas de firewall, las VMs y los grupos de instancias no administrados necesarios en dos regiones diferentes para admitir los balanceadores de cargas principal y de copia de seguridad.

Red de VPC

Desde Cloud Shell

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

Crea dos subredes en REGION_A (principal) y REGION_B (copia de seguridad) para alojar los servidores web de backend.

Crear subredes

Desde 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

Crea subredes de solo proxy en cada región para el balanceador de cargas de aplicaciones externo regional respectivo que se creará más adelante.

Esta subred exclusiva del proxy es un requisito obligatorio para todos los balanceadores de cargas regionales basados en Envoy implementados en la misma región de la red de VPC external-lb-vpc. Estos proxies finalizan de manera eficaz la conexión del cliente y, luego, establecen conexiones nuevas con los servicios de backend.

Desde 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

Crea reglas de firewall de red

fw-allow-health-check. Una regla de entrada, aplicable a las instancias en las que se realiza el balanceo de cargas, que permite todo el tráfico de TCP de los sistemas de verificación de estado de Google Cloud (en 130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.

fw-allow-proxies. Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP en el puerto 80 desde los proxies administrados del balanceador de cargas de aplicaciones externo regional. En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.

Desde 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

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que cumpla con lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
• Permite el tráfico de entrada desde el rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

Desde 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. Crea Cloud NAT y Cloud Routers

Necesitas puertas de enlace de Cloud NAT en ambas regiones para que las VMs privadas puedan descargar e instalar paquetes desde Internet.

• Nuestras VMs de servidor web deberán descargar e instalar el servidor web Apache.
• La VM cliente deberá descargar e instalar el paquete dnsutils que usaremos para nuestras pruebas.

Cada puerta de enlace de Cloud NAT está asociada con una sola red de VPC, una región y un Cloud Router. Por lo tanto, antes de crear las puertas de enlace de NAT, debemos crear Cloud Routers en cada región.

Crea Cloud Routers

Desde 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

Crea puertas de enlace NAT

Desde 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

Crea VMs de backend y grupos de instancias no administrados

Crea una VM en cada región y, luego, instala un servidor web (p. ej., Apache):

Desde 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'

Crea un grupo de instancias no administrado y agrégale la instancia de VM para cada región:

Desde 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. Configura balanceadores de cargas de aplicaciones externos regionales

Configurarás un balanceador de cargas de aplicaciones externo regional completo en REGION_A (principal) y REGION_B (copia de seguridad).

Crea verificaciones de estado y servicios de backend

Los balanceadores de cargas de aplicaciones externos regionales se basan en Envoy y necesitan que se configuren verificaciones de estado regionales.

Crea una verificación de estado HTTP (que usan los balanceadores de cargas para verificar el estado de las instancias):

En Cloud Shell, haga lo siguiente:

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

Crea un servicio de backend regional y conecta el grupo de instancias en cada región**.**

En Cloud Shell, haga lo siguiente:

# 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

NOTA: Para un diseño listo para la producción, se sugiere que uses proxies HTTPS de destino, el puerto 443 y un certificado en el balanceador de cargas.

Crea componentes de frontend

Crea mapas de URL y proxies HTTP de destino en ambas regiones:

En Cloud Shell, haga lo siguiente:

#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

Reserva direcciones IP estáticas (externas) para las reglas de reenvío:

En Cloud Shell, haga lo siguiente:

# 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

Crea las reglas de reenvío para los dos balanceadores de cargas:

En Cloud Shell, haga lo siguiente:

# 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

Configura Cloud DNS para la conmutación por error

Crea una verificación de estado de Cloud DNS para extremos externos

Debes crear una verificación de estado global dedicada para las direcciones IP públicas del balanceador de cargas. Esto es diferente de la verificación de estado interna del balanceador de cargas.

Primero, determinemos las direcciones IP externas de los balanceadores de cargas para configurar la política de conmutación por error y exportémoslas como una variable.

En Cloud Shell, haga lo siguiente:

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)')

Nota: En caso de que no esté instalado gcloud beta, puedes instalarlo ejecutando los siguientes comandos.

gcloud components update

gcloud components install beta

Crea la verificación de estado de DNS global (requiere tres regiones de origen):

En Cloud Shell, haga lo siguiente:

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

Crea una zona pública administrada y una política de enrutamiento de conmutación por error.

Crea una zona administrada pública (usa el dominio DNS que posees):

En Cloud Shell, haga lo siguiente:

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

Crea el registro A con una política de enrutamiento de conmutación por error. Esta política apunta a la IP principal y usa la verificación de estado para determinar cuándo conmutar por error a la IP de copia de seguridad.

El siguiente comando usa los nombres de las reglas de reenvío del balanceador de cargas para hacer referencia a las direcciones IP de la política de enrutamiento.

Nota: Reemplaza el nombre del registro "codelab.gcp.axiszulu.com" with your actual domain name "codelab.gcp.<your public domain>.com"".

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. Prueba de conmutación por error regional

1. Validación inicial: Usa una herramienta (como dig o un navegador web) para consultar tu dominio. Debe resolverse en la IP principal ($PRIMARY_IP) y mostrar la página "Backend principal de la región A".

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>

Salida del navegador

2. Simula la conmutación por error: Accede a la VM principal (vm-a) y apaga Apache para simular una interrupción:

En Cloud Shell, haga lo siguiente:

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

3. Verifica el estado de mal estado: Espera de 2 a 3 minutos para que la verificación de estado de DNS marque el extremo principal como en mal estado.

# 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

4. Validar conmutación por error: Vuelve a consultar tu dominio. Ahora debería resolverse en la IP de copia de seguridad ($BACKUP_IP) y mostrar la página "Backend de copia de seguridad de la región B".

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>

Salida del navegador

5. Simula la recuperación (opcional): Establece una conexión SSH y, luego, inicia Apache en la VM principal. Espera a que la verificación de estado del DNS marque el extremo principal como en buen estado. El tráfico debería volver a enrutarse automáticamente a la IP principal.
6. Opcional: Puedes analizar el registro de verificación de estado de Cloud DNS ejecutando el siguiente comando en 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. Pasos para la limpieza

Borra todos los componentes para evitar cargos adicionales.

Desde 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. ¡Felicitaciones!

Felicitaciones por completar el codelab.

• Configuraste y validaste correctamente una conmutación por error activa-pasiva multirregional con las verificaciones de estado de Cloud DNS y el balanceador de cargas de aplicaciones externo regional.