først offentliggjort på MSDN den 27.maj 2011
Hej Klyngefans,

dette blogindlæg vil afklare planlægningsovervejelser omkring
kvorum
i en Failover-klynge og besvare nogle af de mest almindelige spørgsmål, vi hører.

kvorumskonfigurationen i en failover-klynge bestemmer antallet af fejl, som klyngen kan opretholde, mens den stadig er online. Hvis der opstår en yderligere fejl ud over denne tærskel, stopper klyngen med at køre. En almindelig opfattelse er, at grunden til, at klyngen holder op med at køre, hvis der opstår for mange fejl, er at forhindre, at de resterende noder påtager sig for mange arbejdsbelastninger og får værterne til at blive overforpligtet. Faktisk kender klyngen ikke dine kapacitetsbegrænsninger, eller om du ville være villig til at tage et præstationshit for at holde det online. Snarere kvorum er design til at håndtere scenariet, når der er et problem med kommunikation mellem sæt klyngenoder, så to servere ikke forsøger at være vært for en ressourcegruppe samtidigt og skrive til den samme disk på samme tid. Dette er kendt som en” split hjerne”, og vi ønsker at forhindre dette for at undgå enhver potentiel korruption til en disk min have to samtidige gruppe ejere. Ved at have dette kvorumskoncept vil klyngen tvinge klyngetjenesten til at stoppe i en af undergrupperne af noder for at sikre, at der kun er en sand ejer af en bestemt ressourcegruppe. Når noder, der er stoppet, igen kan kommunikere med hovedgruppen af noder, vil de automatisk slutte sig til klyngen og starte deres klyngetjeneste.

For mere information om kvorum i en klynge, besøg:
http://technet.microsoft.com/en-us/library/cc731739.aspx
.

afstemning mod Kvorum

at have ‘kvorum’ eller et flertal af vælgerne er baseret på afstemningsalgoritme, hvor mere end halvdelen af vælgerne skal være online og i stand til at kommunikere med hinanden. Fordi en given klynge har et specifikt sæt noder og en specifik kvorumskonfiguration, vil klyngen vide, hvor mange “stemmer” der udgør et flertal af stemmer eller beslutningsdygtighed. Hvis antallet af vælgere falder under flertallet, stopper klyngetjenesten på knudepunkterne i den gruppe. Disse noder vil stadig lytte efter tilstedeværelsen af andre noder, hvis en anden knude vises igen på netværket, men knudepunkterne begynder ikke at fungere som en klynge, før kvorummet eksisterer igen.

det er vigtigt at indse, at klyngen kræver
mere end
halvdelen af de samlede stemmer for at opnå beslutningsdygtighed. Dette er for at undgå at have et ‘uafgjort’ i antallet af stemmer i en partition, da flertallet altid vil betyde, at den anden partition har mindre end halvdelen af stemmerne. I en 5-node klynge skal 3 vælgere være online; men i en 4-node klynge skal 3 vælgere også være online for at have flertal. På grund af denne logik anbefales det altid at have et ulige antal samlede vælgere i klyngen. Dette betyder ikke nødvendigvis, at der er behov for et ulige antal noder, da både en disk eller en fildeling kan bidrage med en afstemning, afhængigt af kvorumsmodellen.

en vælger kan være:

  • en node
    • 1 stemme
    • hver node i klyngen har 1 stemme
  • et “Disk vidne”eller” fil Del vidne ”
    • 1 stemme
    • enten 1 Disk vidne eller 1 fil Del vidne kan have en stemme i klyngen, men ikke flere diske, flere fil aktier eller nogen kombination af de to

Kvorumstyper

der er fire kvorumstyper. Denne information er også tilgængelig her:
http://technet.microsoft.com/en-us/library/cc731739.aspx#BKMK_choices
.

node Majority

dette er den nemmeste kvorumstype at forstå og anbefales til klynger med et ulige antal noder (3-noder, 5-noder osv.). I denne konfiguration har hver node 1 stemme, så der er et ulige antal samlede stemmer i klyngen. Hvis der er en partition mellem to delmængder af noder, vil delmængden med mere end halvdelen af knudepunkterne opretholde beslutningsdygtighed. For eksempel, hvis en 5-node klynge partitioner i en 3-node delmængde og en 2-node delmængde, 3-node delmængde vil forblive online og 2-node delmængde vil offline, indtil det kan genoprette forbindelse til de andre 3 noder.

Node & disk flertal

denne kvorum konfiguration er mest almindeligt anvendt, da det fungerer godt med 2-node og 4-node klynger, som er de mest almindelige implementeringer. Denne konfiguration bruges, når der er et lige antal noder i klyngen. I denne konfiguration får hver node 1 stemme, og derudover får 1 disk 1 stemme, så der er generelt et ulige antal samlede stemmer.

denne disk kaldes Diskvidnet (undertiden benævnt ‘kvorumdisken’) og er simpelthen en lille grupperet disk, der er i gruppen Cluster Available Storage. Denne disk er meget tilgængelig og kan fejleover mellem noder. Det betragtes som en del af Cluster Core Resources group, men det er generelt skjult for visning i Failover Cluster Manager, da det ikke behøver at blive interageret med.

da der er et lige antal noder og 1 Tilføjelse Disk vidne stemme, i alt vil der være et ulige antal stemmer. Hvis der er en partition mellem to delmængder af noder, vil delmængden med mere end halvdelen af stemmerne opretholde beslutningsdygtighed. For eksempel, hvis en 4-node klynge med en Disk vidne partitioner i en 2-node delmængde og en anden 2-node delmængde, en af disse delmængder vil også eje disken vidne, så det vil have 3 samlede stemmer og vil forblive online. 2-node-delmængden er offline, indtil den kan oprette forbindelse igen med de andre 3 vælgere. Dette betyder, at klyngen kan miste kommunikationen med to vælgere, uanset om de er 2 noder eller 1 knude og Vidneskiven.

Node & Fildelingsflertal

denne kvorumskonfiguration bruges normalt i klynger med flere steder. Denne konfiguration bruges, når der er et lige antal noder i klyngen, så det kan bruges ombytteligt med Node-og Diskflertal kvorumstilstand. I denne konfiguration får hver node 1 stemme, og derudover får 1 fjernfildeling 1 stemme.

denne fildeling kaldes Fildelingsvidnet og er simpelthen en fildeling på enhver server i samme ANNONCESKOV, som alle klyngeknudepunkter har adgang til. En node i klyngen placerer en lås på fildelingen for at betragte den som ‘ejer’ af den fildeling, og en anden node griber fat i låsen, hvis den oprindelige ejerknude mislykkes. På en enkeltstående server er fildelingen i sig selv ikke meget tilgængelig, men fildelingen kan også lægge en grupperet fildeling på en uafhængig klynge, hvilket gør FSV-klyngen og giver den mulighed for at mislykkes mellem noder. Det er vigtigt, at du ikke sætter denne afstemning på en node i den samme klynge eller inden for en VM i den samme klynge, fordi at miste den node ville få dig til at miste FSV-afstemningen, hvilket får to stemmer til at gå tabt på en enkelt fiasko. En enkelt filserver kan være vært for flere FSA ‘ er til flere klynger.

generelt har multi-site klynger to steder med et lige antal noder på hvert sted, hvilket giver et lige antal noder. Ved at tilføje denne ekstra afstemning på et 3
rd
sted er der et ulige antal stemmer i klyngen til meget lidt udgift sammenlignet med at implementere et 3
rd
sted med en aktiv klyngeknude og skrivbar DC. Dette betyder, at enten site eller FSV kan gå tabt, og klyngen stadig kan opretholde beslutningsdygtighed. For eksempel i en multi-site klynge med 2 noder på Site1, 2 noder på Site2 og en FSV på Site3 er der 5 samlede stemmer. Hvis der er en partition mellem siderne, vil en af knudepunkterne på et sted eje låsen til FSV, så stedet har 3 samlede stemmer og forbliver online. 2-node site vil offline, indtil det kan genoprette forbindelse til de andre 3 vælgere.

Legacy: kun Disk

vigtigt:
denne kvorumstype anbefales ikke, da den har et enkelt fejlpunkt.

diskens eneste kvorumstype var tilgængelig i vinduer Server 2003 og er blevet vedligeholdt af kompatibilitetshensyn, men det anbefales kraftigt at aldrig bruge denne tilstand, medmindre det er instrueret af en lagringsleverandør. I denne tilstand indeholder kun Diskvidnet en stemme, og der er ingen andre vælgere i klyngen. Dette betyder, at hvis disken bliver utilgængelig, vil hele klyngen offline, så dette betragtes som et enkelt fejlpunkt. Men nogle kunder vælger at implementere denne konfiguration for at få en “last man standing” – konfiguration, hvor klyngen forbliver online, så længe en node stadig er operationel og kan få adgang til klyngeskiven. Men med dette implementeringsmål er det vigtigt at overveje, om den sidste resterende knude endda kan håndtere kapaciteten af alle de arbejdsbelastninger, der er flyttet til den fra andre noder.

standard Kvorumvalg

når klyngen oprettes ved hjælp af Failover Cluster Manager, Cluster.cluster vælger automatisk den bedste kvorumstype for dig for at forenkle implementeringen. Dette valg er baseret på antallet af noder og tilgængelig opbevaring. Logikken er som følger:

  • ulige antal noder – brug Node flertal
    • lige antal noder
      • tilgængelige Klyngediske-brug Node & disk flertal
      • Ingen tilgængelig Klyngedisk-brug Node flertal

klyngen vælger aldrig Node og File Share Majority eller Legacy: kun Disk. Kvorumstypen kan stadig konfigureres fuldt ud af administratoren, hvis standardvalgene ikke foretrækkes.

ændring af Kvorumstyper

ændring af kvorumstypen er let gennem Failover Cluster Manager. Højreklik på klyngens navn, vælg Flere handlinger…, og vælg derefter Konfigurer Klyngekvorumindstillinger… for at starte guiden Konfigurer Klyngekvorum. Fra guiden er det muligt at konfigurere alle 4 kvorum typer, ændre disken vidne eller fil aktie vidne. Guiden vil endda fortælle dig antallet af fejl, der kan opretholdes baseret på din konfiguration.

For en trinvis vejledning til konfiguration af beslutningsdygtighed, besøg:
http://technet.microsoft.com/en-us/library/cc733130.aspx
.

Tak!
Symon Perriman
Teknisk Evangelist
Private Cloud Technologies
Microsoft

Opdateret: 6. November 2019 af Rob Hindman

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.

lg