Cluster Proxmox con 2 nodi: Corosync, QDevice e HA — come funziona il failover con dati reali

3 voti, quorum 2, token 1000 millisecondi. Sono i tre numeri che tengono in piedi il mio cluster Proxmox a 2 nodi. Tre numeri che decidono, ogni due secondi, se i container sono vivi o morti. Se il cluster resiste o si spezza in due.

Nella Parte 1 ho spiegato perché tratto il mio homelab come un datacenter. Qui entro nel come: Corosync, QDevice su un Raspberry Pi 5, High Availability su 4 container, replica ZFS ogni 15 minuti. E soprattutto, i limiti che nessun tutorial vi mostra.

Cluster Proxmox a 2 nodi e lo split-brain: il problema reale

Un cluster Proxmox a 2 nodi ha un problema strutturale. Quando i nodi perdono contatto, ognuno crede di essere l'unico sopravvissuto. Entrambi provano a prendere il controllo delle risorse. Il risultato si chiama split-brain: due nodi che scrivono sugli stessi volumi, due istanze dello stesso container, corruzione dati.

Proxmox risolve con il quorum: serve una maggioranza di voti per operare. Con 2 nodi hai 2 voti. La maggioranza è 2. Se un nodo muore, l'altro ha 1 voto su 2 richiesti. Nessuno può operare. Cluster bloccato.

Serve un terzo voto — un arbitro esterno che rompa il pareggio.

Corosync e knet: come i nodi si parlano

Corosync è il cuore della comunicazione cluster. Nel mio setup usa il transport knet con autenticazione cifrata, ip_version ipv4-6 e link_mode passive. Il token è impostato a 1000 millisecondi: se un nodo non risponde entro due cicli, viene dichiarato morto.

Due secondi. È il tempo che passa tra "tutto ok" e "failover in corso".

È anche il tempo in cui un falso positivo può mandare a terra il cluster. Token troppo basso e avrai failover fantasma. Troppo alto e un nodo morto resterà lì a marcire mentre i servizi sono giù.

# /etc/pve/corosync.conf (estratto)
totem {
    version: 2
    cluster_name: homelab-cluster
    transport: knet
    token: 1000
    ip_version: ipv4-6
    link_mode: passive
    secauth: on
}

quorum {
    provider: corosync_votequorum
    expected_votes: 3
    device {
        votes: 1
        model: net
        net {
            algorithm: ffsplit
            host: 10.0.10.1
        }
    }
}

La sezione quorum mostra il punto chiave: expected_votes 3 con un QDevice che aggiunge il terzo voto. L'algoritmo ffsplit assegna il voto al sottoinsieme che mantiene il maggior numero di nodi attivi. Nel nostro caso, con 2 nodi, il voto va sempre al sopravvissuto.