Waarom zijn drie-knooppunt Clusters in Proxmox zo gebruikelijk?

Clustering met drie Proxmox VE-knooppunten verschijnt voortdurend wanneer het gaat over ondernemingsvirtualisatie en hoge beschikbaarheid. De verklaring ligt niet in het feit dat drie servers magisch meer prestaties leveren dan twee, maar in iets veel fundamentelers: de quorum die een gedistribueerd systeem nodig heeft om veilig beslissingen te nemen bij een storing. De Proxmox-documentatie beveelt minimaal drie knooppunten aan voor hoge beschikbaarheid met een betrouwbare quorum.

De kern van drieknooppuntclusters in 30 seconden

• Elk knooppunt levert meestal één stem en het cluster heeft een meerderheid nodig om quorum te behouden.
• Bij drei knooppunten betekent het verlies van één dat er nog twee stemmen over zijn en dat het cluster de meerderheid behoudt.
• Ook twee knooppunten zijn mogelijk; Proxmox overweegt een externe QDevice als derde stem.
• Het hebben van quorum betekent niet dat er voldoende capaciteit is om alle virtuele machines opnieuw op te starten.
• Een HA-architectuur moet rekening houden met CPU- en RAM-N+1, opslag, Corosync, netwerken, switching, energie en back-up.

Duidelijkheid hierover is belangrijk, want het is relatief eenvoudig om drie servers te kopen, Proxmox VE te installeren, het cluster te maken en HA-bronnen te activeren. Dat betekent echter niet dat de infrastructuur correct bestand is tegen het verlies van een van die servers.

Het probleem ontstaat wanneer je het dimensioneert terwijl je bijna 100% van de CPU en RAM gebruikt. Als een van de hosts stopt met werken en de andere twee zijn al verzadigd, kan Proxmox de quorum behouden en het falen detecteren, maar de getroffen virtuele machines zullen niet over voldoende middelen beschikken om opnieuw op te starten.

Daarom is het aantal knooppunten slechts een deel van het ontwerp.

Waarom drie knooppunten zo goed passen door quorum

Proxmox VE gebruikt Corosync voor clustercommunicatie en pmxcfs, een gedistribueerd bestandssysteem voor configuratie. De knooppunten werken via een stem-gebaseerd quorum-systeem. In een conventionele configuratie levert elk knooppunt één stem.

In een cluster van drie servers is de situatie eenvoudig:

Het doel van quorum is niet om de prestaties te verhogen, maar om te voorkomen dat verschillende delen van een gesplitst cluster blijven handelen alsof elk deel de controle over dezelfde middelen heeft.

Dergelijke situaties kunnen leiden tot de bekende split brain-conditie, wat vooral gevaarlijk is wanneer verschillende servers gelijktijdig gedeelde middelen kunnen wijzigen.

Daarom bieden drie knooppunten een natuurlijke meerderheid: als er één verdwijnt, kunnen de andere twee nog steeds overeenkomen.

Is een cluster van twee knooppunten dan verkeerd?

Niet noodzakelijk.

Proxmox staat configuraties toe met twee knooppunten en documenteert specifiek het gebruik van een QDevice als extra stem voor kleine clusters die meer beschikbaarheid vereisen.

De QDevice biedt een externe stem zonder dat een volledige derde virtualisatie-server nodig is. Proxmox beveelt het gebruik ervan aan voor twee-knooppuntclusters en raadt het over het algemeen af om het toe te voegen aan clusters met een oneven aantal knooppunten vanwege het afwijkende stem-systeem.

Een architectuur met twee hosts plus een QDevice kan heel zinvol zijn wanneer de kosten van een derde computing-node niet gerechtvaardigd zijn.

Maar het is belangrijk om concepten opnieuw te scheiden: de QDevice helpt bij het oplossen van quorum, biedt echter geen CPU of RAM voor het uitvoeren van virtuele machines.

Als een van de twee servers uitvalt, moet de andere de werklasten overnemen. Als die niet genoeg capaciteit heeft, lost het toevoegen van een derde stem dat probleem niet op.

De fout van 100% benutting van alle drie servers

Dit is een van de belangrijkste aspecten bij het dimensioneren van hoge beschikbaarheid.

Stel je een cluster voor met drie servers, elk met 512 GB RAM:

De hardware heeft in totaal ongeveer 1,5 TB RAM, maar dat betekent niet dat alles vrij kan worden toegewezen aan virtuele machines, zeker niet als het doel is volledige capaciteit te behouden bij verlies van één host.

Als elke server 500 GB gebruikt en PVE01 uitvalt, blijft er nog maar ongeveer 24 GB over tussen de andere twee knooppunten. De machines die de recursos van de verloren server gebruikten, kunnen daar moeilijk worden herstart.

Daarom wordt een ontwerp met N+1-capaciteit vaak toegepast in een hoge beschikbaarheidssysteem.

Kort gezegd, de resterende middelen moeten voldoende zijn om de belasting te ondersteunen wanneer één knooppunt wegvalt.

Dat betekent niet dat je per se een volledig lege server moet hebben.

De capaciteit kan worden verdeeld over alle knooppunten, met een marge voor het scenario van uitval, en niet alle machines hoeven dezelfde prioriteit te krijgen.

Een organisatie kan bijvoorbeeld besluiten dat ERP-systemen, databases, domeincontrollers of essentiële diensten eerst moeten worden hersteld, terwijl ontwikkel- of testmachines en secundaire diensten tijdens een incident mogelijk uitgeschakeld blijven.

Het dimensioneren moet gebaseerd zijn op reel gebruik en piekbelasting, in plaats van simpelweg te optellen wat de configuraties aan vCPU’s aangeven.

Geheugen is doorgaans minder flexibel. Een systeem met voldoende CPU, maar onvoldoende RAM, zal ook problemen ondervinden bij het herstellen van de belasting.

Hoge Beschikbaarheid betekent niet automatisch live migratie

Er is vaak verwarring tussen High Availability en Live Migration.

Tijdens een live migratie blijft de bron host actief. Proxmox kan een VM verplaatsen naar een andere server volgens plan, bijvoorbeeld voor onderhoud.

Een fysieke storing is anders.

Als een host onverwacht stopt met functioneren, is er geen VM die ordenlijk kan worden verplaatst van de oorspronkelijke server. Het HA-systeem moet vaststellen dat de host is uitgevallen, garanderen dat die geen middelen meer gebruikt en de workloads op een andere knooppunt herstellen.

De documentatie van Proxmox legt uit dat de HA-stack gebruikmaakt van locking- en watchdogmechanismen om automatische herstel van beheerde workloads mogelijk te maken na verlies of fencing van een knooppunt.

Kortom, HA kan het herstel automatiseren en verkorten, maar betekent niet dat er geen onderbreking is.

Applicaties die hogere continuïteit vereisen, moeten hun eigen architectuur uitbreiden met replicatie, database-clustering, load balancers of meerdere instanties.

Corosync, opslag en netwerken maken ook deel uit van HA

Drie knooppunten met voldoende middelen volstaan niet altijd voor een compleet ontwerp.

Corosync vereist betrouwbare communicatie tussen clusterleden. Proxmox raadt een fysiek dedicated netwerk hiervoor aan en benadrukt dat Corosync vooral lage en stabiele latentie nodig heeft, niet een extra groot bandbreedte.

Een dedicated 1 Gbit/s-interface kan in veel scenario’s voldoende zijn.

Corosync ondersteunt ook meerdere communicatieverbindingen. De huidige richtlijnen voorzien tot acht netwerken en adviseren dat redundantie via fysieke paden gebeurt die echt fysiek van elkaar gescheiden zijn.

Dit brengt een belangrijke vraag: als je drie servers hebt, maar alles afhankelijk is van één switch, wat heb je aan die redundancy?

Hetzelfde geldt voor opslag.

Proxmox ondersteunt verschillende opslagarchitecturen: gedeelde opslag, NFS, iSCSI, Fibre Channel, Ceph, ZFS en lokale opslag. De keuze bepaalt hoe migraties verlopen en hoe herstel plaatsvindt als een node wegvalt.

Voor HA stelt Proxmox dat gedeelde opslag verplicht is voor beheerde virtual machines en containers. Er zijn ook gedistribueerde of gerepliceerde opslagoplossingen die afhankelijk van de situatie verder moeten worden onderzocht.

Ceph verdient een speciale vermelding omdat drie knooppunten vaak de minimale praktische configuratie zijn voor kleine implementaties. Maar dat je Ceph kunt bouwen met drie knooppunten betekent niet dat dat geschikt is voor elke belasting. Capaciteit, schijven, replicatie, netwerk, IOPS, latency, herstel en gedrag bij degradatie moeten steeds apart worden afgestemd.

En backup dan

Een cluster van drie knooppunten vervangt niet de back-upstrategie.

HA probeert diensten te behouden of te herstellen na storingen in de infrastructuur. Back-upoplossingen beantwoorden andere problemen: per ongeluk verwijderen, corruptie, ransomware, administratieve fouten of het herstellen van gegevens uit een eerder punt.

Proxmox biedt Proxmox Backup Server (PBS) om VM’s en containers te beschermen, maar de strategie moet bepalen hoe lang back-ups bewaard worden, Recovery Point Objectives (RPO), Recovery Time Objectives (RTO), locatie van de back-ups en testperiodes.

Een platform kan uitstekend in HA presteren, maar een slechte back-upstrategie hebben, of andersom.

Daarom is het bij het evalueren van een drieknooppuntcluster nuttiger om niet te vragen hoeveel servers Proxmox nodig heeft, maar om te stellen: wat moet blijven werken als een component uitvalt.

Dan kunnen CPU, RAM, opslag, netwerk en herstelcapaciteit worden gedimensioneerd.

Drieknooppunten worden vaak gekozen omdat zij een eenvoudige architectuur bieden om quorum te behouden na het verlies van één knooppunt. Maar echte hoge beschikbaarheid begint pas wanneer je nadenkt over wat er daarna gebeurt.

Als de kritieke workloads niet passen op de twee resterende servers, als alles afhankelijk is van dezelfde switch of als de opslag een extra single point of failure vormt, dan wordt een drieknooppuntcluster op zich niet automatisch hoog beschikbaar.

Veelgestelde vragen

Heeft Proxmox verplicht drie knooppunten nodig?

Nee. Proxmox VE kan worden gebruikt met één enkele server en ondersteunt clusters van verschillende groottes. Voor HA met betrouwbare quorum raadt Proxmox minimaal drie knooppunten aan; voor kleine clusters van twee knooppunten kan een QDevice als extra stem worden gebruikt.

Wat gebeurt er als een knooppunt uitvalt in een drieknooppuntcluster?

De overige twee knooppunten behouden de meerderheid van stemmen. Als de machines onder HA beheerd worden en opslag en resources voldoende zijn, kan Proxmox de getroffen workloads herstellen op de beschikbare knooppunten.

Moet je een knooppunt leeg laten voor N+1?

Niet per se. Resources kunnen worden verdeeld over de drie knooppunten, zolang er voldoende vrije capaciteit is om de workloads op te vangen wanneer één knooppunt wegvalt.

Heeft een drieknooppuntcluster met Proxmox Ceph nodig?

Nee. Ceph is een optie, geen verplichting voor het maken van een Proxmox-cluster. De platform ondersteunt verschillende opslagopties, en de keuze moet afhangen van de vereiste beschikbaarheid, performance en herstelmogelijkheden.