"O servidor caiu e ninguém percebeu porque as VMs subiram sozinhas em outro nó." Esse é o objetivo da alta disponibilidade (HA) no Proxmox VE. Alcançá-lo não é mágica — é arquitetura. E arquitetura mal feita cria a falsa sensação de segurança, que é pior do que não ter HA nenhum.

Vamos ao que realmente importa para um cluster que aguenta o tranco.

Primeiro, o que HA não é

Alinhar expectativa evita frustração e decisão errada:

• HA não é backup. Ele protege contra falha de hardware, não contra exclusão acidental, corrupção lógica ou ransomware. As duas coisas são necessárias, e uma não substitui a outra.
• HA não é zero downtime. A VM reinicia em outro nó. Há uma interrupção — curta, mas real. Continuidade sem queda alguma se resolve na camada da aplicação, com múltiplas instâncias atrás de um balanceador.
• HA não conserta aplicação frágil. O reinício é abrupto, equivalente a um corte de energia. Se o seu sistema não sobrevive a isso, HA vai expor o problema em vez de resolvê-lo.

Com isso claro, o objetivo real fica honesto: reduzir a indisponibilidade de horas — o tempo de alguém perceber, diagnosticar e agir — para poucos minutos automáticos.

Cluster: a base de tudo

HA no Proxmox VE exige um cluster — vários nós enxergando uns aos outros e compartilhando configuração. O serviço corosync mantém essa comunicação. E é aqui que aparece o primeiro conceito crítico: quórum.

Quórum: por que três nós, não dois

Quórum é a maioria necessária para o cluster tomar decisões. Com número par de nós — dois, por exemplo — surge o risco de split-brain: os dois lados perdem contato, cada um acha que é o sobrevivente, e ambos tentam assumir as mesmas VMs. Resultado: corrupção de dados.

Por isso o mínimo recomendado é três nós. Com três, se um cai, os outros dois ainda formam maioria e o cluster segue decidindo com segurança. Se você tem só dois servidores, existe a alternativa do QDevice — um voto externo leve que quebra o empate. Mas o padrão saudável é três.

Um detalhe que pega muita gente: perder quórum não derruba as VMs que já estão rodando, mas congela decisões do cluster. Você não consegue iniciar, migrar ou alterar recursos até a maioria se restabelecer. Em nó isolado com HA ativo, o resultado é mais drástico — o watchdog age, como veremos a seguir.

Fencing: garantir que o nó "morto" está morto mesmo

Antes de reiniciar uma VM em outro nó, o cluster precisa ter certeza de que o nó original não vai voltar a acessar o mesmo disco — senão, novamente, corrupção. Esse mecanismo é o fencing. No Proxmox VE, ele acontece por watchdog: o nó problemático se autorreinicia em vez de continuar em estado ambíguo. Configurar isso corretamente é o que torna o HA confiável em vez de perigoso.

Na prática, o nó que perde quórum e tem recursos de HA deixa de alimentar o watchdog e se reinicia sozinho depois de um intervalo curto. Só então o cluster considera seguro reiniciar aqueles recursos em outro lugar. Vale usar o watchdog de hardware quando a placa oferece — é mais confiável que o watchdog em software, embora este resolva bem a maioria dos casos.

Quanto tempo leva, na prática

Expectativa realista de recuperação, somando as etapas:

Ou seja: um ciclo típico de recuperação fica na casa de poucos minutos, não de milissegundos. Quem precisa de menos que isso precisa de redundância na aplicação, com HA como rede de proteção por baixo.

HA Manager: quem sobe o quê, e onde

O HA Manager é o componente que monitora os recursos marcados como de alta disponibilidade e decide onde reiniciá-los quando um nó falha. Você define grupos, prioridades e políticas — por exemplo, "esta VM só roda nestes dois nós" ou "prefira o nó com mais recurso livre".

Alguns controles que valem conhecer antes de precisar deles:

• Estado desejado do recurso: started, stopped ou ignored. Marcar como started significa que o cluster vai insistir em manter aquilo de pé — inclusive reiniciando o que você parou manualmente, se esquecer de mudar o estado.
• Grupos de HA com prioridade: definem quais nós preferenciais recebem cada carga, útil para respeitar licenciamento, afinidade de dados ou capacidade desigual entre servidores.
• Comportamento de retorno: por padrão o recurso pode voltar ao nó preferido quando ele reaparece. Em ambientes sensíveis, desligar esse retorno automático evita uma segunda interrupção no mesmo dia.
• Limites de tentativa: quantas vezes o cluster tenta reiniciar no mesmo nó antes de mover o recurso para outro. Ajuste conforme a carga, para não transformar uma falha de aplicação em ping-pong entre servidores.

O elo que quase sempre é esquecido: o storage

HA de computação sem HA de armazenamento é meia solução. Se as VMs sobem em outro nó, elas precisam enxergar o mesmo disco de lá. É por isso que HA sério anda de mãos dadas com armazenamento compartilhado ou distribuído — tipicamente Ceph, que replica o dado entre os nós e sobrevive à queda de um deles.

Montar HA de compute sobre um storage que tem ponto único de falha é construir uma parede sobre uma fundação de areia.

Existe um meio-caminho legítimo, e é importante entender o que ele custa: replicação ZFS entre nós, agendada em intervalos. Funciona sem storage compartilhado e é barata, mas é assíncrona — a VM reinicia no outro nó a partir do último snapshot replicado. Se a replicação roda a cada quinze minutos, você aceita perder até quinze minutos de escrita. Para muitos serviços internos, é um acordo aceitável. Para banco de dados transacional, quase nunca é.

Rede: o detalhe que derruba clusters

O corosync é sensível a latência. A recomendação é ter a rede de cluster separada da rede de dados e de armazenamento. Misturar tudo em uma interface só é o caminho mais rápido para instabilidade intermitente e difícil de diagnosticar.

Dois cuidados adicionais que valem o investimento: configurar mais de um link de cluster, para que a perda de uma interface não isole o nó, e evitar que tráfego de backup ou de migração sature justamente o caminho por onde o corosync conversa. Cluster que "cai sozinho de madrugada" quase sempre é cluster cuja rede de controle competia com a janela de backup.

Testar a falha — de propósito

Um cluster HA que nunca foi testado é uma promessa, não uma garantia. A validação inclui derrubar um nó de propósito, em janela controlada, e confirmar que as VMs migram, que o fencing atua e que o storage acompanha. Só depois disso o "não cai" vira verdade.

Um roteiro de teste que cobre o que importa:

1. Desligar um nó pela energia, sem aviso ao sistema operacional, e cronometrar a recuperação.
2. Desconectar apenas a rede de cluster de um nó e confirmar que o fencing atua como esperado.
3. Remover um disco do Ceph em produção e acompanhar o cluster recompondo as réplicas sozinho.
4. Reintroduzir o nó e verificar se o retorno das cargas acontece conforme a política definida.
5. Repetir o exercício depois de cada mudança relevante de topologia, e ao menos uma vez por ano.

Documente os tempos medidos. Eles são a base para prometer SLA com honestidade — e para descobrir cedo quando algo regrediu.

Erros comuns

• Cluster de dois nós com HA ativo e sem QDevice.
• Fencing não validado — o cluster tenta recuperar sem certeza de que o nó parou.
• HA de compute sobre storage com ponto único de falha.
• Rede de cluster compartilhada com backup, migração e tráfego de VM.
• Todos os nós no mesmo rack, no mesmo circuito elétrico, no mesmo switch.
• Capacidade sem folga: três nós cheios não têm onde acomodar a carga do que caiu.

Esse último merece ênfase. HA só funciona se sobrar recurso para absorver a carga do nó perdido. Planeje o cluster para operar confortavelmente com um nó a menos — caso contrário, a recuperação automática apenas transfere o problema para os sobreviventes.

Onde entramos

A Solvefy/Cloud projeta e sustenta clusters Proxmox VE com HA e Ceph do zero: quórum, fencing, rede segregada e testes de falha reais. Parceiros oficiais Proxmox, cuidamos do ambiente para você focar no negócio.

Quer avaliar a resiliência do seu ambiente? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.