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.
- Abra o ficheiro de configuração da VM.
- Navegue para a secção
spec:. - Adicione ou modifique os campos
guestEnvironment:eguestHealthCheck:para ativar a verificação. - Defina o campo
enablecomo 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:
- Abra o ficheiro de configuração da VM.
- Adicione a anotação
highavailability.virtualmachine.gdc.goog/enable: falseaos 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
kubeletno 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.