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:
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
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.
- 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.
-
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Ative a API Compute Engine .
- Instale a CLI do Google Cloud.
-
Para inicializar a CLI gcloud, execute o seguinte comando:
gcloud init
-
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Ative a API Compute Engine .
- Instale a CLI do Google Cloud.
-
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.
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, comoapp
.Especifique duas regiões, como
us-west1
eus-west2
, e uma zona dentro de uma dessas regiões, comous-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.
Crie a VPC com um modo de sub-rede personalizado:
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
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
e10.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.
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 intervalo0.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.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.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
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.
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.
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.
Para instalar e configurar o site simples, primeiro conecte-se à VM base usando o SSH.
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
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.Grave o arquivo e saia do editor. Por exemplo, no Nano, use
Ctrl-O
para gravar o arquivo e saia comCtrl-X
.Torne o script de configuração executável e execute-o:
chmod +x configure-vm.sh ./configure-vm.sh
Saia da sessão SSH da VM.
exit
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.
Antes de criar uma imagem, é necessário parar a VM:
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
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.
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
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)")
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.
Verifique o domínio que você quer usar com o bucket do Cloud Storage.
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, comoexample.com
. Este exemplo armazena os arquivos estáticos emstatic-web.example.com
.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
Faça o upload do arquivo HTML básico ao bucket do Cloud Storage:
gsutil cp index.html gs://static-web.$DOMAIN
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
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.
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, comoexample.com
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, comons-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.
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.
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.
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 valorc.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.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.
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, comons-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.
Para resolver o registro
www
da sua zona do Cloud DNS em um desses servidores de nomes, use o comandodig
: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 comandodescribe
anterior. Forneça seu próprio endereço de servidor de nomes mostrado na saída do comando anteriorA 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
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.
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
Crie um registro
CNAME
parawww
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
Confirme as atualizações na zona do Cloud DNS:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use o comando
dig
para confirmar que o registrowww
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 acessarwww.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:
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
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
Confirme as atualizações na zona do Cloud DNS:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use o comando
dig
mais uma vez para confirmar que o registrowww
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:
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
Exclua o bucket do Cloud Storage:
gsutil rm -r gs://static-web.$DOMAIN
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
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
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
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
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.