Configure uma verificação de funcionamento baseada na aplicação e a autorreparação

Este documento descreve como configurar uma verificação de estado baseada em aplicações para recuperar automaticamente VMs num grupo de instâncias gerido (MIG). Também descreve como fazer o seguinte: usar uma verificação de funcionamento sem autorreparação, remover uma verificação de funcionamento, ver a política de autorreparação e verificar o estado de funcionamento de cada VM.

Pode configurar uma verificação de funcionamento baseada na aplicação para verificar se a aplicação numa VM está a responder conforme esperado. Se a verificação de estado que configurar detetar que a sua aplicação numa VM não está a responder, o MIG marca essa VM como não saudável e repara-a por predefinição. A reparação de uma VM com base numa verificação de funcionamento baseada em aplicações chama-se autorreparação.

Também pode desativar a autocorreção num MIG para poder usar uma verificação de estado sem acionar as reparações de VMs não íntegras.

Para saber mais sobre as reparações num MIG, consulte o artigo Acerca da reparação de VMs para alta disponibilidade.

Antes de começar

  • Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-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. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    2. Set a default region and zone.

    Terraform

    Para usar os exemplos do Terraform nesta página num ambiente de desenvolvimento local, instale e inicialize a CLI gcloud e, em seguida, configure as credenciais predefinidas da aplicação com as suas credenciais de utilizador.

      Instale a CLI Google Cloud.

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

      If you're using a local shell, then create local authentication credentials for your user account: 

      gcloud auth application-default login

      You don't need to do this if you're using Cloud Shell.

      If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

    Para mais informações, consulte Set up authentication for a local development environment.

    REST

    Para usar os exemplos da API REST nesta página num ambiente de desenvolvimento local, usa as credenciais que fornece à CLI gcloud.

      Instale a CLI Google Cloud.

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    Para mais informações, consulte o artigo Autenticar para usar REST na Google Cloud documentação de autenticação.

Preços

Quando configura uma verificação de estado baseada em aplicações, sempre que o estado de saúde de uma VM muda, o Compute Engine escreve por predefinição uma entrada de registo no Cloud Logging. O Cloud Logging oferece uma atribuição gratuita por mês após a qual o registo é cobrado por volume de dados. Para evitar custos, pode desativar os registos de alterações do estado de saúde.

Configure uma verificação de funcionamento baseada na aplicação e a autorreparação

Para configurar uma verificação de funcionamento baseada em aplicações e a autorrecuperação num MIG, tem de fazer o seguinte:

  1. Crie uma verificação de funcionamento, se ainda não o fez.
  2. Configure uma política de autorreparação no MIG para aplicar a verificação de funcionamento.

Crie uma verificação de funcionamento

Pode aplicar uma única verificação de estado a um máximo de 50 MIGs. Se tiver mais de 50 grupos, crie várias verificações de funcionamento.

O exemplo seguinte mostra como criar uma verificação de funcionamento para a autorreparação. Pode criar uma verificação de funcionamento regional ou global para a recuperação automática em GIGs. Neste exemplo, cria uma verificação de funcionamento global que procura uma resposta do servidor Web na porta 80. Para permitir que as sondas de verificação de funcionamento alcancem o servidor Web, configure uma regra de firewall.

Consola

  1. Crie uma verificação de funcionamento para a autorrecuperação que seja mais conservadora do que uma verificação de funcionamento do balanceamento de carga.

    Por exemplo, crie uma verificação de funcionamento que procure uma resposta na porta 80 e que possa tolerar algumas falhas antes de marcar as VMs como UNHEALTHY e fazer com que sejam recriadas. Neste exemplo, uma VM é marcada como em bom estado se a verificação de estado for bem-sucedida uma vez. A VM é marcada como danificada se a verificação de estado for devolvida sem êxito 3 vezes consecutivas.

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

      Aceda a Criar uma verificação de saúde

    2. Atribua um nome à verificação de funcionamento, como example-check.

    3. Selecione um Âmbito. Pode selecionar Regional ou Global. Para este exemplo, selecione Global.

    4. Para Protocolo, certifique-se de que HTTP está selecionado.

    5. Em Porta, introduza 80.

    6. Na secção Critérios de saúde, indique os seguintes valores:

      1. Para Intervalo de verificação, introduza 5.
      2. Em Limite de tempo, introduza 5.
      3. Defina um limite de funcionamento para determinar quantas verificações de funcionamento bem-sucedidas consecutivas têm de ser devolvidas antes de uma VM não funcional ser marcada como funcional. Introduza 1 para este exemplo.
      4. Defina um limite de mau estado de funcionamento para determinar quantas verificações de funcionamento sem êxito consecutivas têm de ser devolvidas antes de uma VM em bom estado de funcionamento ser marcada como em mau estado de funcionamento. Introduza 3 para este exemplo.

    7. Clique em Criar para criar a verificação de funcionamento.

  2. Crie uma regra de firewall para permitir que as sondas de verificação de funcionamento se liguem à sua app.

    As sondas de verificação de funcionamento provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Por isso, certifique-se de que as regras da firewall de rede permitem que a verificação de funcionamento se ligue. Para este exemplo, o GIG usa a rede default e as respetivas VMs estão a escutar na porta 80. Se a porta 80 ainda não estiver aberta na rede predefinida, crie uma regra de firewall.

    1. Na Google Cloud consola, aceda à página Políticas de firewall.

      Aceder a Políticas de firewall

    2. Clique em Criar regra de firewall.

    3. Introduza um nome para a regra de firewall. Por exemplo, allow-health-check.

    4. Em Rede, selecione a rede default.

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

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

    7. Para Intervalos IPv4 de origem, introduza 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, introduza 80.

    9. Clique em Criar.

gcloud

  1. Crie uma verificação de funcionamento para a autorrecuperação que seja mais conservadora do que uma verificação de funcionamento do balanceamento de carga.

    Por exemplo, crie uma verificação de funcionamento que procure uma resposta na porta 80 e que possa tolerar algumas falhas antes de marcar as VMs como UNHEALTHY e fazer com que sejam recriadas. Neste exemplo, a VM é marcada como em bom estado se for devolvida com êxito uma vez. A VM é marcada como danificada se devolver um resultado sem êxito 3 vezes consecutivas. O comando seguinte cria uma verificação de funcionamento global.

    gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global

  2. Crie uma regra de firewall para permitir que as sondas de verificação de funcionamento se liguem à sua app.

    As sondas de verificação de funcionamento provêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Por isso, certifique-se de que as regras da firewall permitem a ligação da verificação de funcionamento. Para este exemplo, o MIG usa a rede default e as respetivas VMs escutam na porta 80. Se a porta 80 ainda não estiver aberta na rede predefinida, 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

  1. Crie uma verificação de funcionamento com o recurso google_compute_http_health_check.

    Por exemplo, crie uma verificação de funcionamento 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 em bom estado se for devolvida com êxito uma vez. A VM é marcada como danificada se devolver um resultado sem êxito 3 vezes consecutivas. O pedido seguinte cria uma verificação de funcionamento 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
}

  2. Crie uma firewall com o recurso google_compute_firewall.

    As sondas de verificação de funcionamento são provenientes de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Por isso, certifique-se de que as regras da firewall permitem a ligação da verificação de funcionamento. Para este exemplo, o GIG usa a rede default e as respetivas VMs estão a escutar na porta 80. Se a porta 80 ainda não estiver aberta na rede predefinida, 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 os comandos básicos do Terraform.

REST

  1. Crie uma verificação de funcionamento para a autocorreção que seja mais conservadora do que uma verificação de funcionamento do balanceamento de carga.

    Por exemplo, crie uma verificação de funcionamento 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 em bom estado se for devolvida com êxito uma vez. A VM é marcada como danificada se devolver um resultado sem êxito 3 vezes consecutivas. O pedido seguinte cria uma verificação de funcionamento 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
}

  2. Crie uma regra de firewall para permitir que as sondas de verificação de funcionamento se liguem à sua app.

    As sondas de verificação de funcionamento são provenientes de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Por isso, certifique-se de que as regras da firewall permitem a ligação da verificação de funcionamento. Para este exemplo, o GIG usa a rede default e as respetivas VMs estão a escutar na porta 80. Se a porta 80 ainda não estiver aberta na rede predefinida, 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 seu ID do projeto.

Configure uma política de autorreparação num MIG

Num MIG, só pode configurar uma política de reparação automática para aplicar uma verificação de funcionamento.

Antes de configurar uma política de autocorreção, se ainda não tiver uma verificação de estado, crie uma. Pode usar uma verificação de estado de funcionamento regional ou global para a autorrecuperação em GIGs. Uma verificação de funcionamento regional reduz as dependências entre regiões e ajuda a alcançar a residência de dados, enquanto uma verificação de funcionamento global é conveniente se quiser usar a mesma verificação de funcionamento para MIGs em várias regiões.

Se quiser evitar acionar inadvertidamente a autorreparação ao configurar uma nova verificação de estado ou quiser usar uma verificação de estado sem autorreparação, consulte o artigo Configure a verificação de estado sem autorreparação. Também pode desativar a autocorreção depois de configurar uma verificação de estado no MIG.

Para configurar uma política de autocorreção, selecione uma das seguintes opções:

Consola

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

    Aceda a Grupos de instâncias

  2. Na coluna Nome da lista, clique no nome do MIG no qual quer aplicar a verificação de estado.

  3. Clique em Editar para modificar este MIG.

  4. Clique em Ciclo de vida da instância e autorreparação para expandir a secção.

    1. Na secção Reparação automática, para a Verificação de estado, selecione uma verificação de estado global ou regional.
    2. Para o Atraso inicial, use o valor predefinido ou modifique-o conforme necessário.

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

  5. Clique em Guardar para aplicar as alterações.

gcloud

Para configurar a política de autocorreção num MIG existente, use o comando update. Por exemplo, use o seguinte comando para configurar a política de recuperação automática num MIG zonal existente:

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 autorreparação quando cria um GIG, use o comando create. Por exemplo, use o seguinte comando para configurar a política de autorreparação quando criar um GIG 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 o seguinte:

  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • SIZE: o número de VMs no grupo.
  • INSTANCE_TEMPLATE_URL: o URL do modelo de instância que quer usar para criar VMs no MIG. O URL pode conter o ID ou o nome do modelo de instância. Especifique um dos seguintes valores:
    • Para um modelo de instância regional: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • Para um modelo de instância global: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: O URL parcial da verificação de estado que quer configurar para a autocorreção. Por exemplo:
    • Verificação de saúde regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Verificação de saúde global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado sem êxito porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta saudável durante o atraso inicial, indica que o processo de arranque está concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM muda para VERIFYING. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. O valor predefinido é 0.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use a flag --region.

Terraform

Para configurar uma política de autocorreção num MIG, use o bloco auto_healing_policies.

A seguinte configuração de exemplo configura a política de autorreparação num MIG zonal. Para mais informações sobre o recurso usado no exemplo, consulte google_compute_instance_group_manager. Para um MIG regional, use o recurso 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 os comandos básicos do Terraform.

REST

Para configurar a política de autocura num MIG existente, use o método patch da seguinte forma:

Por exemplo, faça a seguinte chamada para configurar a autorreparação num MIG zonal existente:

  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 autocura ao criar um MIG, use o método insert da seguinte forma:

Por exemplo, faça a seguinte chamada para configurar a política de autorreparação quando criar um GIG 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 o seguinte:

  • PROJECT_ID: o seu ID do projeto.
  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • SIZE: o número de VMs no grupo.
  • INSTANCE_TEMPLATE_URL: o URL do modelo de instância que quer usar para criar VMs no MIG. O URL pode conter o ID ou o nome do modelo de instância. Especifique um dos seguintes valores:
    • Para um modelo de instância regional: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • Para um modelo de instância global: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: O URL parcial da verificação de estado que quer configurar para a autocorreção. Por exemplo:
    • Verificação de saúde regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Verificação de saúde global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado sem êxito porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta saudável durante o atraso inicial, indica que o processo de arranque está concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM muda para VERIFYING. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. O valor predefinido é 0.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use regions/REGION no URL.

Após a conclusão da configuração da autocorreção, podem decorrer 10 minutos antes de a autocorreção começar a monitorizar as VMs no grupo. Após o início da monitorização, o Compute Engine começa a marcar as VMs como em bom estado (ou recria-as) com base na sua configuração de autocura. Por exemplo, se configurar um atraso inicial de 5 minutos, um intervalo de verificação de funcionamento de 1 minuto e um limite de funcionamento de 1 verificação, a cronologia é semelhante à seguinte:

  • Atraso de 10 minutos antes de a autorrecuperação começar a monitorizar as VMs no grupo
  • + 5 minutos para o atraso inicial configurado
  • + 1 minuto para o intervalo de verificação * limite saudável (60 s * 1)
  • = 16 minutos antes de a VM ser marcada como em bom estado ou ser recriada

Configure uma verificação de funcionamento sem autorreparação

Pode desativar a autorrecuperação num MIG e usar a verificação de estado configurada para monitorizar o estado da sua aplicação ou pode implementar a sua própria lógica de reparação. A desativação da autorrecuperação num MIG não afeta o funcionamento da verificação de funcionamento. A verificação de funcionamento continua a testar a aplicação e fornece os estados de funcionamento da VM. No entanto, o MIG deixa de reparar VMs não íntegras.

Para configurar uma verificação de funcionamento sem autorreparação, selecione uma das seguintes opções.

Consola

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

    Aceda a Grupos de instâncias

  2. Na coluna Nome da lista, clique no nome do MIG no qual quer aplicar a verificação de estado.

  3. Clique em Editar para modificar este MIG.

  4. Clique em Ciclo de vida da instância e autorreparação para expandir a secção.

    1. Na secção Reparação automática, para a Verificação de estado, selecione uma verificação de estado global ou regional.
    2. Para o Atraso inicial, use o valor predefinido ou modifique-o conforme necessário.

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

    1. Na lista Na verificação de estado com falha, selecione Nenhuma ação.

  5. Clique em Guardar para aplicar as alterações.

gcloud

Para configurar uma verificação de estado sem autorreparação, quando especifica a configuração da verificação de estado, também tem de definir a flag --action-on-vm-failed-health-check como do-nothing da seguinte forma:

  • Num MIG existente, use o comando beta update.

    Por exemplo, use o seguinte comando num MIG zonal existente:

    gcloud beta compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

  • Quando criar um MIG, use o comando beta create.

    Por exemplo, use o seguinte comando quando criar um MIG zonal:

    gcloud beta compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

Substitua o seguinte:

  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • SIZE: o número de VMs no grupo.
  • INSTANCE_TEMPLATE_URL: o URL do modelo de instância que quer usar para criar VMs no MIG. O URL pode conter o ID ou o nome do modelo de instância. Especifique um dos seguintes valores:
    • Para um modelo de instância regional: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • Para um modelo de instância global: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: O URL parcial da verificação de estado que quer configurar para a autocorreção. Por exemplo:
    • Verificação de saúde regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Verificação de saúde global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado sem êxito porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta saudável durante o atraso inicial, indica que o processo de arranque está concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM muda para VERIFYING. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. O valor predefinido é 0.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use a flag --region.

REST

Para configurar uma verificação de estado sem autorreparação, quando especifica a configuração da verificação de estado, também tem de definir o campo onFailedHealthCheck como DO_NOTHING da seguinte forma:

  • Num MIG existente, use o método patch beta da seguinte forma:

    Por exemplo, faça a seguinte chamada num MIG zonal existente:

    PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

  • Quando criar um MIG, use o método insert beta da seguinte forma:

    Por exemplo, faça a seguinte chamada quando criar um MIG zonal:

    POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL",
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

Substitua o seguinte:

  • PROJECT_ID: o seu ID do projeto.
  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • SIZE: o número de VMs no grupo.
  • INSTANCE_TEMPLATE_URL: o URL do modelo de instância que quer usar para criar VMs no MIG. O URL pode conter o ID ou o nome do modelo de instância. Especifique um dos seguintes valores:
    • Para um modelo de instância regional: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • Para um modelo de instância global: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: O URL parcial da verificação de estado que quer configurar para a autocorreção. Por exemplo:
    • Verificação de saúde regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Verificação de saúde global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: o número de segundos que uma nova VM demora a inicializar e executar o respetivo script de arranque. Durante o período de atraso inicial de uma VM, o MIG ignora as verificações de estado sem êxito porque a VM pode estar no processo de arranque. Isto impede que o MIG recrie prematuramente uma VM. Se a verificação de estado receber uma resposta saudável durante o atraso inicial, indica que o processo de arranque está concluído e que a VM está pronta. O temporizador de atraso inicial começa quando o campo currentAction da VM muda para VERIFYING. O valor do atraso inicial tem de estar entre 0 e 3600 segundos. O valor predefinido é 0.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use regions/REGION no URL.

Depois de configurar a verificação de funcionamento, pode monitorizar os estados de funcionamento da VM para confirmar que a verificação de funcionamento está a funcionar conforme esperado. Se quiser que o GIG repare VMs não íntegras, pode ativar a autorreparação.

Remova uma verificação de funcionamento

Pode remover uma verificação de saúde configurada numa política de autocura da seguinte forma:

Consola

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

    Aceda a Grupos de instâncias

  2. Clique no nome do MIG do qual quer remover a verificação de estado.

  3. Clique em Editar para modificar este MIG.

  4. Clique em Ciclo de vida da instância e autorreparação para expandir a secção.

  5. Na secção Reparação automática, para Verificação de estado, selecione Sem verificação de estado.

  6. Clique em Guardar para aplicar as alterações.

gcloud

Para remover a configuração da verificação de estado numa política de autocorreção, no comando update, use a flag --clear-autohealing da seguinte forma:

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 estado numa política de reparação automática, defina a política de reparação automática para um valor vazio.

Por exemplo, para remover a verificação de funcionamento num MIG zonal, faça o seguinte pedido:

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

{
  "autoHealingPolicies": [
    {}
  ]
}

Substitua o seguinte:

  • PROJECT_ID: o seu ID do projeto.
  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use regions/REGION.

Veja a política de autocorreção num MIG

Pode ver a política de autocorreção de um MIG da seguinte forma:

Consola

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

    Aceda a Grupos de instâncias

  2. Clique no nome do MIG cuja política de autocorreção quer ver.

  3. Aceda ao separador Detalhes.

    A secção Ciclo de vida da instância de VM apresenta a verificação de funcionamento e o atraso inicial configurado na política de reparação automática.

gcloud

Para ver a política de autocorreção num MIG, use o seguinte comando:

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

Substitua MIG_NAME pelo nome de um MIG.

Segue-se 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 ver a política de autocorreção num MIG, use os métodos REST da seguinte forma:

Por exemplo, faça o seguinte pedido para ver a política de autocura num MIG zonal:

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

No corpo da resposta, procure o objeto autoHealingPolicies[].

Segue-se um exemplo de resposta:

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

Substitua o seguinte:

  • PROJECT_ID: o seu ID do projeto.
  • MIG_NAME: o nome do GIG no qual quer configurar a autorreparação.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use regions/REGION.

Verifique o estado

Depois de configurar uma verificação de estado baseada na aplicação num MIG, pode verificar se uma VM está em execução e se a respetiva aplicação está a responder das seguintes formas:

Verifique se as VMs estão em bom estado

Se configurou uma verificação de estado baseada em aplicações no seu MIG, pode rever o estado de saúde de cada instância gerida.

Inspeccione os estados de funcionamento das instâncias geridas para:

  • Identifique VMs não íntegras que não estão a ser reparadas. Uma VM pode não ser reparada imediatamente, mesmo que tenha sido diagnosticada como não saudável nas seguintes situações:
    • A VM ainda está a ser iniciada e o respetivo atraso inicial ainda não passou.
    • Uma parte significativa das instâncias não saudáveis está a ser reparada. O MIG atrasa a autorrecuperação adicional para garantir que o grupo continua a executar um subconjunto de instâncias.
  • Detete erros de configuração de verificações de funcionamento. Por exemplo, pode detetar regras de firewall configuradas incorretamente ou um ponto final de verificação de funcionamento da aplicação inválido se a instância comunicar um estado de funcionamento de TIMEOUT.
  • Determine o valor do atraso inicial a configurar medindo o tempo entre o momento em que a VM passa para um estado RUNNING e o momento em que a VM passa para um estado de saúde HEALTHY. Pode medir esta diferença consultando o método list-instances ou observando o tempo entre a operação instances.insert e o primeiro sinal válido recebido.

Use a consola, a ferramenta de linha de comandos gcloud ou a REST para ver os estados de funcionamento.

Consola

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

    Aceda a Grupos de instâncias.

  2. Na coluna Nome da lista, clique no nome do GIM que quer examinar. É aberta uma página com as propriedades do grupo de instâncias e uma lista de VMs incluídas no grupo.

  3. Se uma VM não estiver em bom estado, pode ver o respetivo estado de saúde na coluna Estado da verificação de estado.

gcloud

Use o subcomando list-instances.

gcloud compute instance-groups managed list-instances MIG_NAME
    --zone ZONE

O comando dá um resultado semelhante ao seguinte. O campo HEALTH_STATE mostra o estado de funcionamento de cada MV.

NAME: igm-with-hc-fvz6
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

NAME: igm-with-hc-gtz3
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

Substitua o seguinte:

  • MIG_NAME: o nome do MIG.
  • ZONE: a zona onde o MIG está localizado. Para um MIG regional, use --region REGION.

REST

Para um GIG regional, crie um pedido POST para o método listManagedInstances 

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

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

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/MIG_NAME/listManagedInstances

O pedido devolve uma resposta semelhante à seguinte, que inclui um campo instanceHealth para cada instância gerida.

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/sproject-id/zones/zone/instances/igm-with-hc-fvz6",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6159431761228150698",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-fvz6"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/igm-with-hc-gtz3",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6622324799312181783",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-gtz3"
    }
  ]
}

Estados de funcionamento

Estão disponíveis os seguintes estados de funcionamento da VM:

  • HEALTHY: A VM está acessível, é possível estabelecer uma ligação ao ponto final de verificação do estado da aplicação e a resposta está em conformidade com os requisitos definidos pela verificação do estado.
  • DRAINING: a VM está a ser esvaziada. As ligações existentes à VM têm tempo para serem concluídas, mas as novas ligações estão a ser recusadas.
  • UNHEALTHY: a VM está acessível, mas não está em conformidade com os requisitos definidos pela verificação de funcionamento.
  • TIMEOUT: a VM está inacessível, não é possível estabelecer uma ligação ao ponto final de verificação do estado da aplicação ou o servidor numa VM não responde dentro do limite de tempo especificado. Por exemplo, isto pode dever-se a regras da firewall configuradas incorretamente ou a uma aplicação de servidor sobrecarregada numa VM.
  • UNKNOWN: o sistema de verificação do estado não tem conhecimento da VM ou o respetivo estado não é conhecido de momento. A monitorização pode demorar 10 minutos a começar em novas VMs num MIG.

As novas VMs devolvem um estado UNHEALTHY até serem validadas pelo sistema de verificação de estado.

A reparação de uma VM depende do respetivo estado de funcionamento:

  • Se uma VM tiver um estado de integridade de UNHEALTHY ou TIMEOUT e tiver passado o período de inicialização, o MIG tenta repará-la imediatamente.
  • Se uma VM tiver um estado de saúde UNKNOWN, o MIG não a repara imediatamente. Isto destina-se a evitar uma reparação desnecessária de uma VM para a qual o sinal de verificação de funcionamento está temporariamente indisponível.

As tentativas de autorrecuperação podem ser atrasadas se:

  • Uma VM permanece em mau estado após várias reparações consecutivas.
  • Existe uma percentagem geral significativa de VMs não saudáveis no grupo.

Queremos saber mais sobre os seus exemplos de utilização, desafios ou feedback acerca dos valores do estado de saúde das VMs. Pode partilhar o seu feedback com a nossa equipa através do endereço de email mig-discuss@google.com.

Verifique as ações atuais nas VMs

Quando um GIG está a criar uma instância de VM, o GIG define o campo currentAction só de leitura dessa instância como CREATING. Se uma política de autocura estiver associada ao grupo, depois de a VM ser criada e estar em execução, o GIG define a ação atual da instância como VERIFYING e o verificador de estado começa a testar a aplicação da VM. Se a aplicação passar nesta verificação de estado inicial no tempo necessário para o arranque da aplicação, a VM é validada e o MIG altera o campo currentAction da VM para NONE.

Para verificar as ações atuais nas VMs, consulte o artigo Veja as ações atuais nas VMs.

Verifique se o MIG é estável

Ao nível do grupo, o Compute Engine preenche um campo só de leitura denominado status que contém uma flag isStable.

Se todas as VMs no grupo estiverem em execução e em bom estado (ou seja, o campo currentAction para cada instância gerida estiver definido como NONE), o GIG define o campo status.isStable como true. Tenha em atenção que a estabilidade de um GIG depende das configurações do grupo além da política de autorreparação. Por exemplo, se o seu grupo tiver escala automática e estiver a ser aumentado ou diminuído, o GIG define o campo status.isStable como false devido à operação do redimensionador automático.

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

Veja as operações de autocorreção do histórico

Pode usar a CLI gcloud ou a REST para ver eventos de autorreparação anteriores.

gcloud

Use o comando gcloud compute operations list com um filtro para ver apenas os eventos de reparação da autocorreção no seu projeto.

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

Para mais informações sobre uma operação de reparação 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 um pedido para o recurso regionOperations e inclua um filtro para restringir a lista de resultados a eventos compute.instances.repair.*.GET

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Para GIGs 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 reparação específica, envie uma GET solicitação 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 é necessário para uma boa verificação de funcionamento de autorreparação

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

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

O que se segue?