Inzicht in cluster- en poolquorum

Van toepassing op: Azure Stack HCI, versies 22H2 en 21H2; Windows Server 2022, Windows Server

Windows Server Failover Clustering biedt hoge beschikbaarheid voor workloads die worden uitgevoerd op Azure Stack HCI- en Windows Server-clusters. Deze resources worden beschouwd als maximaal beschikbaar als de knooppunten die als hostresources fungeren, zijn ingesteld; Het cluster vereist echter over het algemeen dat meer dan de helft van de knooppunten wordt uitgevoerd, wat bekend staat als quorum.

Quorum is ontworpen om split-brain-scenario's te voorkomen die kunnen optreden wanneer er een partitie in het netwerk is en subsets van knooppunten niet met elkaar kunnen communiceren. Dit kan ertoe leiden dat beide subsets van knooppunten proberen eigenaar te zijn van de workload en naar dezelfde schijf schrijven, wat kan leiden tot talloze problemen. Dit wordt echter voorkomen met het concept quorum van failoverclustering, waardoor slechts één van deze groepen knooppunten wordt uitgevoerd, zodat slechts één van deze groepen online blijft.

Quorum bepaalt het aantal fouten dat het cluster kan doorwerken terwijl het nog steeds online blijft. Quorum is ontworpen om het scenario af te handelen wanneer er een probleem is met de communicatie tussen subsets van clusterknooppunten, zodat meerdere servers niet tegelijkertijd proberen een resourcegroep te hosten en naar dezelfde schijf te schrijven. Door dit concept van quorum te gebruiken, dwingt het cluster af dat de clusterservice stopt in een van de subsets van knooppunten om ervoor te zorgen dat er slechts één echte eigenaar van een bepaalde resourcegroep is. Knooppunten die zijn gestopt, kunnen opnieuw communiceren met de hoofdgroep van knooppunten en worden automatisch opnieuw toegevoegd aan het cluster en hun clusterservice starten.

In Azure Stack HCI en Windows Server 2019 zijn er twee onderdelen van het systeem die hun eigen quorummechanismen hebben:

• Clusterquorum: dit werkt op clusterniveau (dat wil zeggen dat u knooppunten kunt verliezen en het cluster up kunt houden)
• Poolquorum: dit werkt op groepsniveau (dat wil zeggen dat u knooppunten en stations kunt verliezen en de pool up kunt houden). Opslaggroepen zijn ontworpen voor gebruik in zowel geclusterde als niet-geclusterde scenario's. Daarom hebben ze een ander quorummechanisme.

Overzicht van clusterquorum

De onderstaande tabel geeft een overzicht van de resultaten van het clusterquorum per scenario:

Serverknooppunten	Kan één serverknooppuntfout overleven	Kan een serverknooppuntfout overleven en vervolgens een andere	Kan twee gelijktijdige serverknooppuntfouten overleven
2	50/50	No	Nee
2 + getuige	Ja	Nee	Nee
3	Ja	50/50	No
3 + witness	Ja	Ja	Nee
4	Ja	Ja	50/50
4 + getuige	Ja	Ja	Ja
5 en hoger	Ja	Ja	Ja

Aanbevelingen voor clusterquorum

• Als u twee knooppunten hebt, is een witness vereist.
• Als u drie of vier knooppunten hebt, wordt witness sterk aanbevolen.
• Als u vijf of meer knooppunten hebt, is een witness niet nodig en biedt deze geen extra tolerantie.
• Als u toegang tot internet hebt, gebruikt u een cloudwitness.
• Als u zich in een IT-omgeving met andere computers en bestandsshares bevindt, gebruikt u een bestandssharewitness.

Hoe clusterquorum werkt

Wanneer knooppunten mislukken of wanneer een subset van knooppunten het contact met een andere subset verliest, moeten overlevende knooppunten controleren of ze het merendeel van het cluster vormen om online te blijven. Als ze dat niet kunnen verifiëren, gaan ze offline.

Het concept meerderheid werkt echter alleen als het totale aantal knooppunten in het cluster oneven is (bijvoorbeeld drie knooppunten in een cluster met vijf knooppunten). Dus hoe zit het met clusters met een even aantal knooppunten (bijvoorbeeld een cluster met vier knooppunten)?

Er zijn twee manieren waarop het cluster het totale aantal stemmen oneven kan maken:

1. Ten eerste kan het één omhoog gaan door een getuige toe te voegen met een extra stem. Hiervoor moet de gebruiker worden ingesteld.
2. Of het kan één naar beneden gaan door de stem van één ongelukkig knooppunt te nulen (gebeurt automatisch als dat nodig is).

Wanneer overlevende knooppunten controleren of ze de meerderheid zijn, wordt de definitie van meerderheid bijgewerkt om alleen de overlevenden te maken. Hierdoor kan het cluster één knooppunt verliezen, dan een ander, dan een ander, enzovoort. Dit concept van het totale aantal stemmen dat na opeenvolgende fouten wordt aangepast, wordt dynamisch quorum genoemd.

Dynamische witness

Dynamische getuige schakelt de stem van de getuige in om ervoor te zorgen dat het totale aantal stemmen oneven is. Als er een oneven aantal stemmen is, heeft de getuige geen stem. Als er een even aantal stemmen is, heeft de getuige een stem. Dynamische witness vermindert het risico dat het cluster uitvalt vanwege een witness-fout aanzienlijk. Het cluster bepaalt of de witness-stem wordt gebruikt op basis van het aantal stemknooppunten dat beschikbaar is in het cluster.

Dynamisch quorum werkt met dynamische witness op de hieronder beschreven manier.

Dynamisch quorumgedrag

• Als u een even aantal knooppunten en geen witness hebt, krijgt één knooppunt zijn stem nul. Zo krijgen slechts drie van de vier knooppunten stemmen, dus het totale aantal stemmen is drie en twee overlevenden met stemmen worden beschouwd als een meerderheid.
• Als u een oneven aantal knooppunten en geen witness hebt, krijgen ze allemaal stemmen.
• Als u een even aantal knooppunten plus witness hebt, worden de witness-stemmen weergegeven, dus het totaal is oneven.
• Als u een oneven aantal knooppunten plus witness hebt, stemt de witness niet.

Dynamisch quorum maakt het mogelijk om dynamisch een stem aan een knooppunt toe te wijzen om te voorkomen dat de meerderheid van stemmen verloren gaat en het cluster kan worden uitgevoerd met één knooppunt (ook wel last-man standing genoemd). Laten we een cluster met vier knooppunten als voorbeeld nemen. Stel dat het quorum 3 stemmen vereist.

In dit geval zou het cluster uitgevallen zijn als u twee knooppunten bent kwijtgeraakt.

Dynamisch quorum voorkomt echter dat dit gebeurt. Het totale aantal stemmen dat is vereist voor quorum wordt nu bepaald op basis van het aantal beschikbare knooppunten. Met dynamisch quorum blijft het cluster dus actief, zelfs als u drie knooppunten kwijtraakt.

Het bovenstaande scenario is van toepassing op een algemeen cluster waarvoor Opslagruimten Direct niet is ingeschakeld. Wanneer Opslagruimten Direct is ingeschakeld, kan het cluster echter slechts twee knooppuntfouten ondersteunen. Dit wordt uitgelegd in de sectie poolquorum.

Voorbeelden

Twee knooppunten zonder witness

De stem van één knooppunt is nul, dus de meerderheidsstem wordt bepaald van een totaal van 1 stem. Als het knooppunt zonder stemgedrag onverwacht uitvalt, heeft de overlevende 1/1 en overleeft het cluster. Als het stemknooppunt onverwacht uitvalt, heeft de overlevende 0/1 en gaat het cluster uit. Als het stemknooppunt zonder problemen wordt uitgeschakeld, wordt de stem overgebracht naar het andere knooppunt en blijft het cluster behouden. Daarom is het essentieel om een witness te configureren.

• Kan één serverfout overleven: vijftig procent kans.
• Kan de ene serverfout overleven en vervolgens een andere: Nee.
• Kan twee serverfouten tegelijk overleven: Nee.

Twee knooppunten met een witness

Beide knooppunten stemmen, plus de witness-stemmen, dus de meerderheid wordt bepaald van een totaal van 3 stemmen. Als een van de knooppunten uitvalt, heeft de overlevende 2/3 en overleeft het cluster.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Nee.
• Kan twee serverfouten tegelijk overleven: Nee.

Drie knooppunten zonder witness

Alle knooppunten stemmen, dus de meerderheid wordt bepaald op basis van een totaal van 3 stemmen. Als een knooppunt uitvalt, zijn de overlevenden 2/3 en overleeft het cluster. Het cluster wordt twee knooppunten zonder witness. Op dat moment bevindt u zich in Scenario 1.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Vijftig procent kans.
• Kan twee serverfouten tegelijk overleven: Nee.

Drie knooppunten met een witness

Alle knooppunten stemmen, dus de witness stemt in eerste instantie niet. De meerderheid wordt bepaald uit een totaal van 3 stemmen. Na één fout heeft het cluster twee knooppunten met een witness. Dit is terug naar Scenario 2. Dus nu de twee knooppunten en de witness-stem.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Ja.
• Kan twee serverfouten tegelijk overleven: Nee.

Vier knooppunten zonder witness

De stem van één knooppunt is nul, dus de meerderheid wordt bepaald van een totaal van drie stemmen. Na één fout wordt het cluster drie knooppunten en bevindt u zich in Scenario 3.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Ja.
• Kan twee serverfouten tegelijk overleven: vijftig procent kans.

Vier knooppunten met een witness

Alle knooppunten stemmen en de witness-stemmen, dus de meerderheid wordt bepaald van een totaal van 5 stemmen. Na één fout bevindt u zich in scenario 4. Na twee gelijktijdige fouten gaat u verder naar Scenario 2.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Ja.
• Kan twee serverfouten tegelijk overleven: Ja.

Vijf knooppunten en meer

Alle knooppunten stemmen, of alle stemmen op één na, wat het totaal ook oneven maakt. Opslagruimten Direct kan toch niet meer dan twee knooppunten offline verwerken, dus op dit moment is er geen witness nodig of nuttig.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Ja.
• Kan twee serverfouten tegelijk overleven: Ja.

Nu we begrijpen hoe quorum werkt, gaan we kijken naar de typen quorumwitnessen.

Quorumwitnesstypen

Failoverclustering ondersteunt drie typen Quorum Getuigen:

• Cloud Witness : blobopslag in Azure die toegankelijk is voor alle knooppunten van het cluster. De clustergegevens worden in een witness.log-bestand bewaard, maar er wordt geen kopie van de clusterdatabase opgeslagen.
• Bestandssharewitness : een SMB-bestandsshare die is geconfigureerd op een bestandsserver met Windows Server. De clustergegevens worden in een witness.log-bestand bewaard, maar er wordt geen kopie van de clusterdatabase opgeslagen.
• Schijfwitness : een kleine geclusterde schijf die zich in de groep Cluster beschikbare opslag bevindt. Deze schijf is maximaal beschikbaar en kan een failover uitvoeren tussen knooppunten. Het bevat een kopie van de clusterdatabase. Een schijfwitness wordt niet ondersteund met Opslagruimten Direct.

Overzicht van poolquorum

We hebben het net gehad over clusterquorum, dat op clusterniveau werkt. Laten we nu eens kijken naar poolquorum, dat werkt op groepsniveau (dat wil zeggen dat u knooppunten en stations kunt verliezen en de pool omhoog kunt laten blijven). Opslaggroepen zijn ontworpen voor gebruik in zowel geclusterde als niet-geclusterde scenario's. Daarom hebben ze een ander quorummechanisme.

De onderstaande tabel geeft een overzicht van de quorumresultaten van de pool per scenario:

Serverknooppunten	Kan één serverknooppuntfout overleven	Kan een serverknooppuntfout overleven en vervolgens een andere	Kan twee gelijktijdige serverknooppuntfouten overleven
2	Ja	Nee	Nee
2 + getuige	Ja	Nee	Nee
3	Ja	Nee	Nee
3 + witness	Ja	Nee	Nee
4	Ja	Nee	Nee
4 + getuige	Ja	Ja	Ja
5 en hoger	Ja	Ja	Ja

Hoe poolquorum werkt

Wanneer stations uitvallen of wanneer een subset van stations het contact met een andere subset verliest, moeten overlevende stations die metagegevens hosten, controleren of ze het merendeel van de groep vormen om online te blijven. Als ze dat niet kunnen verifiëren, gaan ze offline. De pool is de entiteit die offline gaat of online blijft, afhankelijk van of deze voldoende schijven heeft voor quorum (50% + 1). De clusterdatabase kan de +1 zijn, zolang het cluster zelf een quorate heeft.

Maar groepsquorum werkt op de volgende manieren anders dan clusterquorum:

• De pool selecteert een subset stations per knooppunt om metagegevens te hosten
• De pool gebruikt de clusterdatabase om bindingen te verbreken
• De pool heeft geen dynamisch quorum
• De groep implementeert geen eigen versie van het verwijderen van een stem

Voorbeelden

Vier knooppunten met een symmetrische indeling

Elk van de 16 stations heeft één stem en knooppunt twee heeft ook één stem (omdat het de eigenaar van de poolresource is). De meerderheid wordt bepaald uit een totaal van 16 stemmen. Als knooppunten drie en vier uitvalt, heeft de overlevende subset 8 stations en de eigenaar van de poolresource, wat 9/16 stemmen is. Dus, het zwembad overleeft.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Ja.
• Kan twee serverfouten tegelijk overleven: Ja.

Vier knooppunten met een symmetrische indeling en schijffout

Elk van de 16 stations heeft één stem en knooppunt 2 heeft ook één stem (omdat het de eigenaar van de poolresource is). De meerderheid wordt bepaald uit een totaal van 16 stemmen. Eerst gaat station 7 naar beneden. Als knooppunten drie en vier uitvalt, heeft de overlevende subset 7 stations en de resource-eigenaar van de pool, wat 8/16 stemmen is. Het zwembad heeft dus geen meerderheid en gaat omlaag.

• Kan één serverfout overleven: Ja.
• Kan de ene serverfout overleven en vervolgens een andere: Nee.
• Kan twee serverfouten tegelijk overleven: Nee.

Aanbevelingen voor het poolquorum

• Zorg ervoor dat elk knooppunt in uw cluster symmetrisch is (elk knooppunt heeft hetzelfde aantal stations)
• Schakel spiegeling in drie richtingen of dubbele pariteit in, zodat u fouten met twee knooppunten kunt tolereren en de virtuele schijven online kunt houden.
• Als meer dan twee knooppunten offline zijn of als twee knooppunten en een schijf op een ander knooppunt niet beschikbaar zijn, hebben volumes mogelijk geen toegang tot alle drie de kopieën van hun gegevens en worden ze daarom offline gehaald en zijn ze niet beschikbaar. Het wordt aanbevolen om de servers terug te halen of de schijven snel te vervangen om de meeste tolerantie te garanderen voor alle gegevens in het volume.

Volgende stappen

• Quorum configureren en beheren
• Een clusterwitness instellen