Implantar um servidor morno da Web recuperável com o Compute Engine e o Cloud Storage

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

Nesse padrão, um balanceador de carga direciona o tráfego para instâncias do Compute Engine em grupos gerenciados de instâncias que exibem o conteúdo. Caso haja uma interrupção, configuração do balanceamento de carga HTTP(S) externo é atualizada e é feito o failover para um site estático no Cloud Storage.

Para concluir este tutorial, você precisa de um nome de domínio registrado e gerenciado para 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.

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

Um balanceador de carga externo direciona o tráfego para grupos gerenciados de instâncias, e os usuários veem a experiência completa do site.

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

O balanceador de carga agora direciona os usuários para um site estático hospedado no Cloud Storage que exibe uma experiência mais limitada.

Esse padrão de failover morno equilibra o custo de execução de outro grupo gerenciado de instâncias em uma região diferente que você só usa quando as regiões principais falham. O custo de um site estático usando o Cloud Storage é menor do que a execução de outro grupo gerenciado de instâncias, mas há um pequeno atraso ao atualizar a configuração do balanceador de carga entre as opções de hospedagem. A experiência de site limitado no Cloud Storage é melhor do que uma página indisponível e a experiência ruim do cliente.

Para uma abordagem alternativa que usa o Cloud DNS em vez do balanceamento de carga HTTP(S) externo para controlar o failover, consulte Implantar um servidor da Web recuperável usando o Cloud DNS com o Compute Engine e o Cloud Storage. Esse padrão é útil se você tiver ou 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 configure o balanceamento de carga HTTP(S) externo.
  • Testar o failover morno do servidor da Web com uma configuração atualizada do balanceador de carga.
  • Testar a recuperação e o failback com uma configuração atualizada do balanceador de carga.

Custos

Neste tutorial, usamos 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. Novos usuários do Google Cloud podem ser 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.

    Acessar o seletor de projetos

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  4. Ative a API Compute Engine .

    Ative a API

  5. Instale e inicialize o SDK do Cloud..
  6. É possível executar a ferramenta de linha de comando gcloud no Console do Cloud sem instalar o SDK do Cloud. Para executar a ferramenta gcloud no Console do 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 utilizadas pelos comandos da ferramenta de linha de comando gcloud à 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 para desenvolvedores 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.

    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.

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.

A VM tem uma página HTML básica armazenada no disco permanente com um arquivo de configuração do Apache para carregar a partir do local do disco ativado.

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

Adicionar o bucket do Cloud Storage ao balanceador de carga

Com o bucket do Cloud Storage criado e configurado para hospedar conteúdo da Web estático, o balanceador de carga precisa de informações sobre como direcionar o tráfego até ele.

Em Criar e configurar um balanceador de carga, você criou um serviço de back-end para os grupos gerenciados de instâncias. O serviço de back-end tem um mapa de URL, e um proxy HTTP de destino ajuda a direcionar usuários do balanceador de carga às VMs.

Para se preparar para direcionar o tráfego para o bucket do Cloud Storage, configure o balanceador de carga com um novo mapa de URL e back-end para o bucket de armazenamento. Quando você precisar fazer failover, atualize o balanceador de carga para usar essa configuração.

  1. Adicione um back-end para o bucket do Cloud Storage:

    gcloud compute backend-buckets create \
        web-bucket-$NAME_SUFFIX \
        --gcs-bucket-name=static-web.$DOMAIN
    
  2. Crie um mapa de URL que permita o fluxo de tráfego para o back-end:

    gcloud compute url-maps create \
        web-map-http-bucket-$NAME_SUFFIX \
        --default-backend-bucket=web-bucket-$NAME_SUFFIX
    
  3. Revise as implantações de recursos antes de simular uma falha de zona. Todos os recursos foram criados para aceitar o ambiente, conforme mostrado na imagem a seguir:

    Um balanceador de carga externo direciona o tráfego para grupos gerenciados de instâncias, e os usuários veem a experiência completa do site.

    • Um balanceador de carga direciona o tráfego para dois grupos gerenciados de instâncias. Cada grupo gerenciados de instâncias contém duas VMs que executam um site básico.
    • Um bucket do Cloud Storage é configurado para hospedar páginas estáticas se houver uma falha temporária nos grupos gerenciados de instâncias.
    • O balanceador de carga está configurado para usar o site estático no Cloud Storage, mas não direciona o tráfego para o bucket de armazenamento atualmente.

Fazer o failover para o bucket do Cloud Storage

Em um ambiente real, é possível receber um alerta usando o Cloud Monitoring ou outra solução de monitoramento quando há um problema com os grupos gerenciados de instâncias. Este alerta solicita que um humano entenda o escopo da falha antes de atualizar o balanceador de carga para redirecionar o tráfego ao site estático hospedado pelo Cloud Storage. Uma alternativa é usar uma solução de monitoramento para responder automaticamente a interrupções com os grupos gerenciados de instâncias.

Quando você faz o failover, o balanceamento de carga HTTP(S) externo direciona o tráfego para o site estático hospedado no Cloud Storage, como mostrado na imagem a seguir:

O balanceador de carga agora direciona os usuários para um site estático hospedado no Cloud Storage e exibe uma experiência mais limitada.

Quando você ou a solução de monitoramento determinar que a ação mais apropriada é atualizar o balanceador de carga para direcionar o tráfego para o bucket de armazenamento, atualize o destino do proxy HTTP para usar o mapa de URL criado na seção anterior. Neste documento, o balanceador de carga é atualizado manualmente para redirecionar o tráfego ao site estático hospedado no Cloud Storage.

  1. Atualize o destino do proxy HTTP existente para usar o mapa de URL do bucket do Cloud Storage:

    gcloud compute target-http-proxies update \
        http-lb-proxy-$NAME_SUFFIX \
        --url-map=web-map-http-bucket-$NAME_SUFFIX
    
  2. Agora use curl ou abra o navegador da Web para acessar o endereço IP do balanceador de carga:

    curl $IP_ADDRESS
    

    O site estático do Cloud Storage é retornado, conforme mostrado na saída de exemplo a seguir:

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

    Pode levar alguns minutos para que o balanceador de carga atualize a configuração e direcione o tráfego corretamente para o bucket do Cloud Storage. Se necessário, aguarde alguns minutos e tente acessar o site novamente.

Fazer o fail back para os grupos gerenciados de instâncias

Depois que os problemas com os grupos gerenciados de instâncias forem resolvidos, é possível fazer o fail back para o conteúdo dos grupos gerenciados de instâncias com balanceamento de carga atualizando novamente a configuração do mapa de URLs. Novamente, um humano pode tomar essa decisão usando os insights do Cloud Monitoring para a integridade dos grupos gerenciados de instâncias. Ou você pode usar a automação para responder à integridade restaurada do grupo gerenciado de instâncias. Neste documento, você atualiza manualmente a configuração do balanceador de carga.

  1. Atualize o destino do proxy HTTP para usar novamente o mapa de URLs dos grupos gerenciados de instâncias:

    gcloud compute target-http-proxies update \
        http-lb-proxy-$NAME_SUFFIX \
        --url-map=web-map-http-$NAME_SUFFIX
    
  2. Use curl novamente ou abra o navegador da Web para acessar o endereço IP do balanceador de carga:

    curl $IP_ADDRESS
    

    Pode levar alguns minutos para que o balanceador de carga atualize a configuração e direcione corretamente o tráfego de volta para os grupos gerenciados de instâncias. Se necessário, aguarde alguns minutos e tente acessar o site novamente.

    O site principal dos grupos gerenciados de instâncias é retornado, conforme mostrado na saída de exemplo a seguir:

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

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 o bucket do Cloud Storage:

    gsutil rm -r gs://static-web.$DOMAIN
    
  2. 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 url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet
    
    gcloud compute backend-services delete \
        web-backend-service-$NAME_SUFFIX --global --quiet
    
    gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
    
  3. 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
    
  4. 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
    
  5. 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
    
  6. 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