Marcio Cunha

Como configurar alta disponibilidade e failover no Proxmox

Aprenda a estruturar um cluster Proxmox com alta disponibilidade para garantir migração transparente de máquinas virtuais e containers em falhas de hardware.

Marcio Cunha•4 min
Também disponível em:EspañolEnglish
Resumo
  • Clusters Proxmox dependem do Corosync para monitorar a saúde dos nós de forma síncrona
  • O subsistema PVE-HA migra workloads automaticamente quando um servidor físico cai
  • Quórum exige maioria de nós ativos para evitar o temido cenário de brain-split
  • Fencing com STONITH garante que nós travados sejam desligados antes da migração
  • Armazenamento compartilhado via Ceph ou NFS viabiliza o acesso contínuo aos discos

O que é alta disponibilidade e como o Proxmox protege seus dados

Quando gerenciamos servidores de virtualização, o maior pesadelo é a falha repentina de hardware. Um processador que queima ou uma placa-mãe que desliga do nada pode derrubar dezenas de sistemas críticos em segundos. Na prática, isso significa que a alta disponibilidade (ou HA) atua como um mecanismo de salvamento automático, detectando quedas físicas e religando as máquinas afetadas em outro servidor do grupo. No Proxmox, essa mágica operacional combina virtualização de ponta com ferramentas consagradas de cluster aberto, como detalhamos em nossa base sobre como sincronizar nós no Proxmox com alta latencia para manter a integridade operacional mesmo sob estresse de rede.

Entendendo a arquitetura de cluster e a importância do quórum

Para que um ambiente de failover funcione sem intervenção humana, precisamos de pelo menos três servidores físicos trabalhando em conjunto, formando um cluster. O coração dessa comunicação é o Corosync, um serviço de mensagens em tempo real que envia sinais contínuos de pulsação entre os nós para verificar quem está vivo. Esse ecossistema garante também a segurança do tráfego interno, evitando que problemas de roteamento comprometam a infraestrutura, algo semelhante aos cuidados que tomamos ao isolar falhas de rede em containers com iptables para blindar ambientes produtivos. Sem essa troca constante de sinais, o sistema não saberia quando um colega de rede sofreu uma pane elétrica ou se apenas perdeu a conexão temporariamente.

Evitando o cérebro partido com cercamento de nós ou STONITH

Um dos maiores perigos em sistemas distribuídos é o cenário de brain-split, onde o cluster se divide em duas metades isoladas que passam a achar, cada uma por si, que são a autoridade máxima. Para impedir que dois servidores tentem escrever nos mesmos discos virtuais simultaneamente corrompendo tudo, o Proxmox utiliza o conceito de fencing. O termo técnico STONITH, que significa disparar contra a cabeça do nó morto na sigla em inglês, representa dispositivos físicos ou lógicos de energia que desligam à força a máquina travada antes de liberar sua migração. Na prática, o sistema prefere isolar e desligar um servidor suspeito de forma drástica a permitir que dados corrompidos destruam sua base de clientes.

Configurando o armazenamento compartilhado para migração sem perdas

De nada adianta transferir uma máquina virtual para um novo servidor se ela não conseguir enxergar os mesmos arquivos de disco que usava antes. É por isso que o failover automático exige uma camada de armazenamento compartilhado, como clusters Ceph, storages NFS ou SANs dedicadas baseadas em blocos. Quando ocorre uma pane no host original, o novo servidor assume a máquina virtual montando exatamente os mesmos volumes de disco instantaneamente. Para garantir que essa infraestrutura de armazenamento e resiliência física suporte picos de consumo elétrico sem quedas catastróficas, muitos administradores adotam redundâncias elétricas inspiradas em princípios de como projetar fontes N+1 em servidores blade, garantindo estabilidade ponta a ponta.

Passo a passo para ativar o recurso de HA no painel do Proxmox

Depois de estruturar o cluster com três nós e configurar o armazenamento compartilhado, habilitar o failover automatizado exige apenas alguns ajustes na interface web ou via terminal. O processo a seguir demonstra os comandos básicos de gerenciamento de recursos de alta disponibilidade usando a ferramenta de linha de comando oficial do Proxmox.

  1. Verifique o status atual do cluster e confirme se todos os nós estão visíveis executando o comando de checagem no terminal:
    pvecm status
  2. Adicione a máquina virtual ou o container desejado ao grupo de gerenciamento de alta disponibilidade definindo a política padrão:
    ha-manager add vm:100 -state started
  3. Confirme se o recurso foi integrado com sucesso na tabela de monitoramento contínuo de HA do Proxmox:
    ha-manager status

Monitorando e testando o failover na prática

Configurar a ferramenta é apenas metade do trabalho; validar a resiliência em um ambiente controlado é o que separa um sistema confiável de uma promessa vazia. Realize testes simulados desligando a tomada de um dos nós físicos do cluster enquanto executa cargas de trabalho nas máquinas virtuais convidadas. O ecossistema deve identificar a ausência de resposta em poucos segundos, isolar o nó comprometido, liberar os recursos de disco e reiniciar os serviços no servidor saudável adjacente. Esse processo automatizado reduz o tempo de inatividade de horas para poucos minutos, blindando sua operação contra imprevistos de hardware.

Considerações finais sobre resiliência e manutenção preventiva

Implementar alta disponibilidade com Proxmox transforma uma infraestrutura frágil em um ambiente robusto capaz de absorver falhas físicas sem pânico operacional. Embora o failover automático resolva incidentes inesperados, ele não substitui a necessidade de rotinas rigorosas de backup externo e monitoramento proativo de temperatura e desgaste de discos. Manter os firmwares atualizados e testar regularmente os disparos de fencing garante que o cluster reaja exatamente como planejado quando o pior acontecer na sua sala de servidores.