Uma das perguntas mais frequentes de quem opera Proxmox é também uma das mais desconfortáveis: "por que o nó reiniciou sozinho, sem ninguém pedir?" A resposta quase sempre é que o cluster funcionou exatamente como projetado. Aquele reinício não foi uma falha — foi um mecanismo de proteção agindo para evitar algo muito pior. Entender esse mecanismo é o que diferencia operar um cluster de conviver com ele.

O problema que o quórum existe para resolver

Imagine um cluster de quatro nós onde o switch falha e separa a rede em dois pares. Cada par vê dois nós vivos e dois mortos. Se cada lado agir por conta própria e ligar as VMs que "caíram", a mesma VM passa a rodar em dois lugares, escrevendo no mesmo storage. O resultado não é indisponibilidade — é corrupção de dado, que é irreversível e muito pior.

Esse cenário tem nome: split-brain. E o quórum é a regra que o impede. Só o grupo que tem a maioria dos votos pode tomar decisões. O outro lado, mesmo funcionando perfeitamente, precisa se calar.

Essa é a chave para entender todo o comportamento do cluster: perder quórum não significa estar quebrado. Significa não ter autoridade para agir.

Número de nós: por que ímpar importa

A maioria de um número par é frágil. Em quatro nós divididos ao meio, nenhum lado tem maioria e o cluster inteiro para. Em cinco nós divididos em três e dois, o lado de três continua operando.

A conclusão prática é direta: ir de três para quatro nós não aumenta a tolerância a falhas do cluster, só a capacidade. Se o objetivo é resiliência, o salto que importa é de três para cinco.

O cluster de dois nós e o QDevice

Dois nós é a configuração mais comum em quem está começando, e é a mais problemática. A maioria de dois é dois, então a queda de qualquer nó deixa o sobrevivente sem quórum — e portanto sem poder ligar as VMs do que caiu. A alta disponibilidade que se esperava simplesmente não acontece.

A solução correta é o QDevice: um terceiro votante que não precisa ser um nó de virtualização. Uma máquina pequena, uma VM em outro lugar, um dispositivo modesto — basta que rode o serviço de voto e tenha rede para os dois nós. Com ele, o cluster passa a ter três votos, e a queda de um nó deixa dois: maioria, quórum, HA funcionando.

O erro que vemos no lugar disso é reduzir manualmente os votos esperados para que um nó só tenha maioria. Isso funciona como medida temporária durante uma manutenção conhecida, e é perigoso como configuração permanente: você desligou justamente a proteção contra split-brain. Se o problema era rede, e não nó morto, os dois lados vão agir.

Fencing: por que o nó reinicia sozinho

Quando um nó perde quórum, o cluster precisa de certeza de que ele não vai continuar mexendo nas VMs — senão não é seguro ligá-las em outro lugar. Essa certeza se chama fencing.

O Proxmox faz isso por autoexclusão via watchdog. O mecanismo é elegante: enquanto o nó tem quórum, ele alimenta periodicamente um temporizador. Se perde o quórum, para de alimentar, e o temporizador expira e reinicia a máquina. O nó se remove do jogo sozinho, sem depender de nenhuma ação externa — o que é essencial, porque um nó com problema de rede não pode ser contatado justamente por quem precisaria desligá-lo.

Daí vem a resposta à pergunta do começo. O nó reiniciou porque ficou isolado do cluster por tempo suficiente. E a causa raiz, na esmagadora maioria dos casos que investigamos, é rede — Corosync compartilhando link com migração ao vivo ou com backup, perdendo pacote quando o link satura.

Uma consequência importante: o fencing só é acionado quando há HA configurada para as VMs. Um nó sem VMs em HA que perde quórum fica isolado, mas não se reinicia.

Ler o estado do cluster antes de agir

Em incidente, três informações resolvem a maior parte do diagnóstico, e vale saber obtê-las antes de precisar:

• O estado do quórum e a contagem de votos, que diz imediatamente se este nó tem autoridade ou não.
• A saúde dos anéis do Corosync, mostrando se os nós estão se vendo e se há retransmissão de pacote. Retransmissão crescente é o sinal precoce de que o próximo incidente já está a caminho.
• O log do serviço de cluster, onde aparece o momento exato da perda de vínculo e a razão.

Duas orientações de conduta. Primeiro: não reinicie nós no escuro. Reiniciar um nó saudável durante uma perda de quórum pode transformar um problema de rede em perda de maioria de verdade. Segundo: se o cluster está sem quórum e as VMs estão rodando, elas continuam rodando — o storage local não para porque o Corosync parou. Você tem tempo para diagnosticar; a pressa é que costuma piorar a situação.

Manutenção sem provocar incidente

Boa parte dos incidentes de quórum é autoinfligida durante manutenção. O roteiro que evita isso:

1. Coloque o nó em modo de manutenção antes de mexer nele, para que o HA mova as VMs de forma ordenada em vez de reagir a uma queda.
2. Um nó por vez, sempre. Em cluster de três, dois nós em manutenção simultânea significam cluster sem quórum.
3. Confirme o quórum antes de começar o próximo. Nó que voltou não é o mesmo que nó que voltou e reingressou no cluster.
4. Cuidado especial com atualização de switch ou firmware de rede. É o momento de maior risco, porque afeta todos os nós ao mesmo tempo. Se possível, faça com as VMs de HA temporariamente fora de HA.
5. Verifique a saúde do storage antes de devolver o nó ao cluster — em Ceph, espere a recuperação terminar antes de tocar no nó seguinte.

O nó que não volta

Quando um nó reinicia e não reingressa, o roteiro de verificação, em ordem de probabilidade:

• Rede. A interface subiu? O bond está completo ou com um link só? Depois de troca de hardware, o nome da interface mudou? Esta é a causa em quase todos os casos.
• Hora. Divergência grande de relógio impede o Corosync de estabelecer vínculo. Servidor de tempo funcionando é requisito, não recomendação.
• Certificados e chaves do cluster, que podem ficar inconsistentes após restauração de backup do nó ou reinstalação.
• Firewall, se alguma regra nova bloqueou a porta do Corosync.
• Serviço de cluster com falha ao iniciar, cuja mensagem no log costuma ser específica e útil.

Se o nó está definitivamente morto e não vai voltar, remova-o do cluster formalmente. Nó morto continua contando como voto esperado, e isso mantém a barra da maioria mais alta do que precisa: um cluster de três com um nó morto e não removido exige dois votos dos dois nós restantes, ou seja, tolera zero falhas adicionais. E nunca reintroduza uma máquina com o mesmo nome e endereço sem antes remover a entrada antiga — o cluster vai tratar como conflito.

Erros comuns

• Cluster de dois nós sem QDevice, esperando HA funcionar.
• Reduzir votos esperados permanentemente em vez de adicionar um votante.
• Corosync no mesmo link da migração ao vivo, causando reinício de nó saudável.
• Ir de três para quatro nós esperando mais tolerância a falhas.
• Manutenção em dois nós ao mesmo tempo num cluster de três.
• Nó morto não removido, mantendo o voto esperado alto.
• Servidor de tempo ausente ou divergente entre nós.
• Reiniciar nós no escuro durante perda de quórum.
• Nenhum segundo anel de Corosync, deixando o quórum na mão de um switch.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, essa é a área em que mais fazemos correção de desenho: clusters de dois nós vendidos como alta disponibilidade, Corosync disputando link com backup, nós mortos que ninguém removeu. Revisamos a topologia de votos, implantamos QDevice ou o número de nós adequado, separamos a rede de cluster, configuramos o segundo anel e documentamos o procedimento de manutenção para que a sua equipe não provoque o incidente que quer evitar. Também oferecemos sustentação contínua, com monitoramento do Corosync para agir antes do reinício.

Quer uma revisão do quórum e do fencing do seu cluster? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.