Liguei a alta disponibilidade e a máquina parou mesmo assim: o que a HA de fato promete

Você ligou a alta disponibilidade. Um nó caiu e a sua máquina realmente subiu no outro nó. Mas no meio disso ela não serviu nada por alguns minutos, e você achava que não haveria interrupção.

O mal-entendido está aqui: alta disponibilidade não promete funcionamento sem interrupção, promete um reinício automático.

Duas coisas diferentes

A migração em funcionamento é trabalho planejado. Você dispara, a máquina passa para o outro nó junto com a memória e quase não para. É a ferramenta das noites de manutenção.

A alta disponibilidade é para uma falha não planejada. Quando um nó desaba, tudo o que estava na memória dele foi junto; não sobrou nada para copiar. A única coisa possível é subir a máquina do zero em outro nó. Ou seja, ela sobe do jeito que o seu servidor sobe depois de uma queda de energia.

Por isso a medida da HA não deveria ser "houve interrupção" e sim "quanto tempo durou a interrupção".

Três coisas definem a duração

Perceber. O cluster não decide de imediato que um nó realmente morreu. Confundir uma oscilação de rede com morte e mover as máquinas é pior do que não perceber a morte. Por isso existe uma espera.

Silenciar o nó antigo. Esse passo é o mais mal compreendido e é o coração deste artigo: antes de a máquina subir no nó novo, é preciso ter certeza de que o antigo realmente parou. Se isso não puder ser estabelecido, o cluster reinicia aquele nó à força.

Soa duro, mas a alternativa é um desastre: se o nó antigo na verdade está de pé e só a rede dele caiu, a mesma máquina roda em dois lugares e escreve no mesmo disco pelos dois lados. Os dados são danificados sem volta. É por isso que o cluster prefere desligar um nó do qual não tem certeza.

A inicialização. A máquina sobe do começo no nó novo. O sistema operacional inicia, os serviços sobem, um banco de dados, se houver, se recompõe. Esse tempo é o tempo normal de inicialização da sua máquina; o cluster não tem como encurtá-lo.

O total, na maioria das instalações, é da ordem de minutos. Não é zero e não vai ser.

Três condições para a HA funcionar

Uma maioria. A HA depende de o cluster conseguir decidir. Sem maioria, nada migra. Ligar a HA num cluster de dois nós é montar uma rede de segurança que falha justamente na hora em que você mais precisa.

O disco ser visível a partir do outro nó. Se a máquina vai subir no nó novo, ela precisa alcançar o disco dela. Uma máquina que só está em armazenamento local não vai a lugar nenhum.

Capacidade. Os nós restantes precisam aguentar também a carga do nó que caiu. Se os dois nós estão a oitenta por cento, a HA não te salva, ela derruba o segundo também.

Não ligue a HA em toda máquina

Toda máquina com HA ligada vira algo que o cluster observa o tempo todo e sobe ou para por decisão própria quando achar que deve. Isso nem sempre é o que você quer.

O teste é simples: se esta máquina subisse sozinha em outro nó às três da manhã, saber disso de manhã me tranquilizaria ou me preocuparia? Se tranquiliza, ligue a HA. Se preocupa, não ligue; tome você as decisões dessa máquina.

O que o Atlas faz

O Atlas marca à parte as máquinas deixadas à gestão de alta disponibilidade. Onde isso mais ajuda é na manutenção: quando as máquinas de um nó são listadas antes de uma atualização, fica visível em separado quais dependem da sua decisão e quais da decisão do cluster. Mover na mão e deixar para a gestão são coisas diferentes, e confundir sai caro.

Um comportamento pequeno mas significativo: se a alta disponibilidade nunca foi configurada na instalação, o Atlas vê que os arquivos de configuração correspondentes não existem e nem faz essa pergunta, devolve uma resposta vazia. Numa instalação que não usa HA, o produto não ocupa nem você nem o sistema procurando algo que não está lá.

E vale dizer um limite com clareza: o Atlas não toma nem altera a decisão de HA do cluster. Se uma máquina fica ou não sob HA é assunto seu e do Proxmox; o Atlas torna isso visível, não decide por você.