Implante um servidor da Web recuperável usando o Cloud DNS com o Compute Engine e o Cloud Storage

Last reviewed 2021-06-28 UTC

---

Este documento é destinado a arquitetos e pessoas que trabalham em equipes operacionais e administrativas. O documento descreve um padrão de exemplo que pode ser usado em implantações no Google Cloud.

Nesta arquitetura, o Cloud DNS direciona o tráfego para instâncias do Compute Engine em grupos gerenciados de instâncias que disponibilizam o conteúdo. Em uma interrupção, você atualiza a zona do Cloud DNS e faz o failover para um site estático no Cloud Storage.

Para implementar essa solução, você precisa de um nome de domínio registrado que controle e queira usar com este documento.

Em implantações de produção, seu site provavelmente inclui muito mais arquivos e códigos de aplicativo adicionais nas máquinas virtuais (VMs) do grupo de instâncias gerenciadas do que é mostrado neste documento. Em seguida, o Cloud Storage hospeda uma versão estática mais limitada que oferece o mínimo de funcionalidade. Em um cenário de failover quente, os usuários veem esse site limitado até que os grupos de instâncias gerenciadas se recuperem e possam veicular tráfego para a experiência completa do site.

Arquitetura

Nesta arquitetura, você implantará recursos para criar um ambiente, conforme mostrado na imagem a seguir:

Quando você precisar fazer failover, atualize a configuração do Cloud DNS para direcionar o tráfego para o Cloud Storage, conforme mostrado na imagem a seguir:

Esse padrão de failover quente equilibra o custo da execução de outro grupo de instâncias gerenciadas em uma região diferente que só é usada quando a região principal falha. O custo de um site estático que usa o Cloud Storage é menor do que a execução de outro grupo de instâncias gerenciadas, mas há um pequeno atraso à medida que você atualiza o Cloud DNS entre as opções de hospedagem. A experiência limitada de sites no Cloud Storage é melhor do que um site completamente indisponível e uma experiência ruim do cliente.

Para uma abordagem alternativa que usa o balanceador de carga de aplicativo externo em vez do Cloud DNS para controlar o failover, consulte Implantar um servidor da Web recuperável com o Compute Engine e o Cloud Storage. Esse padrão é útil se você não tiver ou não quiser usar o Cloud DNS.

Para executar aplicativos confiáveis no Google Cloud, recomendamos que você projete a infraestrutura do aplicativo para lidar com interrupções. Dependendo das necessidades dos aplicativos e negócios, talvez seja necessário um padrão de failover frio, morno ou quente. Para mais informações sobre como determinar a melhor abordagem para os aplicativos, consulte o Guia de planejamento de recuperação de desastres.

Neste documento, usamos um servidor da Web Apache básico. No entanto, a mesma abordagem para a implantação de infraestrutura se aplica a outros ambientes de aplicativos que você precisar criar.

Objetivos

• Criar grupos gerenciados de instâncias regionais com uma imagem de VM personalizada.
• Criar um bucket do Cloud Storage
• Criar e configurar uma zona do Cloud DNS
• Teste o failover do servidor da Web com os registros do Cloud DNS atualizados.
• Teste a recuperação e o failback com registros atualizados do Cloud DNS.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Compute Engine
• Rede
• Cloud DNS
• Cloud Storage

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

As restrições de segurança definidas pela sua organização podem impedir que você conclua as etapas a seguir. Para informações sobre solução de problemas, consulte Desenvolver aplicativos em um ambiente restrito do Google Cloud.

1. Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

4. Ative a API Compute Engine .

   Ative a API

5. Instale a CLI do Google Cloud.

6. Para inicializar a CLI gcloud, execute o seguinte comando:

   gcloud init

7. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

8. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

9. Ative a API Compute Engine .

   Ative a API

10. Instale a CLI do Google Cloud.

11. Para inicializar a CLI gcloud, execute o seguinte comando:

    gcloud init

É possível executar a Google Cloud CLI no console do Google Cloud sem instalá-la. Para executar a gcloud CLI no Console do Google Cloud, use o Cloud Shell.

Prepare o ambiente

Nesta seção, você define algumas variáveis para os locais e nomes de recursos. Essas variáveis são usadas pelos comandos da Google Cloud CLI à medida que você implanta os recursos.

Nesta implantação, salvo indicação em contrário, você insere todos os comandos no Cloud Shell ou no ambiente de desenvolvimento local.

1. Substitua PROJECT_ID pelo seu código do projeto: Se desejar, forneça seu próprio sufixo de nome para os recursos que ajudam a pesquisar e identificá-los, como app.

   Especifique duas regiões, como us-west1 e us-west2, e uma zona dentro de uma dessas regiões, como us-west1-a. Essa zona define onde a VM inicial de base usada é criada. Ela é usada para criar uma imagem para o grupo gerenciado de instâncias.

   Por fim, defina um domínio usado para o site estático, como example.com.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

Criar uma VPC e uma sub-rede

Para fornecer acesso de rede às VMs, crie a nuvem privada virtual (VPC) e sub-redes. Como você precisa de grupos gerenciados de instâncias em duas regiões, crie uma sub-rede em cada região. Para mais informações sobre as vantagens do modo de sub-rede personalizada para gerenciar intervalos de endereços IP em uso no ambiente, consulte Usar redes VPC de modo personalizado.

1. Crie a VPC com um modo de sub-rede personalizado:

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. Agora, crie duas sub-redes na nova VPC, uma para cada região. Defina seus próprios intervalos de endereços, como 10.1.0.0/20 e 10.2.0.0/20, que se encaixem no intervalo de rede:

   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION1 \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION1
   
   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION2 \
       --network=network-$NAME_SUFFIX \
       --range=10.2.0.0/20 \
       --region=$REGION2
   

Crie regras de firewall

Para permitir o fluxo de tráfego de rede corretamente na VPC, use regras de firewall.

1. Crie regras de firewall para permitir tráfego da Web e verificações de integridade para o balanceador de carga e os grupos gerenciados de instâncias:

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   A regra HTTP permite o tráfego para qualquer VM em que a tag http-server seja aplicada e de qualquer origem usando o intervalo 0.0.0.0/0. Para a regra da verificação de integridade, os intervalos padrão do Google Cloud estão configurados para permitir que a plataforma verifique corretamente a integridade dos recursos.

2. Para permitir o tráfego SSH para a configuração inicial de uma imagem de VM de base, defina o escopo da regra de firewall para o ambiente usando o parâmetro --source-range. Talvez seja necessário trabalhar com a equipe de rede para determinar quais intervalos de origem sua organização usa.

   Atenção: não recomendamos usar um intervalo 0.0.0.0/0 amplo que permita todo o tráfego. Para definir o escopo do tráfego para um único endereço IP, use uma máscara de rede /32, como 35.230.62.163/32.

   Substitua IP_ADDRESS_SCOPE pelos seus próprios escopos de endereços IP:

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. Depois de criar as regras de firewall, verifique se as três regras foram adicionadas:

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   O exemplo de saída a seguir mostra que as três regras foram criadas corretamente:

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

Criar e configurar uma imagem de VM base

Para criar VMs idênticas que podem ser implantadas sem outras configurações, use uma imagem de VM personalizada. Essa imagem captura a configuração do SO e do Apache e é usada para criar cada VM no grupo gerenciado de instâncias nas próximas etapas.

Observação: neste documento, você cria e configura manualmente a VM base e as imagens. Nas implantações de produção, use as ferramentas e os pipelines de implantação existentes para automatizar o máximo possível desse processo. Para mais informações, consulte Como gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.

Na VM, crie um arquivo index.html básico no disco permanente e monte-o em /var/www/example.com. Um arquivo de configuração do Apache em /etc/apache2/sites-available/example.com.conf disponibiliza conteúdo da Web a partir do local do disco permanente ativado.

No diagrama a seguir, veja a página HTML básica exibida pelo Apache que está armazenada no disco permanente.

Crie esse ambiente nas etapas a seguir.

1. Crie uma VM base com um disco permanente anexado:

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION1 \
       --tags=http-server \
       --image=debian-10-buster-v20210420 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
   

   Use os parâmetros definidos no início deste documento para nomear a VM e se conectar à sub-rede correta. Os nomes também são atribuídos pelos parâmetros dos discos de inicialização e de dados.

2. Para instalar e configurar o site simples, primeiro conecte-se à VM base usando o SSH.

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. Na sessão SSH para a VM, crie um script para configurar a VM em um editor de sua escolha. O exemplo a seguir usa Nano (em inglês) como o editor:

   nano configure-vm.sh
   

   Cole o script de configuração a seguir no arquivo.

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   Atualize a variável NAME_SUFFIX para corresponder ao valor definido no início deste documento, como app.

4. Grave o arquivo e saia do editor. Por exemplo, no Nano, use Ctrl-O para gravar o arquivo e saia com Ctrl-X.

5. Torne o script de configuração executável e execute-o:

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. Saia da sessão SSH da VM.

   exit
   

7. Consiga o endereço IP da VM e use curl para ver a página da Web básica:

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   O site básico é retornado, conforme mostrado no seguinte exemplo de saída:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   Esta etapa confirma que o Apache está configurado corretamente e a página está carregada do disco permanente anexado. Nas próximas etapas, você criará uma imagem usando essa VM base e configurará um modelo de instância com um script de inicialização.

Implantar os recursos do Compute Engine

Esse padrão de failover morno usa grupos gerenciados de instâncias para executar as VMs. Os grupos gerenciados de instâncias são executados em duas regiões, e cada grupo monitora a integridade das VMs. Se houver uma interrupção e uma das VMs falhar, o grupo gerenciado de instâncias recriará a VM. Essa configuração cria um aplicativo altamente disponível, mesmo sem o failover quente, em um site estático no Cloud Storage.

1. Antes de criar uma imagem, é necessário parar a VM:

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. Execute o seguinte conjunto de comandos para criar as imagens da VM, modelos de instância e grupos gerenciados de instâncias:

   # Create the base VM images
   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   gcloud compute images create image-disk-$NAME_SUFFIX \
       --source-disk=disk-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   # Create instance templates
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \
       --template=template-$NAME_SUFFIX-$REGION1 \
       --size=2 \
       --region=$REGION1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \
       --template=template-$NAME_SUFFIX-$REGION2 \
       --size=2 \
       --region=$REGION2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

Criar e configurar um balanceador de carga

Para que os usuários acessem um site, é necessário permitir o tráfego até as VMs executadas nos grupos gerenciados de instâncias. Também é necessário redirecionar automaticamente o tráfego para novas VMs se houver uma falha de zona em um grupo gerenciado de instâncias.

Na seção a seguir, você cria um balanceador de carga externo com um serviço de back-end para tráfego HTTP na porta 80, usa a verificação de integridade criada nas etapas anteriores e mapeia um endereço IP até serviço de back-end.

Para mais informações, consulte Como configurar um balanceador de carga HTTP externo simples.

1. Crie e configure o balanceador de carga para o aplicativo:

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --named-ports http:80 \
       --region $REGION1
   
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --named-ports http:80 \
       --region $REGION2
   
   # Create a backend service and add the managed instance groups to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \
       --instance-group-region=$REGION1 \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \
       --instance-group-region=$REGION2 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. Consiga o endereço IP da regra de encaminhamento do tráfego da Web:

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. Use curl ou abra o navegador da Web para ver o site usando o endereço IP do balanceador de carga da etapa anterior:

   curl $IP_ADDRESS
   

   O balanceador de carga leva alguns minutos para concluir a implantação e direcionar o tráfego corretamente para o back-end. Um erro HTTP 404 será retornado se o balanceador de carga ainda estiver em implantação. Se necessário, aguarde alguns minutos e tente acessar o site novamente.

   O site básico é retornado, conforme mostrado no seguinte exemplo de saída:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Criar e configurar um bucket de armazenamento

O Cloud Storage é usado para guardar arquivos estáticos de sites. Neste exemplo básico, você cria um único arquivo com texto um pouco diferente do que nas VMs.

Em implantações de produção, o site provavelmente inclui muito mais arquivos e outros códigos de aplicativo nas VMs do grupo gerenciado de instâncias do que o mostrado neste documento. A versão estática hospedada no Cloud Storage geralmente é uma versão mais limitada que oferece funcionalidade mínima. Em um cenário de failover quente, esse site limitado do Cloud Storage é exibido até que os grupos gerenciados de instâncias se recuperem e possam exibir o tráfego para a experiência completa do site.

1. Verifique o domínio que você quer usar com o bucket do Cloud Storage.

2. Crie um bucket do Cloud Storage para corresponder ao nome do domínio que você tem e quer usar:

   gsutil mb gs://static-web.$DOMAIN
   

   A variável DOMAIN definida no início deste documento é usada, como example.com. Este exemplo armazena os arquivos estáticos em static-web.example.com.

3. Crie um arquivo local que você copiará para o bucket do Cloud Storage na próxima etapa:

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. Faça o upload do arquivo HTML básico ao bucket do Cloud Storage:

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. Para permitir que os usuários visualizem o conteúdo estático da Web, defina as permissões apropriadas no bucket do Cloud Storage:

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. Configure o bucket do Cloud Storage para exibir o arquivo index.html como a página da Web padrão:

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Criar uma zona e um registro DNS

Para permitir que o tráfego seja direcionado ao site estático quente no Cloud Storage quando houver uma interrupção com os grupos de instâncias gerenciadas, crie uma zona do Cloud DNS. Em condições normais, essa zona do DNS direciona o tráfego por meio do balanceador de carga externo para os grupos de instâncias gerenciadas criados nas seções anteriores.

Observação: com uma abordagem baseada em DNS para failover, os usuários continuam a resolver o endereço antigo do balanceador de carga até o registro DNS em cache expirar. O período em que o registro DNS armazenado em cache existe para um usuário é definido com o valor do time to live (TTL) quando você cria os registros do Cloud DNS. Como este documento descreve um padrão de failover morno, uma quantidade de inatividade é esperada como parte do equilíbrio de um padrão de failover quente com custo extra e complexidade de configuração.

1. Criar uma zona do Cloud DNS:

   gcloud dns managed-zones create zone-$NAME_SUFFIX \
       --dns-name=$DOMAIN \
       --description="DNS zone for warm site failover"
   

   É usada a variável DOMAIN definida no início deste documento, como example.com

2. Veja os detalhes da zona do Cloud DNS:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   O exemplo de saída a seguir mostra o nameServers da zona, como ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

3. O Cloud DNS precisa ser autoritativo para seu domínio. Crie registros NS com o registrador de domínios que aponte para a zona do Cloud DNS. Use os endereços do servidor de nomes retornados na etapa anterior.

   Para mais informações e um exemplo usando o Google Domains, consulte Como atualizar servidores de nomes.

4. Na sua zona do Cloud DNS, adicione um registro para www usando o endereço IP do balanceador de carga obtido em uma seção anterior:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

   Esse registro direciona as solicitações do usuário para o site por meio do balanceador de carga para os grupos de instâncias gerenciadas. Um TTL de 300 segundos é definido para reduzir o tempo de duração do registro DNS armazenado em cache para um usuário.

5. Crie um registro para ser usado pelo bucket do Cloud Storage para o site estático:

   gcloud dns record-sets transaction add c.storage.googleapis.com. \
       --name=static-web.$DOMAIN \
       --ttl=300 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

   Neste exemplo, usamos static-web como subdomínio. Deixe o valor c.storage.googleapis.com. novamente. Um TTL de 300 segundos é definido para reduzir o tempo que o registro DNS armazenado em cache existe para um usuário.

6. Por fim, confirme as adições de registro DNS na zona:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

Verificar e testar a zona e os registros DNS

Vamos analisar as implantações de recursos antes de simular uma falha de zona. Todos os recursos foram criados para serem compatíveis com o ambiente, como mostrado na imagem a seguir:

• Os registros da zona do Cloud DNS direcionam os usuários ao balanceador de carga para distribuição entre as VMs do grupo de instâncias gerenciadas.
• Um bucket do Cloud Storage é configurado para hospedar páginas da Web estáticas se houver uma interrupção nos grupos de instâncias gerenciadas.
• A zona do Cloud DNS está configurada para usar o site estático no Cloud Storage, mas atualmente não resolve solicitações para o bucket de armazenamento.

Para ver os registros DNS e a resolução de teste, você precisa resolver endereços nos servidores do Cloud DNS. Nas implantações de produção, teste e verifique se os endereços estão corretos e, em seguida, atualize seus próprios servidores DNS para resolver adequadamente. Este documento não detalha as etapas para atualizar seus próprios servidores DNS, apenas como verificar o fluxo de tráfego corretamente em condições normais e de failover.

1. Para ver os detalhes da zona do Cloud DNS novamente:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   O exemplo de saída a seguir mostra o nameServers da zona, como ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

2. Para resolver o registro www da sua zona do Cloud DNS em um desses servidores de nomes, use o comando dig:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   Neste exemplo, usamos o endereço do servidor de nomes ns-cloud-b1.googledomains.com retornado do comando describe anterior. Forneça seu próprio endereço de servidor de nomes mostrado na saída do comando anterior

   A saída de exemplo a seguir mostra que o registro é resolvido para o endereço IP do balanceador de carga. Se você usou esse servidor de nomes para acessar o endereço, como curl e o parâmetro --resolve com o servidor de nomes do Cloud DNS, a página padrão seria exibida em um dos gerenciados grupos de instâncias por trás do balanceador de carga.

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

3. Use o comando dig novamente para verificar o registro DNS do site estático no Cloud Storage:

   dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
   

   A saída de exemplo a seguir mostra que o registro é resolvido no Cloud Storage que pode exibir o conteúdo estático do bucket de armazenamento:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com static-web.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;static-web.example.com.    IN      A
   
   ;; ANSWER SECTION:
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

Faça o failover para o bucket do Cloud Storage

Em um ambiente de produção, é possível receber um alerta usando o Cloud Monitoring ou outra solução de monitoramento quando houver um problema com os grupos de instâncias gerenciadas. Nesse alerta, uma pessoa precisa entender o escopo da falha antes de atualizar os registros do Cloud DNS para redirecionar o tráfego ao site estático hospedado no Cloud Storage. Uma abordagem alternativa é usar sua solução de monitoramento para responder automaticamente a interrupções com os grupos de instâncias gerenciadas.

Quando você faz o failover, o Cloud DNS resolve o tráfego para o site estático hospedado no Cloud Storage, conforme mostrado na seguinte imagem:

Quando você ou sua solução de monitoramento determinar a ação mais apropriada é atualizar os registros do Cloud DNS para direcionar o tráfego para o Cloud Storage, atualize o registro A do DNS atual. Neste documento, você atualiza manualmente os registros do Cloud DNS para redirecionar o tráfego para o site estático hospedado no Cloud Storage.

1. Para fazer o failover dos registros do Cloud DNS, remova o registro A existente que é resolvido para o balanceador de carga:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

2. Crie um registro CNAME para www que aponte para o conteúdo hospedado no Cloud Storage:

   gcloud dns record-sets transaction add static-web.$DOMAIN \
       --name=www.$DOMAIN. \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

3. Confirme as atualizações na zona do Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Use o comando dig para confirmar que o registro www agora é resolvido para o endereço do site estático do Cloud Storage:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   O exemplo de saída a seguir mostra que o registro www.example.com se refere ao registro CNAME do site estático do Cloud Storage. As solicitações para acessar www.example.com são redirecionadas para o bucket do Cloud Storage, que exibe o site estático:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    30      IN      CNAME   static-web.example.com.
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

Voltar para os grupos de instâncias gerenciadas

Depois que os problemas com os grupos de instâncias gerenciadas forem resolvidos, você poderá falhar ao exibir o conteúdo dos grupos de instâncias gerenciadas com balanceamento de carga atualizando os registros do Cloud DNS. Novamente, uma pessoa pode tomar essa decisão usando os insights do Cloud Monitoring para a integridade dos grupos de instâncias gerenciadas. Ou você pode usar a automação para responder à integridade restaurada do grupo de instâncias gerenciadas. Neste documento, você atualiza manualmente os registros do Cloud DNS.

Quando você falha, o Cloud DNS resolve o tráfego para os grupos de instâncias gerenciadas novamente, conforme mostrado na imagem a seguir:

1. Remova o registro CNAME www que redireciona o tráfego para o conteúdo hospedado no Cloud Storage:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove static-web.$DOMAIN \
       --name=www.$DOMAIN \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

2. Adicione um registro A para apontar novamente para o balanceador de carga na frente dos grupos de instâncias gerenciadas:

   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

3. Confirme as atualizações na zona do Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Use o comando dig mais uma vez para confirmar que o registro www resolve para o endereço do balanceador de carga na frente dos grupos de instâncias gerenciadas novamente:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   A saída de exemplo a seguir mostra que o registro resolve para o endereço IP do balanceador de carga e o tráfego seria exibido de um dos grupos de instâncias gerenciadas:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Para excluir os recursos individuais criados neste documento, conclua as etapas a seguir:

1. Exclua a zona e os registros DNS:

   touch empty-file
   gcloud dns record-sets import -z zone-$NAME_SUFFIX \
       --delete-all-existing \
       empty-file
   rm empty-file
   
   gcloud dns managed-zones delete zone-$NAME_SUFFIX
   

2. Exclua o bucket do Cloud Storage:

   gsutil rm -r gs://static-web.$DOMAIN
   

3. Exclua a configuração do balanceador de carga:

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   

4. Exclua os grupos gerenciados de instâncias e a verificação de integridade:

   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 --quiet
   
   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

5. Exclua os modelos de instância, imagens, VM base e discos permanentes:

   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION1 --quiet
   
   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION2 --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-disk-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX \
       --zone=$ZONE --quiet
   

6. Exclua as regras de firewall.

   gcloud compute firewall-rules delete \
       allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-http-$NAME_SUFFIX --quiet
   

7. Exclua a sub-rede e a VPC.

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet
   
   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

A seguir

• Para uma abordagem alternativa que usa o balanceador de carga de aplicativo externo em vez do Cloud DNS para controlar o failover, consulte Implantar um servidor da Web recuperável com o Compute Engine e o Cloud Storage. Esse padrão é útil se você não tiver ou não quiser usar o Cloud DNS.
• Para saber como determinar a melhor abordagem para os aplicativos e qual método de recuperação usar, consulte o Guia de planejamento de recuperação de desastres.
• Para ver outros padrões de aplicativos, como failover frio e quente, consulte Cenários de recuperação de desastres para aplicativos.
• Para mais maneiras de lidar com o escalonamento e disponibilidade, consulte os Padrões para aplicativos escalonáveis e resilientes.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.