Een Proxmox-cluster met twee nodes maken zonder het quorum op te offeren
Een Proxmox VE-cluster met twee nodes maken, een QDevice toevoegen, VM's migreren, ZFS-volumes repliceren en een veilig herstel na een storing voorbereiden.
Een Proxmox VE-cluster met twee nodes is aantrekkelijk : twee servers verschijnen in dezelfde interface, virtuele machines kunnen van de ene naar de andere migreren en ZFS kan hun schijven repliceren zonder gedeelde opslag. Maar twee servers vormen op zichzelf geen veilig high availability-platform. Wanneer een node verdwijnt, kan de overlevende niet bepalen of hij werkelijk alleen is of gewoon gescheiden van zijn partner door een netwerkstoring.
Deze gids laat zien hoe u het cluster aanmaakt, een VM migreert, ZFS-replicatie configureert en vooral een derde stem toevoegt met een QDevice. Dit onderscheid is essentieel : twee nodes vergemakkelijken het beheer en het onderhoud ; twee nodes vergezeld van een onafhankelijke arbiter kunnen quorum-beslissingen nemen zonder een split-brain te bevorderen.
Wat een cluster met twee nodes werkelijk oplevert
Het Proxmox-cluster brengt meerdere hypervisors samen in een gedistribueerde configuratie. Het bestandssysteem pmxcfs repliceert de instellingen van het datacenter, de gebruikers, de firewall, de opslag en de guests. Vanuit de webinterface van eender welk lid kan men de anderen beheren.
Met twee nodes krijgt u onmiddellijk :
- een gemeenschappelijke multi-master beheersinterface ;
- clusterbrede unieke VM- en container-ID's ;
- hot of offline migratie tussen de hosts ;
- asynchrone replicatie van lokale ZFS-volumes ;
- gedistribueerde back-uptaken, rechten en regels.
Aan de andere kant creëert het cluster niet automatisch een gedeelde opslag, verandert het een replicatie niet in een back-up en activeert het geen betrouwbare high availability zonder quorum. HA-resources moeten afzonderlijk worden geconfigureerd en hun schijven moeten toegankelijk zijn op de node die ze overneemt.
Waarom het quorum de overlevende node blokkeert
Corosync kent normaal één stem toe aan elke node. In een cluster met twee leden is het totaal twee stemmen en de meerderheid vereist er twee. Als de communicatie verbroken is, ziet elke server nog maar één stem. Het bestandssysteem van het cluster schakelt dan over naar alleen-lezen om te voorkomen dat beide kanten tegelijkertijd dezelfde configuratie wijzigen.
Dit gedrag is geen storing van het cluster : het is de belangrijkste bescherming tegen split-brain. Zonder arbiter kan geen enkele server weten of de andere uit staat of nog steeds actief is achter een defecte netwerkverbinding.
| Architectuur | Stemmen | Meerderheid | Storing van één node |
|---|---|---|---|
| 2 nodes alleen | 2 | 2 | De overlevende verliest het quorum |
| 2 nodes + QDevice | 3 | 2 | De overlevende kan de stem van de arbiter ontvangen |
| 3 Proxmox-nodes | 3 | 2 | Twee nodes behouden van nature het quorum |
De QDevice host geen VM's en slaat de schijven van het cluster niet op. Het levert een externe stem aan één enkele partitie van het cluster. Een klein onafhankelijk Debian-systeem is voldoende, op voorwaarde dat het bereikbaar blijft voor beide nodes. Vermijd om deze arbiter te plaatsen in een VM die gehost wordt door het cluster dat hij moet scheidsrechteren.
De twee servers voorbereiden
Voordat u op « Cluster aanmaken » klikt, controleert u de volgende punten :
- Identieke versies : update beide hosts en gebruik dezelfde generatie van Proxmox VE.
- Unieke en opgeloste namen : elke host moet de naam en het adres van de andere kunnen oplossen, zonder toekomstige wijziging van de hostnaam.
- Vaste adressen : reserveer een stabiel adres voor elke Corosync-link.
- Gesynchroniseerde tijd : controleer NTP op beide servers.
- Betrouwbaar netwerk : Corosync gebruikt UDP 5405 tot 5412 en het toevoegen van een node vereist SSH op TCP 22.
- Lege toe te voegen node : deze mag geen VM's of containers bevatten.
- Consistente opslag : gebruik dezelfde opslag-ID's en, voor replicatie, compatibele ZFS-pools op beide hosts.
- Geverifieerde back-up : exporteer de configuraties en maak een back-up van de guests voor enige clusterbewerking.
Een gescheiden Corosync-netwerk is niet strikt verplicht in een klein labo, maar het wordt sterk aangeraden zodra migraties, back-ups en opslag veel verkeer genereren. Als er twee links geconfigureerd zijn, moeten ze werkelijk verschillende paden volgen : twee VLAN's op dezelfde switch beschermen niet tegen een storing van die switch.
1. Het cluster aanmaken op de eerste node
Log in op de webinterface van de eerste server en open vervolgens Datacenter → Cluster → Cluster aanmaken. Kies een korte naam zonder spaties, bijvoorbeeld Prox, en selecteer het adres van het netwerk dat door Corosync gebruikt wordt.
Dezelfde bewerking kan vanuit de shell van de eerste node uitgevoerd worden :
pvecm create Prox --link0 192.168.68.31Controleer daarna de status van het cluster :
pvecm status
pvecm nodesOp dit punt is er slechts één node lid en de interface biedt de knop Verbindingsinformatie aan. Kopieer het meegeleverde blok : het bevat het adres van het bestaande lid, de vingerafdruk van zijn certificaat en de informatie die nodig is voor de toevoeging.
2. Het cluster joinen vanaf de tweede node
Open de webinterface van de tweede server en ga vervolgens naar Datacenter → Cluster → Cluster joinen. Plak de gekopieerde informatie, voer het root-wachtwoord van de eerste node in en selecteer het lokale adres van de Corosync-link.
192.168.68.31 en de tweede node toont zijn lokale link 192.168.68.32.Vanuit de shell van de tweede node is het equivalent :
pvecm add 192.168.68.31 --link0 192.168.68.32De websessie van de tweede node wordt normaal onderbroken tijdens de integratie : zijn certificaat wordt vervangen door een certificaat dat ondertekend is door de autoriteit van het cluster. Wacht even, laad de pagina volledig opnieuw en log opnieuw in met de inloggegevens van het cluster.
Beide nodes moeten nu onder hetzelfde datacenter verschijnen. Controleer opnieuw pvecm status. Zonder QDevice is het cluster operationeel wanneer de twee hosts communiceren, maar het zal het quorum verliezen zodra een van hen of de link die hen verbindt verdwijnt.
3. De derde stem toevoegen met QDevice
Bereid een kleine onafhankelijke machine voor met Debian of een distributie die corosync-qnetd aanbiedt. Ze mag weinig krachtig zijn : haar rol bestaat er enkel in te arbitreren. Plaats ze bij voorkeur op een stroomvoorziening en een netwerkpad die verschillen van die van de twee hypervisors.
Op de arbiter :
apt update
apt install corosync-qnetdOp de twee Proxmox-nodes :
apt update
apt install corosync-qdeviceConfigureer vervolgens de arbiter vanuit een lid van het cluster :
pvecm qdevice setup 192.168.68.50Vervang het adres door dat van uw arbiter. Het commando bereidt de certificaten voor en registreert de externe stem. Een nieuwe uitvoering van pvecm status moet in totaal drie stemmen tonen en een quorum dat op twee is vastgesteld.
4. Een virtuele machine migreren
Klik met de rechtermuisknop op de VM, kies Migreren, en selecteer vervolgens de doelnode. Hot migratie houdt de VM in werking tijdens de overdracht van zijn geheugen en, wanneer de schijven lokaal zijn, van zijn volumes.
local-zfs-schijven naar de doelnode gekopieerd moeten worden.De duur is afhankelijk van de opslag en het netwerk :
- Gedeelde opslag : de schijven blijven op hun plaats en enkel de status van de VM, het gewijzigde geheugen en de virtuele apparaten moeten overschakelen.
- Lokale opslag : Proxmox kopieert de volumes naar de doelopslag, wat meerdere honderden gigabytes kan overdragen.
- Reeds gerepliceerde ZFS : de meerderheid van de blokken bestaat al op het doel en enkel de wijzigingen sinds de laatste replicatie moeten verzonden worden.
De netwerkbruggen moeten dezelfde namen dragen op beide hosts. Voor verschillende processors kiest u een virtueel CPU-model dat compatibel is met beide machines in plaats van host. De QEMU Guest Agent wordt aanbevolen voor propere bewerkingen in de guest, maar het is geen absolute voorwaarde voor hot migratie.
5. De ZFS-schijven repliceren
Proxmox-replicatie werkt met lokale ZFS-volumes. Het creëert snapshots, stuurt een eerste volledige kopie en transfereert daarna enkel de gewijzigde blokken. Open in de betreffende VM Replicatie → Toevoegen, kies de doelnode en definieer de planning.
De eerste synchronisatie is de langste. De volgende zijn incrementeel en hun frequentie vermenigvuldigt de ingenomen ruimte niet automatisch met evenveel volledige kopieën. Een bandbreedtelimiet kan voorkomen dat de replicatie het gebruiksverkeer verstikt.
Na een migratie naar de replicatienode keert Proxmox automatisch de richting van de taak om. De nieuwe bronmachine stuurt dan zijn wijzigingen terug naar de oude host. Controleer regelmatig de status en het logboek van de taak : een gedefinieerde replicatie met een fout vormt geen enkele bescherming.
Wat gebeurt er wanneer een node uitvalt ?
Het antwoord hangt af van drie elementen : het quorum, de beschikbaarheid van de schijven en de activering van HA.
- Twee nodes met QDevice en HA : de overlevende kan het quorum behouden en de HA-resources herstarten waarvan de volumes beschikbaar zijn.
- Twee nodes met QDevice, zonder HA : het cluster blijft bewerkbaar, maar het herstarten van de VM blijft een handmatige bewerking.
- Twee nodes zonder QDevice : de overlevende verliest het quorum en
/etc/pvewordt in de praktijk onbewerkbaar. - Gerepliceerde ZFS : de beschikbare schijf op het doel komt overeen met de laatste geslaagde synchronisatie ; latere schrijfacties zijn verloren.
Voor enig handmatig herstel moet u ervoor zorgen dat de defecte node werkelijk uit staat of geïsoleerd is van de opslag en het netwerk van het cluster. Deze fencing voorkomt dat twee instanties van dezelfde VM toegang krijgen tot dezelfde gegevens.
pvecm expected 1 enkel in nood gebruiken
Zonder QDevice is het mogelijk om op de enige overlevende tijdelijk het aantal verwachte stemmen te verlagen :
pvecm status
pvecm expected 1Dit commando dient voor noodherstel, niet voor dagelijks gebruik. Voer het enkel uit als bevestigd is dat de tweede node uit staat en niet kan herverbinden tijdens de interventie. Voer het strikt noodzakelijke minimum uit, herstel daarna het normale quorum en breng nooit beide kanten weer online met afwijkende statussen.
Voor een VM die niet door HA beheerd wordt en waarvan alle schijven al toegankelijk zijn vanaf de overlevende, staat de Proxmox-documentatie toe om zijn configuratiebestand te verplaatsen naar de map van de actieve node. Voorbeeld voor VM 100 :
mv /etc/pve/nodes/pve-b/qemu-server/100.conf \
/etc/pve/nodes/pve-a/qemu-server/Gebruik dit commando niet als de schijven niet aanwezig en consistent zijn op pve-a. Het wijzigt de logische eigenaar van de configuratie ; het kopieert de gegevens niet. Voor een guest die door HA beheerd wordt, laat u de HA-manager en het fencing-mechanisme het herstel uitvoeren.
Waarom u een node geen twee permanente stemmen mag geven
Het wijzigen van /etc/pve/corosync.conf om twee stemmen toe te kennen aan een « primaire » host lijkt de blokkade op te lossen wanneer de andere server gestopt is. In werkelijkheid verandert deze asymmetrie de eerste node in de arbiter van zijn eigen partitie en verzwakt het het beveiligingsmodel van het cluster.
Als het netwerk uitvalt terwijl beide machines werken, kan de bevoorrechte node blijven schrijven, terwijl de andere een andere situatie ziet. Een opslagfout, een onverwachte opstart of een configuratieherstel kan dan tegenstrijdige statussen creëren. De QDevice bestaat juist om de derde stem toe te vertrouwen aan een onafhankelijk systeem dat in staat is slechts één kant te verkiezen.
Validatieplan voor productie
- Controleer
pvecm statusen de aanwezigheid van de drie stemmen met QDevice. - Test een hot migratie in beide richtingen.
- Maak een korte replicatie aan, controleer het logboek en migreer daarna de VM om de omkering van richting te verifiëren.
- Stop een testnode netjes en bevestig dat de overlevende quorate blijft.
- Test het verlies van de QDevice alleen : de twee verenigde hypervisors moeten blijven functioneren.
- Controleer de opstartvolgorde, de uitschakeltijden en de QEMU Guest Agent van de belangrijke VM's.
- Herstel een back-up op een test-ID voordat u het plan als gevalideerd beschouwt.
- Documenteer de adressen, Corosync-links, opslag, afhankelijkheden en fencing-procedures.
Conclusie
Een Proxmox-cluster met twee nodes is erg nuttig voor de centralisatie van het beheer, het verplaatsen van VM's en het repliceren van ZFS-volumes. Men mag deze functies echter niet verwarren met een volledige high availability. Zonder een derde stem immobiliseert het verlies van een lid opzettelijk de overlevende om de coherentie te beschermen.
De juiste compacte architectuur is dus duidelijk : twee equivalente Proxmox-nodes, een betrouwbaar Corosync-netwerk, consistente opslag, een onafhankelijke QDevice, bewaakte replicaties en gescheiden back-ups. De beschikbaarheid komt voort uit al deze mechanismes samen, niet louter uit het feit dat twee servers onder hetzelfde datacenter verschijnen.
Technische referenties
Daarna lezen
Over de auteur
Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.
Discussie
Reacties
Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.