Proxmox VE: Como Configurar um Cluster de Alta Disponibilidade (HA) do Zero

Se você administra ambientes virtualizados com Proxmox VE e ainda não implementou um cluster de Alta Disponibilidade (HA), este guia foi feito para você. Em ambientes de produção, uma única máquina virtual rodando em um servidor isolado representa um ponto único de falha — e isso pode custar caro. Com um cluster HA bem configurado, o Proxmox garante que, caso um nó do cluster falhe, as VMs e containers sejam automaticamente migrados para outro nó, mantendo os serviços disponíveis.

Neste artigo da Armani Technology, vamos percorrer desde os requisitos mínimos de hardware e rede até a configuração completa do cluster, Corosync, fencing e grupos de HA. Você vai encontrar comandos reais, dicas de troubleshooting e boas práticas que usamos em nossos projetos de infraestrutura em nuvem para empresas.

O Que é Alta Disponibilidade (HA) no Proxmox VE?

Alta Disponibilidade, no contexto do Proxmox VE, é a capacidade do cluster de detectar automaticamente a falha de um nó e reiniciar as cargas de trabalho (VMs e CTs) em nós saudáveis — sem intervenção manual. Esse processo é orquestrado por dois subsistemas principais:

• Corosync: responsável pela comunicação entre nós e pelo controle de quorum do cluster.
• PVE HA Manager: monitora as VMs/CTs e decide quando e para onde migrar em caso de falha.

É importante entender que HA não é o mesmo que migração ao vivo (live migration). No failover de HA, a VM é reiniciada no outro nó — não migrada em memória. A Live Migration é usada para manutenção planejada, enquanto o HA é acionado em falhas não planejadas.

Para ambientes que exigem zero downtime planejado combinado com proteção contra falhas, o ideal é usar ambos: Live Migration para manutenção e HA ativado em todas as VMs críticas. Se você ainda tem dúvidas sobre qual estratégia adotar para seu ambiente, nossa equipe pode ajudar com uma consultoria especializada em TI.

Requisitos para Montar um Cluster HA no Proxmox VE

1. Requisitos de Hardware

O Proxmox HA exige no mínimo 3 nós para garantir quorum — com 2 nós, o cluster não consegue resolver eleições em caso de falha de um nó (split-brain). Para ambientes de produção, recomendamos:

• Mínimo: 3 nós físicos ou 3 VMs dedicadas (para labs)
• Recomendado: 3 a 5 nós com hardware idêntico ou similar
• RAM: Mínimo 16 GB por nó, recomendado 32 GB+
• CPU: x86_64 com suporte a virtualização (Intel VT-x ou AMD-V) habilitado na BIOS
• Storage compartilhado: Ceph, NFS, iSCSI ou Fibra — essencial para HA de VMs com estado

2. Requisitos de Rede

A rede é o componente mais crítico de um cluster Proxmox. Separe o tráfego em interfaces dedicadas:

• Interface de Cluster (Corosync): Rede privada de baixa latência (1 Gbps no mínimo, 10 Gbps recomendado). Nunca use a mesma interface de acesso dos usuários.
• Interface de Armazenamento: Rede separada para tráfego Ceph, iSCSI ou NFS
• Interface de Gerenciamento: Para acesso web (HTTPS) e SSH
• Latência máxima entre nós: < 5ms para Corosync (idealmente < 2ms)

3. Requisitos de Software

• Proxmox VE 8.x instalado em todos os nós
• Todos os nós com o mesmo fuso horário e hora sincronizada via NTP (chrony ou systemd-timesyncd)
• Resolução de nomes funcionando entre os nós (via /etc/hosts ou DNS interno)
• Repositório de atualizações configurado corretamente

Etapa 1 — Preparação dos Nós

1.1 Configurando /etc/hosts em Todos os Nós

Em cada nó, adicione os endereços de todos os membros do cluster. O Corosync depende de resolução de nomes estável:

# /etc/hosts — repita em todos os nós

192.168.10.10  pve-node01  pve-node01.armani.local

192.168.10.11  pve-node02  pve-node02.armani.local

192.168.10.12  pve-node03  pve-node03.armani.local

1.2 Sincronizando o Horário com NTP

Nós com horários dessincronizados causam problemas de quorum e certificados. Verifique e force a sincronização:

# Verificar status do NTP

timedatectl status

# Forçar sincronização imediata

chronyc makestep

# Conferir se todos os nós estão sincronizados

timedatectl show –property=NTPSynchronized

1.3 Atualizando Todos os Nós

Antes de criar o cluster, atualize todos os pacotes em cada nó:

apt update && apt dist-upgrade -y

# Reinicie se houver atualização de kernel

reboot

Etapa 2 — Criando o Cluster Proxmox

2.1 Criando o Cluster no Nó Primário

No primeiro nó (pve-node01), execute o comando de criação do cluster. Defina o endereço de rede que o Corosync usará para comunicação entre os nós:

# Substitua pelo IP da interface de cluster do nó primário

pvecm create armani-cluster –link0 192.168.10.10

Você pode usar múltiplos links para redundância de rede do cluster (recurso disponível no Proxmox VE 6.2+):

pvecm create armani-cluster –link0 192.168.10.10 –link1 10.10.10.10

2.2 Verificando o Status do Cluster

pvecm status

A saída deve mostrar o cluster com 1 nó e quorum: 1. Anote o “Cluster information” para referência.

2.3 Adicionando os Demais Nós

No pve-node02, execute o join apontando para o IP do nó primário. Será solicitada a senha root do nó01:

# Execute no pve-node02

pvecm add 192.168.10.10 –link0 192.168.10.11

# Execute no pve-node03

pvecm add 192.168.10.10 –link0 192.168.10.12

Após adicionar cada nó, verifique o status:

pvecm status

pvecm nodes

A saída de pvecm nodes deve listar os 3 nós como membros ativos do cluster.

Etapa 3 — Configurando Storage Compartilhado

O HA de VMs com estado exige storage compartilhado entre os nós — ou seja, todos os nós precisam ter acesso simultâneo ao disco da VM para que ela possa ser iniciada em qualquer nó após um failover. As opções mais comuns são:

Opção A: Ceph (Recomendado para Clusters Proxmox)

O Ceph é um storage distribuído que pode ser instalado diretamente nos nós Proxmox, eliminando a necessidade de um storage externo dedicado. É a opção mais robusta para clusters HA.

# Instalar Ceph em cada nó (via GUI ou CLI)

pveceph install –repository no-subscription

# Inicializar Ceph no primeiro nó

pveceph init –network 10.10.10.0/24

# Criar Monitor em cada nó

pveceph mon create

# Adicionar OSDs (um por disco de dados em cada nó)

pveceph osd create /dev/sdb

Opção B: NFS

Para ambientes que já possuem um servidor NFS dedicado, basta montar o share em todos os nós e adicioná-lo como storage no Proxmox:

# Adicionar NFS como storage no cluster (via GUI: Datacenter > Storage > Add > NFS)

# Ou via CLI:

pvesm add nfs nfs-shared –server 192.168.10.50 –export /mnt/nfs_proxmox –content images,backup

Opção C: iSCSI + LVM

Para storages SAN, adicione o target iSCSI e crie um Volume Group LVM sobre ele, depois exponha como LVM-Thin no Proxmox para melhor uso do espaço.

Etapa 4 — Configurando o Fencing (STONITH)

O fencing é o mecanismo mais crítico para o funcionamento correto do HA — e o mais negligenciado. Ele garante que um nó com falha de comunicação (mas que ainda pode estar rodando) seja desligado antes de outro nó assumir suas VMs, evitando corrupção de dados por dupla escrita no storage.

Sem fencing configurado, o Proxmox HA Manager não consegue garantir que o nó falho foi realmente desligado antes de iniciar as VMs em outro lugar. Em ambientes de produção, isso é crítico.

4.1 Opções de Fencing no Proxmox

• IPMI/iDRAC/iLO (Recomendado): Usa o interface de gerenciamento do servidor para forçar o desligamento. Funciona mesmo se o SO estiver travado.
• PVE Watchdog (mínimo aceitável): Usa o hardware watchdog da placa-mãe ou o softdog do kernel como mecanismo de fencing local.
• Fence via PDU (Power Distribution Unit): Controla a tomada elétrica do servidor remotamente.

4.2 Configurando o Hardware Watchdog (Softdog)

Se não houver IPMI disponível, configure ao menos o watchdog para ativar o fencing local:

# Carregar o módulo softdog

modprobe softdog

# Tornar permanente

echo “softdog” >> /etc/modules

# Habilitar o watchdog no Proxmox HA

# Edite /etc/pve/ha/resources.cfg (via GUI ou diretamente)

# Datacenter > HA > Resources > Add

4.3 Configurando IPMI Fencing (Recomendado)

Instale os utilitários fence e configure o agente IPMI:

apt install fence-agents -y

# Testar o fencing antes de ativar

fence_ipmilan -a 192.168.10.100 -l admin -p senha -o status

# Configurar como resource no cluster via Datacenter > HA > Fencing

Etapa 5 — Configurando o HA Manager

5.1 Ativando VMs no HA

Com o cluster e storage funcionando, ative o HA para VMs específicas. Faça isso pela GUI ou via linha de comando:

# Adicionar VM 100 ao HA com prioridade máxima

ha-manager add vm:100 –state started –max_restart 3 –max_relocate 1

# Verificar status do HA

ha-manager status

5.2 Criando Grupos de HA

Grupos de HA permitem definir em quais nós uma VM pode rodar e a preferência de nó. Isso é útil para garantir que VMs críticas fiquem no nó com mais recursos ou mais próximo do storage:

# Criar grupo via CLI

pvecm status  # confirme os nomes dos nós

# Via GUI: Datacenter > HA > Groups > Create

# Defina: nome do grupo, nós participantes e nó preferencial

Configurações relevantes de um grupo HA:

• nodes: lista de nós onde as VMs do grupo podem rodar (ex: pve-node01:2,pve-node02:1 — maior número = maior prioridade)
• restricted: se ativado, a VM só roda nos nós do grupo (não migra para nós fora do grupo)
• nofailback: evita que a VM retorne automaticamente ao nó original após sua recuperação

5.3 Verificando o Funcionamento do HA

# Status dos recursos HA

ha-manager status

# Logs do HA Manager

journalctl -u pve-ha-lrm -f

journalctl -u pve-ha-crm -f

# Status do Corosync

corosync-quorumtool -s

Etapa 6 — Testando o Failover de HA

Nunca confie em um cluster HA sem testá-lo em ambiente controlado antes de colocar em produção. Execute o seguinte procedimento de teste:

1. Identifique o nó onde uma VM HA está rodando com ha-manager status
2. Simule uma falha forçando o desligamento abrupto do nó: echo c > /proc/sysrq-trigger (em lab) ou desligue a energia fisicamente.
3. Observe nos logs do CRM nos outros nós como o failover é processado: journalctl -u pve-ha-crm -f
4. Verifique se a VM foi iniciada automaticamente em outro nó
5. Registre os tempos: detecção da falha, fencing e reinício da VM

Em ambientes típicos, o tempo total de failover (do crash ao reinício da VM em outro nó) varia de 2 a 5 minutos com fencing IPMI configurado corretamente.

Troubleshooting Mais Comum

Cluster sem quorum após adicionar nós

# Verificar estado do quorum

pvecm status

corosync-quorumtool -s

# Se cluster tiver apenas 2 nós e quorum estiver quebrado:

pvecm expected 1   # USE COM CAUTELA — apenas em emergência

Nó aparece como OFFLINE mas está rodando

Verifique se o Corosync está ativo no nó e se a rede de cluster está acessível entre os nós:

systemctl status corosync

ping 192.168.10.11  # IP do nó problemático via interface de cluster

journalctl -u corosync –since “1 hour ago”

VM não faz failover mesmo com HA ativo

Confirme que o fencing está funcionando e que o storage é realmente compartilhado:

ha-manager status  # Verifique o estado da VM

pvesm status        # Verifique o storage

journalctl -u pve-ha-crm -n 100

Split-brain: dois nós acreditam ser primários

Situação crítica. Nunca force quorum manualmente sem antes garantir que todas as VMs foram paradas nos nós problemáticos. O fencing existe exatamente para evitar esse cenário automaticamente.

Boas Práticas para Clusters HA em Produção

• Sempre use número ímpar de nós (3, 5, 7) para garantir quorum matemático.
• Documente todos os IPs e funções de rede antes de iniciar a configuração.
• Mantenha os nós sempre atualizados — falhas de HA frequentemente têm origem em bugs já corrigidos.
• Monitore o cluster com ferramentas externas — não confie apenas na GUI do Proxmox para alertas críticos.
• Faça backups regulares das VMs mesmo com HA ativo. HA protege contra falha de nó, não contra corrupção de dados.
• Teste o failover a cada mudança significativa na infraestrutura (atualização de kernel, troca de hardware, mudança de storage).

Para complementar sua estratégia de resiliência, leia também nosso artigo sobre Disaster Recovery e Backup: sua empresa precisa dos dois? — onde discutimos como HA e backup se complementam para garantir continuidade de negócios.

Proxmox HA vs VMware vSphere HA: Vale a Migração?

Com o aumento expressivo dos custos de licenciamento VMware após a aquisição pela Broadcom, muitas empresas estão avaliando o Proxmox como alternativa. Do ponto de vista de HA, ambas as plataformas oferecem recursos equivalentes para a maioria dos ambientes corporativos:

Se sua empresa está considerando uma migração do VMware para o Proxmox, nossa equipe da Armani Technology tem experiência em projetos de migração sem downtime. Fale com um especialista e avalie a viabilidade para o seu ambiente.

Integrando HA com Backup: A Estratégia Completa

Um cluster HA protege contra falhas de hardware, mas não substitui o backup. Se um administrador deletar acidentalmente uma VM, ou se os dados forem corrompidos por um ransomware, o HA não vai te salvar — porque todos os nós terão a mesma visão corrompida do storage.

A estratégia correta combina:

• HA no cluster: para proteger contra falha de hardware de um nó
• Backup com PBS (Proxmox Backup Server): para recuperação pontual de dados e VMs
• Replicação entre sites: para proteção geográfica (Proxmox suporta replicação nativa de VMs entre clusters em localidades diferentes)

Para entender melhor a diferença entre estratégias de proteção de dados, leia nosso artigo: Disaster Recovery e Backup: sua empresa precisa dos dois?. Também recomendamos nosso guia sobre Nuvem Híbrida para Empresas para entender como ambientes on-premises e nuvem podem coexistir de forma complementar.

Se o seu ambiente exige backup gerenciado e seguro, conheça nossa solução de Backup em Nuvem com Acronis — compatível com ambientes Proxmox e com proteção contra ransomware integrada.

Referências e Documentação Oficial

Documentação Oficial do Proxmox VE — High Availability

Proxmox VE 8.x — Cluster Manager Documentation

Corosync Cluster Engine — Projeto Oficial

Proxmox Ceph Integration Guide

Fence Agents — Documentação Red Hat

🚀 Precisa de ajuda para implantar um cluster Proxmox HA no seu ambiente?
A Armani Technology tem experiência em projetos de virtualização com Proxmox VE para empresas de todos os portes. Desde o planejamento da arquitetura até a implantação, monitoramento e suporte contínuo — cuidamos de tudo para que você foque no seu negócio.