Inzicht in cluster- en poolquorum
Van toepassing op: Azure Stack HCI, versies 22H2 en 21H2; Windows Server 2022, Windows Server
Belangrijk
Azure Stack HCI maakt nu deel uit van Azure Local. De naam van productdocumentatie wordt nog steeds bijgewerkt. Oudere versies van Azure Stack HCI, bijvoorbeeld 22H2, blijven verwijzen naar Azure Stack HCI en geven de naamwijziging niet weer. Meer informatie.
Windows Server Failover Clustering biedt hoge beschikbaarheid voor workloads die worden uitgevoerd op Azure Stack HCI- en Windows Server-clusters. Deze resources worden als maximaal beschikbaar beschouwd als de knooppunten die als hostbronnen fungeren; Het cluster vereist echter over het algemeen meer dan de helft van de knooppunten die worden uitgevoerd. 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 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 onderhouden 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 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 | Nr. |
| 2 + Witness | Ja | No | Nr. |
| 3 | Ja | 50/50 | Nee |
| 3 + Witness | Ja | Ja | Nr. |
| 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 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:
- Eerst kan het er één omhoog gaan door een getuige toe te voegen met een extra stem. Hiervoor moet de gebruiker zijn ingesteld.
- Of het kan één omlaag gaan door één onbedoelde stem van één knooppunt te nulen (gebeurt automatisch als dat nodig is).
Wanneer overlevende knooppunten controleren of ze de meerderheid zijn, wordt de definitie van de meerderheid bijgewerkt tot alleen de overlevenden. 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 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 fout in de witness. Het cluster bepaalt of de witness-stem moet worden gebruikt op basis van het aantal stemknooppunten dat beschikbaar is in het cluster.
Dynamisch quorum werkt met dynamische witness op de manier die hieronder wordt 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 kwijtraakt.
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 meer uitgelegd in de sectie voor het quorum van de groep.
Voorbeelden
Twee knooppunten zonder witness
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 overlevende 1/1 en blijft het cluster over. 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 witness te configureren.
- 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 witness
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.
- Kan één serverfout overleven: Ja.
- Kan één serverfout overleven, vervolgens een andere: Nee.
- Kan twee serverfouten tegelijk overleven: Nee.
Drie knooppunten zonder witness
Alle knooppunten stemmen, dus de meerderheid wordt bepaald uit 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 één serverfout overleven, dan nog een: 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 uit totaal 3 stemmen bepaald. Na één fout heeft het cluster twee knooppunten met een witness, die terug is naar Scenario 2. Dus nu de twee knooppunten en de witness stemmen.
- Kan één serverfout overleven: Ja.
- Kan één serverfout overleven, 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 uit een totaal van 3 stemmen. Na één fout wordt het cluster drie knooppunten en bevindt u zich in Scenario 3.
- 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 witness
Alle knooppunten stemmen en de witness-stemmen, 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.
- 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.
- 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.
Typen quorumwitness
Failoverclustering ondersteunt drie typen quorumwitnessen:
- 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.
- Bestandssharewitness : 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 opslaggroep 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 | No | Nr. |
| 2 + Witness | Ja | No | Nr. |
| 3 | Ja | No | Nr. |
| 3 + Witness | Ja | No | Nr. |
| 4 | Ja | No | Nr. |
| 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 deze voldoende schijven heeft 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 een subset stations per knooppunt 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 stations 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 omlaag gaan, heeft de overlevende subset 8 stations en de eigenaar van de poolresource, die 9/16 stemmen is. Dus, het zwembad overleeft.
- 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 stations heeft één stem en knooppunt 2 heeft ook één stem (omdat het de resource-eigenaar van de pool 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.
- 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 stations)
- 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.