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étodoinstanceGroupManagers.deleteInstances
na API Compute Engine ou na ferramenta de linha de comandogcloud
. - 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.
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 comoUNHEALTHY
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 falha3
vezes consecutivas.- No Console do Google Cloud, acesse a página Criar uma verificação de integridade.
- Dê um nome à verificação de integridade, como
example-check
. - Em Protocolo, certifique-se de que HTTP esteja selecionado.
- Em Porta, insira
80
. - Em Intervalo de verificação, insira
5
. - Em Tempo limite, insira
5
. - 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. - 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. - 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.
As sondagens da verificação de integridade provêm de endereços nos intervalos
130.211.0.0/22
e35.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 rededefault
e as VMs dela estão ouvindo na porta80
. Se a porta80
ainda não estiver aberta na rede padrão, crie uma regra de firewall.- No Console do Google Cloud, acesse a página Criar regra de firewall.
- Em Nome, insira um nome para a regra de firewall. Por exemplo,
allow-health-check
. - Em Rede, selecione a rede
default
. - Em Filtro de origem, selecione
IP ranges
. - Em Intervalos de IPs de origem, insira
130.211.0.0/22
e35.191.0.0/16
. - Em Protocolos e portas, selecione Portas e protocolos especificados e insira
tcp:80
. - 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.
- No Console do Google Cloud, acesse a página Grupos 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 grupo para modificar esse MIG.
- Em Recuperação automática, selecione a verificação de integridade criada anteriormente.
- 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
. - 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 comoUNHEALTHY
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 falha3
vezes consecutivas.gcloud compute health-checks create http example-check --port 80 \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3
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
e35.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 rededefault
e as VMs detectam na porta80
. Se a porta80
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 ocurrentAction
da VM éVERIFYING
.Exemplo:
gcloud compute instance-groups managed update my-mig \ --health-check example-check \ --initial-delay 300 \ --zone us-east1-b
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 comoUNHEALTHY
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 falha3
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 }
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
e35.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 rededefault
e as VMs dela estão ouvindo na porta80
. Se a porta80
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
ouregionInstanceGroupManager
.Defina uma política de recuperação automática usando os métodos
insert
oupatch
.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 ocurrentAction
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[]
. ComautoHealingPolicies[]
, o MIG recria apenas VMs que não estão no estadoRUNNING
.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 integridadeHEALTHY
. Esse intervalo pode ser medido pesquisando o métodolist-instances
.
Use o console, a ferramenta de linha de comando gcloud
ou a API para ver os estados de integridade.
Console
No Console do Google Cloud, acesse 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
ouTIMEOUT
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.
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étodosstop
estart
;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 que1
. O ideal é definir esse valor como3
ou mais. Isso protege contra falhas raras, como a perda de pacotes de rede.healthy-threshold
: o valor2
é 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.