Inzicht in cluster- en poolquorum

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

Windows Server-failoverclustering 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 waarop resources worden gehost, zijn ingesteld; Het cluster vereist echter over het algemeen dat meer dan de helft van de knooppunten worden 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 schrijven naar dezelfde schijf, 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 verdragen 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 tegelijkertijd 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 weer communiceren met de hoofdgroep knooppunten en worden automatisch opnieuw toegevoegd aan het cluster en hun clusterservice gestart.

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 (u kunt bijvoorbeeld knooppunten kwijtraken en het cluster up laten blijven)
  • Poolquorum: dit werkt op groepsniveau (u kunt bijvoorbeeld knooppunten en stations kwijtraken en de pool up laten blijven). Opslaggroepen zijn ontworpen om te worden gebruikt in zowel geclusterde als niet-geclusterde scenario's. Daarom hebben ze een ander quorummechanisme.

Overzicht van clusterquorum

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

Serverknooppunten Kan één serverknooppuntfout overleven Kan één 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 + witness 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 knooppunten of meer 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 controleren, gaan ze offline.

Maar het concept meerderheid werkt alleen netjes wanneer het totale aantal knooppunten in het cluster oneven is (bijvoorbeeld drie knooppunten in een cluster met vijf knooppunten). 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 met succes controleren of ze de meerderheid zijn, wordt de definitie van meerderheid bijgewerkt om alleen de overlevenden te zijn. Hierdoor kan het cluster het ene knooppunt verliezen, dan het andere, het andere, enzovoort. Dit concept van het totale aantal stemmen dat na opeenvolgende fouten wordt aangepast, wordt dynamisch quorum genoemd.

Dynamische witness

Dynamische witness 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 de 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, stemmen de getuigen, 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 toe te wijzen aan een knooppunt 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 voorbeeld nemen van een cluster met vier knooppunten. Stel dat het quorum 3 stemmen vereist.

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

Diagram met vier clusterknooppunten, die elk een stem krijgt

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

Diagram met vier clusterknooppunten, met knooppunten die één voor één mislukken, en het aantal vereiste stemmen dat na elke fout wordt aangepast.

Het bovenstaande scenario is van toepassing op een algemeen cluster waarvoor Opslagruimten Direct niet is ingeschakeld. Wanneer Opslagruimten Direct echter is ingeschakeld, kan het cluster 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 op basis van een totaal van 1 stem. Als het niet-stemvrije knooppunt 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 correct is uitgeschakeld, wordt de stem overgebracht naar het andere knooppunt en blijft het cluster behouden. Daarom is het essentieel om een witness te configureren.

Quorum uitgelegd in het geval met twee knooppunten zonder witness

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

Twee knooppunten met een witness

Beide knooppunten stemmen, plus de getuigenstemmen, zodat de meerderheid wordt bepaald op basis van in totaal 3 stemmen. Als een van de knooppunten uitvalt, heeft de overlevende 2/3 en overleeft het cluster.

Quorum uitgelegd in het geval met twee knooppunten met een witness

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

Drie knooppunten zonder witness

Alle knooppunten stemmen, dus de meerderheid wordt bepaald op basis van in totaal 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.

Quorum uitgelegd in het geval met drie knooppunten zonder witness

  • 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 op basis van in totaal 3 stemmen. Na één fout heeft het cluster twee knooppunten met een witness. Dit is terug naar scenario 2. Dus nu stemmen de twee knooppunten en de getuige.

Quorum uitgelegd in het geval met drie knooppunten met een witness

  • 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 op basis van in totaal 3 stemmen. Na één fout wordt het cluster drie knooppunten en bevindt u zich in scenario 3.

Quorum uitgelegd in het geval met vier knooppunten zonder witness

  • 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 op basis van een totaal van 5 stemmen. Na één fout bevindt u zich in scenario 4. Na twee gelijktijdige fouten gaat u verder met scenario 2.

Quorum uitgelegd in het geval met vier knooppunten met een witness

  • 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, ongeacht de totale onevenheid. Opslagruimten Direct kan toch niet meer dan twee knooppunten verwerken, dus op dit moment is er geen witness nodig of nuttig.

Quorum uitgelegd in het geval met vijf knooppunten en verder

  • 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 quorum getuigen.

Typen quorumwitness

Failoverclustering ondersteunt drie typen quorum getuigen:

  • Cloud Witness : blobopslag in Azure die toegankelijk is voor alle knooppunten van het cluster. Er worden clusteringgegevens in een witness.log-bestand bijgehouden, maar er wordt geen kopie van de clusterdatabase opgeslagen.
  • Bestandssharewitness : een SMB-bestandsshare die is geconfigureerd op een bestandsserver met Windows Server. Er worden clusteringgegevens in een witness.log-bestand bijgehouden, maar er wordt geen kopie van de clusterdatabase opgeslagen.
  • Schijfwitness : een kleine geclusterde schijf die zich in de groep Cluster available storage bevindt. Deze schijf is maximaal beschikbaar en kan failovers 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 weten dat u knooppunten en stations kunt verliezen en de pool omhoog kunt laten blijven). Opslaggroepen zijn ontworpen om te worden gebruikt in zowel geclusterde als niet-geclusterde scenario's. Daarom hebben ze een ander quorummechanisme.

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

Serverknooppunten Kan één serverknooppuntfout overleven Kan één 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 + witness 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 grootste deel van de groep vormen om online te blijven. Als ze dat niet kunnen controleren, gaan ze offline. De pool is de entiteit die offline gaat of online blijft op basis van of deze voldoende schijven heeft voor quorum (50% + 1). De clusterdatabase kan de +1 zijn, zolang het cluster zelf een quorate is.

Maar poolquorum werkt op de volgende manieren anders dan clusterquorum:

  • De pool selecteert een subset van 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 op basis van een totaal van 16 stemmen. Als knooppunten drie en vier uitvalt, heeft de resterende subset 8 stations en de resource-eigenaar van de pool, wat 9/16 stemmen is. Dus het zwembad overleeft.

Poolquorum 1

  • 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 op basis van een totaal van 16 stemmen. Eerst gaat station 7 naar beneden. Als knooppunten drie en vier uitvalt, heeft de resterende subset 7 stations en de resource-eigenaar van de pool, wat 8/16 stemmen is. Het zwembad heeft dus geen meerderheid en gaat naar beneden.

Groepsquorum 2

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

Aanbevelingen voor 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 niet beschikbaar 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, waardoor ze offline worden gehaald en niet beschikbaar zijn. Het is raadzaam om de servers terug te brengen of de schijven snel te vervangen om de meeste tolerantie te garanderen voor alle gegevens in het volume.

Volgende stappen