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

Os grupos de instâncias gerenciadas (MIGs, na sigla em inglês) mantêm a alta disponibilidade dos seus aplicativos ao dispor de maneira proativa suas instâncias de máquina virtual (VM, na sigla em inglês), ou seja, no estado RUNNING. Se uma instância interrompe o funcionamento (RUNNING) e a alteração do estado não é iniciada pelo MIG (por exemplo, uma falha de hardware, não uma decisão do autoescalador), o MIG recria essa instância automaticamente. No entanto, depender do estado de uma instância para determinar a integridade do aplicativo pode não ser o suficiente. Por exemplo, uma verificação para saber se uma instância está RUNNING não detecta problemas no aplicativo, como congelamento, sobrecarga ou falha.

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

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

Se o recuperador automático determinar que um aplicativo não está respondendo, o grupo de instâncias gerenciadas recriará essa instância automaticamente. No caso de uma instância preemptiva, o grupo a recriará 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 foi criada usando instance-template-a e você atualizar o grupo de instâncias gerenciadas para usar instance-template-b no modo OPPORTUNISTIC, a recuperação automática ainda usará 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, portanto, 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 por zona tiver apenas uma instância, ou se um grupo de instâncias gerenciadas por região 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 no processo de inicialização. O timer de atraso inicial começa quando o currentAction da instância é 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 reconectado quando o recuperador automático recria a instância.
Disco permanente atual true O disco antigo é excluído. A recriação da instância de VM falha porque o Compute Engine não pode reconectar à instância um disco excluído.
Disco permanente atual false O disco antigo é reconectado 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 apenas poderá ter uma VM, visto que um único disco permanente não pode ser conectado 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.

O recuperador automático não reconecta discos não especificados no modelo de 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 origem, 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

No exemplo a seguir, veja 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, configure uma regra de firewall. Por fim, para aplicar a verificação de integridade ao grupo de instâncias gerenciadas, defina 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 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 for retornada com êxito uma vez. Ela será marcada como não íntegra se for retornada 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, certifique-se de que HTTP esteja 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. Insira 1 para este exemplo.
    8. Defina um Limite não íntegro para determinar quantas verificações de integridade malsucedidas e consecutivas precisam ser retornadas antes que uma instância íntegra seja marcada como não íntegra. Insira 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 provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Sendo assim, confirme se as regras de firewall da sua rede permitem a conexão da verificação de integridade. Para este 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 um nome para a 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 Protocolos e portas, selecione Portas e protocolos 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 por região ou zona.

    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 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 neste 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 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 for retornada com êxito uma vez. Ela será marcada como não íntegra se for retornada 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 provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Sendo assim, confirme se as regras de firewall permitem a conexão da verificação de integridade. Para este 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 por região ou zona.

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

    A configuração initial-delay evita que a recuperação automática recrie prematuramente a instância, caso ela esteja no processo de inicialização. O timer de atraso inicial começa quando currentAction da instância é VERIFYING.

    Por 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 da API deste guia, configure o acesso à API.

  1. Crie uma verificação de integridade para recuperação automática que seja mais conservadora que a 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 for retornada com êxito uma vez. Ela será marcada como não íntegra se for retornada com falha 3 vezes consecutivas.

    POST https://compute.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 provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Sendo assim, confirme se as regras de firewall permitem a conexão da verificação de integridade. Para este 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://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://compute.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 por região ou zona.

    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://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    A configuração initialDelaySec evita que a recuperação automática recrie prematuramente a instância, caso ela esteja no processo de inicialização. O timer de atraso inicial começa quando 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 com base no aplicativo, defina a política de recuperação automática como um valor vazio: autoHealingPolicies[]. Com autoHealingPolicies[], o grupo de instâncias gerenciadas recria somente instâncias que não estão no estado RUNNING.

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

Como verificar o status

É possível verificar se uma instância foi criada e se o aplicativo está respondendo inspecionando o estado de integridade atual de cada instância, verificando a ação atual em cada instância ou verificando 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.

Estado de integridade da instância

Se você configurou a recuperação automática no grupo de instâncias gerenciadas, é possível analisar o estado de integridade de cada instância.

Inspecione os estados de integridade das instâncias gerenciadas para:

  • identificar as VMs não íntegras que não estão sendo recuperadas automaticamente. Uma instância de VM pode não ser reparada imediatamente, mesmo que tenha sido diagnosticada como não íntegra nas seguintes situações:
    • A VM ainda está sendo inicializada e o atraso inicial ainda não foi concluído.
    • No momento, uma parte significativa das instâncias não íntegras está sendo recuperada automaticamente. O recuperador automático atrasa ainda mais a recuperação automática para garantir que o grupo continue executando um subconjunto de instâncias.
  • detectar erros de configuração da verificação de integridade. Por exemplo, é possível detectar regras de firewall mal configuradas ou um endpoint inválido da verificação de integridade do aplicativo, caso a instância informe o estado de integridade TIMEOUT;
  • determinar o valor do atraso inicial a ser configurado medindo o tempo entre a transição da VM para um status RUNNING e para o estado de integridade HEALTHY. Esse intervalo pode ser medido pesquisando o método list-instances.

Queremos saber mais sobre seus casos de uso, desafios ou feedback a respeito dos valores de estado de integridade da instância de VM. Compartilhe seu feedback com nossa equipe em mig-discuss@google.com.

Estados de integridade

Os seguintes estados de integridade da instância estão disponíveis:

  • HEALTHY: a instância é acessível, uma conexão com o endpoint da verificação de integridade do aplicativo pode ser estabelecida e a resposta obedece aos requisitos definidos pela verificação de integridade.
  • DRAINING: a instância está sendo esvaziada. As conexões atuais com a instância têm tempo para serem concluídas, mas novas conexões estão sendo recusadas.
  • UNHEALTHY: a instância é acessível, mas não está em conformidade com os requisitos definidos pela verificação de integridade.
  • TIMEOUT: a instância é inacessível: uma conexão com o endpoint da verificação de integridade do aplicativo não pode ser estabelecida ou o servidor em uma instância de VM não responde dentro do tempo limite especificado. Por exemplo, isso pode ser causado por regras de firewall mal configuradas ou por um aplicativo de servidor sobrecarregado em uma instância de VM.
  • UNKNOWN: o sistema de verificação de integridade não reconhece a instância nem sua integridade é conhecida no momento. O monitoramento das novas instâncias em um MIG pode levar 15 minutos para começar.

As novas instâncias retornarão um estado UNHEALTHY até serem verificadas pelo sistema de verificação de integridade.

A reparação de uma instância depende do estado de integridade dela:

  • Se uma instância tiver estado de integridade UNHEALTHY ou TIMEOUT e tiver passado do período de inicialização, o serviço de recuperação automática tentará repará-la imediatamente.
  • Se uma instância tiver estado de integridade UNKNOWN, ela não será reparada imediatamente. Isso evita um reparo desnecessário de uma instância para a qual o sinal de verificação de integridade está temporariamente indisponível.

As tentativas de recuperação automática poderão ser atrasadas se:

  • uma instância permanecer não íntegra após vários reparos consecutivos;
  • houver uma parcela significativa de instâncias não íntegras no grupo.

Use o console, a ferramenta de linha de comando gcloud ou a API para ver os estados de integridade.

Console

  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 que você quer examinar. Uma página é aberta com as propriedades do grupo de instâncias e a lista de instâncias que estão incluídas no grupo.

  3. Se uma instância não for íntegra, você verá o estado de integridade dela na coluna Problemas de integridade.

gcloud

Use o subcomando list-instances.

$ gcloud beta compute instance-groups managed list-instances [INSTANCE_GROUP]
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

A coluna HEALTH_STATE mostra o estado de integridade de cada instância.

API

Para um grupo de instâncias gerenciadas por região, crie uma solicitação POST para o método listManagedInstances:

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

Para um grupo de instâncias gerenciadas por zona, use o método listManagedInstances desse tipo de grupo:

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

A solicitação retorna uma resposta semelhante à seguinte, que inclui um campo instanceHealth para cada instância gerenciada.

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

Ações atuais nas instâncias

Quando uma instância gerenciada está no processo de criação, a currentAction dela é CREATING. Se uma política de recuperação automática estiver anexada ao grupo, após ser criada e entrar em execução, a instância gerenciada passará para currentAction VERIFYING e o verificador de integridade iniciará a sondagem do aplicativo da instância. Se o aplicativo for aprovado nessa verificação de integridade inicial durante o tempo que ele leva para ser iniciado, a instância será verificada e a respectiva currentAction mudará para NONE.

Para ver a currentAction que está sendo realizada e o status de cada instância em um grupo de instâncias gerenciadas, use a ferramenta de linha de comando gcloud ou a API (ambos em inglês).

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 e os respectivos status e ações atuais. Por 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  STOPPING  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 para o método regionInstanceGroupManagers.listManagedInstances (em inglês). Para um grupo de instâncias gerenciadas por zona, use o método instanceGroupManagers.listManagedInstances (em inglês).

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

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

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

Para cada instância em um grupo de instâncias gerenciadas, o status dela está descrito no campo instanceStatus. Para ver uma lista de valores de campo instanceStatus válidos, 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 seguintes ações 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 por meio 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.

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.

Se todas as instâncias no grupo estiverem em execução e íntegras (ou seja, a currentAction de cada instância gerenciada é NONE), então status.isStable==true. A estabilidade de um grupo de instâncias gerenciadas depende das configurações do 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.

Confirme se um grupo de instâncias gerenciadas está em execução e íntegro verificando o valor do campo status.isStable do recurso instanceGroupManagers ou regionInstanceGroupManagers (ambos em inglês) associado.

É possível também usar o comando wait-until da ferramenta de linha de comando gcloud com a sinalização --stable para aguardar que status.isStable seja definido como true no grupo:

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

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 o seguinte:

  • Nenhuma das instâncias no grupo de instâncias gerenciadas está passando por qualquer tipo de alteração e a currentAction para 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. Por 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 por região, 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.

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

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

gcloud

Use o comando gcloud compute operations list com um filtro para ver apenas os eventos de reparo de recuperação automática no seu 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. Por exemplo:

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

API

No caso de grupos de instâncias gerenciadas por região, envie uma solicitação GET ao recurso regionOperations e inclua um filtro a fim de definir o escopo da lista de saída para eventos compute.instances.repair.*.

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

No caso de grupos de instâncias gerenciadas por zona, use o recurso zoneOoperations.

GET https://compute.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. Por exemplo:

GET https://compute.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, o recuperador automático 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 esse valor de tempo com um número alto (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 ser entre um 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 podem 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