Você já ouviu aquela frase assustadora: "O Proxmox HA funciona magicamente"? Se você acredita nisso, prepare-se para uma dor de cabeça. A alta disponibilidade não é mágica; é engenharia de restrições. Um cluster Proxmox mal configurado para High Availability (HA) não evita downtime; ele apenas espalha o problema por vários nós, criando um cenário de "split-brain" onde duas instâncias competem pelos mesmos recursos, corrompendo dados e travando serviços críticos.

Muitos administradores de sistemas subestimam a complexidade por trás do simples botão "Enable HA". Eles esquecem que o Proxmox VE é um sistema operacional completo com requisitos rigorosos de latência de rede, sincronismo de clock e recursos de disco. Ignorar as regras básicas não resulta em um cluster inativo; resulta em um cluster ativo, mas instável, onde as VMs reiniciam em loop infinito ou falham silenciosamente.

Neste post:

O que é Proxmox HA e por que ele falha?

A alta disponibilidade no Proxmox não é apenas sobre mover uma máquina virtual de um servidor para outro quando o hardware falha. É sobre garantir que, diante de uma interrupção, o serviço continue rodando em um nó saudável, minimizando a janela de indisponibilidade. No entanto, esse mecanismo depende inteiramente da confiança mútua entre os nós do cluster Proxmox.

O módulo HA funciona como um agente distribuído. Cada nó monitora os outros. Se o nó A não consegue comunicar com o nó B por um período determinado (definido pela variável ha-manager), ele assume que B caiu e inicia as VMs que estavam nele. O problema surge quando essa comunicação falha temporariamente, mas os nós ainda estão vivos. Isso é chamado de partição de rede.

Se você não definir restrições claras, o cluster pode entrar em pânico. Sem as regras HA adequadas, você corre o risco de:

  • Split-Brain (Cérebro Dividido): Dois grupos de nós acreditam ser o grupo principal e tentam acessar o mesmo disco compartilhado simultaneamente, corrompendo o sistema de arquivos.
  • Falhas em Cascata: Um nó sobrecarregado tenta iniciar uma VM pesada e falha, fazendo com que outros nós assumam a carga até colapsarem também.
  • Recursos Inutilizáveis: VMs marcadas como HA, mas sem disco acessível em todos os nós, ficam em estado "Stopped" indefinidamente.

A solução não é desativar o HA, mas sim entender e impor limites rígidos. A virtualização moderna exige disciplina operacional.

Reregulas de rede: O sistema nervoso do cluster

A rede é o ponto único de falha mais comum em clusters HA. As regras de comunicação entre os nós são não negociáveis. Se a rede falha, o HA falha.

Primeiro, a latência. O Proxmox exige que a latência entre os nós do cluster seja inferior a 5ms (idealmente < 1ms) e sem perda de pacotes. Isso se aplica especificamente à interface utilizada para o tráfego de cluster e armazenamento. Não use a mesma interface pública para gerenciar o cluster, gerenciar o storage e servir as VMs clientes.

Segundo, a redundância física. Para um setup verdadeiramente HA, você deve ter links de rede redundantes. Se o switch principal cair, os nós precisam continuar se comunicando via link secundário. O Proxmox suporta bonding (agregação de links) para garantir essa resiliência.

Além disso, o tempo de sincronização é crítico. Todos os nós devem estar sincronizados via NTP (Network Time Protocol). Uma diferença de tempo superior a 1 segundo entre os nós pode causar falhas na replicação do banco de dados Corosync e no acesso ao armazenamento, invalidando as restrições de segurança do cluster.

Dica Pro: Monitore a latência da interface de cluster 24/7. Um pico de latência de 10ms por alguns segundos pode ser suficiente para o módulo HA considerar um nó como "down", iniciando uma migração desnecessária e causando jitter nas suas aplicações.

Restrições de armazenamento: O coração do problema

O armazenamento compartilhado é o requisito fundamental para o HA. Se as VMs residem em discos locais (local-lvm, local-zfs), o HA é inútil, pois nenhum outro nó pode acessar esses dados.

As regras aqui são claras:

  1. Acessibilidade Global: O datastore (Ceph, NFS, iSCSI, GlusterFS) deve ser montado e acessível por todos os nós do cluster onde a VM pode rodar.
  2. Permissões Corretas: As permissões de disco no storage devem permitir escrita por todos os nós. No caso do Ceph, isso é automático se configurado corretamente; no NFS, você precisa garantir que o export permita acesso "rw" para as redes dos nós.
  3. Capacidade de Failover: Você precisa ter espaço livre suficiente em todos os nós remanescentes para acomodar a VM falhada. Se a VM ocupa 100GB e o nó restante tem apenas 50GB livres, o HA não conseguirá iniciá-la.

Um erro comum é confiar em snapshots locais como backup para o HA. Snapshots não são alta disponibilidade; são um estado pontual do disco. Para o HA funcionar, o disco deve estar disponível no momento da falha.

Regras para VMs e LXC Containers

Nem toda máquina virtual deve ter HA ativado. Ativar HA indiscriminadamente pode sobrecarregar o cluster. Existem regras específicas para decidir quais workloads merecem proteção:

  • VMs de Produção Críticas: Servidores web, bancos de dados, ERPs e sistemas de controle que não podem parar.
  • LXC Containers Leves: Containers Linux são mais rápidos para reiniciar. Se o container está configurado com "on-fail: restart", ele pode ser iniciado rapidamente em outro nó.
  • Recursos Reservados: VMs com HA devem ter recursos de CPU e RAM reservados (reservations) definidos no cluster. Isso garante que, quando o failover ocorrer, o nó destino tenha a garantia de poder alocar esses recursos sem disputa com outras VMs.

Por outro lado, evite colocar no HA:

  • VMs de teste ou desenvolvimento.
  • Máquinas que dependem de hardware específico (ex: GPU PCIe passthrough) que não está disponível em todos os nós do cluster.
  • VMs com discos locais únicos.

Erros comuns na configuração de HA

Ainda que você conheça as regras, a implementação prática está cheia de armadilhas. Aqui estão os erros mais frequentes que vemos em ambientes corporativos:

Erro Consequência Solução
Cluster com menos de 3 nós Falta de quorum (maioria). Se um nó cair, o restante não sabe se deve assumir o controle. Sempre use um número ímpar de nós (3, 5, 7) para garantir quorum.
Ignorar o Quorum Disk Em clusters de 2 nós, a falha de um nó quebra o quorum do outro, paralisando o cluster. Configure um Quorum Device (como um Quorum Disk ou Vote Server externo) para desempatar.
HA sem Storage Compartilhado O nó tenta iniciar a VM, mas falha porque o disco não está disponível. Verifique a conectividade ao storage antes de ativar o HA.
Migrações Manuais vs. HA Confusão entre Live Migration (vzdump/migrate) e Failover Automático. O HA só atua em falhas de nó ou desligamento forçado do serviço, não em reinícios manuais.

Outro ponto crucial é a configuração do ha-manager. Os parâmetros enabled, enabled-migrate e as configurações de max-restart devem ser ajustados. Por exemplo, definir max-restart muito alto pode fazer o cluster tentar reiniciar uma VM defeituosa infinitamente, consumindo recursos do sistema.

Perguntas frequentes

O Proxmox HA funciona com apenas 2 nós?

Tecnicamente sim, mas é altamente desencorajado. Com 2 nós, se um deles cair, o nó restante perde o quorum (maioria dos votos) e entra em estado de espera, impedindo que ele inicie as VMs sozinho. Isso anula a alta disponibilidade. Para 2 nós, você precisa obrigatoriamente configurar um Quorum Device externo (como um servidor dedicado pequeno ou um disco USB conectado a um dos nós) para atuar como árbitro e manter o quorum ativo.

A diferença entre Live Migration e HA é apenas a velocidade?

Não. A migração ao vivo (Live Migration) é uma operação planejada, iniciada manualmente ou por balanceamento de carga (HAMove), que transfere a VM com zero downtime enquanto os dois nós estão online. O HA (Failover) é uma resposta a uma falha catastrófica (nó desligado, crash do kernel). No HA, há um downtime inevitável, pois a VM precisa ser reiniciada ("booted") no nó de destino, o que leva segundos ou minutos dependendo do sistema operacional convidado.

Posso usar HA para VMs Windows?

Sim. O Proxmox trata VMs Windows e Linux da mesma forma em nível de hipervisor. No entanto, para maximizar a disponibilidade, recomenda-se instalar o Proxmox Agent dentro do Windows. Isso permite que o cluster saiba exatamente quando o sistema operacional convidado está travado (mesmo que o nó físico esteja vivo) e force um reinício mais limpo da VM, evitando corrupção de dados.

O que acontece se eu desligar um nó manualmente?

Se você desligar um nó pelo comando shutdown -h, o módulo HA detectará a parada do serviço e iniciará as VMs nos outros nós, conforme configurado. Isso é intencional e seguro. No entanto, se você apenas desconectar a energia (pull the plug), o Proxmox tentará iniciar as VMs assim que o nó voltar, mas pode haver conflito de disco se o storage não for configurado para exclusão mútua (ex: Ceph com cluster-fsid correto). Sempre use desligamento ordenado quando possível.

Como saber se meu cluster HA está saudável?

Você pode verificar o status no painel web em "Datacenter" > "HA". O ícone verde indica que todas as VMs estão rodando nos nós esperados. Você também pode usar a CLI: ha-manager status. Se houver erros, eles aparecerão como "Failed" ou "Stopped". Verifique também os logs do sistema em /var/log/pveha para entender por que uma VM não foi iniciada.

Conclusão

Configurar o proxmox ha vai muito além de clicar em um botão. É um exercício de arquitetura de infraestrutura que exige respeito pelas restrições de rede, armazenamento e recursos. Um cluster bem planejado protege seu negócio contra falhas de hardware; um mal planejado cria ilusões de segurança que se quebram no momento mais crítico.

A regra de ouro é: comece simples. Tenha pelo menos 3 nós, storage compartilhado robusto (como Ceph ou NFS com redundância) e monitore a latência da rede. Não adicione complexidade desnecessária antes de validar o básico.

Se você está avaliando como estruturar sua infraestrutura de virtualização sem se preocupar com a camada física, lembre-se que a expertise em alta disponibilidade faz toda a diferença entre um downtime de minutos e uma paralisação de dias. Na Toda Solução, entendemos que a tecnologia é apenas uma parte da equação; a estratégia por trás dela é o que garante a continuidade do seu negócio. Conte com profissionais que falam a língua da infraestrutura para transformar sua VM em um ativo resiliente.