Resiliência da VM

Este documento apresenta uma visão geral da capacidade de recuperação de máquina virtual (VMs) e das verificações opcionais que os operadores de aplicativos podem ativar para ter insights mais detalhados em uma VM isolada por air gap no Google Distributed Cloud (GDC).

Este documento é destinado a desenvolvedores do grupo de operadores de aplicativos que operam VMs. Para mais informações, consulte Públicos-alvo da documentação isolada do GDC.

As VMs no GDC oferecem alta disponibilidade para melhorar a continuidade do serviço em caso de falhas na infraestrutura ou no convidado. Também é possível configurar o sistema para emitir indicadores de integridade opcionais que oferecem insights mais detalhados sobre o status da VM.

Verificações de disponibilidade de VM

O sistema oferece as seguintes verificações de disponibilidade de VM:

Nome no cheque Descrição Suporte a ações de mitigação Disponibilidade de indicadores
Verificação de integridade do visitante Verifica a integridade do SO convidado. Um pré-requisito para outras verificações no dispositivo. Sim Verificação de hóspedes
Verificação de armazenamento Verifica a integridade do armazenamento subjacente da VM. Sim Verificação de hóspedes
Verificação de saída Verifica a conectividade com um endpoint interno conhecido. Não Dentro e fora do quarto
Verificação de entrada Verifica a acessibilidade da VM usando o ingresso configurado (VirtualMachineExternalAccess). Não Verificação de hóspedes

As ações de mitigação podem reiniciar a VM e reprogramar para outro nó em falhas frequentes.

Solicitar permissões e acesso

Para executar as tarefas listadas nesta página, você precisa ter o papel de administrador de máquina virtual do projeto. Siga as etapas para verificar se você tem o papel de administrador de máquina virtual do projeto (project-vm-admin) no namespace do projeto em que a VM reside.

Ativar verificações no quarto

Por padrão, a verificação no convidado é desativada se o guestHealthCheck não estiver presente.

Para ativar ou desativar a verificação no convidado de uma VM, atualize o GuestEnvironment na especificação da VM. Essa configuração coleta métricas de dentro da VM, desde que o agente convidado esteja instalado. Se o guestHealthCheck não estiver presente, as verificações no convidado serão desativadas por padrão.

  1. Abra o arquivo de configuração da VM.
  2. Navegue até a seção spec:.
  3. Adicione ou modifique os campos guestEnvironment: e guestHealthCheck: para ativar a verificação.
  4. Defina o campo enable como verdadeiro.

Confira um exemplo da configuração em um arquivo YAML:

spec:
  compute:
    virtualMachineType: n2-standard-2-gdc
  guestEnvironment:
    guestHealthCheck:
      enable: true

Verificar as verificações

Depois de configurar a VM, é possível verificar o status das verificações de disponibilidade inspecionando o Condition da máquina virtual no Status dela.

kubectl --kubeconfig MANAGEMENT_API_SERVER \
  -n NAMESPACE_NAME \
  get gvm -o yaml

A saída mostra o status das várias verificações. Por exemplo, se o guestHealthCheck estiver ativado, as condições de status gvm serão preenchidas com o sinal VMGuestHealth.

Desativar a alta disponibilidade da VM

Por padrão, a alta disponibilidade de VM é ativada se a anotação não estiver presente. É possível desativar explicitamente a alta disponibilidade para uma VM específica adicionando uma anotação. Adicione a anotação para desativar a alta disponibilidade da VM:

  1. Abra o arquivo de configuração da VM.
  2. Adicione a anotação highavailability.virtualmachine.gdc.goog/enable: false aos metadados da VM para desativar a alta disponibilidade.

Confira um exemplo da anotação em um arquivo YAML:

metadata:
  annotations:
    highavailability.virtualmachine.gdc.goog/enable: false

Mitigação de falhas de nós

As ações de mitigação automatizadas resolvem falhas de VM e mantêm a alta disponibilidade. Quando a infraestrutura subjacente não consegue mais oferecer suporte a uma VM em execução, o sistema tenta isolar o nó não íntegro e reprogramar a VM para um nó íntegro. Os seguintes cenários podem acionar essa mitigação no nível do nó:

  • Partição de nó do servidor da API: o nó bare metal que hospeda a VM é particionado do servidor da API Management devido a uma condição como esta:

    • Perda de conectividade de rede entre o nserver da API e o nó.
    • O agente kubelet no nó está inativo.
    • O nó observa uma falha de energia.

  • Partição de VM do cluster de usuário: uma VM de worker do cluster de usuário é particionada do servidor da API Management do cluster.