Een Proxmox-cluster met hoge beschikbaarheid bouwen op dedicated servers

Eerst het antwoord: wat het vraagt, wat je ervoor krijgt

De eisen, volgens Proxmox' eigen documentatie en niet gebogen door wishful thinking:

• Minimaal drie nodes voor betrouwbaar quorum. (Een cluster met twee nodes werkt met een externe QDevice als tiebreaker, details hieronder, maar drie is waar het ontwerp naartoe wil.)
• Een betrouwbaar low-latency netwerk tussen nodes, onder de 5 ms, met clusterverkeer idealiter op zijn eigen NIC. Dit is een eis voor dezelfde locatie, een private LAN, geen verbinding die je over meerdere regio's uitrekt.
• Opslag die de overlevende nodes kunnen benaderen: hyperconverged Ceph, ZFS-replicatie per gast, of externe gedeelde opslag.

Wat je ervoor terugkrijgt, even plat gezegd: sterft een node, dan herstart HA de gasten ervan automatisch op de overlevende nodes, binnen enkele minuten. Dat is crash recovery zonder mens, enorm waardevol, maar het is geen zero-downtime fouttolerantie: de gasten herstarten. Live migration (voor geplande verplaatsingen) is de onzichtbare variant; failover is een herstart.

Is je eigenlijke behoefte "herstellen van storingen binnen één werkdag", dan is een goede backup- en restorepraktijk op één solide host minder machinerie. Clustering verdient zijn complexiteit terug wanneer minuten ertoe doen, of wanneer je genoeg gasten draait dat single-pane beheer en live migration zich dagelijks terugbetalen.

Clustering vóór HA: op zichzelf al de moeite waard

Een veelvoorkomende verwarring: cluster ≠ HA. Nodes samenvoegen tot een cluster (pvecm) levert je, zonder dat er ook maar iets aan HA is geconfigureerd: één web-UI die elke node beheert, live migration van VM's tussen nodes (hardware-onderhoud zonder downtime), clusterbrede SDN-netwerken en firewallconfiguratie, en gedeeld taak- en rechtenbeheer. Veel productieclusters draaien precies dit (mensen beslissen wanneer gasten verhuizen) en voegen HA later selectief toe, per gast, voor de diensten die geautomatiseerde failover rechtvaardigen.

Quorum: waarom drie nodes

Het probleem dat quorum oplost is split-brain. Als clusterverbindingen uitvallen en nodes elkaar niet meer zien, moet elke kant beslissen: "ben ik nu het cluster?" Zeggen beide kanten ja, dan starten beide dezelfde VM's op dezelfde gedeelde opslag, en dan ontdek je hoe corrupte disk images eruitzien. De regel die dit voorkomt: alleen een groep met een meerderheid van de stemmen mag handelen. Bij drie nodes heeft elke partitie een meerderheidskant (2) en een minderheidskant (1) die bevriest; bij twee nodes maakt een kapotte verbinding beide kanten tot minderheid: geen van beide kan handelen, en de beschikbaarheid is nu slechter dan bij één enkele node.

Vandaar de twee toegestane vormen: drie of meer nodes, of twee nodes plus een QDevice, een piepklein corosync-daemon dat als getuige fungeert op een willekeurige derde machine (een VPS of kleine server volstaat; die draait geen gasten, hij stemt alleen). Wat nooit is toegestaan, is de workaround die forums om middernacht aanraden: handmatig het aantal verwachte stemmen op 1 zetten om een gepartitioneerde node geforceerd actief te maken. Die schakelaar is precies hoe split-brain een persoonlijke ervaring wordt.

Het corosync-netwerk: latency is de wet

Corosync, de membership- en messaginglaag van het cluster, is het onderdeel waarvan de eisen het minst onderhandelbaar zijn en het vaakst worden overtreden:

• Latency onder de 5 ms tussen alle nodes. Dit is LAN-natuurkunde: dezelfde locatie, een privénetwerk. Nodes in verschillende steden zijn geen cluster; het zijn twee clusters en een replicatiestrategie.
• Bandbreedte is irrelevant; contentie is fataal. Corosync heeft maar kilobits nodig, maar zodra het een link deelt met backupjobs, opslagverkeer of VM-migratie en die link verzadigt, komen membership-pakketten te laat aan, worden nodes dood verklaard, en begint HA gasten te "herstellen" die niets mankeerden. De officiële aanbeveling, het letterlijk opvolgen waard: een dedicated NIC (1 Gbit is ruim voldoende) voor clusterverkeer, en tot acht redundante corosync-links als je paden over hebt. Op zijn minst een tweede link op een ander netwerk als fallback.
• Opslagverkeer (vooral Ceph) wil eveneens zijn eigen rijstrook; zie hieronder.

Op onze dedicated servers vertaalt zich dat direct: het private netwerk tussen je machines draagt corosync (en opslag) op interfaces die nooit hoeven te wedijveren met publiek verkeer.

Opslag: de echte architectuurbeslissing

De premisse van HA is dat de disks van een gast de node waarop die draaide overleven. Drie manieren om daar te komen:

Ceph: hyperconverged, het volledige antwoord

Proxmox integreert Ceph native: elke node levert disks (OSD's), Ceph repliceert data over de nodes (standaard 3 kopieën), elke node ziet alle opslag, en het verlies van een node kost je niets. Selfhealing, geen externe SAN, schaalt door nodes toe te voegen. Dit is het klassieke hyperconverged cluster, en de officiële eisen zijn eerlijk over de honger ervan: drie of meer, bij voorkeur identieke, servers, een dedicated netwerk van 10 Gbit/s+ uitsluitend voor Ceph (25 Gbit/s+ zodra NVMe in het spel is: een enkele moderne NVMe kan in zijn eentje 10 Gbit/s verzadigen), disks op HBA's, geen RAID-controllers (Ceph regelt de redundantie zelf; een RAID-laag eronder werkt actief tegen), ruwweg een CPU-thread per Ceph-dienst en ~8 GiB RAM per OSD voor comfort. Begroot die resources als infrastructuuroverhead per node, bovenop de sizing van de gasten.

ZFS-replicatie: het pragmatische midden

Waar de eisen van Ceph het budget overstijgen, repliceert pvesr gastvolumes tussen nodes volgens een schema (zo strak als elke minuut) over het migratienetwerk, ZFS-naar-ZFS. Failover herstart de gast vervolgens vanaf zijn replica, met één addertje dat Ceph niet kent: een expliciet dataverliesvenster. Alles wat is veranderd sinds de laatste sync (tot een minuut, of je schema) is weg. Voor veel workloads is die ruil uitstekend: geen complexiteit van gedeelde opslag, lokale NVMe-snelheid voor elke gast, redundantie per gast in plaats van clusterbreed. Vereist ZFS-onderbouwde gastopslag aan beide kanten.

Externe gedeelde opslag

NFS of iSCSI die alle nodes kunnen bereiken voldoet ook aan HA, conceptueel het simpelst, en het verplaatst het probleem: die opslagbox is nu het single point of failure dat je cluster niet afdekt. Zinvol wanneer het een werkelijk veerkrachtig opslagsysteem is; schijnbesparing wanneer het één NFS-server in hetzelfde rack is.

Hoe een failover er in de praktijk uitziet

Het mechanisme verdient het om ontrafeld te worden, want "het cluster regelt het" verbergt één pittig staaltje gedrag. Elke node die HA-gasten draait, bewaakt een watchdog, een dodemansknop (hardware-watchdog waar geconfigureerd, anders de kernel-softdog). Verliest een node zijn quorum, dan stopt hij met de watchdog voeden, en na de timeout (~60 seconden) past de node fencing op zichzelf toe: hij herstart, wat garandeert dat zijn gasten werkelijk dood zijn en hun disks zijn vrijgegeven. De meerderheid met quorum wacht dat venster uit, en herstart daarna de HA-gasten van de door fencing geïsoleerde node vanaf gedeelde of gerepliceerde opslag.

Totale ervaren downtime voor een gast: watchdog-venster + scheduling + boot van de gast, doorgaans enkele minuten. Configuratie gebeurt per gast (Datacenter → HA): markeer de gasten die het verdienen, groeps-/affiniteitsregels sturen waar ze landen (PVE 9 voegde volwaardige resource-affiniteitsregels toe, en de dynamische load scheduler van 9.2 kan balanceren op realtime gebruik). Twee operationele kanttekeningen die zelf veroorzaakte incidenten voorkomen: gebruik maintenance mode (en de clusterbrede HA-uitschakeling van PVE 9.2) vóór bewuste herstarts, zodat de watchdog-machinerie niet een node gaat "herstellen" die je aan het patchen bent; en besef dat fencing ook de reden is waarom je nooit quorum voorwendt op een gepartitioneerde node: de watchdog is de laatste linie die voorkomt dat twee kopieën van je database naar dezelfde disk schrijven.

Wanneer je niet moet clusteren

• Twee nodes, nergens een derde stem. Voeg een QDevice toe (een kleine VM waar dan ook) of blijf ongeclusterd: een cluster met twee nodes zonder QDevice faalt erger dan onafhankelijke nodes.
• Nodes gescheiden door echte latency. >5 ms betekent nee. Multi-site-veerkracht los je op met onafhankelijke locaties plus replicatie en backups, niet met een uitgerekt cluster.
• Wanneer de eerlijke eis "morgen hersteld" is. Eén goed geback-upte host met reprovisioning binnen een minuut erachter is veel minder om te beheren, en PBS live-restore verkleint het verschil verder.
• Niet-passende hardware voor Ceph. Sterk uiteenlopende nodes maken Ceph ongelukkig (de traagste disk bepaalt het tempo); ZFS-replicatie verdraagt asymmetrie veel beter.

Veelgestelde vragen

Kan ik een cluster met twee nodes bouwen?

Ja, met de QDevice als verplichte derde stem: corosync-qnetd op een willekeurige altijd-actieve machine buiten het paar (een kleine cloud-instance is de klassieke keuze; die draait geen gasten en heeft nauwelijks resources nodig). Met de QDevice kan elk van beide nodes uitvallen en behoudt de overlevende node quorum en voert die HA-herstel uit. Zonder QDevice moet je het niet doen: elke storing in de verbinding of een node bevriest het hele cluster, wat strikt genomen slechter is dan twee onafhankelijke hosts.

Geeft HA mij zero-downtime failover?

Nee. En weten waarom geeft je de juiste verwachtingen. Een ongeplande failover is fencing gevolgd door herstart: de gasten van de uitgevallen node starten vers op bij de overlevenden na het watchdog-venster, dus reken op enkele minuten downtime en ontwerp applicaties zodat ze netjes herstellen van een harde stop (dat zouden ze sowieso moeten kunnen). Wat wel zero-downtime is, is geplande verplaatsing: live migration ontlast een node vóór onderhoud terwijl de gasten blijven draaien. HA vangt de verrassingen op; live migration regelt de planning.

Kunnen mijn nodes in verschillende datacenters staan?

Verschillende racks of ruimtes binnen één faciliteit met private connectiviteit onder de 5 ms: ja, en dat is goede failure-domain-hygiëne. Verschillende steden: nee. Zowel corosync-membership als (erger nog) synchrone Ceph-replicatie worden instabiel bij WAN-latency. Het multiregio-patroon is onafhankelijke clusters per locatie met asynchrone replicatie en backup-sync ertussen, en failover als een bewuste actie in plaats van een automatische.

Moeten alle nodes identieke hardware hebben?

Voor het cluster zelf niet. Gemengde nodes clusteren prima, en live migration tussen verschillende CPU-generaties werkt met een gemeenschappelijk baseline-CPU-type ingesteld op de gasten (de prijs: gasten kunnen geen nieuwere instructies gebruiken). Voor Ceph is bijna-identiek de sterke aanbeveling: capaciteit en prestaties balanceren over de OSD's, en één trage node vertraagt de hele pool. Pragmatisch patroon voor gemengde vloten: cluster ze allemaal voor beheer, draai Ceph (of replicatieparen) over de bijpassende subset, en zet HA-gasten daar vast.

Uitrollen op Serverside

Het cluster uit dit artikel vertaalt zich naar een concrete bestelling: drie identieke dedicated servers (Proxmox voorgeïnstalleerd, NVMe op HBA's voor Ceph of ZFS voor replicatie), verbonden via onze private netwerken voor corosync- en opslagverkeer (je publieke bandbreedte krijgt nooit clustergebabbel te zien), elk met KVM-over-IP voor de dag dat een node out-of-band aandacht nodig heeft. Provisioning duurt minder dan een minuut op ASN 55285, wat zelfs het QDevice-patroon triviaal maakt: elke kleine derde machine volstaat.

Bouw ernaartoe met de reeks: setup, networking, LXC vs VM's, en backups, die je nog steeds nodig hebt; een cluster repliceert je fouten met uitstekende beschikbaarheid.