Een Proxmox-cluster met 47 knooppunten kan meer dan 70 seconden solely in Corosync overschrijden

Een Proxmox VE-cluster van 47 knooppunten dat de historische timers van Corosync behoudt, kan ongeveer 70,95 seconden tussen token en consensus bereiken voordat een nieuwe lidmaatschap wordt gevormd na het verlies van een knooppunt. Deze waarde geeft niet de totale hersteltijd van virtuele machines weer, maar onthult wel een belangrijk probleem: het overschrijdt de watchdog-tijd van 60 seconden die Proxmox HA gebruikt voor zelfbeveiliging (self-fencing). Een dergelijke infrastructuur zou haar configuratie moeten herzien voordat men ervan uitgaat dat de instellingen nog steeds geschikt zijn.

De sleutels van Corosync in een Proxmox-cluster van 47 knooppunten binnen 20 seconden

• Met een token van 3.000 ms en een factor van 650 ms brengen 47 knooppunten het token effectief op 32,25 seconden.
• Het automatische consensus komt ongeveer uit op 38,70 seconden.
• De totale tijd bedraagt dus ongeveer 70,95 seconden.
• Met de nieuwere token_coefficient van 125 ms in Proxmox VE 9.2 daalt dit naar ongeveer 18,98 seconden.
• Bij meer dan 32 knooppunten is het raadzaam ook andere parameters en vooral de netwerkkwaliteit van Corosync te herzien.

Het verschil is significant vergeleken met een cluster van 10 of 15 servers, aangezien het effectieve timing van Corosync niet constant blijft wanneer de token_coefficient wordt gebruikt.

Dit mechanisme is bedoeld om automatisch de tijd te laten toenemen naarmate het cluster groeit, zodat het protocol voor lidmaatschap zonder handmatige aanpassingen kan werken wanneer er nieuwe knooppunten worden toegevoegd.

Het probleem ontstaat wanneer een cluster jaren groeit en een oude configuratie aanhoudt. Een waarde die met slechts vijf servers weinig effect had, kan nu tientallen seconden extra toevoegen wanneer het aantal knooppunten in de tientallen loopt.

Van 3 seconden tot 32,25 seconden effectieve token-tijd

In de traditionele versies van Corosync die Proxmox gebruikt, begint token bij 3.000 ms en is de token_coefficient meestal 650 ms, tenzij anders gespecificeerd.

Voor een cluster van minstens drie knooppunten wordt de effectieve tijd berekend met:

effectief token = token + (aantal knooppunten - 2) × token_coefficient

Corosync documenteert deze formule. Het doel is om automatisch de timers aan te passen naarmate het cluster groter wordt.

Voor 47 knooppunten geeft dat:

3.000 + (47 - 2) × 650

Dat zijn 45 knooppunten meer dan de eerste twee, dus:

45 × 650 = 29.250 ms

En de totale effectieve tokentijd wordt:

3.000 + 29.250 = 32.250 ms

Dus het effectieve token is 32,25 seconden.

Het consensus wordt doorgaans automatisch berekend als minimaal 1,2 keer de effectieve token:

32.250 × 1,2 = 38.700 ms

De som van deze twee geschatte timers bedraagt zo:

32.250 + 38.700 = 70.950 ms

Dat is ongeveer 70,95 seconden.

Deze waarden zijn calculaties van timers, geen metingen van de daadwerkelijke tijd die nodig is voor herstel van applicaties.

Deze onderscheid is belangrijk, omdat na het vormen van de nieuwe lidmaatschap nog steeds Proxmox HA Manager, fencing, opslag, CPU- en RAM-bronnen, opstarten van VM’s en herstel van services kunnen plaatsvinden.

Maar 70,95 seconden is opvallend om een andere reden.

De 70,95 seconden botsen met de watchdog van Proxmox HA

Proxmox gebruikt een watchdog als onderdeel van het self-fencing-mechanisme.

Een knooppunt met high availability dat quorum verliest, kan haar watchdog niet meer correct beheren en, indien het quorum niet wordt hersteld, wordt het automatisch opnieuw opgestart zodra de timer verloopt. Proxmox documenteert hiervoor een timeout van circa 60 seconden.

Het doel hiervan is te voorkomen dat een geïsoleerd knooppunt doorgaat met het draaien van virtuele machines, terwijl andere clusteronderdelen denken dat ze deze kunnen ophalen.

Daarom benadrukt Proxmox dat de timers voor het vormen van nieuwe lidmaatschappen voldoende speling moeten hebben ten opzichte van de watchdog-tijd.

Voor een cluster van 29 knooppunten en een token_coefficient van 650 ms was de totale geschatte tijd ongeveer 45,21 seconden.

Bij 47 knooppunten wordt dat 70,95 seconden, wat de grens overschrijdt van de geadviseerde 60 seconden watchdog-tijd.

Kortom, dit gaat niet meer alleen om het beperken van de wachttijd, maar de theorie wijst uit dat de timers deze limiet ruimschoots overschrijden.

Dit betekent niet dat een cluster met 47 knooppunten willekeurig servers zou moeten herstarten bij elk verlies van een lid. Het daadwerkelijke gedrag hangt af van welke knooppunten connectivity verliezen, de netwerktopologie, quorumstatus, berichtenuitwisseling tussen Corosync en andere timers.

Wat we wel kunnen zeggen, is dat een cluster van 47 knooppunten niet zonder meer met deze waarden zou moeten werken zonder expliciete herziening.

Met 125 ms daalt hetzelfde cluster tot ongeveer 19 seconden

Proxmox heeft haar aanpak aangepast door de token_coefficient aanzienlijk te verlagen in nieuwe clusters.

De documentatie voor Proxmox VE 9.2 geeft nu een token_coefficient van 125 milliseconden in plaats van de oude 650 ms voor nieuwe clusters.

Ook voor een cluster van 47 knooppunten levert dat een veel kleinere timer:

3.000 + (47 - 2) × 125

45 × 125 = 5.625 ms

De totale geschatte timers worden dan:

3.000 + 5.625 = 8.625 ms

Het geschatte consensus:

8.625 × 1,2 = 10.350 ms

En de som wordt:

8.625 + 10.350 = 18.975 ms

Dus ongeveer 18,98 seconden.

De vermindering is ongeveer 52 seconden, enkel door het aanpassen van de coefficient.

In percentage daalt de som van token + consensus met ongeveer 73 %.

Dit betekent niet dat virtuele machines automatisch 52 seconden sneller herstellen onder elke situatie, want er zijn meer processen en afwachttijden. Maar het verlicht wel een aanzienlijk onderdeel van het detectie- en herordeningproces binnen het cluster.

Een upgrade van Proxmox 8 naar 9 betekent niet automatisch de nieuwe waarde krijgen

Dit is een belangrijk aandachtspunt voor beheerders.

Het nieuwe gedrag wordt toegepast op nieuwe clusters die worden aangemaakt met de huidige Proxmox VE-versies. Een bestaande infrastructuur behoudt gewoonlijk haar corosync.conf en een update vanuit een oudere versie betekent niet automatisch dat de parameters voor Corosync worden aangepast.

Met andere woorden: een cluster dat jaren heeft uitgebreid, kan nog steeds Proxmox VE 9 draaien en een configuratie gebruiken die is ingesteld toen het minder knooppunten had.

De effectieve waarden van timers controleren is simpel met:

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

Het is belangrijk om de daadwerkelijke runtime-waarden te controleren, niet te geloven dat deze automatisch veranderen door de upgrade.

Voor een cluster van 47 knooppunten dat de oude coefficient zou gebruiken, zouden de waarden circa zijn:

runtime.config.totem.token = 32250
runtime.config.totem.consensus = 38700

Met de nieuwe coefficient (125 ms) zou dat ongeveer zijn:

runtime.config.totem.token = 8625
runtime.config.totem.consensus = 10350

De exacte waarden komen altijd uit het cluster zelf.

Het rechtstreeks aanpassen van token_coefficient op basis van tabellen wordt afgeraden. Corosync adviseert dat timers consistent moeten zijn en afgestemd op het daadwerkelijke netwerkgedrag, vooral in verbindingen met packet loss en jitter.

Een cluster van 47 knooppunten en de parameter send_join

Bij grote clusters is er nog een extra aandachtspunt: voor clusters groter dan 32 knooppunten wordt in de documentatie aangegeven dat de parameter send_join relevant kan worden tijdens de formatie van nieuwe lidmaatschappen.

Voor kleinere clusters is dit meestal niet nodig, maar bij meer dan 32 knooppunten kan het helpen om te voorkomen dat het netwerk overspoeld raakt met join-berichten, wat de netwerkbelasting en timings beïnvloedt.

Het wordt aanbevolen om voor grote clusters de documentatie en eventueel specialistisch advies te raadplegen, omdat het gehele configuratieproces complexer wordt en afhankelijk is van de netwerktopologie en het quorum.

Voor een cluster van 47 knooppunten wordt dit steeds relevanter en het is verstandig om Corosync niet te behandelen als een secundair beheersysteem, maar als een core-infrastructuur binnen het cluster.

Netwerkprestaties zijn crucialer dan het verminderen van knooppunten

Hoewel Corosync normaal gesproken geen grote bandbreedte vereist, zijn lage latency, stabiliteit en geen pakketverlies essentieel voor betrouwbaar functioneren op grote schaal.

Bij 47 knooppunten wordt het aantal relaties en berichten dat moet worden verwerkt bij lidmaatschap-wijzigingen aanzienlijk groter. Daarom is een goede netwerkconditie noodzakelijk en moeten aspecten zoals latency, packet loss, redundantie, MTU-afstemming en beveiliging worden gecontroleerd.

Daarnaast is testen van de reactie van het cluster bij het uitvallen van een knooppunt cruciaal om de werkelijke reactiviteit en hersteltijd te meten. Dit omvat niet alleen het zien of het knooppunt als offline wordt weergegeven, maar vooral de volledige reactietijd totdat de diensten weer operationeel zijn.

De echte hersteltijd omvat:

Corosync detectie → nieuwe lidmaatschap → fencing → HA Manager → opslagtoegang → VM opstarten → applicatie opstarten

Het unieke tijdsverloop hangt af van de netwerkarchitectuur, beschikbare bronnen en de hele keten van herstelstappen. Als hardware of opslag niet krachtig genoeg is, kunnen snelle timers geen snelle hersteling garanderen.

Het aanpassen van token geeft een indicatie, maar is geen volledig beeld van high availability prestaties. Als bij een 47-knooppunten cluster effectief 70,95 seconden wordt gevonden, wijst dat vooral op de noodzaak om het ontwerp te herzien. Een timer van 18,98 seconden betekent niet automatisch dat alles probleemloos is, maar dat de timers momenteel veel speling bieden ten opzichte van de watchdog.

Veelgestelde vragen

Hoe lang duurt Corosync met 47 knooppunten en een coefficient van 650 ms?

Met een token van 3.000 ms en een coefficient van 650 ms, wordt het effectieve token ongeveer 32,25 seconden, en het consensus rond 38,70 seconden. Samen is dit circa 70,95 seconden.

Wat is de timing met een token_coefficient van 125 ms?

Voor hetzelfde cluster van 47 knooppunten wordt het effectieve token ongeveer 8,63 seconden, en consensus rond 10,35 seconden. De totale timer komt dan uit op ongeveer 18,98 seconden.

Worden timers automatisch aangepast bij een upgrade naar Proxmox VE 9?

Niet per definitie. Bij nieuwe clusters wordt de token_coefficient zoals beschreven momenteel ingesteld op 125 ms, maar bestaande clusters behouden mogelijk hun oude configuratie. Het is aanbevolen om de actuele timerwaarden te controleren met:

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

Is het mogelijk om de coefficient direct te veranderen van 650 naar 125 ms?

Dit wordt afgeraden zonder eerst de netwerkcondities en de huidige configuratie te evalueren. Vermindering van timers in een onstabiel netwerk kan leiden tot false positives en andere problemen. Corrigeer de timers pas nadat je de netwerkstabiliteit goed hebt vastgesteld.

Over send_join en grote clusters van meer dan 32 knooppunten

Bij grote clusters maakt de parameter send_join een verschil. Corosync vermeldt dat voor clusters met >32 knooppunten aandacht nodig is voor send_join, omdat het tijdens de formatie van lidmaatschappen kan helpen voorkomen dat het netwerk overspoeld raakt door join-berichten.

Voor kleinere clusters is dit meestal niet nodig. Maar bij grote clusters is goede afstemming en eventueel advies van een specialist aanbevolen, omdat de netwerkbelasting kan toenemen en de timing accurater moet worden afgestemd op de topologie en quorum.

Dit voorbeeld van 47 knooppunten toont dat het belangrijk is om Corosync niet als secundaire netwerklaag te zien, maar als een kerncomponent waarvan de configuratie en performantie nauwkeurig moet worden afgestemd op de omgeving.

Netwerkprestaties: meer dan alleen het verminderen van knooppunten

Corosync verlangt niet veel bandbreedte onder normale omstandigheden, maar lage latency, stabiliteit en geen pakketverlies zijn essentieel, vooral bij grotere clusters.

Bij 47 knooppunten worden alle relaties en berichten bij lidmaatschap-wijzigingen vele malen groter. Daarom moet de netwerkkwaliteit zorgvuldig worden gecontroleerd op onder andere latency, packet loss, redundantie, MTU-instellingen en beveiliging.

Bovendien is het belangrijk om te testen wat er gebeurt wanneer een knooppunt uitvalt. Het is niet genoeg om alleen maar te kijken of het in Proxmox wordt weergegeven als offline. De echte prestatie-indicator is hoe lang het duurt voordat de services op een ander knooppunt wieder online zijn, inclusief:

Corosync detectie → nieuw lidmaatschap → fencing → HA management → opslag toegang → VM start → applicatie herstart

De totale tijd is afhankelijk van de hardware, netwerkomstandigheden en de hele keten van herstelstappen. Een zwakke CPU, trage opslag of gebrekkige redundantie kunnen de daadwerkelijke hersteltijd aanzienlijk verlengen, ondanks snelle timers.

Het aanpassen van token biedt een goede indicator, maar is geen volledig vervanging voor een uitgebreide HA-test. Als de timers in een 47-knooppuntencluster op 70,95 seconden liggen, is dat een teken dat het ontwerp herzien moet worden. Een gecalculeerd herstel van 18,98 seconden betekent niet dat alles vlekkeloos verloopt, maar dat de timers momenteel ruimschoots binnen veilige marges blijven.

Veelgestelde vragen

Hoe lang duurt Corosync met 47 knooppunten en een coefficient van 650 ms?

Met een token van 3.000 ms en een coefficient van 650 ms wordt het effectiefe token ongeveer 32,25 seconden, en consensus rond 38,70 seconden. Samen ongeveer 70,95 seconden.

Wat is de timing met een token_coefficient van 125 ms?

Voor hetzelfde cluster wordt het effectieve token ongeveer 8,63 seconden, en consensus circa 10,35 seconden, waardoor de totale timer ongeveer 18,98 seconden wordt.

Worden timers automatisch aangepast na een upgrade naar Proxmox VE 9?

Niet automatisch. De nieuwe standaard voor token_coefficient in nieuw aangemaakte clusters is 125 ms, maar bestaande clusters behouden mogelijk hun oude configuratie. Het is aan te bevelen om de actuele timers te controleren met:

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

Kun je de coefficient direct aanpassen van 650 naar 125 ms?

Dit wordt niet aanbevolen zonder vooraf de netwerkcondities en de huidige timers te evalueren. Een te drastische verlaging in onstabiele netwerken kan leiden tot false positives en connectiviteitsproblemen. Pas de timers pas aan nadat je netwerk en hardware goed hebt beoordeeld.

Extra aandacht bij clusters groter dan 32 knooppunten: send_join

Voor grote clusters (meer dan 32 knooppunten) beveelt de documentatie aan te letten op de parameter send_join. Deze kan nodig blijken tijdens de formatie van nieuwe lidmaatschappen om overbelasting of netwerkproblemen te voorkomen.

Voor kleinere clusters is dit meestal niet nodig. Maar voor grote varianten is het verstandig om de documentatie goed te bestuderen en mogelijk advies in te winnen, omdat de configuratiecomplexiteit en de netwerkinfrastructuur een grote rol spelen.

Voor een cluster van 47 knooppunten wordt het belang hiervan steeds duidelijker en moet Corosync niet worden beschouwd als een secundair netwerk, maar als een kerncomponent waar de stabiliteit en performance nauwkeurig op afgestemd moeten worden.

Netwerk prestaties: meer dan het aantal knooppunten reduceren

Corosync vereist geen grote bandbreedte in normale omstandigheden, maar lage latency, stabiliteit en geen pakketverlies zijn essentieel, vooral bij grote schaal.

Bij 47 knooppunten wordt het aantal relaties en berichten dat verwerkt moet worden aanzienlijk groter. Zodoende moet het netwerk gecontroleerd worden op latency, packet loss, redundantie, MTU-instellingen, switching en beveiliging.

Daarnaast is het belangrijk om te testen wat er gebeurt bij het uitvallen van een knooppunt: de daadwerkelijke hersteltijd en reactiviteit moeten gemeten worden, niet alleen de status in het beheer. Het volledige herstelproces kan omvatten:

Corosync detectie → nieuwe lidmaatschap → fencing → HA management → opslagherstel → VM opstarten → applicatie opstarten

De totale vertraging hangt af van de hardware, netwerkcondities en de complexiteit van de reactiestappen. Een langzamer knooppunt of gebrekkige opslag kunnen het herstel aanzienlijk vertragen, ongeacht de timers.

Het aanpassen van de timerparameters biedt een indicatie, maar absolute performantie hangt af van het gehele systeem. Het is belangrijk om niet alleen naar timerwaarden te kijken, maar de daadwerkelijke hersteltijd te meten bij uitval, vooral in een groot cluster.

Samengevat: het volgen van de timers geeft aanwijzingen, maar is geen garantie voor hoge beschikbaarheid. Bij 70 seconden herstel ligt de noodzaak voor herziening van het ontwerp en de netwerkconfiguratie de hoogste prioriteit.

Veelgestelde vragen

Hoe lang duurt Corosync met 47 knooppunten en een coefficient van 650 ms?

Bij een token van 3.000 ms en een coefficient van 650 ms wordt het effectieve token ongeveer 32,25 seconden, en consensus rond 38,70 seconden. Samen ongeveer 70,95 seconden.

Wat is de timing met een token_coefficient van 125 ms?

Voor hetzelfde cluster wordt het effectieve token ongeveer 8,63 seconden, en consensus circa 10,35 seconden. Het totaal ligt dus rond 18,98 seconden.

Worden timers automatisch aangepast bij een upgrade naar Proxmox VE 9?

Niet automatisch. De nieuwe standaard voor token_coefficient in nieuwe clusters is 125 ms. Bestaande clusters behouden mogelijk hun oude timerwaarden. Gebruik corosync-cmapctl om de daadwerkelijke timers te controleren.

Kan je de coefficient direct wijzigen van 650 naar 125 ms?

Het wordt afgeraden om dat zonder inspectie te doen. Verminderen van timers in onstabiele netwerken kan leiden tot verkeerd gedrag en false positives. Controleer eerst netwerkcondities en pas timers aan op basis van de praktijk.