Alta disponibilidade e cluster no Proxmox

Um único servidor é um único ponto de falha. Não importa quanto ele custou nem quantas fontes redundantes tenha: uma placa-mãe queimada derruba tudo o que está nele. Quando a operação não pode parar, a resposta é cluster com alta disponibilidade — e o Proxmox entrega isso sem software adicional nem licença extra.

O que é um cluster

Vários servidores Proxmox, chamados de nós, trabalham como um só. A configuração é replicada entre todos, e uma interface web única gerencia o conjunto — você acessa qualquer nó e enxerga o ambiente inteiro.

Só isso já traz ganhos, mesmo sem alta disponibilidade ligada: gerência centralizada, migração de VMs entre nós, backup unificado e controle de acesso comum.

Como a HA age

Com alta disponibilidade configurada, se um nó falha, o cluster detecta a ausência e reinicia automaticamente as VMs afetadas em outro nó saudável. O serviço volta em poucos minutos, sem ninguém precisar acordar às três da manhã.

É importante entender o que isso significa exatamente: a VM é reiniciada, não transferida em funcionamento. Quem estava conectado cai, transações em andamento se perdem e o sistema sobe como depois de uma queda de energia. A HA reduz a indisponibilidade de horas para minutos — ela não a elimina.

Quórum: por que três nós

O quórum resolve isso pela matemática simples da maioria. Com três nós, quem enxerga pelo menos dois tem a maioria e pode operar; o nó isolado sabe que está em minoria e se cala. Para quem só tem dois servidores, existe o QDevice: um terceiro voto rodando em uma máquina modesta, que não hospeda VMs e só participa da decisão.

O armazenamento compartilhado

Para uma VM subir em qualquer nó, seus dados precisam estar acessíveis a todos. Sem storage compartilhado não há HA de verdade. As opções:

A terceira opção merece cuidado. Ela é barata e funciona, mas a recuperação volta ao estado da última replicação — se ela roda de 15 em 15 minutos, você pode perder até 15 minutos de trabalho. Para alguns sistemas isso é aceitável; para um ERP com lançamentos contínuos, geralmente não é.

A rede do cluster

É a parte mais negligenciada e a que mais causa problema. A comunicação entre nós é sensível a latência: se ela oscila, o cluster acha que perdeu um nó e pode disparar uma migração desnecessária — derrubando VMs que estavam funcionando.

Recomendações que evitam isso:

• Rede dedicada para a comunicação do cluster, separada do tráfego das VMs;
• Um segundo caminho configurado como anel redundante, para que a queda de um switch não isole nós;
• Rede separada e rápida para Ceph, se for usá-lo — 10 Gbps é o mínimo razoável;
• Relógios sincronizados por NTP em todos os nós. Diferença de horário entre nós causa comportamento errático e difícil de diagnosticar.

Fencing: o detalhe que evita o desastre

Antes de reiniciar uma VM em outro nó, o cluster precisa ter certeza de que ela não está rodando no nó original. Se estiver, e ambas escreverem no mesmo disco, os dados se corrompem.

O Proxmox usa um mecanismo de auto-isolamento: um nó que perde o quórum se reinicia sozinho dentro de um tempo determinado. Só depois desse prazo o cluster libera a subida das VMs em outro lugar. É por isso que a recuperação leva alguns minutos e não é instantânea — essa espera é proposital e protege seus dados.

Nem tudo precisa de HA

Ligar alta disponibilidade para todas as VMs é um erro comum. Cada máquina em HA consome recursos reservados em outro nó e adiciona complexidade. Vale separar:

• Com HA: ERP, banco de dados, e-mail, controlador de domínio, firewall — o que para a empresa quando cai;
• Sem HA: homologação, laboratório, ferramentas internas, ambientes de teste.

Dimensione também a folga: se você tem três nós e quer sobreviver à perda de um, os três juntos não podem estar usando mais de dois terços da capacidade total. Um cluster com os três nós lotados não tem para onde migrar quando um cai.

Teste antes de precisar

Um cluster de HA que nunca foi testado é uma suposição cara. O teste é direto: em horário combinado, desligue um nó na tomada — não pelo menu, porque desligamento limpo não simula falha real — e cronometre.

Observe se as VMs subiram no outro nó, quanto tempo levaram, se todos os serviços iniciaram na ordem certa e se alguém foi avisado pelo monitoramento. Depois, religue e confira se o nó volta ao cluster sozinho.

Esse teste costuma revelar coisas úteis: uma VM que não estava no grupo de HA, um serviço que não iniciava automaticamente, um alerta que não chegava a ninguém.

Vale a pena?

Para sistemas onde cada hora parada custa caro — ERP, e-mail, banco de dados, emissão de nota fiscal — o investimento se paga na primeira falha que passa despercebida pelos usuários.

Para empresas cuja operação tolera algumas horas de parada, um servidor único com backup bem feito e testado pode ser a escolha mais sensata: custa uma fração, exige menos manutenção e resolve o cenário que realmente acontece com mais frequência.

A TRIAT ajuda a fazer essa conta com o custo real da parada e implanta o que ela indicar — do servidor único bem protegido ao cluster com storage redundante.