Bij het configureren van een Windows cluster zal er door de Failover Cluster Manager aangegeven worden welke quorum configuratie het beste bij dat cluster past. Het belang van deze keuze wordt echter vaak over het hoofd gezien.
Maar voordat we de opties behandelen, is het eerst handig om te weten wat de functie is van een quorum binnen een Windows cluster.

Wat is een quorum?

Een quorum is niets anders dan het minimale aantal stemmen dat benodigd is om een meerderheid te vormen.

Cluster nodes communiceren met elkaar over het netwerk (over poort 3343). Op het moment dat deze nodes niet meer met elkaar kunnen communiceren, zullen ze ieder denken dat de resources van de andere cluster nodes weer online gebracht moeten worden. Omdat er vervolgens resources op nodes online gebracht zullen worden die al op andere nodes actief zijn, kan er data corruptie ontstaan. Zo’n situatie wordt ook wel “split brain” genoemd…
In dergelijke situaties zou het wenselijk zijn dat het cluster op een democratische wijze zichzelf kan onderhouden en repareren. Als dit democratisch gebeurd, kan dit enkel met een meerderheid (quorum) van de stemmen.

Iedere cluster node heeft een stem, evenals de quorum disk of file share (hier straks meer over).
Wanneer het merendeel van het aantal nodes is gefaald, zal ook het gehele cluster falen. De stappen die het cluster doorloopt om zichzelf te repareren zijn als volgt:

1. Iedere node zal met de andere nodes proberen te communiceren.
2. Zodra deze communicatie is gelegd zullen ze met elkaar overleggen over de status van het cluster tot het punt dat ze het met elkaar eens zijn en “alle neuzen dezelfde kant op staan”.
3. De nodes zijn zich bewust van het aantal nodes dat lid is van het cluster, ongeacht of ze actief zijn of niet. Deze kennis gecombineerd met het aantal actief gevonden nodes zal de mogelijkheid geven om te bepalen of er een meerderheid van het aantal nodes aanwezig is.
4. Indien er geen meerderheid is behaald, zullen de nodes wachten tot er meer nodes zich komen melden.
5. Indien er wel een meerderheid is behaald, zal het cluster actief worden en de resources online brengen.

Let op: Deze stappen zijn versimpeld uitgelegd, op de achtergrond gebeurt er aanzienlijk meer.

Met deze methode zal het cluster enkel actief worden indien het merendeel van het aantal stemmen aanwezig is, wat dus te allen tijde een “split brain” situatie zal vermijden.

Quorum configuraties

De Failover Cluster Manager zal zelf bij het configureren de meest gangbare optie voorstellen en dit is later, indien gewenst, aan te passen via de Failover Cluster Manager op cluster niveau.

Ook al is het voorstel van de Failover Cluster Manager vaak de meest verstandige optie, is het verstandig de voor- en nadelen te begrijpen van de mogelijke keuzes.

Node Majority
Deze optie is aanbevolen voor clusters met een oneven aantal nodes. Deze configuratie kan uitval van de helft van het aantal cluster nodes naar beneden afgerond opvangen.  Een cluster van vijf nodes kan dus de uitval van twee nodes opvangen.

In een vijf node cluster dat gebruik maakt van “node majority”, waarbij drie van de nodes wel met elkaar kunnen communiceren maar niet meer met de laatste 2. De drie nodes vormen op dat punt een meerderheid van het aantal stemmen en zal het cluster actief blijven op die nodes en zullen deze besluiten dat de twee nodes waar geen communicatie meer mee is het actieve cluster lidmaatschap ontnomen zal worden. Valt er echter nog een node uit dan zullen er twee nodes in het cluster overblijven. Gezien twee nodes niet een meerderheid van vijf vormen, zal het gehele cluster falen omdat er geen meerderheid aanwezig is.

No Majority: Disk Only
Hoewel deze optie slechts een cluster node nodig heeft om het cluster actief te houden, wordt het quorum opgeslagen op een disk. Hiermee is gelijk die disk een single-point-of-failure en dus een risico. Met die reden is deze optie dan ook over het algemeen niet aanbevolen.
Alle nodes kunnen gezond zijn, het netwerk heeft geen problemen… maar zodra de disk niet meer beschikbaar is, of corrupt is geraakt, zal het cluster falen.

Node and Disk Majority
Deze optie is aanbevolen voor clusters met een even aantal nodes. Deze configuratie geeft meerdere mogelijkheden met het maximaal aantal op te vangen nodes, afhankelijk van de beschikbaarheid van de disk.
De disk wordt ook wel een “Disk witness resource” genoemd. Naast het bieden van een stem om een meerderheid te vormen dient deze disk ook als opslag voor de meest recente cluster database.
Indien de disk wel beschikbaar is, kan deze configuratie een uitval van de helft van het aantal cluster nodes opvangen. Een cluster met zes nodes kan met deze configuratie een uitval van drie nodes opvangen. Een cluster met zes nodes kan zodoende het falen van drie nodes opvangen.
Indien de disk niet beschikbaar is, kan deze configuratie een uitval van de helft van het aantal cluster nodes minus een opvangen. Een cluster met zes nodes kan zodoende het falen van twee nodes opvangen.
In onderstaande tekening is de “witness” dus de Disk Witness Resource.

Node and File Share Majority
Het principe van deze configuratie is hetzelfde als bij “node and disk majority” echter zal hier de disk vervangen worden voor een file share, ook wel “File Share Witness Resource” genoemd.
Er is echter een groot en belangrijk verschil. Na het falen van een cluster zal een van de beschikbare nodes een lokale kopie moeten hebben van de huidige cluster configuratie. Als deze niet aanwezig is, of slechts een verouderde versie, kan op een node de cluster service handmatig gestart worden wat ervoor zorgt dat de laatste cluster configuratie van de file share opgehaald zal worden.
Deze optie wordt vaak gebruikers in het geval SAP systemen en in het geval van clusters waarbij de nodes zich op verschillende fysieke locaties bevinden.
In onderstaande tekening is de “witness” dus de File Share Witness Resource.

Welke optie in welke situatie?

Voor het gemak heb ik onderstaande tabel samen gesteld om overzicht te geven welke optie in welke situatie mogelijk, aanbevolen of afgeraden is.

Conclusie

Iedere optie heeft voor- en nadelen. Hoewel de Failover Cluster Manager zelf met de meest logische keuze zal komen, is het mogelijk af te wijken van dit advies. Mijn persoonlijke ervaring is echter dat de keuze door de Failover Cluster Manager de juiste is en dat deze keuze over het algemeen “Node Majority” of “Node and Disk Majority” zal zijn.
Voor het gemak heb ik een tabel samen gesteld aan de hand van dit artikel om eenvoudig en overzichtelijk te maken. Hierbij ga ik uit van een situatie waarin de cluster nodes zich op dezelfde fysieke locatie bevinden.

X = Aanbevolen
I = Mogelijk
0 = Afgeraden