De ZFS-replicatie in Proxmox VE 9.2 maakt het mogelijk om een kopie van virtuele machines en containers op een tweede server te behouden zonder gedeelde opslag. Deze functie kan kleine en middelgrote ondernemingen helpen bij het herstellen van diensten wanneer een knooppunt uitvalt, maar heeft een belangrijke beperking die u moet kennen voordat u de infrastructuur ontwerpt: de kopie is niet altijd up-to-date en de laatste gegevens kunnen verloren gaan bij een plotselinge uitval. Daarnaast is voor automatische herstel in een twee knooppunt cluster een juiste oplossing voor quorum met een derde stem nodig.
De kernpunten van ZFS-replicatie in Proxmox VE 9.2 in 20 seconden
- De replicatie maakt gebruik van ZFS-snapshots die periodiek wijzigingen tussen servers overdragen.
- De standaardinterval is 15 minuten, maar kan worden teruggebracht tot slechts één minuut.
- Beide knooppunten moeten lokale, compatibele ZFS-opslag hebben en dezelfde opslagidentificatie.
- Een externe QDevice levert de derde stem die nodig is om het quorum te behouden bij uitval van een knooppunt.
- Replicatie vervangt geen back-ups en garandeert geen gegevensverliesloze herstelmogelijkheden.
Deze oplossing is interessant voor bedrijven die een tweede server willen hebben voor snelle dienstherstel zonder de kosten van gedeelde opslaginfrastructuur. Het resultaat hangt echter af van de configuratie van Proxmox, de beschikbare capaciteit op de backup-knooppunt, netwerkomstandigheden en de herstelbehoeften van elke applicatie.
De documentatie van Proxmox VE 9 bevat wijzigingen in de configuratie van replicatie en high availability die oude handleidingen beïnvloeden. Zo is het nu mogelijk om een dedicated netwerk voor replicatie te gebruiken en kunnen node-affiniteitsregels in plaats van verouderde high-availability-groepen worden toegepast.
Hoe werkt ZFS-replicatie tussen twee servers
De tool in Proxmox VE die dit beheert heet pvesr. Het werkt op basis van ZFS-snapshots; eerst wordt een volledige volume overgedragen, daarna worden alleen de veranderingen sinds de laatste snapshot gestuurd.
Bij een installatie met twee knooppunten blijft een machine actief en schrijft in zijn lokale disks. De andere ontvangt de replica en houdt een actuele kopie beschikbaar voor snel herstel indien de primaire server uitvalt.
Het standaardinterval van 15 minuten kan worden aangepast van één minuut tot zelfs een week. Hoe korter de interval, des te minder gegevens er verloren gaan bij uitval, maar ook de belasting op het netwerk en systeem neemt toe. Bij uitval van de hoofdserver vóór het moment van replicatie kunnen recent geschreven gegevens verloren gaan.
Replicatie maakt geen gedeelde opslag van de disks; elke machine schrijft alleen op haar eigen node, en de ander houdt via geplande taken een actuele kopie bij.
Wat opslagcompatibiliteit betreft: in Proxmox VE 9.2 ondersteunt de ingebouwde replicatie alleen lokale ZFS-opslag, aangeduid als zfspool. Het werkt niet automatisch met andere volumetypen zoals LVM-thin, directories of QCOW2-afbeeldingen, dus controleer waar al je disks staan voordat je de replicatie implementeert.
De derde stem: essentieel voor high availability
Een belangrijke factor voor het functioneren van een twee knooppunt cluster is het quorum. Proxmox gebruikt Corosync voor clustercoördinatie en heeft een meerderheid van stemmen nodig om operaties voort te zetten.
Met slechts twee knooppunten geeft elk één stem, waardoor de uitval van één knooppunt het andere knooppunt zonder meerderheid achterlaat. Hoewel de disks van de virtuele machines worden gerepliceerd, betekent dit niet automatisch dat service automatisch herstart wordt.
De oplossing hiervoor is een QDevice: een externe component die een extra stem toevoegt. Het corosync-qnetd-service kan op een losstaand apparaat of in een aparte infrastructuur draaien, mits niet afhankelijk van dezelfde servers die uit kunnen vallen.
De QDevice wordt niet gebruikt voor opslag of VM-data; zijn taak is om mee te beslissen over het quorum. Met twee knooppunten en een derde stem kan het cluster de meerderheid behouden wanneer een server wegvalt.
De installatie vereist dat je corosync-qnetd op het externe apparaat installeert en corosync-qdevice op de Proxmox-knooppunten. Daarna registreer je het apparaat met pvecm qdevice setup en controleer je de status met pvecm status.
Zorg er ook voor dat de overige knooppunten voldoende resources hebben voor het draaien van de workload van het geknipte knooppunt. Bij maximale belasting riskeert hersteltrajecten problemen met geheugen en processorgebruik.
Wijzigingen in Proxmox VE 9 en wat verloren gaat bij uitval
Proxmox VE 9 introduceert nieuwe instellingen die de configuratie verbeteren. Zo kan replicatie een apart netwerk gebruiken dat losstaat van de beheer- of migratienetwerken. High availability kan nu regels voor node-affiniteit gebruiken, in plaats van verouderde HA-groepen.
Ook wordt het terugkoppelen van virtuele machines naar hun voorkeursknooppunt anders geregeld, en automatisch terugplaatsen is standaard aangezet, maar kan worden uitgeschakeld om handmatig te controleren.
Bij uitval detecteert HA automatisch het probleem, checkt of het herstarten mogelijk is en zet de virtuele machine weer aan volgens de laatst beschikbare replica. De geschatte hersteltijd ligt rond twee minuten, afhankelijk van de omstandigheden.
De RTO (Recovery Time Objective) gaat over de tijd die het kost om de service te herstellen, terwijl de RPO (Recovery Point Objective) de maximale hoeveelheid gegevensverliezen meet. Een kortere replicatieintervallen verkleinen de RPO, maar garanderen geen nulverlies.
Applicaties die geen gegevensverlies kunnen verdragen, zoals databases, vereisen additionele maatregelen, bijvoorbeeld realtime replicatie of synchrone opslagoplossingen.
Replicatie vervangt geen back-upstrategieën. Verwijderingen of aanvallen kunnen nog steeds gegevensverlies veroorzaken. Voor het herstellen van eerdere versies zijn back-ups met geschiedenis nodig die buiten het cluster worden bewaard en getest.
ZFS, Ceph of gedeelde opslag: welke optie past het beste?
ZFS-replicatie gebruikt lokale disks op beide servers, wat een goede optie is voor bedrijven die geen gedeelde opslag willen aanschaffen en accepteren dat er minimale gegevensverlies is na de laatste replicatie. Het biedt snelle herstelopties, maar met een korte window voor gegevensverlies.
Ceph biedt een gedistribueerde opslagoplossing en kan geschikt zijn voor grootschalige of veerkrachtige omgevingen, mits de netwerkinfrastructuur en onderhoudsdiensten goed zijn ingericht om redundantie te garanderen en bottlenecks te voorkomen.
De keuze hangt af van de servicevereisten. Interne applicaties kunnen enkele minuten dataverlies tolereren, terwijl kritische systemen zoals transactiedatabases of financiële diensten vaak een oplossing vereisen met hogere betrouwbaarheid en minimale gegevensverliezen.
Voordat je een twee knooppuntcluster in gebruik neemt, controleer je dat alle ZFS-pools dezelfde naam hebben, dat de QDevice los staat van het cluster en dat de replicatie-netwerken niet conflicteren met andere diensten zoals Corosync. Het is ook verstandig om een echte uitval te simuleren, de herstelduur te meten en te beoordelen welke gegevens verloren kunnen gaan.
Veelgestelde vragen
Kan ik een virtuele machine repliceren zonder ZFS in Proxmox?
De ingebouwde opslagrepllocatie in Proxmox VE 9.2 ondersteunt alleen lokale ZFS. Andere opslagtypen zoals LVM-thin, directories of QCOW2-afbeeldingen kunnen niet via deze methode worden gerepliceerd.
Hoeveel gegevens kunnen verloren gaan bij uitval van een knooppunt?
Dat hangt af van de intervaltijd tussen kopieën. Bij het standaardinterval van 15 minuten kunnen gegevens geschreven na de laatste snapshot verloren gaan. Bij korte intervallen, bijvoorbeeld één minuut, wordt die window kleiner, maar is niet volledig afwezig.
Is een QDevice noodzakelijk voor een twee knooppuntcluster?
Voor de replicatie zelf niet, maar wel voor het behouden van een werkend quorum bij onverwachte uitval. Zonder een aanvullende stem verliest het cluster de meerderheid wanneer één knooppunt uitvalt.
Vervangt ZFS-replicatie back-ups?
Nee. Replicatie brengt onbedoelde wijzigingen over, zoals verwijderingen en ransomware-versleutelde bestanden. Het is essentieel om aparte back-ups te behouden, met geschiedenis en buiten het cluster, voor volledige herstelmogelijkheden.