Cluster de 2 nós no Proxmox: QDevice e o problema do quórum

Dois servidores é o que cabe no orçamento de muita gente, e a ideia de juntá-los num cluster Proxmox é natural: gestão unificada, migração de VM entre eles, e a expectativa de que se um cair o outro assume. As duas primeiras coisas funcionam. A terceira, não — pelo menos não sem um componente a mais, e a descoberta costuma acontecer na pior hora possível.

O motivo é aritmético e vale entender antes de montar.

Por que dois nós não fecham quórum

Cluster precisa decidir, sem ambiguidade, quem está vivo. Quando a rede entre os nós cai, cada lado vê o outro sumir — e cada um precisa responder à mesma pergunta: "o outro morreu, ou fui eu que me isolei?".

Se ambos concluírem "o outro morreu" e assumirem as VMs, você tem a mesma máquina virtual rodando nos dois lados, escrevendo no mesmo storage. É o split-brain, e o resultado é corrupção de dado, não indisponibilidade. Indisponibilidade se resolve; corrupção silenciosa de storage compartilhado, muitas vezes não.

A proteção clássica é a maioria: um lado só age se tiver mais da metade dos votos. Com três nós, dois de um lado formam maioria e o nó isolado se cala. Com dois nós, cada lado tem exatamente metade — não existe maioria possível. Por isso o Proxmox, por padrão, faz o que é seguro: sem quórum, o nó fica somente leitura, não inicia VM gerenciada por HA e não permite alterar configuração de cluster.

Ou seja: com dois nós e a configuração padrão, a queda de um deles não é resolvida automaticamente pelo outro. O comportamento está correto; a expectativa é que estava errada.

O QDevice, e o que ele faz

O QDevice é a resposta oficial para isso. Trata-se de um terceiro votante que não é um nó Proxmox: uma máquina qualquer rodando um pequeno serviço (corosync-qnetd), que participa apenas da decisão de quem tem maioria.

Com ele, o cluster passa a ter três votos: um por nó e um do árbitro. Se um nó cai, o sobrevivente soma o próprio voto ao do árbitro e tem dois de três — maioria. Ele mantém o cluster operante e o HA reinicia as VMs do nó perdido.

O que o árbitro precisa ser:

Uma máquina pequena. Um container, uma VM em outro lugar, um mini PC, um servidor que você já tem. O consumo é irrisório.
Fora dos dois nós. Colocá-lo em uma VM dentro de um dos nós anula o propósito inteiro: se aquele nó cair, cai junto o voto que decidiria.
Com rede independente até os dois nós, tanto quanto possível. O ideal é que ele não compartilhe o mesmo switch que liga os nós entre si — se o switch é o ponto de falha, o árbitro precisa sobreviver a ele.
Ligado. Árbitro desligado devolve o cluster ao problema original, em silêncio.

Onde colocá-lo, na prática: outro site da empresa, um escritório, uma VPS barata em provedor externo ou um equipamento pequeno no mesmo rack mas em outra fonte de energia e outro switch. A melhor escolha é a que compartilha o mínimo de destino com os nós.

O que o QDevice não resolve

E aqui está a parte que as instruções de instalação não enfatizam o suficiente. QDevice resolve quórum. Ele não resolve storage nem capacidade.

Storage. Para a VM do nó caído subir no sobrevivente, o disco dela precisa estar acessível lá. Isso significa storage compartilhado ou replicado:

Ceph não é opção em dois nós. Ele precisa de três nós para manter réplicas com segurança; forçar dois é um desenho frágil que devolve corrupção sob falha.
Replicação ZFS é o caminho usual em dois nós: o Proxmox replica os volumes entre os nós em intervalo definido. Funciona bem, e tem uma consequência que precisa estar escrita no contrato ou no acordo interno — você perde o que mudou desde a última replicação. Se replica a cada 15 minutos, o RPO é 15 minutos. Não é zero.
Storage externo — NFS, iSCSI, Fibre Channel — resolve o acesso compartilhado, e transfere o ponto único de falha para o array. Se o storage não for redundante, você tirou o SPOF de um lugar e o colocou em outro.

Capacidade. Se cada nó opera a 80% de uso, o sobrevivente não tem onde colocar as VMs do outro. Dois nós com HA de verdade precisam operar, cada um, com folga para receber a carga do parceiro. Na prática, isso significa não passar de cerca de 45–50% de uso por nó — o que muda bastante a conta de quantas VMs cabem.

Fencing: o detalhe que evita o pior

Quórum impede que o nó isolado tome decisões. Mas existe um cenário sutil: o nó travou de forma que parou de responder ao cluster e ainda assim continua escrevendo no storage. Nesse caso, subir a mesma VM no outro nó é perigoso.

O Proxmox trata isso com autoisolamento: o nó que perde quórum se reinicia sozinho por watchdog, garantindo que pare de escrever. É o comportamento padrão e é a razão de o watchdog precisar estar funcionando — e de a configuração do HA não ser algo para improvisar.

Em ambientes que exigem mais garantia, existe fencing por hardware, desligando o nó pela interface de gestão fora de banda. É mais trabalho e é o que se usa quando o storage compartilhado não perdoa.

Quando dois nós bastam, e quando não

Dois nós com QDevice atendem bem quando:

O RPO de minutos da replicação ZFS é aceitável para o negócio.
Há folga de capacidade real em cada nó.
O árbitro está em local independente e monitorado.
O ambiente é pequeno e o crescimento previsto é modesto.

Dois nós não bastam quando:

O requisito é RPO próximo de zero — aí é storage compartilhado redundante ou três nós com Ceph.
Você quer Ceph. Não force; o mínimo é três.
O crescimento previsto vai exigir o terceiro nó em menos de um ano — nesse caso, comprar três agora sai mais barato que montar dois e refazer o desenho depois.
A operação não tem como garantir que o árbitro fique de pé e monitorado.

Vale dizer com franqueza: a diferença de custo entre dois e três nós costuma ser menor do que parece, e o terceiro nó elimina toda a complexidade descrita neste artigo — árbitro, replicação com RPO, folga assimétrica. Se o orçamento alcança três, alcance três.

Monitorar o que agora importa

Um cluster de dois nós com QDevice tem três coisas que precisam estar no painel, com alerta:

Estado do quórum. Deve haver três votos disponíveis; dois é um alerta, não uma condição normal.
Saúde do QDevice. Árbitro inalcançável é uma falha silenciosa que só aparece na hora do incidente.
Atraso da replicação. Replicação parada significa que o RPO cresceu sem ninguém saber. É a falha mais traiçoeira do desenho.

Erros comuns

Montar dois nós esperando failover automático sem QDevice.
Colocar o árbitro em uma VM dentro de um dos dois nós.
Ligar o árbitro no mesmo switch que liga os nós entre si.
Forçar Ceph em dois nós.
Operar os dois nós acima de 50% e não ter onde absorver a queda.
Não escrever o RPO da replicação ZFS no acordo de serviço.
Não monitorar o atraso da replicação nem a saúde do árbitro.
Desabilitar o watchdog para "resolver" reinícios e abrir caminho para split-brain.
Storage externo único sem redundância, virando o novo ponto de falha.
Adiar o terceiro nó por uma diferença de custo pequena diante da complexidade evitada.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, montamos cluster de dois nós quando ele é a escolha certa — com QDevice em local independente, replicação ZFS dimensionada ao RPO que o seu negócio aceita, folga de capacidade calculada para a queda de um nó e monitoramento de quórum, árbitro e atraso de replicação. E dizemos quando dois nós não atendem o requisito, com a conta do terceiro nó na mesa, antes de você descobrir isso durante um incidente.

Seu cluster de dois nós realmente sobrevive à queda de um? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.