Failover multirregional para endpoints externos regionais usando verificações de integridade do Cloud DNS

1. Introdução

O serviço Cloud DNS oferece uma solução de Sistema de Nomes de Domínio (DNS) global, resiliente e de alto desempenho. Com ele, é possível publicar zonas e registros sem precisar de uma infraestrutura de DNS autogerenciada.

O mais importante é que o Cloud DNS incorpora suporte para verificação de integridade e recursos de failover automatizados nas políticas de roteamento para endpoints externos. No entanto, as verificações de integridade desses endpoints externos estão disponíveis exclusivamente em zonas públicas, e os próprios endpoints precisam estar acessíveis publicamente pela Internet.

O que você vai aprender

• Como criar um balanceador de carga de aplicativo externo regional com um grupo de instâncias não gerenciado.
• Como configurar verificações de integridade do Cloud DNS para roteamento de DNS externo.
• Como criar uma política de roteamento de failover.

O que é necessário

• Conhecimento básico de DNS.
• Conhecimento básico do Google Compute Engine.
• Conhecimento básico do balanceador de carga de aplicativo.
• Um projeto do Google Cloud com permissões de proprietário
• Um domínio público de sua propriedade, para o qual você pode criar uma zona pública do Cloud DNS.
• As seguintes políticas organizacionais não são aplicadas no projeto do Google Cloud: VMs protegidas e Grupos de endpoints de rede da Internet.

OBSERVAÇÃO:será necessário atualizar os servidores de nomes da zona pública que você vai criar neste laboratório com seu provedor de DNS, que gerencia seu domínio.

2. Topologia do codelab

Neste codelab, você vai usar verificações de integridade do Cloud DNS para endpoints externos e redirecionar o tráfego para um balanceador de carga de aplicativo externo regional de backup se o back-end do balanceador de carga principal ficar em estado ruim.

Você vai criar um site em duas regiões, cada uma com um balanceador de carga de aplicativo externo. Em seguida, você vai configurar as verificações de integridade do Cloud DNS com uma política de roteamento de failover.

3. Configuração e requisitos

Configuração de ambiente autoguiada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você usa uma conta do Gmail, defina o local padrão como Sem organização. Se você usa uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

4. Antes de começar

Ativar APIs

No Cloud Shell, verifique se o projeto está configurado e configure as variáveis.

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

Ative todos os serviços necessários

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

5. Criar infraestrutura do Cloud Load Balancing

Nesta seção, você vai criar a VPC, as sub-redes, as regras de firewall, as VMs e os grupos de instâncias não gerenciadas necessários em duas regiões diferentes para oferecer suporte aos balanceadores de carga primário e de backup.

Rede VPC

No Cloud Shell

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

Crie duas sub-redes em REGION_A (primária) e REGION_B (backup) para hospedar os servidores da Web de back-end.

Criar sub-redes

No 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

Crie sub-redes somente proxy em cada região para o respectivo balanceador de carga de aplicativo externo regional que será criado mais tarde.

Essa sub-rede somente proxy dedicada é um requisito obrigatório para todos os balanceadores de carga regionais baseados no Envoy implantados na mesma região da rede VPC external-lb. Esses proxies encerram a conexão do cliente e estabelecem novas conexões com os serviços de back-end.

No 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

Criar regras de firewall de rede

fw-allow-health-check. Uma regra de entrada aplicável às instâncias com balanceamento de carga, que permite todo o tráfego TCP dos sistemas de verificação de integridade do Google Cloud (em 130.211.0.0/22 e 35.191.0.0/16). Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

fw-allow-proxies. Uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite o tráfego TCP na porta 80 dos proxies gerenciados do balanceador de carga de aplicativo externo regional. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

No 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 o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.

No 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. Criar o Cloud NAT e os Cloud Routers

Você precisa de gateways do Cloud NAT nas duas regiões para que as VMs privadas possam fazer o download e instalar pacotes da Internet.

• As VMs do servidor da Web precisam baixar e instalar o servidor da Web Apache.
• A VM do cliente precisará fazer o download e instalar o pacote dnsutils, que será usado para nossos testes.

Cada gateway do Cloud NAT está associado a uma única rede VPC, região e Cloud Router. Portanto, antes de criar os gateways NAT, precisamos criar Cloud Routers em cada região.

Criar Cloud Routers

No 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

Criar gateways NAT

No 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

Criar VMs de back-end e grupos de instâncias não gerenciadas

Crie uma VM em cada região e instale um servidor da Web (por exemplo, Apache):

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

Crie um grupo de instâncias não gerenciadas e adicione a instância de VM a ele em cada região:

No 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. Configurar balanceadores de carga de aplicativo externos regionais

Você vai configurar um balanceador de carga de aplicativo externo regional completo em REGION_A (primária) e REGION_B (backup).

Criar verificações de integridade e serviços de back-end

Os balanceadores de carga de aplicativo externos regionais são baseados no Envoy e precisam de verificações de integridade regionais configuradas.

Crie uma verificação de integridade HTTP (usada pelos balanceadores de carga para verificar a integridade da instância):

No Cloud Shell, faça o seguinte:

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

Crie um serviço de back-end regional e anexe o grupo de instâncias em cada região.

No Cloud Shell, faça o seguinte:

# 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

OBSERVAÇÃO:para um design pronto para produção, sugerimos que você use proxies HTTPS de destino, porta 443 e um certificado no balanceador de carga.

Criar componentes de front-end

Crie mapas de URL e proxies HTTP de destino nas duas regiões:

No Cloud Shell, faça o seguinte:

#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

Reserve endereços IP estáticos (externos) para as regras de encaminhamento:

No Cloud Shell, faça o seguinte:

# 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

Crie as regras de encaminhamento para os dois balanceadores de carga:

No Cloud Shell, faça o seguinte:

# 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

Configurar o Cloud DNS para failover

Criar uma verificação de integridade do Cloud DNS para endpoints externos

Crie uma verificação de integridade global dedicada para os endereços IP públicos do balanceador de carga. Isso é diferente da verificação de integridade interna do balanceador de carga.

Primeiro, vamos determinar os endereços IP externos dos balanceadores de carga para configurar a política de failover e exportá-los como uma variável.

No Cloud Shell, faça o seguinte:

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

Observação: se o gcloud beta não estiver instalado, execute os comandos a seguir para fazer a instalação.

gcloud components update

gcloud components install beta

Crie a verificação de integridade global do DNS (requer três regiões de origem):

No Cloud Shell, faça o seguinte:

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

Crie uma zona pública gerenciada e uma política de roteamento de failover.

Crie uma zona pública gerenciada (use o domínio DNS que você tem):

No Cloud Shell, faça o seguinte:

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

Crie o registro A com uma política de roteamento de failover. Essa política aponta para o IP principal e usa a verificação de integridade para determinar quando fazer failover para o IP de backup.

O comando abaixo usa os nomes das regras de encaminhamento do balanceador de carga para referenciar os endereços IP da política de roteamento.

Observação: substitua o nome do 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. Como testar o failover regional

1. Validação inicial:use uma ferramenta (como dig ou um navegador da Web) para consultar seu domínio. Ele precisa ser resolvido para o IP principal ($PRIMARY_IP) e retornar a página "Região A - back-end 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>

Saída do navegador

2. Simular failover:faça login na VM principal (vm-a) e desligue o Apache para simular uma interrupção:

No Cloud Shell, faça o seguinte:

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

3. Verificar o status não íntegro:aguarde de 2 a 3 minutos para que a verificação de integridade do DNS marque o endpoint principal como não íntegro.

# 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 failover:consulte seu domínio novamente. Agora ele vai resolver o IP de backup ($BACKUP_IP) e retornar a página "Região B: back-end de backup".

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>

Saída do navegador

5. Simular failback (opcional): faça SSH e inicie o Apache na VM principal e aguarde a verificação de integridade do DNS marcar o endpoint principal como íntegro. O tráfego será automaticamente roteado de volta para o IP principal.
6. Opcional:analise o registro em registros da verificação de integridade do Cloud DNS executando o comando abaixo no 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. Etapas de limpeza

Exclua todos os componentes para evitar mais cobranças.

No 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. Parabéns!

Parabéns por concluir o codelab.

• Você configurou e validou com êxito um failover ativo-passivo multirregional usando verificações de integridade do Cloud DNS e balanceador de carga de aplicativo externo regional.