Esta página foi traduzida pela API Cloud Translation.

Configurar uma verificação de integridade e recuperação automática com base em aplicativos

Neste documento, descrevemos como configurar uma verificação de integridade baseada em aplicativo para recuperar VMs automaticamente em um grupo gerenciado de instâncias (MIG). Também descrevemos como fazer o seguinte: usar uma verificação de integridade sem recuperação automática, remover uma verificação de integridade, visualizar a política de recuperação automática e verificar o estado de integridade de cada VM.

É possível configurar uma verificação de integridade baseada em aplicativo para conferir se o aplicativo em uma VM está respondendo conforme o esperado. Se a verificação de integridade configurada detectar que o aplicativo em uma VM não está respondendo, o MIG marcará essa VM como não íntegra e a corrigirá. O reparo de uma VM com base na verificação de integridade do aplicativo é chamado de recuperação automática.

Também é possível desativar os reparos em um MIG para que seja possível usar uma verificação de integridade sem acionar a recuperação automática.

Para saber mais sobre reparos em um MIG, consulte Como reparar VMs para alta disponibilidade.

Antes de começar

Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud. Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.

Preços

Quando você configura uma verificação de integridade baseada em aplicativo, sempre que o estado de integridade de uma VM é alterado, por padrão, o Compute Engine grava uma entrada de registro no Cloud Logging. O Cloud Logging oferece uma cota gratuita por mês. Depois disso, a geração de registros é cobrada pelo volume de dados. Para evitar custos, é possível desativar os registros de alteração do estado de integridade.

Configurar uma verificação de integridade e recuperação automática com base em aplicativos

Para configurar uma verificação de integridade e recuperação automática baseadas em aplicativo em um MIG, faça o seguinte:

Crie uma verificação de integridade, caso ainda não tenha feito isso.
Configure uma política de recuperação automática no MIG para aplicar a verificação de integridade.

Criar uma verificação de integridade

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.

No exemplo a seguir, mostramos como criar uma verificação de integridade para recuperação automática. É possível usar uma verificação de integridade regional ou global para recuperação automática em MIGs. Neste exemplo, você cria uma verificação de integridade globsl que procura uma resposta do servidor da Web na porta 80. Para permitir que as sondagens de verificação de integridade alcancem o servidor da Web, configure uma regra de firewall.

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 firewall.
compute.networks.updatePolicy na rede ao criar um novo firewall

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;

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 será marcada como íntegra se a verificação de integridade retornar com êxito uma vez. A VM será marcada como não íntegra se a verificação de integridade retornar com falha 3 vezes consecutivas.
1. No Console do Google Cloud, acesse a página Criar uma verificação de integridade.
  
  Acesse "Criar verificação de integridade"
2. Dê um nome à verificação de integridade, como example-check.
3. Selecione um Escopo. Você pode selecionar Regional ou Global. Neste exemplo, selecione Global.
4. Em Protocolo, certifique-se de que HTTP esteja selecionado.
5. Em Porta, insira 80.
6. Na seção Critérios de integridade, forneça os seguintes valores:
  1. Em Intervalo de verificação, insira 5.
  2. Em Tempo limite, insira 5.
  3. 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.
  4. 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.
7. 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 políticas de Firewall.
  
  Acesse as políticas de firewall
2. Clique em Criar regra de firewall.
3. Digite um Nome para a regra do firewall. Por exemplo, allow-health-check.
4. Em Rede, selecione a rede default.
5. Em Destinos, selecione All instances in the network.
6. Em Filtro de origem, selecione IPv4 ranges.
7. Em Intervalos IPv4 de origem, insira 130.211.0.0/22 e 35.191.0.0/16.
8. Em Protocolos e portas, selecione Protocolos e portas especificados e faça o seguinte:
  1. Selecione TCP.
  2. No campo Portas, insira 80.
9. Clique em Criar.

gcloud

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, a VM é marcada como íntegra se retornar com êxito uma vez. A VM será marcada como não íntegra se retornar com falha 3 vezes consecutivas. O comando a seguir cria uma verificação de integridade global.
```
gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global
```
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.

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

Terraform

Crie uma verificação de integridade usando o recurso google_compute_http_health_check.

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. A VM será marcada como não íntegra se retornar com falha 3 vezes consecutivas. A solicitação a seguir cria uma verificação de integridade global.
```
resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}
```
Crie um firewall usando o recurso google_compute_firewall.

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 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.
```
resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}
```

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

REST

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. A VM será marcada como não íntegra se retornar com falha 3 vezes consecutivas. A solicitação a seguir cria uma verificação de integridade global.
```
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.

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 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.
```
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"
  }
 ]
}
```
Substitua PROJECT_ID pelo ID do projeto.

Configurar uma política de recuperação automática em um MIG

Em um MIG, é possível configurar apenas uma política de recuperação automática para aplicar uma verificação de integridade.

É possível usar uma verificação de integridade regional ou global para recuperação automática em MIGs. As verificações de integridade regionais reduzem as dependências entre regiões e ajudam a conseguir a residência dos dados. As verificações de integridade globais são convenientes quando você quer usar a mesma verificação de integridade para MIGs em várias regiões.

Antes de configurar uma política de recuperação automática:

Se você ainda não tem uma verificação de integridade, crie uma.
Se você quiser evitar o acionamento falso da recuperação automática ao configurar uma nova verificação de integridade, primeiro desative os reparos no MIG e configure a política de recuperação automática.

Permissões exigidas para a tarefa

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

compute.instanceGroupManagers.update no MIG

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

compute.instanceAdmin.v1 para criar e atualizar políticas de recuperação automática em MIGs.

Console

No Console do Google Cloud, acesse a página Grupos de instâncias.

Acesse grupo de instâncias
Na coluna Nome da lista, clique no nome do MIG em que você quer aplicar a verificação de integridade.
Clique em Editar para modificar esse MIG.
Na seção Ciclo de vida da instância de VM, em Recuperação automática, selecione uma Verificação de integridade global ou regional.
Altere ou mantenha a configuração de Atraso inicial.

O atraso inicial é o número de segundos que uma nova VM leva para inicializar e executar o script de inicialização. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de integridade malsucedidas, porque a VM pode estar no processo de inicialização. Isso impede que o MIG recrie prematuramente uma VM. Se a verificação de integridade receber uma resposta íntegra durante o atraso inicial, ela indica que o processo de inicialização foi concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM é alterado para VERIFYING. O valor do atraso inicial precisa estar entre 0 e 3.600 segundos. No console, o valor padrão é 300.
Clique em Salvar para aplicar as alterações.

gcloud

Para configurar a política de recuperação automática em um MIG, use o comando update.

Por exemplo, use o comando a seguir para configurar a política de recuperação automática em um MIG zonal atual:

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Para configurar a política de recuperação automática ao criar um MIG, use o comando create.

Por exemplo, use o comando a seguir para configurar a política de recuperação automática ao criar um MIG zonal:

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Substitua:

MIG_NAME: o nome do MIG em que você quer configurar a recuperação automática.
SIZE: o número de VMs no grupo.
INSTANCE_TEMPLATE_URL: o URL parcial do modelo de instância que você quer usar para criar as VMs no grupo. Por exemplo:
- Modelo de instância regional: projects/example-project/regions/us-central1/instanceTemplates/example-template
- Modelo global de instância: projects/example-project/global/instanceTemplates/example-template
HEALTH_CHECK_URL: o URL parcial da verificação de integridade que você quer configurar para recuperação automática. Se você quiser usar uma verificação de integridade regional, forneça o URL parcial dela. Por exemplo:
- Verificação de integridade regional: projects/example-project/regions/us-central1/healthChecks/example-health-check
- Verificação de integridade global: projects/example-project/global/healthChecks/example-health-check.
INITIAL_DELAY: o número de segundos que uma nova VM leva para inicializar e executar o script de inicialização dela. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de integridade malsucedidas, porque a VM pode estar no processo de inicialização. Isso impede que o MIG recrie prematuramente uma VM. Se a verificação de integridade receber uma resposta íntegra durante o atraso inicial, ela indica que o processo de inicialização foi concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM é alterado para VERIFYING. O valor do atraso inicial precisa estar entre 0 e 3600 segundos. O valor padrão é 0.
ZONE: a zona em que o MIG está localizado. Para um MIG regional, use a sinalização --region.

Terraform

Para configurar uma política de recuperação automática em um MIG, use o bloco auto_healing_policies.

O exemplo a seguir configura a política de recuperação automática em um MIG zonal. Para mais informações sobre o recurso usado na amostra, consulte google_compute_instance_group_manager. Para um MIG regional, use o método google_compute_region_instance_group_manager.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

REST

Para configurar a política de recuperação automática em um MIG, use o método patch da seguinte maneira:

Para um MIG zonal, use o método instanceGroupManager.patch.
Para um MIG regional, use o método regionInstanceGroupManager.patch.

Por exemplo, faça a seguinte chamada para configurar a recuperação automática em um MIG zonal atual:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
  {
    "healthCheck": "HEALTH_CHECK_URL",
    "initialDelaySec": INITIAL_DELAY
  }
  ]
}

Para configurar a política de recuperação automática ao criar um MIG, use o método insert da seguinte maneira:

Para um MIG zonal, use o método instanceGroupManager.insert.
Para um MIG regional, use o método regionInstanceGroupManager.insert.

Por exemplo, faça a seguinte chamada para configurar a política de recuperação automática ao criar um MIG zonal:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers

{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL"
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
}

Substitua:

PROJECT_ID: o ID do projeto;
MIG_NAME: o nome do MIG em que você quer configurar a recuperação automática.
SIZE: o número de VMs no grupo.
INSTANCE_TEMPLATE_URL: o URL parcial do modelo de instância que você quer usar para criar as VMs no grupo. Por exemplo:
- Modelo de instância regional: projects/example-project/regions/us-central1/instanceTemplates/example-template
- Modelo global de instância: projects/example-project/global/instanceTemplates/example-template
HEALTH_CHECK_URL: o URL parcial da verificação de integridade que você quer configurar para recuperação automática. Por exemplo:
- Verificação de integridade regional: projects/example-project/regions/us-central1/healthChecks/example-health-check
- Verificação de integridade global: projects/example-project/global/healthChecks/example-health-check.
INITIAL_DELAY: o número de segundos que uma nova VM leva para inicializar e executar o script de inicialização dela. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de integridade malsucedidas, porque a VM pode estar no processo de inicialização. Isso impede que o MIG recrie prematuramente uma VM. Se a verificação de integridade receber uma resposta íntegra durante o atraso inicial, ela indica que o processo de inicialização foi concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM é alterado para VERIFYING. O valor do atraso inicial precisa estar entre 0 e 3600 segundos. O valor padrão é 0.
ZONE: a zona em que o MIG está localizado. Para um MIG regional, use regions/REGION no URL.

Depois que a configuração da recuperação automática for concluída, poderá levar 10 minutos para que ela comece a monitorar as VMs no grupo. Depois que o monitoramento começa, o Compute Engine começa a marcar as VMs 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 10 minutos antes que a recuperação automática comece a monitorar VMs no grupo
+ 5 minutos para o atraso inicial configurado
+ 1 minuto para o intervalo de verificação * limite íntegro (60s * 1)
= 16 minutos antes de a VM ser marcada como íntegra ou recriada

Se você desativou os reparos no MIG antes de configurar a política de recuperação automática, será possívelmonitorar os estados de integridade da VM para confirmar que a verificação de integridade está funcionando conforme o esperado.configurar o MIG de volta para reparar VMs de dois minutos.

Usar uma verificação de integridade sem recuperação automática

É possível usar a verificação de integridade configurada em um MIG sem recuperação automática desativando os reparos no MIG. Isso é útil quando você quer usar a verificação de integridade apenas para monitorar a integridade do aplicativo ou quando quer implementar sua própria lógica de reparo com base na verificação de integridade.

Para que o MIG volte a reparar VMs não íntegras, consulte Definir um MIG para reparar VMs com falha ou não íntegras.

Remover uma verificação de integridade

É possível remover uma verificação de integridade configurada em uma política de recuperação automática a seguir:

Console

No Console do Google Cloud, acesse a página Grupos de instâncias.

Acesse grupo de instâncias
1. Clique no nome do MIG de que você quer remover a verificação de integridade.
2. Clique em Editar para modificar esse MIG.
3. Na seção Ciclo de vida da instância de VM, em Recuperação automática, selecione Nenhuma verificação de integridade.
4. Clique em Salvar para aplicar as mudanças.

gcloud

Para remover a configuração da verificação de integridade em uma política de recuperação automática, no comando update, use a sinalização --clear-autohealing da seguinte maneira:

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

Substitua MIG_NAME pelo nome de um MIG.

REST

Para remover a configuração da verificação de integridade em uma política de recuperação automática, defina-a com um valor vazio.

Para um MIG zonal, use o método instanceGroupManagers.patch.
Para um MIG regional, use o método regionInstanceGroupManagers.patch.

Por exemplo, para remover a verificação de integridade em um MIG zonal, faça a seguinte solicitação:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

Substitua:

PROJECT_ID: o ID do projeto;
MIG_NAME: o nome do MIG em que você quer configurar a recuperação automática.
ZONE: a zona em que o MIG está localizado. Para um MIG regional, use regions/REGION.

Ver a política de recuperação automática em um MIG

É possível visualizar a política de recuperação automática de um MIG da seguinte maneira:

Console

No Console do Google Cloud, acesse a página Grupos de instâncias.

Acesse grupo de instâncias
Clique no nome do MIG de que você quer ver a política de recuperação automática.
Acesse a guia Detalhes.
Na seção Ciclo de vida da instância de VM, o campo Recuperação automática exibe a verificação de integridade e o atraso inicial configurado na política de recuperação automática.

gcloud

Para ver a política de recuperação automática em um MIG, use o seguinte comando:

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

Substitua MIG_NAME pelo nome de um MIG.

Veja um exemplo de saída:

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

Para visualizar a política de recuperação automática em um MIG, use os métodos REST da seguinte maneira:

Para um MIG zonal, use o método instanceGroupManagers.get.
Para um MIG regional, use o método regionInstanceGroupManagers.get.

Por exemplo, faça a solicitação a seguir para visualizar a política de recuperação automática em um MIG zonal:

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

No corpo da resposta, verifique se há o objeto autoHealingPolicies[].

Veja a seguir um exemplo de resposta:

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

Substitua:

PROJECT_ID: o ID do projeto;
MIG_NAME: o nome do MIG em que você quer configurar a recuperação automática.
ZONE: a zona em que o MIG está localizado. Para um MIG regional, use regions/REGION.

Verificar o status

Depois de configurar uma verificação de integridade baseada em aplicativo em um MIG, é possível verificar se uma VM está em execução e se o aplicativo está respondendo das seguintes maneiras:

Verificar se as VMs estão íntegras
Verificar as ações atuais nas VMs
Verificar se o MIG está estável

Verificar se as VMs estão íntegras

Se você configurou uma verificação de integridade baseada em aplicativo para o 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.
- Uma parcela significativa das instâncias não íntegras está sendo reparada. O MIG 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 ou observando o tempo entre a operação instances.insert e a primeira sinal íntegro recebido.

Use o console, a ferramenta de linha de comando gcloud ou a REST 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.

Acesse 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.

REST

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 10 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, o MIG não a repara 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. Deixe seu feedback com nossa equipe em mig-discuss@google.com.

Verificar as ações atuais nas VMs

Quando um MIG está em processo de criação de uma instância de VM, o MIG define o campo currentAction somente leitura dessa instância como CREATING. Se uma política de recuperação automática estiver anexada ao grupo, após a criação e a execução da VM, o MIG definirá a ação atual da instância como VERIFYING e o verificador de integridade iniciará a sondagem do aplicativo da VM. Se o aplicativo for aprovado nessa verificação de integridade inicial durante o tempo que leva para iniciar, a VM será verificada e o MIG alterará o campo currentAction da VM para NONE.

Para verificar as ações atuais nas VMs, consulte Ver ações atuais nas VMs.

Verificar se o MIG está 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, se o campo currentAction de cada instância gerenciada for definido como NONE), o MIG definirá o campo status.isStable como true. A estabilidade de um MIG depende de configurações de grupo além da política de recuperação automática. Por exemplo, se o grupo for escalonado automaticamente e estiver aumentando ou diminuindo o escalonamento, o MIG definirá o campo status.isStable como false por causa da operação do escalonador automático.

Para verificar os valores do campo status.isStable do MIG, consulte Verificar se um MIG é estável.

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

Use a gcloud CLI ou a REST 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 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

REST

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 zoneOperations.

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.

Configurar uma verificação de integridade e recuperação automática com base em aplicativos

Antes de começar

Console

gcloud

Terraform

REST

Preços

Configurar uma verificação de integridade e recuperação automática com base em aplicativos

Criar uma verificação de integridade

Permissões exigidas para a tarefa

Console

gcloud

Terraform

REST

Configurar uma política de recuperação automática em um MIG

Permissões exigidas para a tarefa

Console

gcloud

Terraform

REST

Usar uma verificação de integridade sem recuperação automática

Remover uma verificação de integridade

Console

gcloud

REST

Ver a política de recuperação automática em um MIG

Console

gcloud

REST

Verificar o status

Verificar se as VMs estão íntegras

Permissões exigidas para a tarefa

Console

gcloud

REST

Estados de integridade

Verificar as ações atuais nas VMs

Verificar se o MIG está estável

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

gcloud

REST

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

A seguir