Corosync en Proxmox: wat het is en waarom het essentieel is voor een cluster

Corosync is een essentiële component die ervoor zorgt dat meerdere servers Proxmox VE als een gecoördineerde cluster werken. Het doet geen virtuele machines draaien of disks opslaan, maar houdt de communicatie tussen de knooppunten in stand, beheert de lidmaatschap en levert de informatie die nodig is om te bepalen of er quorum is. Het is een onopvallend onderdeel tijdens normaal gebruik, maar cruciaal bij server- of netwerkstoringen.

De kern van Corosync in Proxmox in 20 seconden

• Corosync zorgt voor een coördinatie tussen de knooppunten van een Proxmox-cluster.
• De lidmaatschap bepaalt welke servers deel uitmaken van het cluster, terwijl quorum bepaalt of er een voldoende meerderheid is voor beslissingen.
• Proxmox gebruikt Corosync samen met pmxcfs, Kronosnet en de high-availability (HA) systemen.
• Timers helpen bij het detecteren van storingen en het reorganiseren van de lidmaatschap.
• Een stabiel, redundante en lage latentie netwerk is belangrijker dan veel bandbreedte.

Bij het opzetten van een cluster met pvecm configureert Proxmox deze communicatie-infrastructuur grotendeels automatisch, zodat de beheerder niet met alle componenten direct hoeft te werken. Dit verklaart waarom je Proxmox jarenlang kunt gebruiken zonder diepgaande kennis van Corosync.

Het begrijpen van Corosync is nuttig omdat concepten zoals cluster, quorum, Corosync, fencing, watchdog, QDevice, HA of Ceph gerelateerd zijn, maar verschillende problemen oplossen. Het verwarren van deze termen kan leiden tot de illusie dat een cluster high-availability biedt, terwijl het in feite alleen uit meerdere servers bestaat.

Wat is Corosync en welke rol speelt het binnen Proxmox

Corosync is een communicatiemotor voor clusters die in diverse high-availability projecten op Linux wordt gebruikt. Proxmox VE gebruikt het als onderdeel van de clusterarchitectuur om te zorgen dat servers een coherente visie hebben op wie deel uitmaakt van het cluster.

Een cluster kan bijvoorbeeld bestaan uit:

De servers moeten weten dat ze tot hetzelfde cluster behoren en actuele informatie uitwisselen over de aanwezigheid van de andere knooppunten.

Als PVE03 niet meer reageert, is het niet genoeg om dit als offline te markeren. PVE01 en PVE02 moeten samen een nieuwe lidmaatschap overeenkomen waarin PVE03 niet meer deelneemt.

Hier komt een van de belangrijkste functies van Corosync om de hoek kijken.

Lidmaatschap

Lidmaatschap beschrijft welke knooppunten op dat moment deel uitmaken van het cluster.

Het kan veranderen doordat een server uitvalt, wordt herstart, de connectiviteit verliest of zich opnieuw aansluit.

Dit concept is belangrijk omdat een server die leeg lijkt te zijn, nog steeds actief kan zijn maar geïsoleerd kan zijn door netwerkproblemen.

Quorum

Het tweede concept is quorum.

Proxmox gebruikt een stemmodel om te bepalen of een deel van het cluster voldoende autoriteit heeft om door te gaan met operationele taken.

In een eenvoudig voorbeeld met drie knooppunten:

Als PVE03 uitvalt, blijven er twee stemmen over uit drie. Er is een meerderheid en dus quorum.

Als PVE01 volledig geïsoleerd raakt van de andere twee, heeft het slechts één stem. Het kan niet met zekerheid vaststellen of PVE02 en PVE03 daadwerkelijk uitgeschakeld zijn of dat ze door een netwerkonderbreking nog steeds functioneren.

Quorum voorkomt dat beide partijen gelijktijdig dezelfde resources controleren of wijzigen, wat de consistentie beschermt.

Dit is een belangrijke bescherming tegen split brain, een heel gevaarlijke situatie in gedistribueerde systemen waarin verschillende servergroepen denken dat zij de juiste groep zijn.

Daarom spreekt men vaak over drie knooppunten in Proxmox. Het gaat niet per se om betere virtualisatie met drie servers, maar drie stemmen zorgen dat er een meerderheid van twee overblijft, zelfs bij verlies van één knooppunt.

Corosync, Kronosnet, pmxcfs en QDevice: de onderdelen en hun rol

Corosync werkt niet geïsoleerd. Rondom Corosync ontsluiten zich verschillende componenten die belangrijk zijn om te onderscheiden.

Door deze functies te scheiden wordt duidelijk wat er gebeurt bij storingen.

Kronosnet: het transport

De actuele versies van Corosync gebruiken Kronosnet, vaak afgekort tot knet, als transportlaag.

Het zorgt voor het transport van communicatie tussen knooppunten en ondersteunt meerdere verbindingen tussen servers.

Praktisch betekent dit dat een cluster redundantie kan bieden in de communicatie. Maar die redundantie moet wel in de infrastructuur aanwezig zijn.

Twee verbindingen via verschillende VLAN’s, switch-portals of fysieke kabels kunnen nog steeds één enkel punt van uitval vormen als ze door hetzelfde fysieke apparaat lopen.

pmxcfs: het gedistribueerde configuratiesysteem van Proxmox

Proxmox voegt een ander belangrijke component toe: Proxmox Cluster File System (pmxcfs).

Dit is het bestandssysteem dat wordt gemount op /etc/pve en deelt configuraties tussen de clusterknopen.

Hier staan VM-instellingen, storageconfiguraties, gebruikers en meer. pmxcfs gebruikt de informatie van Corosync om de consistentie van het cluster te waarborgen. Als een knooppunt het quorum verliest, past het bestandssysteem zich aan om conflicten te voorkomen.

Daarom kan het gebeuren dat je na verlies van quorum /etc/pve slechts in leesm.bewaarmodus hebt. Het is geen simpel bestandsrecht probleem, maar een gedrag dat door Corosync wordt gestuurd.

pvecm: het beheerhulpmiddel voor de beheerder

Proxmox biedt pvecm als een commandoregelinterface voor clusterbeheer.

Een basiscommando is bijvoorbeeld:

pvecm status

Dit geeft informatie over het aantal knooppunten, stemmen, quorumstatus en algemene status.

Een ander handig commando is:

pvecm nodes

De Corosync-configuratie van Proxmox is te vinden in:

/etc/pve/corosync.conf

Dit is een cruciaal configuratiebestand dat niet zonder kennis moet worden aangepast.

QDevice en waarom het relevant is bij twee-knoppencusters

Een cluster met twee knooppunten biedt een duidelijk probleem.

Als elke server één stem heeft en de verbinding tussen hen wordt verbroken, weet geen van beiden zeker of de andere uitgeschakeld is of slechts geïsoleerd door netwerkproblemen.

Proxmox biedt voor kleine clusters de oplossing door een QDevice te gebruiken, meestal ondersteund door een externe QNetd. Dit fungeert als een externe stem voor quorumbesluiten.

Het hoeft niet per se een tweede Proxmox-server te zijn; het kan bijvoorbeeld ook een eenvoudige hardwarearbitragemachine of een externe service zijn.

Deze opzet kan er zo uitzien:

Het verschil is dat QDevice een stem toevoegt, maar geen herstelcapaciteit biedt.

Als PVE01 uitvalt, kan PVE02 nog steeds de juiste quorumstatus handhaven, mits de QDevice aanwezig is. Maar alle VM’s die in dat cluster aanwezig zijn, moeten op PVE02 kunnen draaien.

Een derde stem geeft geen CPU, RAM of opslag; het is puur voor stemmogelijkheden.

Token en consensus: hoe Corosync weet dat er iets is veranderd

Om het cluster te coördineren gebruikt Corosync verschillende timers, waaronder token en consensus.

token is onderdeel van het mechanisme dat probleeme detecteert in de circulatie ervan tussen leden.

consensus is betrokken bij het tot stand brengen van een nieuwe lidmaatschap.

Deze parameters verklaren waarom het niet direct reageert als een server uitvalt. In een gedistribueerd systeem is een te snelle reactie vaak juist gevaarlijk.

Verloren pakketten of enkele milliseconden vertraging mogen niet leiden tot het onterecht uitschakelen van een werkende server.

Daarom bestaan timers. Ze voorkomen overhaaste acties.

Een ander gevolg is dat het verlagen van de waarden van Corosync voor snellere failover vaak juist het tegenovergestelde effect kan hebben: onstabiele netwerken kunnen valse detecties en onnodige lidmaatschapswijzigingen veroorzaken.

De grootte van het cluster speelt ook een rol. Corosync gebruikt token_coefficient om de tijd aan te passen naarmate het aantal knooppunten toeneemt.

Vanaf Proxmox VE 9.2 wordt een expliciete coefficient van 125 ms gebruikt voor nieuwe clusters, tegenover de oude setting van 650 ms die in eerdere versies gebruikelijk was.

Dit is vooral relevant voor grote clusters, maar kan ook worden behouden bij upgrades. Het is daarom beter om de werkelijke waarden te controleren dan te gokken op de standaardinstellingen.

Controleer de actuele timers met:

corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'

Deze timers zijn belangrijk, vooral in grote infrastructuren. Maar Corosync omvat veel meer dan alleen token en consensus. Het is vooral bedoeld om een consistente en coherente clusterweergave te behouden.

Corosync en Proxmox HA: de relatie

Corosync is niet hetzelfde als de high-availability (HA) van Proxmox.

Het levert de basisinformatie die HA nodig heeft om te functioneren.

Wanneer een VM als HA-resource wordt ingesteld, Proxmox HA Manager bewaakt waar deze moet draaien en kan ingrijpen bij bepaalde storingen.

1. Een host verliest de connectie of valt uit.
2. Corosync detecteert de verandering.
3. De overblijvende leden stemmen een nieuwe lidmaatschap af.
4. Er wordt bepaald of quorum aanwezig is.
5. Fencing mechanisme worden ingezet om conflicten te voorkomen.
6. De HA Manager kan resources op andere servers herstellen.

Hiermee wordt duidelijk dat HA niet gelijk staat aan Live Migration.

Bij live migratie blijft de oorspronkelijke host actief en participeert actief in het overplaatsen van de VM. Bij een plotselinge uitval is de bronhost verdwenen en krijgt de VM een herstel op een andere node, waarna deze wordt opgestart.

Watchdog en fencing

Proxmox gebruikt een watchdog in zijn HA-architectuur.

Als een node de quorum verliest en het watchdog niet meer kan onderhouden, kan dit leiden tot automatische herstarten (self-fencing). Proxmox stelt hiervoor ongeveer 60 seconden in.

De logica is conservatief: voorzichtigheid staat voorop.

Voordat een resource wordt overgenomen door een ander node, moet worden verzekerd dat de eerder geïsoleerde node deze niet meer gebruikt.

Fencing voorkomt dat twee servers gelijktijdig eigenaar worden van hetzelfde resource.

De timers in Corosync en de watchdog werken samen. Proxmox raadt aan voldoende ruimte te laten voor het vormen van een nieuwe lidmaatschap, voordat het fencing limiet wordt bereikt.

Het ontwerp van het Corosync-netwerk

Een van de kenmerken van Corosync is dat het niet per se hoge bandbreedte vereist, maar wel een stabiel netwerk met lage latency.

Dit is een belangrijke overweging.

Een betrouwbare 1 Gbit/s verbinding kan voor sommige setups volstaan, terwijl een 25 Gbit/s-verbinding die wordt gebruikt voor Ceph, migraties, en backups, mogelijk slechtere omstandigheden creëert voor Corosync-verkeer.

Proxmox adviseert om aandacht te besteden aan de netwerkconfiguratie en, waar mogelijk, meerdere verbindingen te gebruiken via Kronosnet.

Voor bedrijfsomgevingen wordt geadviseerd te letten op:

• Latentie tussen knooppunten
• Packet loss
• Jitter
• Redundantie van interfaces
• Redundantie van switches
• Consistente MTU
• Netwerkcongestie
• Splitsing van zwaar verkeer
• Fysieke scheiding van fysieke paden

Dit is des te belangrijker wanneer Proxmox wordt gebruikt in combinatie met Ceph.

Ceph genereert tijdens herstel, herverdelen en reconstrueren grote hoeveelheden verkeer. In die momenten is het extra belangrijk dat Corosync en opslag niet de schouders ophalen door gedeelde infrastructuur te gebruiken die onder druk staat.

Corosync is niet Ceph

De aanwezigheid van zowel Corosync als Ceph in veel Proxmox-implementaties kan leiden tot verwarring.

Corosync coördineert het Proxmox-cluster.

Ceph verzorgt gedistribueerde opslag.

Een installatie kan zonder Ceph werken, bijvoorbeeld met gedeelde opslag via NFS, iSCSI of Fibre Channel.

Het is ook mogelijk om beide te gebruiken, maar dan zijn er twee verschillende distributed systems met eigen netwerken en timers. Het quorum van Corosync betekent niet automatisch dat Ceph operationeel is en vice versa.

Wat moet een Proxmox-beheerder over Corosync weten

Het is niet nodig om iedere parameter in corosync.conf uit je hoofd te kennen om een Proxmox-omgeving goed te beheren.

Wel is het nuttig om enkele vragen te kunnen beantwoorden:

De laatste vraag, over capaciteit, valt buiten Corosync, maar is wel een van de belangrijkste. Een cluster kan perfect quorum hebben, correct geconfigureerd zijn en een goed netwerk, maar nog steeds niet voldoende high availability bieden als de overige knooppunten niet over voldoende CPU en RAM beschikken om de verloren VM’s te herstellen.

Back-ups behoren niet tot Corosync. Ze zorgen voor gegevensherstel, bijvoorbeeld na ransomware-aanvallen, corruptie of per ongeluk verwijderen, en vallen onder andere beheerprocedures.

Het begrijpen van de grenzen van Corosync helpt te plaatsen waar het thuishoort. Het is de laag die ervoor zorgt dat Proxmox-leden een eenduidige visie behouden over wie nog deel uitmaakt van het cluster en wie beslissingsbevoegd is.

Corosync blijft vaak stil, maar het is belangrijk het te kennen voordat je geconfronteerd wordt met een server die niet meer reageert.

Veelgestelde vragen

Wat is Corosync in Proxmox?

Corosync is het systeem dat Proxmox VE gebruikt voor communicatie, lidmaatschap en quorum services tussen de knooppunten in een cluster. Het zorgt voor een coherente weergave van de samenstelling van het cluster.

Kan Proxmox zonder Corosync werken?

Een standalone Proxmox-server heeft geen cluster nodig. Corosync wordt relevant wanneer meerdere knooppunten worden gebruikt voor clustering. Dan vormt Corosync de communicatiebasis.

Biedt Corosync high availability?

Niet op zichzelf. Corosync zorgt alleen voor communicatie, lidmaatschap en quorum. High-availability in Proxmox wordt gecreëerd door een combinatie van Corosync, HA Manager, fencing en storage-oplossingen.

Heeft Corosync een dedicated netwerk nodig?

Proxmox raadt aan om speciale aandacht te besteden aan de netwerkconfiguratie van Corosync. Het is niet zozeer de bandbreedte die telt, maar de lage latency, betrouwbaarheid en redundantie van de verbindingen. Veel netwerkfouten kunnen de werking verstoren, vooral bij grote infrastructuren met intensief gebruik van Ceph en back-up verkeer.