Usar a autorrecuperação para apps altamente disponíveis

Este tutorial interativo mostra como usar a recuperação automática para criar apps de alta disponibilidade no Compute Engine.

As apps de elevada disponibilidade são concebidas para publicar conteúdo para clientes com latência mínima e tempo de inatividade. A disponibilidade é comprometida quando uma app falha ou fica bloqueada. Os clientes de uma app comprometida podem sofrer uma latência elevada ou um tempo de inatividade.

A autorrecuperação permite-lhe reiniciar automaticamente as apps comprometidas. Deteta imediatamente instâncias de máquinas virtuais (VM) com falhas e recria-as automaticamente, para que os clientes possam voltar a receber serviços. Com a autorrecuperação, já não tem de repor manualmente uma app em serviço após uma falha.

Arquitetura da app

A app inclui os seguintes componentes do Compute Engine:

• Verificação de funcionamento: Uma política de verificação de funcionamento de HTTP usada pelo reparador automático para detetar VMs com falhas.
• Regras de firewall: Google Cloud as regras de firewall permitem-lhe autorizar ou negar tráfego para as suas VMs.
• Grupo de instâncias geridas: Um grupo de VMs que executam o mesmo serviço Web de demonstração.
• Modelo de instância: um modelo usado para criar cada VM no grupo de instâncias.

Como a verificação de funcionamento sonda o serviço Web de demonstração

Uma verificação de estado envia pedidos de sondagem a uma VM através de um protocolo especificado, como HTTP(S), SSL ou TCP. Para mais informações, consulte como funcionam as verificações de funcionamento e categorias, protocolos e portas de verificação de funcionamento.

A verificação de funcionamento neste tutorial é uma verificação de funcionamento de HTTP que analisa o caminho HTTP /health na porta 80. Para uma verificação de funcionamento de HTTP, o pedido de sondagem é aprovado apenas se o caminho devolver uma resposta HTTP 200 (OK). Para este tutorial, o servidor Web de demonstração define o caminho /health para devolver uma resposta HTTP 200 (OK) quando está em bom estado ou uma resposta HTTP 500 (Internal Server Error) quando está em mau estado. Para mais informações, consulte os critérios de êxito para HTTP, HTTPS e HTTP/2.

Crie a verificação de funcionamento

Para configurar a autorreparação, crie uma verificação de funcionamento personalizada e configure a firewall de rede para permitir sondagens de verificação de funcionamento.

Neste tutorial, cria uma verificação de funcionamento regional. Para a autocorreção, pode usar uma verificação de estado regional ou global. As verificações de estado regionais reduzem as dependências entre regiões e ajudam a alcançar a residência dos dados. As verificações de estado globais são convenientes se quiser usar a mesma verificação de estado para os MIGs em várias regiões.

Sugestão profissional: use verificações de funcionamento separadas para o balanceamento de carga e para a recuperação automática. As verificações de estado do balanceamento de carga detetam VMs que não respondem e desviam o tráfego das mesmas. As verificações de funcionamento para a autocorreção detetam e recriam VMs com falhas, pelo que devem ser menos agressivas do que as verificações de funcionamento do balanceamento de carga. A utilização da mesma verificação de estado para estes serviços removeria a distinção entre VMs sem resposta e VMs com falhas, o que causaria latência e indisponibilidade desnecessárias para os seus utilizadores.
Para mais informações, consulte o artigo O que torna uma verificação de funcionamento de autorrecuperação eficaz.

Consola

1. Crie uma verificação de funcionamento.

   1. Na Google Cloud consola, aceda à página Criar verificação de funcionamento.

      Aceda a Criar verificação de saúde

   2. No campo Nome, introduza autohealer-check.

   3. Defina o Âmbito como Regional.

   4. No menu pendente Região, selecione europe-west1.

   5. Para Protocolo, selecione HTTP.

   6. Defina o Caminho do pedido como /health. Isto indica o caminho HTTP que a verificação de estado usa. Para este tutorial, o servidor Web de demonstração define o caminho /health para devolver uma resposta HTTP 200 (OK) quando está em bom estado ou uma resposta HTTP 500 (Internal Server Error) quando está em mau estado.

   7. Defina os critérios de saúde:

      1. Defina o Intervalo de verificação como 10. Isto define o período de tempo desde o início de uma sondagem até ao início da seguinte.
      2. Defina o Limite de tempo para 5. Isto define o período durante o qual o dispositivoGoogle Cloud aguarda uma resposta a uma sondagem. Este valor tem de ser inferior ou igual ao intervalo de verificação.
      3. Definir limite saudável para 2. Isto define o número de sondagens sequenciais que têm de ser bem-sucedidas para que a VM seja considerada em bom estado.
      4. Defina o limite não saudável para 3. Isto define o número de sondagens sequenciais que têm de falhar para que a VM seja considerada não saudável.

   8. Deixe os valores predefinidos para as outras opções.

   9. Clique em Criar na parte inferior.

2. Crie uma regra de firewall para permitir que as sondas de verificação de funcionamento façam pedidos HTTP.

   1. Na Google Cloud consola, aceda à página Criar regra de firewall.

      Aceda a Criar regra de firewall

   2. Em Nome, introduza default-allow-http-health-check.

   3. Para Rede, selecione default.

   4. Em Segmentações, selecione All instances in the network.

   5. Para o Filtro de origem, selecione IPv4 ranges.

   6. Para Intervalos de IPv4 de origem, introduza 130.211.0.0/22, 35.191.0.0/16.

      Nota: as sondagens de verificação de funcionamento provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Para este tutorial, a verificação de funcionamento usa o protocolo HTTP, por isso, certifique-se de que a regra da firewall permite ligações à porta 80. Para mais informações, consulte o artigo Configurar a verificação de funcionamento e a autorrecuperação para grupos de instâncias geridos.

   7. Em Protocolos e portas, selecione TCP e introduza 80.

   8. Deixe os valores predefinidos para as outras opções.

   9. Clique em Criar.

gcloud

1. Crie uma verificação de funcionamento com o comando health-checks create http.

   gcloud compute health-checks create http autohealer-check \
       --region europe-west1 \
       --check-interval 10 \
       --timeout 5 \
       --healthy-threshold 2 \
       --unhealthy-threshold 3 \
       --request-path "/health"
   

   • check-interval define o período de tempo desde o início de uma sondagem até ao início da seguinte.
   • timeout define a quantidade de tempo que Google Cloud aguarda uma resposta a uma sondagem. Este valor tem de ser inferior ou igual ao intervalo de verificação.
   • healthy-threshold define o número de sondagens sequenciais que têm de ser bem-sucedidas para que a VM seja considerada em bom estado.
   • unhealthy-threshold define o número de sondagens sequenciais que têm de falhar para que a VM seja considerada danificada.
   • request-path indica o caminho HTTP que a verificação de estado usa. Para este tutorial, o servidor Web de demonstração define o caminho /health para devolver uma resposta HTTP 200 (OK) quando estiver em bom estado ou uma resposta HTTP 500 (Internal Server Error) quando estiver em mau estado.

2. Crie uma regra de firewall para permitir que as sondas de verificação de funcionamento façam pedidos HTTP.

   gcloud compute firewall-rules create default-allow-http-health-check \
       --network default \
       --allow tcp:80 \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

   Nota: as sondas de verificação de funcionamento provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Para este tutorial, a verificação de funcionamento usa o protocolo HTTP, por isso, certifique-se de que a regra da firewall permite ligações à porta 80. Para mais informações, consulte o artigo Configurar a verificação de funcionamento e a autorrecuperação para grupos de instâncias geridos.

O que torna uma verificação de funcionamento de autorreparação boa

As verificações de estado de funcionamento usadas para a autorreparação devem ser conservadoras para não eliminarem e recriarem as instâncias antecipadamente. Quando uma verificação de estado do reparador automático é demasiado agressiva, o reparador automático pode confundir instâncias ocupadas com instâncias com falhas e reiniciá-las desnecessariamente, reduzindo a disponibilidade.

• unhealthy-threshold. Deve ser superior a 1. Idealmente, defina este valor como 3 ou mais. Isto protege contra falhas raras, como a perda de um pacote de rede.
• healthy-threshold. Um valor de 2 é suficiente para a maioria das apps.
• timeout. Defina este valor de tempo para um valor generoso (cinco vezes ou mais do que o tempo de resposta esperado). Isto protege contra atrasos inesperados, como instâncias ocupadas ou uma ligação de rede lenta.
• check-interval. Este valor deve estar entre 1 segundo e o dobro do tempo limite (não demasiado longo nem demasiado curto). Quando um valor é demasiado longo, não é detetada uma instância com falha com a devida antecedência. Quando um valor é demasiado curto, as instâncias e a rede podem ficar visivelmente ocupadas, dado o elevado número de sondagens de verificação do estado de funcionamento que são enviadas a cada segundo.

Configure o serviço Web

Este tutorial usa uma app Web armazenada no GitHub. Se quiser saber mais sobre como a app foi implementada, consulte o repositório do GitHub GoogleCloudPlatform/python-docs-samples.

Para configurar o serviço Web de demonstração, crie um modelo de instância que inicie o servidor Web de demonstração no arranque. Em seguida, use este modelo de instância para implementar um grupo de instâncias gerido e ativar a autorrecuperação.

Consola

1. Crie um modelo de instância. Inclua um script de arranque que inicie o servidor Web de demonstração.

   1. Na Google Cloud consola, aceda à página Criar modelo de instância.

      Aceda a Criar modelo de instância

   2. Defina o Nome como webserver-template.

   3. Na secção Localização, no menu pendente Região, selecione europe-west1.

   4. Na secção Configuração da máquina, no menu pendente Tipo de máquina, selecione e2-medium.

   5. Na secção Firewall, selecione a caixa de verificação Permitir tráfego HTTP.

   6. Expanda a secção Opções avançadas para revelar as definições avançadas. São apresentadas várias subsecções.

   7. Na secção Gestão, encontre Automatização e introduza o script de arranque seguinte:

      apt-get update
      apt-get -y install git python3-pip python3-venv
      git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
      python3 -m venv venv
      ./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
      ./venv/bin/pip3 install gunicorn
      ./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo
      

   8. Deixe os valores predefinidos para as outras opções.

   9. Clique em Criar.

2. Implemente o servidor Web como um grupo de instâncias geridas.

   1. Na Google Cloud consola, aceda à página Criar grupo de instâncias.

      Aceda a Criar grupo de instâncias

   2. Defina o Nome como webserver-group.

   3. Para Modelo de instância, selecione webserver-template.

   4. Para Região, selecione europe-west1.

   5. Para Zona, selecione europe-west1-b.

   6. Na secção Ajuste automático de escala, para Modo de ajuste automático de escala, selecione Desativado: não ajustar automaticamente a escala.

   7. Desloque a página para trás até ao campo Número de instâncias e defina-o como 3.

   8. Na secção Reparação automática, faça o seguinte:

      1. No menu pendente Verificação de saúde, selecione autohealer-check.

      2. Defina Initial delay como 300.

         Nota: o atraso inicial é o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado com falhas porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta válida durante o atraso inicial, indica que o processo de arranque está concluído e a VM está pronta. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. Na consola, o valor predefinido é 300.

   9. Deixe os valores predefinidos para as outras opções.

   10. Clique em Criar.

3. Crie uma regra de firewall que permita pedidos HTTP aos servidores Web.

   1. Na Google Cloud consola, aceda à página Criar regra de firewall.

      Aceda a Criar regra de firewall

   2. Em Nome, introduza default-allow-http.

   3. Para Rede, selecione default.

   4. Em Segmentações, selecione Specified target tags.

   5. Para Etiquetas de segmentação, introduza http-server.

   6. Para o Filtro de origem, selecione IPv4 ranges.

   7. Para Intervalos IPv4 de origem, introduza 0.0.0.0/0 para permitir o acesso a todos os endereços IP.

   8. Em Protocolos e portas, selecione TCP e introduza 80.

   9. Deixe os valores predefinidos para as outras opções.

   10. Clique em Criar.

gcloud

1. Crie um modelo de instância. Inclua um script de arranque que inicie o servidor Web de demonstração.

   gcloud compute instance-templates create webserver-template \
       --instance-template-region europe-west1 \
       --machine-type e2-medium \
       --tags http-server \
       --metadata startup-script='
     apt-get update
     apt-get -y install git python3-pip python3-venv
     git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
     python3 -m venv venv
     ./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
     ./venv/bin/pip3 install gunicorn
     ./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo'
   

2. Crie um grupo de instâncias gerido.

   gcloud compute instance-groups managed create webserver-group \
       --zone europe-west1-b \
       --template projects/PROJECT_ID/regions/europe-west1/instanceTemplates/webserver-template \
       --size 3 \
       --health-check projects/PROJECT_ID/regions/europe-west1/healthChecks/autohealer-check \
       --initial-delay 300
   

   Nota: o atraso inicial é o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado sem êxito porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta saudável durante o atraso inicial, indica que o processo de arranque está concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o MIG altera o campo currentAction da VM para VERIFYING. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. O valor predefinido é 0.

3. Crie uma regra de firewall que permita pedidos HTTP aos servidores Web.

   gcloud compute firewall-rules create default-allow-http \
       --network default \
       --allow tcp:80 \
       --target-tags http-server
   

Aguarde alguns minutos para que o grupo de instâncias gerido crie e valide as respetivas VMs.

Nota: se as verificações de estado falharem, as suas VMs podem estar a demorar mais tempo do que o esperado a inicializar. Pondere ajustar o atraso inicial:

1. Na Google Cloud consola, aceda à página Grupos de instâncias.
2. Clique em webserver-group.
3. Clique em Edit.
4. Em Período de inicialização, aumente o número de segundos. Pode introduzir um número de 0 a 3600.
5. Clique em Guardar e aguarde que o grupo de instâncias gerido seja atualizado.

Simule falhas de verificações de funcionamento

Para simular falhas na verificação de funcionamento, o servidor Web de demonstração oferece formas de forçar uma falha na verificação de funcionamento.

Consola

1. Navegue para uma VM de servidor Web.

   1. Na Google Cloud consola, aceda à página Instâncias de VM.

      Aceder às instâncias de VM

   2. Para qualquer VM webserver-group, na coluna IP externo, clique no endereço IP. É aberto um novo separador no seu navegador de Internet. Se o pedido expirar ou a página Web não estiver disponível, aguarde um minuto para permitir que o servidor termine a configuração e tente novamente.

   O servidor Web de demonstração apresenta uma página semelhante à seguinte:

   

2. Na página Web de demonstração, clique em Tornar não saudável.

   Isto faz com que o servidor Web falhe a verificação de funcionamento. Especificamente, o servidor Web faz com que o caminho /health devolva um HTTP 500 (Internal Server Error). Pode verificar esta situação rapidamente clicando no botão Verificar estado de funcionamento (esta ação deixa de funcionar depois de o reparador automático ter começado a reiniciar a VM).

3. Aguarde que o autohealer tome medidas.

   1. Na Google Cloud consola, aceda à página Instâncias de VM.

      Aceder às instâncias de VM

   2. Aguarde que o estado da VM do servidor Web se altere. A marca de verificação verde junto ao nome da VM deve mudar para um quadrado cinzento, o que indica que o reparador automático começou a reiniciar a VM não saudável.

   3. Clique em Atualizar na parte superior da página periodicamente para ver o estado mais recente.

   4. O processo de autorrecuperação termina quando o quadrado cinzento volta a ser uma marca de verificação verde, o que indica que a VM está novamente em bom estado.

gcloud

1. Monitorize o estado do grupo de instâncias geridas. (Quando terminar, pare premindo Ctrl+C.)

   while : ; do
     gcloud compute instance-groups managed list-instances webserver-group \
     --zone europe-west1-b
     sleep 5  # Wait for 5 seconds
   done
   

     NAME: webserver-group-0zx6
     ZONE: europe-west1-b
     STATUS: RUNNING
     HEALTH_STATE: HEALTHY
     ACTION: NONE
     INSTANCE_TEMPLATE: webserver-template
     VERSION_NAME:
     LAST_ERROR:
   
     NAME: webserver-group-4qbx
     ZONE: europe-west1-b
     STATUS: RUNNING
     HEALTH_STATE: HEALTHY
     ACTION: NONE
     INSTANCE_TEMPLATE: webserver-template
     VERSION_NAME:
     LAST_ERROR:
   
     NAME: webserver-group-m5v5
     ZONE: europe-west1-b
     STATUS: RUNNING
     HEALTH_STATE: HEALTHY
     ACTION: NONE
     INSTANCE_TEMPLATE: webserver-template
     VERSION_NAME:
     LAST_ERROR:
   

   Todas as VMs no grupo têm de apresentar STATUS: RUNNING e ACTION: NONE. Caso contrário, aguarde alguns minutos para que as VMs terminem a configuração e tente novamente.

2. Abra uma nova sessão do Cloud Shell com a CLI Google Cloud instalada.

   Nota: se estiver a usar o Cloud Shell, pode abrir várias sessões.

3. Obtenha o endereço de uma VM do servidor Web.

   gcloud compute instances list --filter webserver-group
   

   Na coluna EXTERNAL_IP, copie o endereço IP de qualquer VM do servidor Web e guarde-o como uma variável bash local.

   export IP_ADDRESS=EXTERNAL_IP_ADDRESS
   

4. Verifique se o servidor Web concluiu a configuração. O servidor devolve uma resposta HTTP 200 OK.

   curl --head $IP_ADDRESS/health
   

   HTTP/1.1 200 OK
   Server: gunicorn
   ...
   

   Se receber um erro Connection refused, aguarde um minuto para permitir que o servidor conclua a configuração e tente novamente.

5. Tornar o servidor Web pouco saudável.

   curl $IP_ADDRESS/makeUnhealthy > /dev/null
   

   Isto faz com que o servidor Web falhe a verificação de funcionamento. Especificamente, o servidor Web faz com que o caminho /health devolva um HTTP 500 INTERNAL SERVER ERROR. Pode verificar isto rapidamente fazendo um pedido para /health (isto deixa de funcionar depois de o reparador automático ter começado a reiniciar a VM).

   curl --head $IP_ADDRESS/health
   

   HTTP/1.1 500 INTERNAL SERVER ERROR
   Server: gunicorn
   ...
   

6. Regresse à primeira sessão da shell para monitorizar o grupo de instâncias gerido e aguarde que o reparador automático tome medidas.

   1. Quando o processo de autorreparação é iniciado, as colunas STATUS e ACTION são atualizadas, indicando que o autorreparador começou a reiniciar a VM não saudável.

        NAME: webserver-group-0zx6
        ZONE: europe-west1-b
        STATUS: STOPPING
        HEALTH_STATE: UNHEALTHY
        ACTION: RECREATING
        INSTANCE_TEMPLATE: webserver-template
        VERSION_NAME:
        LAST_ERROR:
      
        ...
      

   2. O processo de autocorreção termina quando a VM volta a comunicar um STATUS de RUNNING e um ACTION de NONE, o que indica que a VM foi reiniciada com êxito.

        NAME: webserver-group-0zx6
        ZONE: europe-west1-b
        STATUS: RUNNING
        HEALTH_STATE: HEALTHY
        ACTION: NONE
        INSTANCE_TEMPLATE: webserver-template
        VERSION_NAME:
        LAST_ERROR:
      
        ...
      

   3. Quando terminar a monitorização do grupo de instâncias gerido, pare premindo Ctrl+C.

   Nota: para mais informações acerca dos possíveis estados e ações das VMs, consulte Ciclo de vida da instância e Ações atuais nas instâncias.

Não hesite em repetir este exercício. Seguem-se algumas ideias:

• O que acontece se tornar todas as VMs não íntegras ao mesmo tempo? Para mais informações sobre o comportamento da autocorreção durante falhas simultâneas, consulte o comportamento da autocorreção.

• Pode atualizar a configuração da verificação de funcionamento para reparar as VMs o mais rapidamente possível? (Na prática, deve definir os parâmetros de verificação do estado para usar valores conservadores, conforme explicado neste tutorial. Caso contrário, pode correr o risco de as VMs serem eliminadas e reiniciadas por engano quando não existe um problema real.)

• O grupo de instâncias geridas tem uma initial delay definição de configuração. Consegue determinar o atraso mínimo necessário para este servidor Web de demonstração? (Na prática, deve definir o atraso para um período ligeiramente superior (10% a 20%) ao necessário para uma VM arrancar e começar a publicar pedidos de apps. Caso contrário, corre o risco de a VM ficar bloqueada num ciclo de arranque de autorreparação.)

Veja o histórico do reparador automático (opcional)

Para ver um histórico das operações do Autohealer, use o seguinte comando gcloud:

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

Para mais informações, consulte o artigo Ver operações de autocorreção do histórico