Antes de gastar dinheiro, fui entender o que um cluster de dois nós exige de verdade. E a primeira descoberta muda o plano: com dois nós, o Proxmox precisa de um terceiro voto, e esse voto pode vir de um aparelho bem simples, o QDevice. Este post é o meu planejamento, com o que a documentação oficial diz. Ainda não montei o cluster.

Por que dois nós não bastam #

O cluster do Proxmox usa o Corosync e decide tudo por quórum: cada nó tem um voto, e o cluster só funciona normalmente quando a maioria dos votos está presente. Pela documentação, quando perde o quórum, o cluster entra em modo somente leitura para se proteger.

Com dois nós, a conta não fecha. Se um cai, sobra um voto de dois, que não é maioria. O nó que ficou não sabe se o outro morreu ou se só a rede entre eles caiu, e não pode assumir sozinho sem arriscar que os dois mexam nos mesmos dados ao mesmo tempo.

A própria documentação diz que, para alta disponibilidade (HA) confiável, são necessários pelo menos três votos. E aponta a saída para clusters pequenos: o QDevice como terceiro voto.

O que é o QDevice #

O QDevice é um “desempatador” externo. Não é um terceiro servidor do Proxmox: é um serviço leve, o corosync-qnetd, rodando em qualquer máquina Linux fora do cluster. Ele não roda container nem VM. Só vota.

Pela documentação:

• ele dá o voto dele para um lado do cluster por vez, e só se aquele lado consegue alcançá-lo pela rede;
• a conexão é por TCP/IP, então ele pode até ficar fora da rede do cluster, mas precisa alcançar os nós (porta TCP 5403);
• em empate, por padrão, o voto vai para o lado com o menor ID de nó;
• o serviço roda como usuário sem privilégios e o tráfego com o cluster é criptografado.

No meu caso, uma opção natural seria o NAS que também está nos planos, para guardar backups e rodar um Nextcloud. Um Raspberry Pi ou qualquer máquina pequena que fica ligada o tempo todo também serve.

Os comandos, segundo a documentação #

Criar o cluster é feito no primeiro nó, e o nome não pode ser trocado depois:

pvecm create homelab
pvecm status

No segundo nó, você entra no cluster apontando para o IP de um nó que já faz parte dele. Por padrão, o comando autentica pela API e pede a senha do root daquele nó:

pvecm add 192.168.1.10

Para o QDevice, há pacotes dos dois lados. Na máquina externa:

apt install corosync-qnetd

Em todos os nós do cluster:

apt install corosync-qdevice

E, com todos os nós no ar, a configuração é feita em um deles:

pvecm qdevice setup 192.168.1.20
pvecm status

A configuração precisa de acesso SSH como root na máquina externa, por chave ou com login por senha liberado só durante o processo.

A rede entre os nós #

O Corosync é exigente com a rede. A documentação pede latência abaixo de 5 ms, o que na prática significa os nós na mesma rede local, ligados por cabo. Wi-Fi e nós em casas diferentes estão fora.

O recomendado é deixar os nós na mesma rede, com cabo, e, se o hardware tiver uma segunda porta de rede, considerar uma rede separada só para o tráfego do Corosync.

Cluster não é alta disponibilidade automática #

Essa foi a segunda descoberta. Montar o cluster já traz vantagens: um painel só para as duas máquinas e migrar containers e VMs de um nó para o outro. Mas para o Proxmox religar um container sozinho em outro nó quando um deles morre, os dados daquele container precisam estar disponíveis no outro nó.

Há dois caminhos comuns:

• Storage compartilhado (um NAS servindo os discos pela rede, por exemplo).
• Replicação de storage do próprio Proxmox, que copia os discos de um nó para o outro de tempos em tempos.

Pela documentação, a replicação só funciona com ZFS local, roda por padrão a cada 15 minutos e, combinada com HA, pode perder o que mudou desde a última sincronização. O meu SSD hoje não sei se está em ZFS ou LVM, então essa é uma das primeiras coisas a conferir antes de escolher a segunda máquina e o disco dela.

O meu plano, em ordem #

1. Conferir o storage atual e decidir se o próximo nó vai ter ZFS.
2. Comprar a segunda máquina, com mais memória. Contei o que penso do M720q no post sobre o ThinkCentre M720q no homelab.
3. Montar o cluster e o QDevice no NAS ou numa máquina pequena.
4. Só então pensar em HA para os serviços que não podem parar.

E antes de qualquer passo: backup em dia. Criar cluster mexe na configuração do host, e eu já sei bem o que é perder tudo. A rotina está no post sobre backup com vzdump.

Resumindo #

• Dois nós não formam maioria quando um cai: o cluster precisa de um terceiro voto.
• O QDevice dá esse voto com um serviço leve (corosync-qnetd) numa máquina externa.
• Rede de baixa latência (menos de 5 ms) é obrigatória entre os nós.
• Cluster não é HA sozinho: precisa de storage compartilhado ou replicação, que exige ZFS.

Quando a segunda máquina chegar, volto aqui para contar como foi na prática.