Failover multirregional usando políticas de roteamento do Cloud DNS e verificações de integridade para o balanceador de carga TCP/UDP interno

1. Introdução

Última atualização:22/09/2022

O que é uma política de roteamento de DNS

As políticas de roteamento do Cloud DNS permitem que os usuários configurem o direcionamento de tráfego baseado em DNS de acordo com critérios específicos, como peso, localização geográfica ou verificações de integridade.

O Cloud DNS oferece suporte às seguintes políticas de roteamento:

  • Política de roteamento de round-robin ponderado
  • Política de roteamento de geolocalização
  • Política de roteamento com fronteiras geográficas virtuais
  • Política de roteamento de failover

Neste laboratório, você vai configurar e testar a política de roteamento de failover.

Política de roteamento de failover

O Cloud DNS oferece suporte a verificações de integridade para balanceadores de carga TCP/UDP internos com acesso global ativado. Com uma política de roteamento de failover, é possível configurar IPs principais e de backup para um registro de recurso. Em operação normal, o Cloud DNS responderá às consultas com os endereços IP provisionados no conjunto principal. Quando todos os endereços IP no conjunto principal falham (o status de integridade muda para não íntegro), o Cloud DNS começa a disponibilizar os endereços IP no conjunto de backup.

Verificações de integridade

A política de roteamento de DNS depende das verificações de integridade unificadas do balanceador de carga interno(UHC) nativas. Um balanceador de carga interno será considerado íntegro se 20% ou mais dos back-ends estiverem íntegros. As verificações de integridade para balanceadores de carga TCP/UDP internos e HTTP(S) internos fornecem informações diferentes. Em um balanceador de carga HTTP(S) interno, o UHC fornece o status de integridade de todos os proxies Envoy. Já para um balanceador de carga TCP/UDP interno, o Cloud DNS recebe sinais diretos de integridade das instâncias de back-end individuais. Os detalhes das verificações de integridade podem ser encontrados aqui .

O que você vai criar

Neste codelab, você criará um site em execução em duas regiões e associará uma política de roteamento de DNS de failover a ele. A configuração terá:

Recursos ativos -

  • Balanceador de carga interno L4 em REGION_1
  • Uma VM executando o servidor da Web Apache em REGION_1

Recursos de backup:

  • Balanceador de carga interno L4 em REGION_2
  • Uma VM executando o servidor da Web Apache em REGION_2

A configuração é a mostrada abaixo:

d0a91d3d3698f544.png

O que você vai aprender

  • Como criar uma política de roteamento de failover
  • Acionar failover de DNS
  • Como transferir o tráfego para o conjunto de backup

O que é necessário

  • Noções básicas de DNS
  • Conhecimento básico do Google Compute Engine
  • Conhecimento básico sobre o balanceador de carga interno L4.

2. Configuração e requisitos

  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.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • 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 Você pode atualizar a qualquer momento.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O console do Cloud gera automaticamente uma string exclusiva. normalmente você não se importa com o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, que normalmente é identificado como PROJECT_ID. Se você não gostar do ID gerado, pode gerar outro ID aleatório. Como alternativa, você pode tentar o seu próprio e ver se ele está disponível. Ela não pode ser alterada após essa etapa e permanecerá durante a duração do projeto.
  • Para sua informação, há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
  1. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar faturamento além deste tutorial, exclua os recursos criados ou exclua o projeto inteiro. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Iniciar 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:

55efc1aaa7a4d3ad.png

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:

7ffe5cbb04455448.png

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.

3. Versão do SDK Google Cloud

No momento em que este artigo foi escrito, 401.0.0 é a versão mais recente do SDK do Google Cloud. Todos os comandos deste laboratório foram testados com a versão mais recente do SDK Google Cloud. Antes de continuar, verifique se o Cloud Shell está usando a versão mais recente do SDK.

Como verificar a versão do SDK

Use o comando gcloud version para verificar a versão do SDK. Execute os comandos a seguir no Cloud Shell

Comando

gcloud version | grep "Google Cloud SDK"

Exemplo de saída

Google Cloud SDK 401.0.0

Próximas etapas

  1. Se a versão do SDK for 401.0.0 ou mais recente, pule para a próxima seção.
  2. Se a versão do SDK for anterior à 401.0.0, execute o comando listado abaixo para atualizar o SDK.

Comando opcional

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. Antes de começar

Antes de começar a implantar a arquitetura explicada acima, verifique se o Cloud Shell está configurado corretamente e se todas as APIs necessárias estão ativadas.

Configurar o ID do projeto

No Cloud Shell, verifique se o ID do projeto está configurado. Se o comando do Cloud Shell tiver essa aparência e você não quiser alterar o ID do projeto, pule para a próxima etapa (Definir variáveis de ambiente).

USER@cloudshell:~ (PROJECT_ID)$

Se você ainda quiser alterar o ID do projeto, use o comando listado abaixo. O prompt do Cloud Shell mudará de (PROJECT_ID) para (YOUR-PROJECT-ID)

Comando opcional

gcloud config set project [YOUR-PROJECT-ID]

Exemplo de saída

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Definir as variáveis de ambiente

Defina as variáveis de ambiente

Usaremos o comando export para definir as variáveis de ambiente. Execute os comandos a seguir no Cloud Shell

Comandos

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Verificar

Agora que as variáveis de ambiente estão definidas, vamos fazer a verificação usando o comando echo. A saída de cada comando precisa ser o valor que configuramos acima usando o comando export. Execute os comandos a seguir no Cloud Shell

Comandos

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Ativar todos os serviços necessários

Use o comando gcloud services enable para ativar as APIs do Compute e do DNS. Execute os comandos a seguir no Cloud Shell

Ativar a API Compute

Comando

gcloud services enable compute.googleapis.com

Ativar a API DNS

Comando

gcloud services enable dns.googleapis.com

Verificar

Agora que os serviços estão ativados, use o comando gcloud services list para listar todas as APIs ativadas.

Comando

gcloud services list | grep -E 'compute|dns'

Exemplo de saída

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. Crie regras de firewall, redes VPC e sub-redes

Nesta seção, vamos criar a rede VPC, duas sub-redes (uma em cada região) e as regras de firewall necessárias.

Criar rede VPC

Use o comando gcloud compute networks create para criar a rede VPC. Vamos definir o modo da sub-rede como personalizado porque criaremos nossas próprias sub-redes na próxima etapa. Execute os comandos a seguir no Cloud Shell.

Comando

gcloud compute networks create my-vpc --subnet-mode custom

Criar sub-redes

Use o comando gcloud compute networks subnets create para criar duas sub-redes, uma em REGION_1 e outra em REGION_2. Execute os comandos a seguir no Cloud Shell

Sub-rede REGION_1

Comando

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

Sub-rede REGION_2

Comando

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

Criar regras de firewall

Você precisa permitir o tráfego na porta 80 das sub-redes VPC e dos intervalos de IP de verificação de integridade do balanceador de carga.

Além disso, você também precisa criar uma regra de firewall para permitir o tráfego SSH nas VMs de clientes.

Use o comando gcloud compute firewall-rules create para criar as regras de firewall. Execute os comandos a seguir no Cloud Shell

Permitir tráfego na porta 80

Comando

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

Permitir tráfego SSH na VM de cliente

Comando

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Criar Cloud NAT

Você precisa de gateways do Cloud NAT em ambas as regiões para que as VMs particulares possam fazer o download e a instalação de pacotes da Internet.

  • Nossas VMs de servidor da Web vão precisar fazer o download e instalar o servidor da Web Apache.
  • A VM cliente precisará fazer o download e instalar o pacote dnsutils que será usado nos 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

Use o comando gcloud compute routers create para criar Cloud Routers nas regiões us-west1 e us-east4. Execute os comandos a seguir no Cloud Shell.

Cloud Router Region_1

Comandos

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Cloud Router Region_2

Comandos

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

Crie os gateways NAT

Use o comando gcloud compute routers nat create para criar os gateways NAT nas regiões us-west1 e us-east4. Execute os comandos a seguir no Cloud Shell.

Gateway NAT da Region_1

Comandos

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

Gateway NAT da Region_2

Comandos

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

7. Criar VMs do Compute Engine

Nesta seção, você vai criar os servidores da Web, grupos de instâncias não gerenciadas para os servidores da Web e a VM de cliente.

Criar VMs de servidor da Web

Use o comando gcloud compute instances create para criar os servidores da Web. Precisamos criar dois servidores da Web, um em REGION_1 e outro em REGION_2. Estamos usando scripts de inicialização para instalar e configurar o Apache nos servidores da Web.

Servidor da Web REGION_1

Execute o comando a seguir no Cloud Shell

Comando

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Servidor da Web REGION_2

Execute o comando a seguir no Cloud Shell

Comando

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Criar grupos de instâncias não gerenciadas

Nesta seção, vamos criar dois grupos de instâncias não gerenciadas. Vamos usar esses grupos na próxima seção para configurar os serviços de back-end do ILB. Depois que os grupos de instâncias forem criados, vamos adicionar as VMs de servidor da Web a eles.

Crie os grupos de instâncias não gerenciadas

Use o comando gcloud compute instance-groups unmanaged create para criar dois grupos de instâncias não gerenciadas, um para o servidor da Web us-west1 e outro para o servidor da Web us-east4.

Grupo de instâncias Region_1

Comandos

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Grupo de instâncias Region_2

Comandos

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

Adicionar VMs aos grupos de instâncias

Use o comando gcloud compute instance-groups unmanaged add-instances para adicionar as instâncias aos grupos de instâncias que acabamos de criar. Adicionar o servidor da Web de REGION_1 ao grupo de instâncias REGION_1 e o servidor da Web REGION_2 ao grupo de instâncias REGION_2

Grupo de instâncias Region_1

Comandos

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Grupo de instâncias Region_2

Comandos

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Crie uma VM cliente

Vamos usar essa VM para executar testes e verificar a configuração do DNS. Estamos usando um script de inicialização para instalar o pacote dnsutils. Execute os comandos a seguir no Cloud Shell.

Comando

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Criar balanceadores de carga internos L4

Para criar o ILB L4, é preciso criar uma verificação de integridade, um serviço de back-end e uma regra de encaminhamento.

Criar verificação de integridade

Use o comando gcloud compute health-checks create para criar a verificação de integridade. Estamos criando uma verificação de integridade HTTP básica e a porta de destino é a 80. Execute os comandos a seguir no Cloud Shell

Comando

gcloud compute health-checks create http http-hc --port 80

Configurar serviços de back-end

Use o comando gcloud compute backend-services create para criar o serviço de back-end. Depois que os serviços de back-end forem criados, adicionaremos os grupos de instâncias não gerenciadas aos serviços de back-end usando o comando gcloud compute backend-services add-backend. Execute os comandos a seguir no Cloud Shell.

Criar serviço de back-end

Comandos

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Adicionar back-end

Comando

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Criar regras de encaminhamento

Use o comando gcloud compute forwarding-rules create para criar as regras de encaminhamento nas duas regiões. Execute os comandos a seguir no Cloud Shell

Regra de encaminhamento de REGION_1

Comandos

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Regra de encaminhamento REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. Configura o DNS

Nesta seção, vamos criar a zona particular e um conjunto de registros DNS com a política de roteamento de failover.

Criar uma zona de DNS particular

Use o comando gcloud dns managed-zones create para criar uma zona particular para example.com. Vamos usar essa zona para criar um conjunto de registros de recursos com a política de roteamento de failover. Execute o comando a seguir no Cloud Shell

Comandos

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc

Criar um registro DNS com a política de roteamento de failover

Use o comando gcloud dns record-sets create para criar um registro DNS com a política de roteamento de failover. O destino principal é o balanceador de carga em REGION_1. O Cloud DNS só oferece suporte a destinos de backup baseados em localização geográfica, o conjunto de backup é uma política de geolocalização com balanceador de carga REGION_2 como destino para REGION_1 e REGION_2. Execute os comandos a seguir no Cloud Shell

Comando

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Exemplo de saída

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. Testar a resolução de DNS

Antes de testar nossa configuração de failover, vamos anotar os endereços IP de ambos os balanceadores de carga internos. Execute os comandos a seguir no Cloud Shell.

Comando

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Exemplo de saída

Neste exemplo, us-west1-ilb tem um endereço IP de 10.1.0.4 e us-east4-ilb tem um endereço IP de 10.2.0.3

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Agora vamos fazer login na instância do cliente e testar a resolução do DNS. No console da Web, navegue até "Compute Engine | instâncias de VM"

5c824940bf414501.png

Clique no botão SSH para fazer login na instância do cliente no console.

b916eb32c60a4156.png

Agora que estamos na VM de cliente, use o comando dig para resolver o nome de domínio failover.example.com.

O loop está configurado para executar o comando dez vezes com um timer de suspensão de 6 segundos.

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Como o TTL no registro DNS está definido para 5 segundos, um timer de suspensão de 6 segundos foi adicionado. O timer vai garantir que você receba uma resposta DNS sem cache para cada solicitação DNS. Esse comando vai levar aproximadamente um minuto para ser executado.

Na saída, você verá o endereço IP do balanceador de carga no conjunto principal do registro de recurso. Na nossa configuração, será o IP do balanceador de carga na região us-west1.

11. Testar o failover

Vamos simular um failover removendo a tag de rede da VM REGION_1. Isso bloqueará o acesso à porta 80 e, como resultado, as verificações de integridade começarão a falhar.

Remover a tag de rede

Use o comando gcloud compute instances remove-tags para remover a tag de rede da VM. Execute o comando a seguir no Cloud Shell

Comando

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

A verificação de integridade vai falhar em 10 segundos. Execute o teste de resolução de DNS novamente.

Resolução de DNS

Na instância do cliente, execute o seguinte comando:

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Na saída, você verá o endereço IP do balanceador de carga no conjunto de backup do registro de recurso. Na nossa configuração, será o IP do balanceador de carga na região us-east4.

12. Testar o gotejamento de tráfego

Por padrão, a política de failover retorna o IP do endpoint principal de todas as solicitações de DNS e só retorna os IPs de backup se o primário falhar nas verificações de integridade. O Cloud DNS permite que os usuários configurem a proporção de erros, possibilitando que o Cloud DNS envie uma parte do tráfego para os destinos de backup, mesmo quando os alvos principais estiverem íntegros. A proporção precisa ser um valor entre 0 e 1. O valor padrão é 0.

Para testar isso, adicione a tag de rede de volta ao servidor da Web REGION_1.

Adicionar tag de rede

Adicione a tag novamente à VM do servidor da Web para permitir o tráfego HTTP na VM da região primária. Execute o seguinte comando no Cloud Shell:

Comando

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

As verificações de integridade são aprovadas em 10 segundos

Verifique se a resolução de DNS aponta para o balanceador de carga principal. Na nossa configuração, será o endereço IP do balanceador de carga na região us-west1.

Na instância do cliente, execute o seguinte comando:

Comando

dig +short failover.example.com

Atualizar o registro DNS

Agora, vamos modificar o registro DNS de failover.example.com para transferir 30% do tráfego para o conjunto de backup, mesmo quando o principal estiver íntegro. Execute o comando a seguir no Cloud Shell

Comando

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

Resolução de DNS

Execute o comando a seguir na VM de cliente. Você vai observar que o registro DNS failover.example.com vai ser resolvido para o IP aproximado do balanceador de carga principal. aproximadamente 70% do tempo e para o IP do balanceador de carga de backup 30% das vezes.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Etapas de limpeza

Para limpar os recursos usados neste laboratório, execute os comandos a seguir no Cloud Shell

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

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

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

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

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

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Parabéns

Parabéns, você implantou e testou com sucesso a política de roteamento de failover do Cloud DNS

O que vimos

  • Como configurar a política de roteamento de failover do Cloud DNS
  • Testar failover de DNS
  • Como transferir o tráfego para o conjunto de backup

Qual é a próxima etapa?

  • Tentar configurar vários IPs para conjuntos ativos e de backup
  • Tente adicionar várias VMs de back-end aos seus grupos de instâncias não gerenciadas
  • Tente configurar vários balanceadores de carga em regiões diferentes para a política de geolocalização no conjunto de backup.

Saiba mais

https://cloud.google.com/dns/docs/zones/manage-routing-policies