Resiliência da VM

Este documento oferece uma vista geral da resiliência das máquinas virtuais (VMs) e das verificações opcionais que os operadores de aplicações podem ativar para obter estatísticas mais detalhadas a partir de uma VM no Google Distributed Cloud (GDC) isolado.

Este documento destina-se a programadores no grupo de operadores de aplicações que operam VMs. Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

As VMs no GDC oferecem HA para melhorar a continuidade do serviço em caso de falhas na infraestrutura subjacente ou no convidado. Também pode configurar o sistema para emitir sinais de estado opcionais que oferecem estatísticas mais detalhadas sobre o estado da VM.

Verificações de disponibilidade de VMs

O sistema fornece as seguintes verificações de disponibilidade de VMs:

Nome da verificação Descrição Apoio técnico para ações de mitigação Disponibilidade do sinal
Verificação de funcionamento do convidado Valida o estado do SO convidado. Um pré-requisito para outras verificações no quarto. Sim In-Guest Check
Verificação de armazenamento Valida o estado de funcionamento do armazenamento subjacente da VM. Sim In-Guest Check
Verificação de saída Valida a conetividade a um ponto final interno conhecido. Não Check-in no hotel e fora
Verificação de entrada Valida a acessibilidade da VM através da respetiva entrada configurada (VirtualMachineExternalAccess). Não In-Guest Check

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

Pedir autorizações e acesso

Para realizar as tarefas indicadas nesta página, tem de ter a função de administrador da máquina virtual do projeto. Siga os passos para validar que tem a função de administrador de máquinas virtuais do projeto (project-vm-admin) no espaço de nomes do projeto onde a VM reside.

Ative as verificações no hóspede

Por predefinição, a verificação no convidado está desativada se o elemento guestHealthCheck não estiver presente.

Para ativar ou desativar a verificação no convidado de uma VM, tem de atualizar o elemento GuestEnvironment na especificação da VM. Esta definição recolhe métricas do interior da VM, desde que o agente convidado esteja instalado. Se o elemento guestHealthCheck não estiver presente, as verificações no SO convidado são desativadas por predefinição.

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

Segue-se um exemplo da configuração num ficheiro YAML:

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

Valide as verificações

Depois de configurar a VM, pode verificar o estado das verificações de disponibilidade inspecionando o Condition da máquina virtual no respetivo Status.

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

O resultado mostra o estado das várias verificações. Por exemplo, se a opção guestHealthCheck estiver ativada, as condições de estado gvm são preenchidas com o sinal VMGuestHealth.

Desative a alta disponibilidade de VMs

Por predefinição, a alta disponibilidade da VM está ativada se a anotação não estiver presente. Pode desativar explicitamente a HA para uma VM específica adicionando uma anotação. Adicione a anotação para desativar a HA de VMs:

  1. Abra o ficheiro 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.

Segue-se um exemplo da anotação num ficheiro YAML:

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

Mitigação de falhas de nós

As ações de mitigação automatizadas resolvem as falhas de VMs e mantêm a HA. Quando a infraestrutura subjacente já não consegue suportar uma VM em execução, o sistema tenta isolar o nó não saudável e reagendar a VM para um nó saudável. Os seguintes cenários podem acionar esta mitigação ao nível do nó:

  • Partição do nó do servidor da API: o nó de metal exposto que aloja a VM está particionado do servidor da API de gestão devido a uma condição como a seguinte:

    • Perda da conetividade de rede entre o servidor de nomes 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 utilizadores: uma VM de trabalho do cluster de utilizadores é particionada a partir do servidor da API Management do respetivo cluster.