først publisert På MSDN 27. Mai 2011
Hei Cluster Fans,

dette blogginnlegget vil klargjøre planleggingshensyn rundt
quorum
I En Failover-Klynge og svare på noen av de vanligste spørsmålene vi hører.

quorumskonfigurasjonen i en failover-klynge bestemmer antall feil som klyngen kan opprettholde mens den fortsatt er tilkoblet. Hvis det oppstår en ekstra feil utenfor denne terskelen, slutter klyngen å kjøre. En vanlig oppfatning er at grunnen til at klyngen vil slutte å kjøre hvis for mange feil oppstår, er å hindre at de gjenværende nodene tar på seg for mange arbeidsbelastninger og at vertene blir overcommitted. Faktisk vet klyngen ikke kapasitetsbegrensningene dine, eller om du vil være villig til å ta en ytelse hit for å holde den online. Snarere quorum er design for å håndtere scenariet når det er et problem med kommunikasjon mellom sett med klyngenoder, slik at to servere ikke prøver å samtidig være vert for en ressursgruppe og skrive til samme disk samtidig. Dette er kjent som en «delt hjerne», og vi vil forhindre dette for å unngå potensiell korrupsjon til en disk som jeg har to samtidige gruppeeiere. Ved å ha dette begrepet quorum, vil klyngen tvinge klyngetjenesten til å stoppe i en av delsettene av noder for å sikre at det bare er en sann eier av en bestemt ressursgruppe. Når noder som har blitt stoppet, igjen kan kommunisere med hovedgruppen av noder, vil de automatisk bli med i klyngen og starte klyngetjenesten.

hvis du vil ha mer informasjon om quorum i en klynge, kan du gå til:
http://technet.microsoft.com/en-us/library/cc731739.aspx
.

Stemme Mot Quorum

Å Ha ‘quorum’, eller et flertall av velgerne, er basert på stemmealgoritme der mer enn halvparten av velgerne må være online og kunne kommunisere med hverandre. Fordi en gitt klynge har et bestemt sett med noder og en bestemt quorumskonfigurasjon, vil klyngen vite hvor mange «stemmer» som utgjør et flertall av stemmer, eller quorum. Hvis antall velgere faller under flertallet, stopper klyngetjenesten på nodene i den gruppen. Disse nodene vil fortsatt lytte etter tilstedeværelsen av andre noder, hvis en annen node vises igjen på nettverket, men nodene vil ikke begynne å fungere som en klynge før quorumet eksisterer igjen.

det er viktig å innse at klyngen krever
mer enn
halvparten av de totale stemmene for å oppnå quorum. Dette er for å unngå å ha et slips i antall stemmer i en partisjon, siden flertallet alltid vil bety at den andre partisjonen har mindre enn halvparten av stemmene. I en 5-node klynge, 3 velgere må være online; likevel i en 4-node klynge, 3 velgere må også være online for å ha flertall. Pa grunn av denne logikken anbefales det a alltid ha et merkelig antall totale velgere i klyngen. Dette betyr ikke nødvendigvis at et oddetall antall noder er nødvendig siden både en disk eller en fildeling kan bidra med en stemme, avhengig av quorumsmodellen.

en velger kan være:

  • en node
    • 1 Stemme
    • Hver node i klyngen har 1 stemme
  • Et «Diskvitne » Eller»Fildelingsvitne»
    • 1 Stemme
    • Enten 1 Diskvitne eller 1 Fildelingsvitne kan ha en stemme i klyngen, men ikke flere disker, flere filandeler eller en kombinasjon av de to

Quorumstyper

det finnes fire quorumstyper. Denne informasjonen er også tilgjengelig her:
http://technet.microsoft.com/en-us/library/cc731739.aspx#BKMK_choices
.

Node Majority

Dette er den enkleste quorumstypen å forstå Og anbefales for klynger med et merkelig antall noder(3-noder, 5-noder, etc.). I denne konfigurasjonen har hver node 1 stemme, så det er et merkelig antall totale stemmer i klyngen. Hvis det er en partisjon mellom to delsett av noder, vil delsettet med mer enn halvparten av nodene opprettholde quorum. For eksempel, hvis en 5-node klynge partisjoner i en 3-node delsett og en 2-node delsett, 3-node delsett vil være tilkoblet og 2-node delsett vil frakoblet til den kan koble til med de andre 3 noder.

Node & Disk Flertall

denne quorum konfigurasjon er mest brukt siden det fungerer godt med 2-node og 4-node klynger som er de vanligste distribusjoner. Denne konfigurasjonen brukes når det er et jevnt antall noder i klyngen. I denne konfigurasjonen får hver node 1 stemme, og i tillegg får 1 disk 1 stemme, så det er generelt et merkelig antall totale stemmer.

denne disken kalles Diskvitnet (noen ganger referert til som ‘quorum disk’) og er ganske enkelt en liten gruppert disk som er I Klyngen Tilgjengelig Lagringsgruppe. Denne disken er svært tilgjengelig og kan failover mellom noder. Det regnes som en del Av Gruppen Cluster Core Resources, men det er vanligvis skjult i Failover Cluster Manager siden det ikke trenger å være interaksjon med.

Siden det er et jevnt antall noder og 1 tillegg Disk Vitne stemme, totalt vil det være et oddetall antall stemmer. Hvis det er en partisjon mellom to delsett av noder, vil delsettet med mer enn halvparten av stemmene opprettholde quorum. For eksempel, hvis en 4-node klynge med En Disk Vitne partisjoner i en 2-node delsett og en annen 2-node delsett, en av disse delsett vil også eie Disk Witness, så det vil ha 3 totale stemmer og vil være online. 2-node-delmengden vil være frakoblet til den kan koble til igjen med de andre 3-velgerne. Dette betyr at klyngen kan miste kommunikasjon med noen to velgere, enten de er 2 noder, eller 1 node og Vitneskiven.

Node & Flertall For Fildeling

denne quorumskonfigurasjonen brukes vanligvis i klynger med flere områder. Denne konfigurasjonen brukes når det er et jevnt antall noder i klyngen, slik at den kan brukes om hverandre Med Node Og Disk Flertall quorum modus. I denne konfigurasjonen får hver node 1 stemme, og i tillegg får 1 ekstern fildeling 1 stemme.

denne fildelingen kalles File Share Witness (FSW) og er ganske enkelt en fildeling på en hvilken som helst server i SAMME ANNONSESKOG som alle klyngenodene har tilgang til. En node i klyngen vil plassere en lås på fildelen for å betrakte den som eier av den filen, og en annen node vil ta tak i låsen hvis den opprinnelige eiernoden mislykkes. På en frittstående server er fildelingen i seg selv ikke svært tilgjengelig, men fildelingen kan også sette på en gruppert fildeling på en uavhengig klynge, noe SOM gjør FSW-klyngen og gir den muligheten til å mislykkes mellom noder. Det er viktig at du ikke legger denne avstemningen på en node i samme klynge, eller i EN VM på samme klynge, fordi å miste den noden vil føre til at DU mister FSW-stemmen, noe som fører til at to stemmer går tapt på en enkelt feil. En enkelt filserver kan være vert for flere FSWs for flere klynger.

vanligvis har multi-site-klynger to steder med like mange noder på hvert sted, noe som gir et jevnt antall noder. Ved å legge til denne ekstra avstemningen på et nettsted med 3
rd
, er det et merkelig antall stemmer i klyngen, med svært liten kostnad sammenlignet med å distribuere et nettsted med 3
rd
med en aktiv klyngenode og skrivbar DC. Dette betyr at enten området eller FSW kan gå tapt og klyngen kan fortsatt opprettholde quorum. For eksempel, i en multi-site-klynge med 2 noder På Site1, 2 noder På Site2 og EN FSW På Site3, er det 5 totalt stemmer. Hvis det er en partisjon mellom nettstedene, vil en av nodene på et nettsted eie låsen TIL FSW, slik at nettstedet vil ha 3 totale stemmer og vil forbli online. 2-node-nettstedet vil være offline til det kan koble til igjen med de andre 3-velgerne.

Legacy: Bare Disk

Viktig:
denne quorum-typen anbefales ikke, da den har et enkelt feilpunkt.

disk bare quorum typen var tilgjengelig I Windows Server 2003 og har blitt vedlikeholdt av kompatibilitetshensyn, men det anbefales sterkt å aldri bruke denne modusen med mindre regissert av en storage vender. I denne modusen inneholder Bare Diskvitnet en stemme, og det er ingen andre velgere i klyngen. Dette betyr at hvis disken blir utilgjengelig, vil hele klyngen være frakoblet, så dette regnes som et enkelt feilpunkt. Men noen kunder velger å distribuere denne konfigurasjonen for å få en» last man standing » – konfigurasjon der klyngen forblir online, så lenge en node fortsatt er operativ og kan få tilgang til klyngedisken. Med dette distribusjonsmålet er det imidlertid viktig å vurdere om den siste gjenværende noden til og med kan håndtere kapasiteten til alle arbeidsbelastningene som har flyttet til den fra andre noder.

Standard Quorumsvalg

Når klyngen er opprettet ved Hjelp Av Failover Cluster Manager, Klynge.exe Eller PowerShell, vil klyngen automatisk velge den beste quorum typen for deg å forenkle distribusjonen. Dette valget er basert på antall noder og tilgjengelig lagring. Logikken er som følger:

  • Oddetall Noder-Bruk Node Flertall
    • Partall Noder
      • Tilgjengelige Cluster Disker – Bruk Node & Disk Flertall
      • Ingen Tilgjengelig Cluster Disk-Bruk Node Flertall

klyngen vil aldri velge Node Og File Share Majority Eller Legacy: Disk Bare. Quorum-typen kan fortsatt konfigureres fullt ut av administratoren hvis standardvalgene ikke foretrekkes.

Endre Quorumstyper

Endre quorumstypen er enkelt Gjennom Failover Cluster Manager. Høyreklikk på navnet på klyngen, velg Flere Handlinger…, og velg Deretter Konfigurer Cluster Quorum Settings … for å starte Veiviseren Konfigurer Cluster Quorum. Fra veiviseren er det mulig å konfigurere alle 4 quorum typer, endre Diskvitne Eller Fildelingsvitne. Veiviseren vil til og med fortelle deg antall feil som kan opprettholdes basert på konfigurasjonen din.

hvis du vil ha en trinnvis veiledning for konfigurering av quorum, kan du gå til:
http://technet.microsoft.com/en-us/library/cc733130.aspx
.

Takk!
Symon Perriman
Teknisk Evangelist
Private Skyteknologier
Microsoft

Oppdatert: November 6th, 2019 av Rob Hindman

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

lg