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 com base em DNS, dependendo de critérios específicos, como peso, geolocalização 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.

Observação:no momento da criação deste laboratório, a política de failover e o suporte para verificações de integridade estão em pré-lançamento público.

Política de roteamento de failover

O Cloud DNS aceita 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 primários e de backup para um registro de recurso. Na operação normal, o Cloud DNS responde à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 veicular os endereços IP no conjunto de backup.

Observação:para que o Cloud DNS funcione conforme o esperado com as verificações de integridade, é preciso ativar o acesso global no balanceador de carga. Os usuários poderão criar políticas de roteamento para ILBs com acesso global desativado, mas o failover do Cloud DNS não vai funcionar.

Verificações de integridade

A política de roteamento de DNS depende das verificações de integridade unificadas(UHCs, na sigla em inglês) nativas do balanceador de carga interno. Um balanceador de carga interno é 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. Para um balanceador de carga HTTP(S) interno, a 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 de integridade diretos das instâncias de back-end individuais. Confira mais detalhes sobre as verificações de integridade aqui .

O que você vai criar

Neste codelab, você vai 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 é mostrada abaixo:

Observação:para simplificar este codelab, vamos ter um único balanceador de carga em cada uma das regiões configuradas como o conjunto ativo e de backup da política de roteamento de failover.

O que você vai aprender

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

O que é necessário

• Conhecimento básico de DNS
• Conhecimento básico do Google Compute Engine
• Conhecimento básico do 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.

• 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 É possível atualizar o local 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. 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 precisa ser 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ê estiver usando uma conta do Gmail, deixe o local padrão definido como Sem organização. Se você estiver usando 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 será muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou 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:

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.

3. Versão do SDK Google Cloud

No momento da redação deste artigo, 401.0.0 é a versão mais recente do SDK do Google Cloud. Todos os comandos deste laboratório foram testados usando 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.

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

Atenção:selecione a opção 1 ou 2 com base na saída do comando gcloud version.

1. Se a versão do SDK for 401.0.0 ou mais recente, avance para a próxima seção.
2. Se a versão do SDK for inferior a 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 prompt do Cloud Shell for parecido com a saída abaixo e você não planeja mudar o ID do projeto, pule para a próxima etapa (Definir variáveis de ambiente).

USER@cloudshell:~ (PROJECT_ID)$

Se você ainda quiser mudar o ID do projeto, use o comando listado abaixo. O prompt do Cloud Shell vai 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

Definir as variáveis de ambiente

Vamos usar 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

Observação:neste laboratório, usamos as regiões us-west1 e us-east4. A capacidade de computação pode ser limitada em uma zona. Se você encontrar erros de capacidade ao criar as VMs, use outra região/zona. Uma lista de regiões e zonas disponíveis pode ser encontrada aqui.

Verificar

Agora que as variáveis de ambiente estão definidas, vamos verificar usando o comando echo. A saída de cada comando deve 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 Compute e 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, vamos verificar usando 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. Criar regras de firewall, rede e sub-redes VPC

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. Estamos definindo o modo de sub-rede como personalizado porque vamos criar 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

É necessário permitir o tráfego na porta 80 das sub-redes da 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 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 do 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 o Cloud NAT

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

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 da região_1

Comandos

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

Cloud Router da região 2

Comandos

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

Criar 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 região_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 região_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, os grupos de instâncias não gerenciadas para os servidores da Web e a VM cliente.

Observação:neste laboratório, usamos as regiões us-west1 e us-east4. A capacidade de computação pode ser limitada em uma zona. Se você encontrar erros de capacidade ao criar as VMs, use outra região/zona. Uma lista de regiões e zonas disponíveis pode ser encontrada aqui.

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 de instâncias 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 do servidor da Web a eles.

Criar 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 da região 1

Comandos

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

Grupo de instâncias da região 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. Adicione o servidor da Web 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 da região 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 da região 2

Comandos

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

Criar uma VM de cliente

Vamos usar essa VM para executar testes e verificar nossa configuração de 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, precisamos 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, vamos adicionar os grupos de instâncias não gerenciadas a eles 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 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_DA_REGIÃO_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 uma 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 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ó é compatível com destinos de backup baseados em localização geográfica. O conjunto de backup é uma política de geolocalização com o 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, anote os endereços IP dos dois 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, o us-west1-ilb tem um endereço IP de 10.1.0.4 e o 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 de DNS. No console da Web, acesse "Compute Engine | Instâncias de VM".

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

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 de suspensão vai garantir que você receba uma resposta DNS sem cache para cada solicitação DNS. Esse comando leva aproximadamente um minuto para ser executado.

Na saída, você vai encontrar o endereço IP do balanceador de carga no conjunto principal do registro de recurso. Na nossa configuração, esse 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 vai bloquear o acesso à porta 80 e, como resultado, as verificações de integridade vão começar 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ê vai encontrar o endereço IP do balanceador de carga no conjunto de backup do registro de recurso. Na nossa configuração, esse será o IP do balanceador de carga na região us-east4.

12. Teste de gotejamento de tráfego

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

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

Adicionar tag de rede

Adicione a tag de volta à VM do servidor da Web para permitir o tráfego HTTP à VM da região principal. 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 serão aprovadas em 10 segundos.

Verifique se a resolução de DNS aponta para o balanceador de carga principal. Na nossa configuração, esse 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 enviar 30% do tráfego ao conjunto de backup, mesmo quando o primário 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 seguinte comando na VM do cliente. Você vai observar que o registro DNS failover.example.com será resolvido para o IP do balanceador de carga principal em aproximadamente 70% das vezes e para o IP do balanceador de carga de backup em aproximadamente 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 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 o failover de DNS
• Como direcionar o tráfego do trickle para o conjunto de backup

Qual é a próxima etapa?

• Tente 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