Um único nó Proxmox é suficiente para muita coisa. Mas chega um momento em que você precisa de mais: mais capacidade, manutenção sem downtime, ou a tranquilidade de saber que se um servidor morrer às 3h da manhã, as VMs vão subir em outro lugar sozinhas.

Esse post cobre o cluster Proxmox do jeito que ele realmente funciona. O post anterior sobre Proxmox além do basicão toca em Ceph, que é uma das opções de storage compartilhado para cluster. Aqui o foco é na camada de cluster e alta disponibilidade em si.

⚠️ O que você vai encontrar em outros tutoriais: instruções para instalar pacemaker e corosync via apt e editar /etc/corosync/corosync.conf na mão. Isso é o jeito errado para Proxmox. O Proxmox tem sua própria stack de cluster (pvecm, pve-ha-manager) que gerencia o corosync internamente. Não mexa no corosync.conf diretamente.

O que compõe o cluster Proxmox

Antes de criar qualquer coisa, vale entender o que está rodando por baixo:

Corosync faz a comunicação entre os nós: heartbeat, eleição de quorum, propagação de estado. O Proxmox já instala e gerencia o corosync automaticamente via pvecm. Você não precisa e não deve instalar o pacote corosync manualmente.

pmxcfs (Proxmox Cluster File System) é um filesystem distribuído em memória, sincronizado via corosync, que armazena a configuração do cluster em /etc/pve/. Quando você adiciona um nó ao cluster, a configuração se propaga automaticamente.

pve-ha-manager é o gerenciador de alta disponibilidade. É ele que decide quando reiniciar uma VM em outro nó após uma falha, não o pacemaker.

Requisitos antes de começar

Rede:

• Todos os nós precisam se comunicar entre si via hostname (configure /etc/hosts em cada um ou use DNS)
• Recomendado: uma interface de rede dedicada para tráfego de cluster (separada da rede de VMs e da rede de storage)
• Latência baixa entre os nós. Cluster Proxmox não funciona bem sobre WAN

Nós:

• Mínimo 3 nós para HA com quorum seguro
• Com 2 nós: precisa de um QDevice externo para desempate (ver adiante)
• Todos os nós devem ter a mesma versão maior do Proxmox

Storage:

• Para live migration funcionar, os nós precisam de acesso ao mesmo storage
• Opções: NFS, iSCSI, Ceph (configurado no Proxmox além do basicão), ou Proxmox Backup Server para backup

Criando o cluster

No primeiro nó (só nele):

pvecm create nome-do-cluster

# Confirmar que está ativo
pvecm status
# Deve mostrar: Quorum information, Nodes: 1, Quorate: Yes

Nos outros nós, um de cada vez:

# Substituir pelo IP do primeiro nó
pvecm add 192.168.1.10

# Vai pedir a senha de root do nó principal
# Depois de aceitar, confirmar
pvecm status

⚠️ Antes de adicionar um nó ao cluster: certifique-se de que ele não tem VMs importantes em execução com IDs que colidam com os outros nós. Depois que entra no cluster, a configuração do pmxcfs é sobrescrita pela do cluster.

Verificar o estado do cluster:

pvecm status         # estado geral e quorum
pvecm nodes          # listar nós
corosync-quorumtool  # detalhe técnico do quorum

Quorum: o conceito mais importante do cluster

Quorum é o mecanismo que evita o "split-brain" — situação onde dois grupos de nós acham que são o cluster real e tomam decisões conflitantes (como subir a mesma VM em dois lugares ao mesmo tempo).

A regra básica: o cluster só opera se tiver mais da metade dos votos. Com 3 nós (3 votos), precisa de pelo menos 2 para ter quorum. Se um nó cair, os outros 2 ainda têm maioria e o cluster continua funcionando. Se dois caírem, o nó restante não tem maioria e para de operar.

# Ver configuração de quorum
cat /etc/pve/corosync.conf | grep -A5 quorum

# Estado atual de quorum
pvecm status | grep Quorate
# Quorate: Yes = cluster operando normalmente
# Quorate: No = cluster parou por falta de quorum

O problema com 2 nós

Com apenas 2 nós, qualquer falha em um coloca o outro sem quorum (1 de 2 votos não é maioria). Para resolver isso sem precisar de um terceiro servidor completo, o Proxmox suporta um QDevice: um processo leve rodando em qualquer máquina Linux (pode ser um Raspberry Pi, um container, uma VM) que participa do quorum como árbitro sem hospedar VMs.

# No nó árbitro (qualquer Debian/Ubuntu com corosync-qnetd)
apt install corosync-qnetd

# Em qualquer nó do cluster de 2 nós
pvecm qdevice setup 192.168.1.99  # IP do árbitro

Com QDevice, o cluster de 2 nós passa a ter 3 votos (1 por nó + 1 do árbitro). Qualquer nó que cair, o outro ainda tem maioria (2 de 3).

Storage compartilhado: a base da live migration

Live migration funciona assim: o estado da CPU e memória da VM é transferido para o nó destino enquanto a VM continua rodando. Para isso funcionar, o disco da VM precisa estar acessível de qualquer nó do cluster.

NFS (mais simples de configurar)

# No servidor NFS (pode ser um NAS, outro servidor, etc.)
# /etc/exports:
/mnt/vms  192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

# Nos nós Proxmox: adicionar o NFS como storage
# Datacenter → Storage → Add → NFS
pvesm add nfs nas-vms \
  --server 192.168.1.200 \
  --export /mnt/vms \
  --path /mnt/pve/nas-vms \
  --content images,iso,vztmpl

Ceph (melhor para clusters nativos)

Com Ceph configurado conforme o Proxmox além do basicão, o storage já está disponível em todos os nós automaticamente. Não precisa de configuração adicional para live migration.

iSCSI + LVM

# Adicionar target iSCSI
pvesm add iscsi iscsi-san \
  --portal 192.168.1.201 \
  --target iqn.2024-01.com.empresa:storage

# Criar pool LVM sobre o LUN iSCSI
pvesm add lvmthin thin-vms \
  --vgname vg-san \
  --thinpool thin-pool \
  --content images

Live migration na prática

Com storage compartilhado configurado e cluster funcionando, live migration é simples:

# Migrar VM 100 para o nó pve2 (online, sem downtime)
qm migrate 100 pve2 --online

# Migrar container LXC 200
pct migrate 200 pve2 --online

# Se não tiver storage compartilhado, migração offline com cópia de disco
qm migrate 100 pve2 --with-local-disks
# A VM fica offline durante a cópia do disco

Via UI: clique com botão direito na VM, Migrate, escolha o nó destino.

O tempo de downtime em live migration com storage compartilhado é tipicamente menor que 1 segundo. O que acontece por baixo:

1. Proxmox começa a copiar páginas de memória da VM para o nó destino em background
2. As páginas modificadas durante a cópia são sincronizadas iterativamente
3. Quando a taxa de modificação fica baixa o suficiente, a VM é brevemente pausada
4. O estado restante é transferido e a VM retoma no nó destino
5. O nó original libera os recursos

# Acompanhar migração em andamento
qm monitor 100
# No prompt do monitor:
info migrate

Alta Disponibilidade com ha-manager

HA no Proxmox não é automático. Você precisa configurar explicitamente quais VMs/containers devem ter HA habilitado. O pve-ha-manager monitora essas VMs e reinicia em outro nó se o nó atual falhar.

Habilitando HA em uma VM

# Via CLI
ha-manager add vm:100 \
  --state started \
  --max_restart 3 \
  --max_relocate 1

# Listar recursos com HA
ha-manager status

# Ver estado dos recursos
ha-manager crm-command status

Via UI: VM Options → HA.

HA Groups: controlar onde as VMs podem rodar

Grupos definem em quais nós uma VM pode ser iniciada em caso de failover:

# Criar grupo com prioridade (nós preferidos primeiro)
ha-manager groupadd producao \
  --nodes pve1:2,pve2:1,pve3:1 \
  --restricted 0  # 0 = pode migrar para qualquer nó se os do grupo falharem
                  # 1 = só os nós do grupo

# Associar VM ao grupo
ha-manager add vm:100 --group producao --state started

O que acontece quando um nó cai

1. Os outros nós param de receber heartbeat do nó morto
2. Após o timeout de fence (padrão: 60 segundos), o cluster considera o nó morto
3. O fencing é executado para garantir que o nó realmente parou (evitar split-brain)
4. O pve-ha-manager inicia as VMs com HA em outro nó disponível

O timeout inteiro costuma ser entre 2 e 5 minutos dependendo da configuração.

Fencing: o mecanismo mais importante do HA

Fencing é o processo de garantir que um nó que parou de responder foi realmente desligado antes de subir suas VMs em outro lugar. Sem fencing, você corre o risco de ter a mesma VM rodando em dois nós ao mesmo tempo (e corrompendo dados).

O Proxmox usa dois mecanismos de fencing:

Watchdog (padrão): cada nó tem um processo watchdog que precisa ser alimentado periodicamente. Se o nó perder comunicação com o cluster, o watchdog para de ser alimentado e reinicia o servidor automaticamente. O Proxmox configura isso automaticamente com /dev/watchdog.

# Verificar se o watchdog está ativo
systemctl status pve-ha-crm
cat /sys/class/watchdog/watchdog0/identity  # deve mostrar o driver ativo

IPMI/STONITH (mais confiável para produção): usa o IPMI/iDRAC/iLO do servidor para forçar desligamento via rede, independente do estado do SO:

# Instalar fence agents
apt install fence-agents

# Configurar fence via IPMI
# Datacenter → HA → Fencing

# Testar o fence (CUIDADO: desliga o nó)
fence_ipmilan -a 192.168.1.10 -u ADMIN -p senha -o status

🔥 Na prática: para homelab com hardware comum sem IPMI, o watchdog funciona bem. Para produção com servidores Dell/HP/Supermicro, configure IPMI também como camada adicional.

Manutenção de nós sem downtime

Para atualizar ou fazer manutenção em um nó sem afetar as VMs:

# 1. Colocar o nó em modo de manutenção (migra as VMs automaticamente)
# Via UI: Node → Shell:
ha-manager crm-command node-maintenance enable pve1

# 2. Ou migrar manualmente cada VM primeiro
qm migrate 100 pve2 --online
qm migrate 101 pve3 --online

# 3. Fazer a manutenção (atualizar pacotes, trocar hardware, etc.)
apt dist-upgrade

# 4. Reiniciar se necessário
reboot

# 5. Reativar o nó
ha-manager crm-command node-maintenance disable pve1

Para atualização simples de pacotes sem reboot, o Proxmox tem suporte a live patch do kernel via /usr/sbin/pve-kernel-update (em versões enterprise).

Troubleshooting de cluster

# Nó não consegue entrar no cluster
# Verificar se a porta 5405 (corosync UDP) está aberta
ss -ulnp | grep 5405
# Firewall bloqueando?
iptables -L INPUT | grep 5405

# Cluster perdeu quorum
# Opção nuclear: forçar quorum com o nó atual (PERIGOSO em produção)
pvecm expected 1

# Ver logs do cluster em tempo real
journalctl -u pve-cluster -f
journalctl -u corosync -f
journalctl -u pve-ha-crm -f

# Estado detalhado do HA
ha-manager status --verbose

# Remover nó do cluster (nó precisa estar offline ou inacessível)
pvecm delnode pve3

Reconstruindo um nó problemático

Se um nó corrompeu e precisa ser reinstalado:

# 1. No cluster (nos outros nós), remover o nó problemático
pvecm delnode pve3

# 2. Reinstalar o Proxmox no nó problemático do zero

# 3. Re-adicionar ao cluster
pvecm add 192.168.1.10  # IP de qualquer nó ativo

As VMs que estavam no nó reinstalado precisam ser registradas novamente (se tinham storage local) ou já aparecem disponíveis (se tinham storage compartilhado).

Conclusão

Cluster Proxmox bem configurado resolve dois problemas ao mesmo tempo: você faz manutenção sem downtime e tem recuperação automática de falhas. O segredo é fazer direito desde o começo: storage compartilhado configurado antes de habilitar HA, fencing funcionando, e quorum com número ímpar de votos.

Para configurar segurança do ambiente agora que o cluster está de pé, veja Proxmox blindado com MFA.