Acerca da reparação de VMs para alta disponibilidade

Este documento descreve como um grupo de instâncias gerido (MIG) oferece alta disponibilidade da sua aplicação reparando VMs com falhas e não íntegras no grupo.

Um GIG mantém a sua aplicação atualizada e disponível, mantendo proativamente o número de VMs em execução no grupo. Se uma VM no grupo ficar inativa, o GIG repara a VM recriando-a das seguintes formas para voltar a colocar a VM em serviço:

  • Repare automaticamente uma VM com falhas: se uma VM falhar ou for eliminada por uma ação não iniciada pelo GIG, o GIG repara automaticamente a VM com falhas. Neste documento, consulte o artigo Repare automaticamente uma VM com falhas.
  • Repare uma VM com base numa verificação de funcionamento da aplicação: uma forma opcional de melhorar ainda mais a elevada disponibilidade reparando VMs não saudáveis. Se configurar uma verificação de estado baseada na aplicação e a sua aplicação falhar na verificação de estado, o MIG marca essa VM como não saudável e repara-a. A reparação de uma VM com base numa verificação de funcionamento da aplicação também é denominada autorreparação. Neste documento, consulte o artigo Repare uma VM com base numa verificação de funcionamento da aplicação.

Repare automaticamente uma VM com falhas

Se uma VM num GIG falhar, o GIG repara automaticamente a VM com falhas recriando-a. Uma MV pode falhar pelos seguintes motivos:

Se o MIG parar intencionalmente uma VM, por exemplo, quando um autoscaler elimina uma VM, o MIG não repara essa VM.

Repare uma VM com base numa verificação de funcionamento da aplicação

Além da reparação automática de VMs com falhas, pode querer reparar uma VM se a sua aplicação em execução na VM bloquear, falhar ou ficar sem memória. Para garantir que a aplicação está a responder conforme esperado, pode configurar uma verificação do estado de funcionamento baseada na aplicação.

Uma verificação de estado baseada na aplicação verifica periodicamente se a sua aplicação em cada VM num MIG está a responder conforme esperado. Se a aplicação numa VM não responder, o MIG marca essa VM como danificada. Em seguida, o GIG repara a VM não saudável. A reparação de uma VM com base numa verificação de funcionamento da aplicação chama-se autorrecuperação.

Para garantir que o MIG continua a executar um subconjunto das respetivas VMs, o grupo nunca repara automaticamente todas as VMs em simultâneo. Isto é útil se, por exemplo, uma verificação de funcionamento incorreta acionar reparações desnecessárias, uma regra de firewall mal configurada impedir que uma verificação de funcionamento analise a VM ou existirem problemas de conetividade de rede ou de infraestrutura que identifiquem incorretamente uma VM em bom estado como estando em mau estado. No entanto, se um GIG zonal tiver apenas uma VM ou um GIG regional tiver apenas uma VM por zona, um GIG repara automaticamente estas VMs quando ficam em mau estado.

Política de autocorreção

Cada GMG tem uma política de autocura na qual pode configurar uma verificação de estado e também definir um atraso inicial. O atraso inicial é o tempo que uma nova VM demora a inicializar e executar o respetivo script de arranque. O temporizador de atraso inicial começa quando o MIG altera o campo currentAction da VM para VERIFYING. 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.

Para mais informações sobre a configuração de uma política de autocura, consulte o artigo Configure uma verificação de funcionamento da aplicação e a autocura.

Monitorize as alterações do estado de funcionamento das aplicações

Se configurou uma verificação de estado baseada em aplicações no MIG, pode verificar o estado de funcionamento de cada VM no MIG. Para mais informações, consulte o artigo Verifique se as VMs estão em bom estado.

Também pode monitorizar as alterações no estado de funcionamento de uma VM. Para mais informações, consulte o artigo Monitorize as alterações do estado de funcionamento.

Preços

Quando configura uma verificação de estado baseada em aplicações, por predefinição, o Compute Engine escreve uma entrada de registo sempre que o estado de saúde de uma instância gerida muda. 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.

Comportamento durante uma reparação

As secções seguintes explicam o comportamento durante as reparações automáticas e as reparações baseadas na verificação do estado da aplicação.

Atualização sobre a reparação

Por predefinição, durante uma reparação, um MIG recria uma VM através do modelo de instância original que foi usado para criar a VM. Por exemplo, se uma VM foi criada com instance-template-a e, em seguida, atualizar o GIG para usar instance-template-b no modo OPPORTUNISTIC, o GIG continua a usar instance-template-a para recriar a VM.

Se quiser que o GIG use o modelo de instância mais recente e as configurações por instância durante a reparação de VMs, pode configurar o grupo para aplicar atualizações de configuração durante as reparações.

Manuseamento de discos

Durante uma reparação, quando recria uma VM com base no respetivo modelo, o MIG processa diferentes tipos de discos de forma diferente. Algumas configurações de disco podem fazer com que a reparação falhe ao tentar recriar uma VM.

Tipo de disco autodelete Comportamento durante uma reparação
Novo disco persistente true O disco é recriado conforme especificado no modelo de instância. Todos os dados escritos nesse disco são perdidos quando o disco e a respetiva VM são recriados.
Novo disco persistente false O disco é preservado e anexado novamente quando o MIG recria a VM.
Disco persistente existente true O disco antigo é eliminado. A operação de recriação da VM falha porque o Compute Engine não consegue voltar a anexar um disco eliminado à VM. No entanto, para discos de leitura/escrita existentes, um MIG só pode ter até uma VM, porque não é possível anexar um único disco persistente a várias VMs no modo de leitura/escrita.
Disco persistente existente false O disco antigo é novamente anexado conforme especificado no modelo de instância. Os dados no disco são preservados. No entanto, para discos de leitura/escrita existentes, um MIG só pode ter até uma VM, porque não é possível anexar um único disco persistente a várias VMs no modo de leitura/escrita.
Novo SSD local N/A O disco é recriado conforme especificado no modelo de instância. Os dados num SSD local são perdidos quando uma VM é recriada ou eliminada.

O MIG não volta a associar discos que não estejam especificados no modelo de instância ou nas configurações por instância, como discos que associou a uma VM manualmente após a criação da VM.

Para preservar dados importantes que foram escritos no disco, tome precauções, como as seguintes:

Se as suas VMs tiverem definições importantes que quer preservar, a Google também recomenda que use uma imagem personalizada no modelo de instância. Uma imagem personalizada contém todas as definições personalizadas de que precisa. Quando especifica uma imagem personalizada no modelo de instância, o MIG recria as VMs com a imagem personalizada que contém as definições personalizadas de que precisa.

Desative as reparações

Pode desativar as reparações feitas automaticamente por um MIG. Quando desativa as reparações num MIG, a reparação de VMs com falhas e a reparação com base numa verificação de funcionamento da aplicação são desativadas. Também pode desativar separadamente as reparações com base numa verificação de funcionamento da aplicação.

Pode desativar as reparações num MIG em cenários como os seguintes:

  • Para investigar ou depurar uma VM com falhas sem interrupções da reparação automática.
  • Para reparar VMs manualmente ou implementar a sua própria lógica de reparação.
  • Para evitar a recriação de VMs enquanto um trabalho em lote está em curso.
  • Para observar os estados de funcionamento das aplicações sem reparar uma VM danificada.
  • Para otimizar a configuração da verificação de funcionamento sem acionar inadvertidamente reparações.

Quando desativa as reparações, o MIG não toma nenhuma medida se uma VM no grupo falhar ou ficar em mau estado. As VMs com falhas e em mau estado de funcionamento continuam no grupo e o número de VMs em execução no GIG (targetSize) permanece o mesmo. No entanto, se tiver definido um limite de tempo para as VMs, quando as VMs com falhas e não íntegras atingirem esse limite de tempo, o MIG elimina automaticamente essas VMs e o targetSize diminui.

Se o tipo de atualização do MIG estiver definido como proactive e estiver disponível um novo modelo de instância, o MIG atualiza as VMs com falhas e não íntegras recriando essas VMs com o novo modelo. Se não quiser atualizar as VMs com falhas e em mau estado, tem de definir o tipo de atualização como opportunistic.

Se configurou uma verificação de estado baseada na aplicação, desativar as reparações não afeta o funcionamento da verificação de estado. A verificação de funcionamento continua a sondar a aplicação e a fornecer os estados de funcionamento da VM. Isto permite-lhe monitorizar os estados de funcionamento das aplicações e, ao mesmo tempo, impedir que o MIG repare VMs em mau estado.

Se o MIG fizer parte de um serviço de back-end de um balanceador de carga e desativar as reparações no MIG, todas as VMs com falhas e não íntegras não reparadas não respondem à verificação de estado do balanceador de carga. Se o número destas VMs com falhas ou em mau estado no MIG aumentar, o balanceador de carga pode reduzir o tráfego para esse MIG ou mudar para outro back-end, se estiver configurado. Quando as VMs com falhas ficam novamente disponíveis, o balanceador de carga retoma o tráfego para o MIG.

Para mais informações, consulte o artigo Desative as reparações num MIG.

O que se segue?