Como configurar a verificação de integridade e a recuperação automática

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 gerenciada parar de ser executada, mas a alteração de estado não tiver sido iniciada pelo MIG, ele recria automaticamente essa instância. Por outro lado, se o MIG interromper intencionalmente uma instância de RUNNING, por exemplo, quando um escalonador automático excluir uma instância, o MIG não recriará essa instância.

As alterações do estado da instância que não são iniciadas pelo MIG incluem:

Falhas de hardware.
Encerrar uma instância preemptiva.
A exclusão de uma instância MIG usando o método instances.delete em vez do método instanceGroupManagers.deleteInstances na API Compute Engine ou na ferramenta de linha de comando gcloud.
Eventos de manutenção de infraestrutura quando a instância de VM não está definida como migração em tempo real.

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 verificar se uma instância é RUNNING não detecta falhas no aplicativo, como congelamento, sobrecarga ou falha.

Para melhorar ainda mais a disponibilidade do seu aplicativo e verificar se ele está respondendo, configure uma política de recuperação automática para o 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 uma VM está no estado RUNNING.

Se a recuperação automática determinar que um aplicativo não está respondendo, o MIG recriará automaticamente essa VM. Para uma VM 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 VMs não íntegras usando o modelo de instância original usado para criar a VM (não necessariamente o modelo de instância atual no MIG). Por exemplo, se uma VM foi criada usando instance-template-a e você atualizou o MIG para usar instance-template-b no modo OPPORTUNISTIC, a recuperação automática ainda usa instance-template-a para recriar a VM. Isso ocorre porque as recriações de recuperação automática não são iniciadas pelo usuário. Portanto, o Compute Engine não pressupõe que a VM use o novo modelo. Se você quiser aplicar um novo modelo, consulte Como alterar o modelo de instância para um MIG.

A qualquer momento, o número de VMs recuperadas automaticamente de modo simultâneo é menor que o tamanho do MIG. Isso garante que o grupo continue executando um subconjunto de VMs 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 conectividade de rede ou infraestrutura que identifiquem incorretamente uma VM íntegra. No entanto, se uma MIG zonal tiver apenas uma VM ou uma MIG regional tiver apenas uma VM por zona, a recuperação automática recria essas VMs quando elas não forem íntegras.

A recuperação automática não recria uma VM durante o período de inicialização dela. Para mais informações, consulte a propriedade autoHealingPolicies[].initialDelaySec. Essa configuração atrasa a verificação automática e a recriação possivelmente prematura da VM se ela estiver em processo de inicialização. O timer de atraso inicial é iniciado quando a VM tem um currentAction de VERIFYING.

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

Recuperação automática e discos

Ao recriar uma VM com base no modelo, a recuperação automática lida com diferentes tipos de discos. Algumas configurações de disco podem fazer com que a recuperação automática falhe ao tentar recriar uma VM.

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 gravados nesse disco são perdidos quando o disco e a VM dele são recriados.
Novo disco permanente	`false`	O disco é preservado e reanexado quando a recuperação automática recria a VM.
Disco permanente atual	`true`	O disco antigo é excluído. A recriação de VM falha porque o Compute Engine não pode anexar novamente um disco excluído à VM.
Disco permanente atual	`false`	O disco antigo é reanexado conforme especificado no modelo da instância. Os dados no disco são preservados. No entanto, para discos de leitura/gravação existentes, um MIG pode ter apenas uma VM porque um único disco permanente não pode ser anexado a várias VMs 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 VM é 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:

Tire instantâneos do disco permanente regularmente.
Exporte dados para outra fonte, como o Cloud Storage.
Configure discos permanentes com estado.

Se as VMs têm configurações importantes que você quer preservar, o Google também recomenda que você use uma imagem personalizada no modelo de instância. Uma imagem personalizada contém as configurações personalizadas necessárias. Quando você especifica uma imagem personalizada no modelo de instância, o MIG recria as VMs 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

Você pode definir no máximo uma política de recuperação automática por MIG.

Você pode aplicar uma única verificação de integridade a até 50 MIGs. 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 MIG. 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, você aplica a verificação de integridade ao MIG definindo a política de recuperação automática do grupo.

Permissões exigidas para a tarefa

Para executar esta tarefa, é necessário ter as seguintes permissões:

compute.healthChecks.create no projeto ao criar uma nova verificação de integridade
compute.healthChecks.use na verificação de integridade a ser usada
compute.firewalls.create no projeto ao criar um novo firewall
compute.networks.updatePolicy na rede ao criar um novo firewall
compute.instanceGroupManagers.update no MIG

As permissões estão disponíveis nos papéis predefinidos:

compute.networkAdmin para criar verificações de integridade;
compute.securityAdmin para configurar regras de firewall a fim de permitir a conexão da verificação de integridade;
compute.instanceAdmin.v1 para criar e atualizar políticas de recuperação automática em MIGs.

Console

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 VMs como UNHEALTHY e fazer com que sejam recriadas. Neste exemplo, uma VM é marcada como íntegra se retornar com êxito uma vez. Ela será marcada como não íntegra se for retornada com falha 3 vezes consecutivas.
1. No Console do Google Cloud, acesse a página Criar uma verificação de integridade.
  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 precisam ser retornadas antes que uma VM 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 consecutivas precisam ser retornadas antes que uma VM íntegra seja marcada como não íntegra. Insira 3 para este exemplo.
9. Clique em Criar para criar a verificação de integridade.
Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao app.

Cuidado: se as sondagens da verificação de integridade forem bloqueadas pelas regras de firewall, elas marcarão suas instâncias como UNHEALTHY porque não conseguem se conectar ao app. Isso poderá solicitar a recriação automática das instâncias que estejam íntegras.

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, nossa MIG usa a rede default e as VMs dela estão ouvindo na porta 80. Se a porta 80 ainda não estiver aberta na rede padrão, crie uma regra de firewall.
1. No Console do Google Cloud, acesse a página Criar regra de firewall.
  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
Aplique a verificação de integridade configurando uma política de recuperação automática para o MIG regional ou por zona.
1. No Console do Google Cloud, acesse a página Grupos de instâncias.
  Acessar a página "Grupos de instâncias"
2. Na coluna Nome da lista, clique no nome do MIG em que você quer aplicar a verificação de integridade.
3. Clique em Editar grupo para modificar esse MIG.
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 atrasa a recuperação automática da recriação prematura da VM, caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando o currentAction da VM é VERIFYING.
6. Clique em Salvar para aplicar as alterações.

gcloud

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

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 VMs como UNHEALTHY e fazer com que sejam recriadas. Neste exemplo, uma VM é marcada como íntegra se retornar 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
```
Observação: use verificações de integridade mais recentes compatíveis com os protocolos HTTP, HTTPS, TCP e SSL (TLS). As verificações de integridade HTTP/HTTPS legadas do Compute Engine continuam funcionando.
Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao 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. Neste exemplo, nosso MIG usa a rede default e as VMs detectam 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
```
Aplique a verificação de integridade configurando uma política de recuperação automática para o MIG regional ou por zona.

Use o comando update para aplicar a verificação de integridade ao MIG.

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

Exemplo:
```
gcloud compute instance-groups managed update my-mig \
        --health-check example-check \
        --initial-delay 300 \
        --zone us-east1-b
```
Observação: o comando set-autohealing é obsoleto e será removido. Em vez dele, use o comando update.

API

Para usar os exemplos da API deste guia, configure o acesso a ela.

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 que possa tolerar alguma falha antes de marcar as VMs como UNHEALTHY e fazer com que sejam recriadas. Neste exemplo, uma VM é marcada como íntegra se retornar 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
}
```
Observação: use verificações de integridade mais recentes compatíveis com os protocolos HTTP, HTTPS, TCP e SSL (TLS). As verificações de integridade HTTP/HTTPS legadas do Compute Engine continuam funcionando.
Crie uma regra de firewall para permitir que as sondagens da verificação de integridade se conectem ao 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 MIG usa a rede default e as VMs dela estão ouvindo 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://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"
  }
 ]
}
```
Aplique a verificação de integridade configurando uma política de recuperação automática para o MIG regional ou por 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.

Aviso: os métodos instanceGroupManagers.setAutohealingPolicies e regionInstanceGroupManager.setAutohealingPolicies não fazem parte da API geralmente disponível e terão o uso suspenso. Em vez deles, use os métodos insert e 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 atrasa a recuperação automática da recriação prematura da VM, caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando o currentAction da VM é VERIFYING.

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 MIG recria apenas VMs que não estão no estado RUNNING.

Para receber a política de recuperação automática de um MIG, leia o campo instanceGroupManagers.autoHealingPolicies. Você pode obter um recurso MIG usando um dos seguintes métodos:
- instanceGroupManagers.get retorna o recurso de grupo de instâncias gerenciadas por zona especificado.
- instanceGroupManagers.list retorna todos os MIGs zonais em um projeto e zona especificados.
- regionInstanceGroupManagers.get retorna o recurso MIG regional especificado.
- regionInstanceGroupManagers.list retorna todos os MIGs regionais gerenciados em um projeto e uma região especificados.

Após a conclusão da atualização da configuração do grupo ou da verificação de integridade, pode levar 30 minutos para que a recuperação automática comece a monitorar as instâncias no grupo. Depois que o monitoramento é iniciado, o Compute Engine começa a marcar instâncias como íntegras (ou recriá-las) com base na configuração de recuperação automática. Por exemplo, se você configurar um atraso inicial de 5 minutos, um intervalo de verificação de integridade de 1 minuto e um limite de integridade de 1 verificação, a linha do tempo será semelhante a esta:

Atraso de 30 minutos antes que a recuperação automática comece a monitorar instâncias no grupo
+ 5 minutos para o atraso inicial configurado
+ 1 minuto para o intervalo de verificação * limite íntegro (60s * 1)
= 36 minutos antes de a instância ser marcada como íntegra ou recriada

Verificar o status

Você pode verificar se uma VM foi criada e se o aplicativo está respondendo inspecionando o estado de integridade atual de cada VM, verificando a ação atual em cada VM ou verificando o status do grupo.

Como verificar se as VMs estão íntegras

Se você configurou a recuperação automática para seu MIG, é possível avaliar o estado de integridade de cada instância gerenciada.

Inspecione os estados de integridade da instância gerenciada para:

identificar as VMs não íntegras que não estão sendo recuperadas automaticamente. Uma 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 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.

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

Permissões exigidas para a tarefa

Para executar esta tarefa, é necessário ter as seguintes permissões:

compute.instanceGroupManagers.get no MIG

Console

No Console do Google Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Na coluna Nome da lista, clique no nome do MIG que você quer examinar. Uma página é aberta com as propriedades do grupo de instâncias e uma lista de VMs incluídas no grupo.
Se uma VM não estiver íntegra, você poderá ver o estado de integridade dela na coluna Status da verificação de integridade.

gcloud

Use o subcomando list-instances.

gcloud 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 VM.

API

Para um MIG regional, crie uma solicitação POST para o método listManagedInstances:

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

Para um MIG zonal, use o método listManagedInstances MIG zonal:

POST https://compute.googleapis.com/compute/v1/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://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

Estados de integridade

Os seguintes estados de integridade da VM estão disponíveis:

HEALTHY: a VM pode ser acessada, uma conexão com o ponto de extremidade de verificação de integridade do aplicativo pode ser estabelecida e a resposta está em conformidade com os requisitos definidos pela verificação de integridade.
DRAINING: a VM está sendo drenada. As conexões existentes com a VM têm tempo para serem concluídas, mas novas conexões estão sendo recusadas.
UNHEALTHY: a VM pode ser acessada, mas não está em conformidade com os requisitos definidos pela verificação de integridade.
TIMEOUT: a VM está inacessível: uma conexão com o ponto de extremidade de verificação de integridade do aplicativo não pode ser estabelecida ou o servidor em uma VM não responde dentro do tempo limite especificado. Por exemplo, isso pode ser causado por regras de firewall configuradas incorretamente ou por um aplicativo de servidor sobrecarregado em uma VM.
UNKNOWN: o sistema de verificação de integridade não está ciente da VM ou a integridade dela não é conhecida no momento. Pode levar 30 minutos para que o monitoramento comece em novas VMs em um MIG.

Novas VMs retornam um estado UNHEALTHY até que sejam verificadas pelo sistema de verificação de integridade.

Se uma VM é reparada, ela depende do estado de integridade dela:

Se uma VM tiver um estado de integridade de UNHEALTHY ou TIMEOUT e tiver passado o período de inicialização, o serviço de recuperação automática tentará repará-la imediatamente.
Se uma VM tiver um estado de integridade de UNKNOWN, ela não será reparada imediatamente. Isso evita um reparo desnecessário de uma VM 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 VM permanece não íntegra após vários reparos consecutivos.
Há uma parcela geral significativa de VMs não íntegras no grupo.

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

Como visualizar ações atuais em VMs

Quando uma VM está em processo de criação, a currentAction dessa instância é CREATING. Se uma política de recuperação automática for anexada ao grupo, depois que a VM for criada e executada, a instância prosseguirá para um currentAction de VERIFYING e o verificador de integridade começará a sondar o aplicativo da VM. Se o aplicativo for aprovado nessa verificação de integridade inicial dentro do tempo necessário para que ele seja iniciado, a VM será verificada e o currentAction mudará para NONE.

É possível ver a currentAction sendo realizada e os status de cada instância em um grupo de instâncias gerenciadas usando a ferramenta de linha de comando gcloud ou a API Compute Engine.

Permissões exigidas para a tarefa

Para executar esta tarefa, é necessário ter as seguintes permissões:

compute.instanceGroupManagers.get no grupo
compute.instanceGroupManagers.list no grupo

gcloud

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

O comando retorna uma lista de instâncias no MIG e os status e ações atuais delas. Exemplo:

NAME               ZONE           STATUS   HEALTH_STATE  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

A coluna HEALTH_STATE aparece vazia, a menos que você tenha configurado a verificação de integridade.

API

Chame o método listManagedInstances em um recurso MIG regional ou zonal. Exemplo:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

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

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

Para ver uma lista de valores válidos do campo instanceStatus, consulte Como verificar o status de uma instância.

Se uma 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 MIG.
CREATING. A instância está em processo de criação.
CREATING_WITHOUT_RETRIES. A instância está sendo criada sem novas tentativas. Se a instância não for criada na primeira tentativa, o MIG não tentará substituí-la novamente.
DELETING: a instância está em processo de exclusão;
RECREATING: a instância 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.

Como verificar se o MIG se encontra estável

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 VMs no grupo estiverem em execução e íntegras (ou seja, o currentAction de cada instância gerenciada for NONE), status.isStable==true. Lembre-se de que a estabilidade de um MIG 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 se estiver escalonando no momento, isStable==false devido à operação do escalonador automático.

Verifique se todas as instâncias em um grupo de instâncias gerenciadas estão em execução e íntegras verificando o valor do campo status.isStable do grupo.

gcloud

Use o comando describe (em inglês).

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

A ferramenta gcloud retorna informações detalhadas sobre o MIG, incluindo o campo status.isStable.

Para pausar um script até que o MIG esteja estável, use o comando wait-until com a sinalização --stable. Exemplo:

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

O comando retorna depois que status.isStable é definido como true para o MIG.

API

Para um MIG por zona, faça uma solicitação GET para o método instanceGroupManagers.get:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

Para um grupo de instâncias gerenciadas por região, substitua zones/zone por regions/region:

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

A API do Compute Engine retorna informações detalhadas sobre o MIG, incluindo o campo status.isStable.

status.isStable definido como false indica que as alterações estão ativas, pendentes ou que o próprio MIG está sendo modificado.

status.isStable definido como true indica o seguinte:

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

A estabilidade de um MIG depende de vários fatores porque ele pode ser modificado 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 MIG.
Um escalonador automático solicita o redimensionamento do MIG.
Um recurso de recuperação automática está substituindo uma ou mais instâncias não íntegras do MIG.
Em um MIG 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 MIG.

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

Para MIGs regionais, envie uma solicitação GET ao recurso regionOperations e inclua um filtro para selecionar a 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

Para MIGs zonais, 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 para essa operação específica. Por exemplo:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/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 poderão ficar ocupadas devido ao alto número de sondagens da verificação de integridade que são enviadas por segundo.

A seguir

Teste o tutorial em Como usar a recuperação automática para apps altamente disponíveis.
Saiba mais sobre grupos de instâncias.
Ative o escalonamento automático para seu MIG.
Ative o balanceamento de carga para seu MIG.