Implantar um servidor da Web recuperável a frio com discos permanentes regionais

Last reviewed 2021-08-04 UTC

---

No documento, descrevemos como implantar uma topologia de failover frio para um servidor da Web usando um grupo gerenciado de instâncias com discos permanentes regionais. Este documento é destinado a arquitetos e pessoas que trabalham em equipes operacionais e administrativas.

Você cria um grupo gerenciado de instâncias que executa uma única VM com um disco permanente regional que armazena dados. Um balanceamento de carga de aplicativo externo direciona os usuários para a VM executada no grupo gerenciado de instâncias, conforme mostrado no diagrama a seguir:

Se houver uma falha na instância, o grupo de instâncias gerenciadas tentará recriar a VM na mesma zona. Se a falha estiver no nível da zona, o Cloud Monitoring ou similar pode informar que há um problema e você cria manualmente outro grupo de instâncias gerenciadas em outra zona de trabalho. Em qualquer um dos cenários de failover, a plataforma anexa o disco permanente regional à nova VM no grupo de instâncias.

Neste documento, você usa o endereço IP externo da VM ou o balanceador de carga para visualizar uma página básica no servidor da Web. Essa abordagem permite testar o padrão de failover frio se você não tiver um nome de domínio registrado e sem alterações no DNS. Em um ambiente de produção, crie e configure uma zona e um registro do Cloud DNS que sejam resolvidos para o endereço IP externo atribuído ao balanceador de carga.

Esse cenário equilibra a diferença de custos de execução de várias VMs com a manutenção de um determinado nível de proteção de dados. Os custos aumentam à medida que você executa um disco permanente regional que fornece a replicação contínua de dados entre duas zonas em uma região, mas minimiza o risco de perda de dados se houver uma falha no nível da zona. Para reduzir seus custos de armazenamento, implante um servidor da Web recuperável a frio usando snapshots de disco permanente.

Veja na tabela a seguir algumas diferenças de alto nível nas opções de proteção de dados para abordagens recuperáveis que usam discos permanentes regionais ou snapshots de discos permanentes. Para mais informações, consulte Opções de alta disponibilidade usando discos permanentes.

	Discos permanentes regionais	Snapshots de discos permanentes
Perda de dados: objetivo de ponto de recuperação (RPO)	Zero para uma única falha, como interrupção sustentada em uma zona ou rede desconectada.	Qualquer dado desde o último snapshot foi tirado, que normalmente é de uma hora ou mais. A possível perda de dados depende da programação de snapshot que controla a frequência com que os snapshots são tirados.
Objetivo de tempo de recuperação (RTO).	Tempo de implantação de uma nova VM, além de vários segundos para que o disco permanente regional seja reanexado.	O tempo de implantação de uma nova VM e o tempo para criar um novo disco permanente a partir do snapshot mais recente. O tempo de criação do disco depende do tamanho dele e pode levar dezenas de minutos ou horas.
Custo	O custo de armazenamento é o dobro, já que o disco permanente regional é replicado continuamente para outra zona.	Você paga apenas pela quantidade de espaço de snapshot consumido.
	Para mais informações, consulte Preços de discos e imagens.

Objetivos

• Crie um grupo de instâncias gerenciadas para executar uma VM com um disco permanente regional.
• Crie um modelo de instância e um script de inicialização.
• Criar e configurar um balanceador de carga de aplicativo externo.
• Teste o failover do servidor da Web frio com um grupo de instâncias gerenciadas de substituição.

Custos

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

• Compute Engine
• Rede
• Disco permanente

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

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.

Neste documento, 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 necessário, forneça seu próprio sufixo de nome para recursos, como app.

   Especifique uma região, como us-central1, e duas zonas nessa região, como us-central1-a e us-central1-f. Essas zonas definem onde o disco permanente regional e o grupo de instâncias gerenciadas inicial são implantados e onde você pode fazer o failover manualmente, se necessário.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION=us-central1
   ZONE1=us-central1-a
   ZONE2=us-central1-f
   

Criar uma VPC e uma sub-rede

Para fornecer acesso à rede às VMs, crie uma nuvem privada virtual (VPC, na sigla em inglês) e uma sub-rede. Como o grupo de instâncias gerenciadas funciona entre zonas dentro de uma única região, somente uma sub-rede é criada. 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
   

   Se você vir um prompt do Cloud Shell, autorize essa primeira solicitação para fazer chamadas de API.

2. Crie uma sub-rede na nova VPC. Defina seu próprio intervalo de endereços, como 10.1.0.0/20, que caiba no intervalo da rede:

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

Crie 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 uma VM e um disco permanente regional

Um disco permanente regional oferece replicação contínua de dados entre duas zonas em uma região. Os grupos de instâncias gerenciadas, executados nas mesmas duas zonas que o disco permanente regional, podem anexar o disco a uma VM.

Observação: neste documento, você cria e configura manualmente a VM base e as imagens. Nas implantações reais, 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.

1. Crie um SSD de 10 GiB. Entenda suas necessidades de armazenamento e os custos associados ao pagamento pelo espaço provisionado, não pelo consumido. Para mais informações, consulte preços do disco permanente.

   gcloud compute disks create disk-$NAME_SUFFIX \
       --region $REGION \
       --replica-zones $ZONE1,$ZONE2 \
       --size=10 \
       --type=pd-ssd
   

2. Crie uma VM base com o disco permanente regional anexado:

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE1 \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=debian-10-buster-v20210721 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --disk=mode=rw,name=disk-$NAME_SUFFIX,device-name=disk-$NAME_SUFFIX,scope=regional
   

   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.

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

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

4. 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. Atualize a variável NAME_SUFFIX para corresponder ao valor definido no início deste documento, como app:

   #!/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-$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 test web server with regional persistent disks!</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
   

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

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

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

7. Saia da sessão SSH da VM.

   exit
   

8. 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 $ZONE1 \
       --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 test web server with regional persistent disks!</p>
   </body>
   </html>
   

   Esta etapa confirma que o Apache está configurado corretamente e a página está carregada do disco permanente regional 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.

Crie uma imagem de VM e um modelo de instância

Para criar VMs idênticas que podem ser implantadas automaticamente sem configuração adicional, use uma imagem de VM personalizada. Essa imagem captura a configuração do SO e do Apache. Cada VM criada no grupo de instâncias gerenciadas nas próximas etapas usa essa imagem.

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

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

2. Crie uma imagem da VM base configurada na seção anterior:

   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE1 \
       --storage-location=$REGION
   

3. Crie um modelo de instância que defina a configuração de cada VM:

   gcloud compute instance-templates create template-$NAME_SUFFIX \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION/subnetworks/subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=image-$NAME_SUFFIX \
       --region=$REGION \
       --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
   

   A imagem criada na etapa anterior é definida como a origem de cada VM, e um script de inicialização também é definido para montar o disco permanente regional.

Criar um grupo de instâncias gerenciadas

Um grupo gerenciado de instâncias executa as VMs. O grupo de instâncias gerenciadas é executado em uma zona definida e monitora a integridade das VMs. Se houver uma falha de instância e a VM parar de ser executada, o grupo de instâncias gerenciadas tentará recriar outra VM na mesma zona e anexará o disco permanente regional. Se a falha estiver no nível da zona, execute manualmente o failover frio e crie outro grupo de instâncias gerenciadas em uma zona diferente. A mesma imagem personalizada e o mesmo modelo de instância configuram a VM automaticamente de maneira idêntica.

1. Crie uma verificação de integridade para monitorar as VMs no grupo gerenciado de instâncias. Essa verificação de integridade garante que a VM responda na porta 80. Para seus próprios aplicativos, monitore as portas apropriadas para verificar a integridade da VM.

   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX --port 80
   

2. Crie um grupo de instâncias gerenciadas, inicialmente com zero VMs, que usa o modelo de instância criado na etapa anterior.

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE1 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

3. Crie uma única VM no grupo gerenciado de instâncias e anexe o disco permanente regional. Se houver uma falha dessa VM, o grupo de instâncias gerenciadas tentará recriá-la na mesma zona e reanexar o disco permanente.

   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE1\
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   Observação: não é possível ter mais de uma VM em execução no grupo de instâncias gerenciadas ao mesmo tempo. O disco permanente regional só pode ser conectado a uma VM por vez.

Para este cenário de aplicativo recuperável, não crie regras de escalonamento automático para aumentar o número de VMs executadas no grupo de instâncias gerenciadas.

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 no grupo gerenciado 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-$ZONE1 \
       --named-ports http:80 \
       --zone $ZONE1
   
   # Create a backend service and add the managed instance group 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-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --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 ou 502 será retornado se o balanceador de carga ainda estiver sendo implantado. 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 test web server with regional persistent disks!</p>
   </body>
   </html>
   

Simular uma falha e recuperação de zona

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

• Uma VM com execuções em um grupo de instâncias gerenciadas, com um disco permanente regional anexado que armazena um site básico.
• Um script de inicialização é aplicado a um modelo de instância para que as VMs criadas no grupo de instâncias gerenciadas ativem o disco permanente regional.
• Uma verificação de integridade monitora o status das VMs dentro do grupo gerenciado de instâncias.
• O balanceador de carga de aplicativo externo direciona os usuários para a VM que é executada no grupo de instâncias gerenciadas.
• Se a VM falhar, o grupo de instâncias gerenciadas tentará recriar uma na mesma zona. Se a falha estiver no nível da zona, você precisará criar manualmente um grupo de instâncias gerenciadas substituto em outra zona de trabalho.

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. Esse alerta solicita que um humano entenda o escopo da falha antes de criar manualmente um grupo de instâncias gerenciadas de substituição em outra zona de trabalho. Uma abordagem alternativa é usar sua solução de monitoramento para responder automaticamente a interrupções com o grupo gerenciado de instâncias.

Quando você ou sua solução de monitoramento determinarem a ação mais apropriada é fazer o failover, crie um grupo de instâncias gerenciadas de substituição. Neste documento, você cria manualmente esse recurso de substituição.

1. Para simular uma falha no nível da zona, exclua o back-end do balanceador de carga e o grupo de instâncias gerenciadas:

   gcloud compute backend-services remove-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --global
   
   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE1 \
         --zone=$ZONE1
   

   Quando solicitado, confirme a solicitação para excluir o grupo de instâncias gerenciadas.

   Em um ambiente de produção, seu sistema de monitoramento gera um alerta para solicitar ações de failover a frio.

2. Use curl ou seu navegador da Web novamente para acessar o endereço IP do balanceador de carga:

   curl $IP_ADDRESS --max-time 5
   

   A solicitação curl falha porque não há destinos íntegros para o balanceador de carga.

3. Para simular o failover frio, crie um grupo de instâncias gerenciadas em uma zona diferente:

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE2 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE2 \
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   A imagem da VM, o modelo da instância e o disco permanente regional mantêm toda a configuração da instância do aplicativo.

4. Atualize o balanceador de carga para adicionar o novo grupo de instâncias gerenciadas e a nova VM:

   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$ZONE2 \
       --named-ports http:80 \
       --zone $ZONE2
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance-group-zone=$ZONE2 \
       --global
   

5. Use curl ou o navegador da Web mais uma vez para acessar o endereço IP do balanceador de carga que direciona o tráfego para a VM executada no grupo de instâncias gerenciadas:

   curl $IP_ADDRESS
   

   A VM leva alguns minutos para concluir a implantação e anexar o disco permanente regional. Se necessário, aguarde alguns minutos e tente acessar o site novamente.

   Na resposta de exemplo a seguir, a página da Web é executada corretamente na VM:

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

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

2. Exclua o grupo de instâncias gerenciadas e a verificação de integridade:

   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE2 \
       --zone=$ZONE2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

3. Exclua o modelo de instância, a imagem, a VM base e o disco permanente:

   gcloud compute instance-templates delete template-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX --zone=$ZONE1 --quiet
   
   gcloud compute disks delete disk-$NAME_SUFFIX --region=$REGION --quiet
   

4. 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
   

5. Exclua o endereço IP externo estático, a sub-rede e a VPC:

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

A seguir

• Para uma abordagem alternativa e reduzir seus custos de armazenamento, consulte Implantar um servidor da Web recuperável a frio usando snapshots de disco permanente.
• 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.