Delen via


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 als zeer beschikbaar beschouwd indien de knooppunten die de resources hosten actief zijn; In de regel vereist het cluster echter dat meer dan de helft van de knooppunten om te draaien. Dit staat bekend 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 de eigenaar van de workload te zijn en naar dezelfde schijf te schrijven, wat kan leiden tot talloze problemen. Dit wordt echter voorkomen met het concept van quorum van Failover Clustering, waardoor slechts één van deze groepen knooppunten actief blijft, zodat slechts één van deze groepen online blijft.

Quorum bepaalt het aantal storingen dat het cluster kan verdragen terwijl het 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 een resourcegroep hosten en naar dezelfde schijf schrijven. Door dit concept van quorum te hebben, dwingt het cluster de clusterservice af om te stoppen 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 automatisch opnieuw deelnemen aan het cluster en de clusterservice starten.

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

  • Clusterquorum: dit werkt op clusterniveau (u kunt knooppunten verliezen en het cluster up laten blijven)
  • Poolquorum: dit werkt op het poolniveau (u kunt knooppunten en stations verliezen en de pool up laten staan). 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 één serverknooppuntfout overleven en vervolgens een andere Kan twee gelijktijdige serverknooppuntfouten overleven
2 50/50 Nee. Nee.
2 + Getuige Ja Nee. Nee.
3 Ja 50/50 Nee.
3 + Getuige 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 getuige vereist.
  • Als u drie of vier knooppunten hebt, is het sterk aanbevolen om witness te gebruiken.
  • Als u vijf of meer knooppunten hebt, is een getuige niet nodig en biedt deze geen extra veerkracht.
  • Als u internettoegang hebt, gebruikt u een cloudwitness.
  • Als u zich in een IT-omgeving bevindt met andere computers en bestandsshares, gebruikt u een bestandssharewitness.

Hoe clusterquorum werkt

Wanneer knooppunten mislukken of wanneer sommige subset van knooppunten geen contact meer heeft met een andere subset, 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.

Maar het concept van meerderheid werkt alleen op schone wijze 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. Eerst kan het met één punt stijgen door een getuige met een extra stem toe te voegen. Hiervoor is gebruikersinstelling vereist.
  2. Of het kan met één verminderen door de stem van één ongelukkig knooppunt op nul te zetten (gebeurt automatisch indien nodig).

Wanneer overlevende knooppunten succesvol verifiëren dat ze de meerderheid vormen, wordt de definitie van meerderheid bijgewerkt om alleen tot de overlevenden te behoren. Hierdoor verliest het cluster één knooppunt, vervolgens een ander, vervolgens een ander, enzovoort. Dit concept van het totale aantal stemmen dat wordt aangepast nadat opeenvolgende fouten zijn mislukt, wordt dynamisch quorum genoemd.

Dynamische getuige

De dynamische getuige schakelt de stem van de getuige 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 getuige vermindert aanzienlijk het risico dat het cluster uitvalt vanwege een storing in de getuige. Het cluster beslist of de "witness vote" gebruikt moet worden op basis van het aantal stemnodes dat beschikbaar is in het cluster.

Dynamisch quorum werkt met dynamische witness zoals hieronder beschreven.

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 witness, dus het totaal is oneven.
  • Als u een oneven aantal knooppunten plus witness hebt, stemt de witness niet.

Met dynamisch quorum kan een stem dynamisch aan een knooppunt worden toegewezen om te voorkomen dat de meerderheid van de 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 verloren had.

Diagram met vier clusterknooppunten, die elk een stem krijgen.

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.

Diagram met vier clusterknooppunten, waarbij knooppunten éé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 is ingeschakeld, kan het cluster echter slechts twee knooppuntfouten ondersteunen. Dit wordt meer uitgelegd in de sectie voor het quorum van de groep.

Voorbeelden

Twee knooppunten zonder getuige

De stem van één knooppunt is nul, dus de meerderheidsstem wordt uit een totaal van 1 stem bepaald. Als het niet-stemknooppunt onverwacht uitvalt, heeft de overblijvende node 1/1 en blijft het cluster operationeel. 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 over. Daarom is het essentieel om een getuige te configureren.

Quorum uitgelegd in het geval van twee knooppunten zonder getuige.

  • Kan één serverfout overleven: Vijftig procent kans.
  • Kan één serverfout overleven, vervolgens een andere: Nee.
  • Kan twee serverfouten tegelijk overleven: Nee.

Twee knooppunten met een getuige

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

Quorum uitgelegd in het geval met twee knooppunten met een getuige.

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

Drie knooppunten zonder getuige

Alle knooppunten stemmen, dus de meerderheid wordt bepaald uit een totaal van 3 stemmen. Als een knooppunt uitvalt, blijft 2/3 van de knooppunten operationeel en overleeft het cluster. Het cluster wordt twee knooppunten zonder getuige – op dat moment bevindt u zich in Scenario 1.

Quorum wordt uitgelegd in een geval van drie knooppunten zonder getuige.

  • Kan één serverfout overleven: Ja.
  • Kan één serverfout overleven, dan nog een: Vijftig procent kans.
  • Kan twee serverfouten tegelijk overleven: Nee.

Drie knooppunten met een getuige

Alle knooppunten stemmen, dus de getuige stemt aanvankelijk niet. De meerderheid wordt uit totaal 3 stemmen bepaald. Na een storing heeft het cluster twee knooppunten met een getuige, wat teruggaat naar Scenario 2. Dus nu stemmen de twee knooppunten en de getuige.

Quorum uitgelegd in het geval van drie knooppunten met een getuige.

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

Vier knooppunten zonder getuige

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

Quorum uitgelegd in het geval van vier knooppunten zonder getuige.

  • Kan één serverfout overleven: Ja.
  • Kan één serverfout overleven, vervolgens een andere: Ja.
  • Kan twee serverfouten tegelijk overleven: Vijftig procent kans.

Vier knooppunten met een getuige

Alle knooppunten stemmen en de getuigenstemmen worden meegerekend, dus de meerderheid wordt bepaald uit 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 wordt uitgelegd in het geval van vier knooppunten met een getuige.

  • Kan één serverfout overleven: Ja.
  • Kan één serverfout overleven, vervolgens een andere: Ja.
  • Kan twee serverfouten tegelijk overleven: Ja.

Vijf knooppunten en verder

Alle knooppunten stemmen, of allemaal behalve één stem, wat het totaal oneven maakt. Opslagruimten Direct kan toch niet meer dan twee knooppunten naar beneden 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 één serverfout overleven, vervolgens een andere: Ja.
  • Kan twee serverfouten tegelijk overleven: Ja.

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

Soorten quorumgetuigen

Failover Clustering ondersteunt drie typen quorum-witnessen:

  • CloudWitness - Blob-opslag in Azure die toegankelijk is voor alle knooppunten van het cluster. Het onderhoudt clustergegevens in een witness.log-bestand, maar slaat geen kopie van de clusterdatabase op.
  • File Share Witness – een SMB-bestandsshare die is geconfigureerd op een bestandsserver met Windows Server. Het onderhoudt clustergegevens in een witness.log-bestand, maar slaat geen kopie van de clusterdatabase op.
  • Schijfwitness - een kleine geclusterde schijf die zich in de Cluster Beschikbare Opslag-groep bevindt. Deze schijf is maximaal beschikbaar en kan failover uitvoeren tussen knooppunten. Het bevat een kopie van de clusterdatabase. Een schijfwitness wordt niet ondersteund met Opslagruimten Direct.

Overzicht van het poolquorum

We hebben het net gehad over clusterquorum, dat op clusterniveau werkt. Laten we nu ingaan op het poolquorum, dat op poolniveau werkt (u kunt knooppunten en stations verliezen en de pool up 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 resultaten van het poolquorum 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 + Getuige Ja Nee. Nee.
4 Ja Nee. Nee.
4 + Witness Ja Ja Ja
5 en hoger Ja Ja Ja

Hoe het quorum van de pool werkt

Wanneer stations mislukken of wanneer sommige subset stations geen contact meer hebben met een andere subset, 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 verifiëren, gaan ze offline. De groep is de entiteit die offline gaat of online blijft op basis van of er voldoende schijven zijn voor quorum (50% + 1). De clusterdatabase kan de +1 zijn, zolang het cluster zelf quorate is.

Het quorum van de pool werkt echter op de volgende manieren anders dan het clusterquorum:

  • De pool selecteert per knooppunt een subset schijven om metagegevens te hosten.
  • De pool gebruikt de clusterdatabase om de banden 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 schijven heeft één stem en knooppunt twee heeft ook één stem (omdat het de resource-eigenaar van de pool is). De meerderheid wordt in totaal uit 16 stemmen bepaald. Als knooppunten drie en vier uitvallen, heeft de overgebleven subset 8 schijven en de resource-eigenaar van de pool, wat overeenkomt met 9/16 stemmen. Dus, het zwembad overleeft.

Pool Quorum 1.

  • Kan één serverfout overleven: Ja.
  • Kan één serverfout overleven, vervolgens een andere: Ja.
  • Kan twee serverfouten tegelijk overleven: Ja.

Vier knooppunten met een symmetrische indeling en schijffout

Elk van de 16 schijven heeft één stem en knooppunt 2 heeft ook één stem (omdat het de eigenaar van de poolresource is). De meerderheid wordt in totaal uit 16 stemmen bepaald. Ten eerste, rij 7 gaat omlaag. Als knooppunten drie en vier omlaag gaan, heeft de overlevende subset 7 stations en de eigenaar van de poolresource, wat 8/16 stemmen is. Het zwembad heeft dus geen meerderheid en gaat omlaag.

Pool Quorum 2.

  • Kan één serverfout overleven: Ja.
  • Kan één serverfout overleven, 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 schijven)
  • Schakel spiegeling in drie richtingen of dubbele pariteit in, zodat u twee knooppuntfouten kunt verdragen en de virtuele schijven online kunt houden.
  • Als er meer dan twee knooppunten niet beschikbaar zijn, of twee knooppunten en een schijf op een ander knooppunt offline is, hebben volumes mogelijk geen toegang tot alle drie de kopieën van hun gegevens en zijn ze dus offline gehaald en niet beschikbaar. Het is raadzaam om de servers terug te brengen of de schijven snel te vervangen om de meeste tolerantie voor alle gegevens in het volume te garanderen.

Volgende stappen