Como configurar verificação de integridade e recuperação automática para instâncias em MIGs

Para melhorar a disponibilidade do seu app e verificar se ele está respondendo, configure uma política de recuperação automática para o seu grupo de instâncias gerenciadas (MIG, na sigla em inglês).

Essa política depende de uma verificação de integridade baseada em aplicativo para verificar se um app está respondendo conforme o esperado. Verificar se um app responde é mais preciso do que apenas verificar se uma instância está em estado RUNNING.

Quando a recuperação automática determina que um app não está respondendo, o grupo de instâncias gerenciadas recria automaticamente essa instância. No caso de uma instância preemptiva, o grupo recriará a instância quando os recursos necessários ficarem disponíveis novamente.

Comportamento da recuperação automática

A recuperação automática recria instâncias não íntegras usando o modelo original usado para criar a instância de máquina virtual (VM, na sigla em inglês), que não é necessariamente o modelo atual no grupo de instâncias gerenciadas. Por exemplo, se uma instância de VM tiver sido criada com instance-template-a e depois você atualizar o grupo de instâncias gerenciadas para usar instance-template-b no modo OPPORTUNISTIC, a recuperação automática continuará usando instance-template-a para recriar a instância. Isso ocorre porque as recriações da recuperação automática não são iniciadas pelo usuário. Por isso, o Compute Engine não supõe que a instância de VM precise usar o novo modelo. Se você quiser aplicar um novo modelo, consulte Como alterar o modelo de instância de um grupo de instâncias gerenciadas.

Em determinado momento, o número de instâncias com recuperação automática simultânea é menor que o tamanho do grupo de instâncias gerenciadas. Isso garante que o grupo continue executando um subconjunto de instâncias mesmo que, por exemplo, a política de recuperação automática não se ajuste à carga de trabalho, as regras de firewall estejam configuradas incorretamente ou haja problemas de infraestrutura ou conectividade de rede que identifiquem erroneamente a instância como não íntegra. No entanto, se um grupo de instâncias gerenciadas zonal tiver apenas uma instância ou um grupo de instâncias gerenciadas regional tiver apenas uma instância por zona, a recuperação automática recriará essas instâncias quando elas não estiverem íntegras.

A recuperação automática não recria uma instância durante o período de inicialização dessa instância. Para mais informações, consulte a propriedade autoHealingPolicies[].initialDelaySec. Essa configuração atrasa a verificação feita pela recuperação automática e a recriação possivelmente prematura da instância caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando a instância tem uma currentAction VERIFYING.

Recuperação automática e discos

Ao recriar uma instância com base no modelo, o recuperador automático lida com diferentes tipos de discos de maneiras distintas. Com algumas configurações de disco, o recuperador automático pode falhar ao tentar recriar uma instância gerenciada.

Tipo de disco autodelete Comportamento durante uma operação de recuperação automática
Novo disco permanente true O disco é recriado conforme especificado no modelo da instância. Todos os dados que foram gravados nele são perdidos quando o disco e a respectiva instância são recriados.
Novo disco permanente false O disco é preservado e reanexado quando o recuperador automático recria a instância.
Disco permanente atual true O disco antigo é excluído. A recriação da instância da VM falha porque o Compute Engine não pode reanexar um disco excluído à instância.
Disco permanente existente false O disco antigo é reanexado conforme especificado no modelo da instância. Os dados no disco são mantidos. No entanto, caso haja discos de leitura e gravação, um grupo de instâncias gerenciadas só pode ter uma VM, visto que um único disco permanente não pode ser anexado a várias instâncias no modo de leitura/gravação.
Novo SSD local N/A O disco é recriado conforme especificado no modelo da instância. Os dados em um SSD local são perdidos quando uma instância é recriada ou excluída.

A recuperação automática não reanexa discos não especificados no modelo da instância, como discos que você anexou manualmente a uma VM após a criação dela.

Para manter dados importantes que foram gravados no disco, tome precauções como estas:

  • Crie snapshots do disco permanente regularmente.

  • Exporte dados para outra fonte, como o Cloud Storage.

Se suas instâncias têm configurações importantes que você quer manter, o Google também recomenda o uso de uma imagem personalizada no modelo da instância. Uma imagem personalizada contém as configurações personalizadas necessárias. Quando você especifica uma imagem personalizada no modelo da instância, o grupo de instâncias gerenciadas (MIG, na sigla em inglês) recria instâncias usando a imagem personalizada que contém as configurações personalizadas necessárias.

Como configurar uma verificação de integridade e uma política de recuperação automática

É possível definir, no máximo, uma política de recuperação automática por grupo de instâncias gerenciadas.

É possível aplicar uma única verificação de integridade a até 50 grupos de instâncias gerenciadas. Se você tiver mais de 50 grupos, crie várias verificações de integridade.

Exemplo de configuração de verificação de integridade

O exemplo a seguir mostra como usar uma verificação de integridade em um grupo de instâncias gerenciadas. Neste exemplo, você cria uma verificação de integridade que procura uma resposta do servidor da Web na porta 80. Para permitir que as sondagens da verificação de integridade alcancem cada servidor da Web, você configura uma regra de firewall. Por fim, para aplicar a verificação de integridade ao grupo de instâncias gerenciadas, você define a política de recuperação automática do grupo.

Console

  1. Crie uma verificação de integridade para recuperação automática que seja mais conservadora do que uma verificação de integridade de balanceamento de carga.

    Por exemplo, crie uma verificação de integridade que procure uma resposta na porta 80 e que possa tolerar alguma falha antes de marcar as instâncias como UNHEALTHY e fazer com que elas sejam recriadas. Neste exemplo, uma instância será marcada como íntegra se retornar com êxito uma só vez. Ela será marcada como não íntegra se retornar com falha 3 vezes consecutivas.

    1. Acesse a página Criar verificação de integridade no Console do GCP.

      Acessar a página "Criar verificação de integridade"

    2. Dê um nome à verificação de integridade, como example-check.
    3. Em Protocolo, verifique se HTTP está selecionado.
    4. Em Porta, insira 80.
    5. Em Intervalo de verificação, insira 5.
    6. Em Tempo limite, insira 5.
    7. Defina um Limite íntegro para determinar quantas verificações de integridade bem-sucedidas e consecutivas precisam ser retornadas antes que uma instância não íntegra seja marcada como íntegra. Digite 1 para este exemplo.
    8. Defina um Limite não íntegro para determinar quantas verificações de integridade malsucedidas consecutivas precisam ser retornadas antes que uma instância íntegra seja marcada como não íntegra. Digite 3 para este exemplo.
    9. Clique em Criar para criar a verificação de integridade.
  2. Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao seu app.

    As sondagens da verificação de integridade são provenientes dos endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Portanto, verifique se as regras de firewall da sua rede permitem a conexão da verificação de integridade. Neste exemplo, nosso grupo de instâncias gerenciadas usa a rede default e as respectivas instâncias escutam na porta 80. Se a porta 80 ainda não estiver aberta na rede padrão, crie uma regra de firewall.

    1. Acesse a página Criar regra de firewall no Console do GCP.

      Acessar a página "Criar regra de firewall"

    2. Em Nome, insira o nome da regra de firewall (por exemplo, allow-health-check).
    3. Em Rede, selecione a rede default.
    4. Em Filtro de origem, selecione IP ranges.
    5. Em Intervalos de IPs de origem, insira 130.211.0.0/22 e 35.191.0.0/16.
    6. Em Portas e protocolos, selecione Protocolos e portas especificados e insira tcp:80.
    7. Clique em Criar.
  3. Aplique a verificação de integridade configurando uma política de recuperação automática para seu grupo de instâncias gerenciadas regional ou zonal.

    1. Acesse a página Grupos de instâncias no Console do GCP.

      Acessar a página "Grupos de instâncias"

    2. Na coluna Nome da lista, clique no nome do grupo de instâncias em que você quer aplicar a verificação de integridade.
    3. Clique em Editar grupo para modificar o grupo de instâncias gerenciadas.
    4. Em Recuperação automática, selecione a verificação de integridade criada anteriormente.
    5. Altere ou mantenha a configuração de Atraso inicial. Essa configuração impede que a recuperação automática recrie prematuramente uma instância em processo de inicialização. O timer de atraso inicial começa quando a currentAction da instância é VERIFYING.
    6. Clique em Salvar para aplicar as alterações.

    A recuperação automática pode levar 15 minutos para começar a monitorar as instâncias no grupo.

gcloud

Para usar os exemplos de linha de comando deste guia, instale a ferramenta de linha de comando gcloud ou use um Cloud Shell.

  1. Crie uma verificação de integridade para recuperação automática que seja mais conservadora do que uma verificação de integridade de balanceamento de carga.

    Por exemplo, crie uma verificação de integridade que procure uma resposta na porta 80 e possa tolerar alguma falha antes de marcar as instâncias como UNHEALTHY e induzir a recriação delas. Neste exemplo, uma instância será marcada como íntegra se retornar com êxito uma só vez. Ela será marcada como não íntegra se retornar com falha 3 vezes consecutivas.

    gcloud compute health-checks create http example-check --port 80 \
        --check-interval 30s \
        --healthy-threshold 1 \
        --timeout 10s \
        --unhealthy-threshold 3
    
  2. Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao seu app.

    As sondagens da verificação de integridade são provenientes dos endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Portanto, verifique se suas regras de firewall permitem a conexão da verificação de integridade. Neste exemplo, nosso grupo de instâncias gerenciadas usa a rede default e as respectivas instâncias escutam na porta 80. Se a porta 80 ainda não estiver aberta na rede padrão, crie uma regra de firewall.

    gcloud compute firewall-rules create allow-health-check \
        --allow tcp:80 \
        --source-ranges 130.211.0.0/22,35.191.0.0/16 \
        --network default
    
  3. Aplique a verificação de integridade configurando uma política de recuperação automática para seu grupo de instâncias gerenciadas regional ou zonal.

    Use o comando update para aplicar a verificação de integridade ao grupo de instâncias gerenciadas.

    A configuração initial-delay da recuperação automática atrasa a recriação prematura da instância caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando a currentAction da instância é VERIFYING.

    Exemplo:

    gcloud compute instance-groups managed update my-mig \
        --health-check example-check \
        --initial-delay 300 \
        --zone us-east1-b
    

    A recuperação automática pode levar 15 minutos para começar a monitorar as instâncias no grupo.

API

Para usar os exemplos de API deste guia, configure o acesso à API.

  1. Crie uma verificação de integridade para recuperação automática que seja mais conservadora do que uma verificação de integridade de balanceamento de carga.

    Por exemplo, crie uma verificação de integridade que procure uma resposta na porta 80 e possa tolerar alguma falha antes de marcar as instâncias como UNHEALTHY e induzir a recriação delas. Neste exemplo, uma instância será marcada como íntegra se retornar com êxito uma só vez. Ela será marcada como não íntegra se retornar com falha 3 vezes consecutivas.

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
    
    {
     "name": "example-check",
     "type": "http",
     "port": 80,
     "checkIntervalSec": 30,
     "healthyThreshold": 1,
     "timeoutSec": 10,
     "unhealthyThreshold": 3
    }
    
  2. Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao seu app.

    As sondagens da verificação de integridade são provenientes dos endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Portanto, verifique se suas regras de firewall permitem a conexão da verificação de integridade. Neste exemplo, nosso grupo de instâncias gerenciadas usa a rede default e as respectivas instâncias escutam na porta 80. Se a porta 80 ainda não estiver aberta na rede padrão, crie uma regra de firewall.

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
     "sourceRanges": [
      "130.211.0.0/22",
      "35.191.0.0/16"
     ],
     "allowed": [
      {
       "ports": [
        "80"
       ],
       "IPProtocol": "tcp"
      }
     ]
    }
    
  3. Aplique a verificação de integridade configurando uma política de recuperação automática para seu grupo de instâncias gerenciadas regional ou zonal.

    Uma política de recuperação automática faz parte de um recurso instanceGroupManager ou regionInstanceGroupManager.

    Defina uma política de recuperação automática usando os métodos insert ou patch.

    No exemplo a seguir, definimos uma política de recuperação automática usando o método instanceGroupManagers.patch.

    PATCH https://www.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    A configuração initialDelaySec da recuperação automática atrasa a recriação prematura da instância caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando a currentAction da instância é VERIFYING.

    A recuperação automática pode levar 15 minutos para começar a monitorar as instâncias no grupo.

    Para desativar a recuperação automática baseada em aplicativo, defina a política de recuperação automática com um valor vazio, autoHealingPolicies[]. Com autoHealingPolicies[], o grupo de instâncias gerenciadas só recria as instâncias que não estão em estado RUNNING.

    É possível ver a política de recuperação automática de um grupo de instâncias gerenciadas lendo o campo instanceGroupManagers.autoHealingPolicies. É possível receber um recurso de grupo de instâncias gerenciadas usando um dos métodos a seguir:

Como verificar o status

Para verificar se uma instância foi criada e o respectivo aplicativo está respondendo, inspecione a ação atual em cada instância ou verifique o status do grupo.

Quando você anexa uma verificação de integridade a um grupo de instâncias gerenciadas pela primeira vez, o monitoramento pode levar 15 minutos para começar.

Ações atuais nas instâncias

Quando uma instância gerenciada está em processo de criação, o currentAction dela é CREATING. Se uma política de recuperação automática é anexada ao grupo, com a instância gerenciada criada e em execução, a instância passa ao currentAction VERIFYING e o verificador de integridade começa a sondar o aplicativo dela. Se o aplicativo for aprovado nessa verificação de integridade inicial durante o tempo que ele leva para iniciar, a instância será verificada e o respectivo currentAction passará a ser NONE.

Para visualizar o desempenho do currentAction e o status de cada instância em um grupo de instâncias gerenciadas, use a ferramenta de linha de comandogcloud ou a API.

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud retorna uma lista de instâncias no grupo de instâncias e respectivos status e ações atuais. Exemplo:

NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f           CREATING  my-new-template
vm-instances-h2r1  us-central1-f           DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING  NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING  NONE      my-old-template

API

Na API, faça uma solicitação POST ao método regionInstanceGroupManagers.listManagedInstances. Para um grupo de instâncias gerenciadas zonal, use o método instanceGroupManagers.listManagedInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

A API retorna uma lista de instâncias do grupo, incluindo instanceStatus e currentAction de cada instância.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

Cada instância em um grupo de instâncias gerenciadas tem o status descrito no respectivo campo instanceStatus. Para ver uma lista de valores válidos do campo instanceStatus, consulte Como verificar o status de uma instância.

Se a instância estiver passando por algum tipo de alteração, o campo currentAction será preenchido com uma das ações a seguir para ajudar você a acompanhar o andamento da alteração. Caso contrário, o campo currentAction será NONE.

Os valores possíveis de currentAction são:

  • ABANDONING: a instância está sendo removida do grupo de instâncias gerenciadas;
  • CREATING: a instância está em processo de criação;
  • CREATING_WITHOUT_RETRIES: a instância está sendo criada sem novas tentativas. Se ela não for criada na primeira tentativa, o grupo de instâncias gerenciadas não tentará substituí-la novamente;
  • DELETING: a instância está em processo de exclusão;
  • RECREATING: a instância foi excluída e está sendo substituída;
  • REFRESHING: a instância está sendo removida e adicionada novamente à lista de pools de destino atuais. Essa lista pode corresponder ou não aos pools de destino atuais;
  • RESTARTING: a instância está em processo de reinicialização com o uso dos métodos stop e start;
  • VERIFYING: a instância foi criada e está em processo de verificação;
  • NONE: nenhuma ação está sendo executada na instância.

Quando a atualização de uma instância é concluída, o respectivo campo instanceStatus reflete o estado atual dela.

Status do grupo

No nível do grupo, o Compute Engine preenche um campo somente leitura denominado status que contém uma sinalização isStable. Para acessar essa sinalização, use a ferramenta gcloud ou a API.

Se todas as instâncias do grupo estiverem funcionando com integridade (ou seja, o currentAction de cada instância gerenciada for NONE), então status.isStable==true. A estabilidade de um grupo de instâncias gerenciadas depende das configurações de grupo além da política de recuperação automática. Por exemplo, se o grupo for escalonado automaticamente e estiver no processo de escalonamento vertical, então isStable==false em virtude da operação do autoescalador.

É possível verificar se um grupo de instâncias gerenciadas está funcionando com integridade conferindo o valor do campo status.isStable do recurso instanceGroupManagers ou regionInstanceGroupManagers associado.

status.isStable, definido como false, indica que as alterações estão ativas, pendentes ou que o próprio grupo de instâncias gerenciadas está sendo modificado.

status.isStable definido como true indica as seguintes condições:

  • Nenhuma das instâncias no grupo de instâncias gerenciadas está passando por qualquer tipo de alteração, e a currentAction de todas as instâncias é NONE.
  • Nenhuma alteração está pendente para as instâncias no grupo de instâncias gerenciadas.
  • O grupo de instâncias gerenciadas não está sendo modificado.

Os grupos de instâncias gerenciadas podem ser modificados de várias maneiras. Exemplo:

  • Você faz uma solicitação para lançar um novo modelo de instância.
  • Você faz uma solicitação para criar, excluir, redimensionar ou atualizar instâncias no grupo.
  • Um autoescalador solicita o redimensionamento do grupo.
  • Um recurso de recuperação automática está substituindo uma ou mais instâncias não íntegras do grupo de instâncias gerenciadas.
  • Em um grupo de instâncias gerenciadas regional, algumas das instâncias estão sendo redistribuídas.

Assim que todas as ações forem concluídas, status.isStable será definido como true novamente para esse grupo de instâncias gerenciadas.

Também é possível usar o comando gcloud beta compute instance-groups managed wait-until com a sinalização --stable para aguardar até que status.isStable seja definido como true para o grupo:

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

Como ver o histórico de operações de recuperação automática

Use a ferramenta gcloud ou a API para ver eventos de recuperação automática antigos.

gcloud

Use o comando gcloud compute operations list com um filtro para ver apenas os eventos de reparo da recuperação automática no projeto.

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

Para mais informações sobre uma operação de reparo específica, use o comando describe. Exemplo:

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

API

Para grupos de instâncias gerenciadas regionais, envie uma solicitação GET ao recurso regionOperations e inclua um filtro para que a lista de saída mostre eventos compute.instances.repair.*.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Para grupos de instâncias gerenciadas zonais, use o recurso zoneOoperations.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Para mais informações sobre uma operação de reparo específica, envie uma solicitação GET referente a ela. Exemplo:

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

O que constitui uma boa verificação de integridade de recuperação automática

As verificações de integridade usadas para recuperação automática precisam ser conservadoras, de modo que não excluam e recriem preventivamente suas instâncias. Quando uma verificação de integridade é muito agressiva, a recuperação automática pode confundir instâncias ocupadas com instâncias com falhas e reiniciá-las desnecessariamente, reduzindo a disponibilidade.

  • unhealthy-threshold. Precisa ser maior que 1. O ideal é definir esse valor como 3 ou mais. Isso protege contra falhas raras, como a perda de pacotes de rede.
  • healthy-threshold. O valor 2 é suficiente para a maioria dos apps.
  • timeout. Defina este valor temporal com um valor generoso (cinco vezes ou mais além do tempo de resposta esperado). Isso protege contra atrasos inesperados, como instâncias ocupadas ou uma conexão de rede lenta.
  • check-interval. Esse valor precisa estar entre 1 segundo e duas vezes o tempo limite (nem muito longo nem muito curto). Quando o valor é muito longo, uma instância com falha não é detectada a tempo. Quando o valor é curto demais, as instâncias e a rede poderão ficar ocupadas devido ao alto número de sondagens da verificação de integridade que são enviadas por segundo.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine