Forstå klynge-og utvalgsquorum

• 01/18/2019
• 11 minutter å lese
• • a
  • e
  • v
  • C
  • J
  • +3

Gjelder For: Windows Server 2019, Windows Server 2016

Windows Server Failover Clustering gir høy tilgjengelighet for arbeidsbelastninger. Disse ressursene anses som svært tilgjengelige hvis nodene som vertsressurser er oppe; klyngen krever imidlertid generelt mer enn halvparten av nodene som skal kjøres, som er kjent som å ha quorum.

Quorum er utformet for å hindre split-hjerne scenarier som kan skje når det er en partisjon i nettverket og delsett av noder ikke kan kommunisere med hverandre. Dette kan føre til at begge delsettene av noder prøver å eie arbeidsbelastningen og skrive til samme disk som kan føre til mange problemer. Dette er imidlertid forhindret Med Failover Clustering konsept quorum som tvinger bare en av disse gruppene av noder å fortsette å kjøre, så bare en av disse gruppene vil være online.

Quorum bestemmer antall feil som klyngen kan opprettholde mens de fortsatt er tilkoblet. Quorum er utformet for å håndtere scenariet når det er et problem med kommunikasjon mellom delsett av klyngenoder, slik at flere servere ikke prøver å samtidig være vert for en ressursgruppe og skrive til samme disk samtidig. 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.

I Windows Server 2019 Og Windows Server 2016 er det to komponenter i systemet som har sine egne quorum mekanismer:

• Klyngekvorum: dette opererer på klyngenivå (dvs. Du kan miste noder og få klyngen til å holde seg oppe)
• Bassengkvorum: dette opererer på bassengnivå når Storage Spaces Direct er aktivert (dvs.du kan miste noder og stasjoner og få bassenget til å holde seg oppe). Lagringsbassenger ble designet for å brukes i både grupperte og ikke-grupperte scenarier, og derfor har de en annen quorumsmekanisme.

oversikt Over Klyngekvorum

tabellen nedenfor gir en oversikt over resultatene For Klyngekvorum per scenario:

Servernoder	kan overleve en servernodefeil	kan overleve en servernodefeil, og en annen	kan overleve to samtidige servernodefeil
2	50/50	Nei	Nei
2 + Vitne	Ja	Nei	Nei
3	Ja	50/50	Nei
3 + Vitne	Ja	Ja	Nei
4	Ja	Ja	50/50
4 + Vitne	Ja	Ja	Ja
5 og over	Ja	Ja	Ja

Cluster quorum anbefalinger

• hvis du har to noder, kreves et vitne.
• hvis du har tre eller fire noder, er witness sterkt anbefalt.
• hvis Du har Internett-tilgang, bruker du et skyvitne
• hvis DU er I ET IT-miljø med andre maskiner og fildeling, bruker du et fildelingsvitne

hvordan cluster quorum fungerer

når noder mislykkes, eller når et delsett av noder mister kontakten med et annet delsett, må overlevende noder bekrefte at de utgjør størstedelen av klyngen for å forbli tilkoblet. Hvis de ikke kan bekrefte det, vil de gå offline.

men begrepet flertall fungerer bare rent når det totale antall noder i klyngen er merkelig (for eksempel tre noder i en fem node-klynge). Så, hva med klynger med et jevnt antall noder (si en fire nodeklynge)?

det er to måter klyngen kan gjøre det totale antall stemmer merkelig:

1. Først kan det gå opp en ved å legge til et vitne med en ekstra stemme. Dette krever brukeroppsett.
2. eller det kan gå ned en ved å nullstille en uheldig nodes stemme (skjer automatisk etter behov).

når overlevende noder vellykket verifiserer at de er flertallet, oppdateres definisjonen av flertall for å være blant bare de overlevende. Dette gjør at klyngen kan miste en node, deretter en annen, deretter en annen, og så videre. Dette konseptet av det totale antall stemmer som tilpasser seg etter suksessive feil er kjent som Dynamisk quorum.

Dynamisk vitne

Dynamisk vitne veksler vitnets stemme for å sikre at det totale antall stemmer er merkelig. Hvis det er et merkelig antall stemmer, har vitnet ikke en stemme. Hvis det er et jevnt antall stemmer, har vitnet en stemme. Dynamisk vitne reduserer risikoen for at klyngen vil gå ned på grunn av vitnefeil betydelig. Klyngen avgjør om vitnestemmen skal brukes basert på antall stemmenoder som er tilgjengelige i klyngen.

Dynamisk quorum arbeider Med Dynamisk vitne på den måten som er beskrevet nedenfor.

Dynamisk quorumsadferd

• hvis du har et jevnt antall noder og ikke noe vitne, får en node sin stemme nullstilt. For eksempel får bare tre av de fire noder stemmer, så totalt antall stemmer er tre, og to overlevende med stemmer regnes som et flertall.
• hvis du har et merkelig antall noder og ikke noe vitne, får de alle stemmer.
• hvis du har et jevnt antall noder pluss vitne, stemmer vitnet, så summen er merkelig.
• hvis du har et ulikt antall noder pluss vitne, stemmer ikke vitnet.

Dynamisk quorum gjør det mulig å tildele en stemme til en node dynamisk for å unngå å miste flertallet av stemmer og for å tillate klyngen å kjøre med en node (kjent som siste mann stående). La oss ta en fire-node klynge som et eksempel. Anta at quorum krever 3 stemmer.

i dette tilfellet ville klyngen ha gått ned hvis du mistet to noder.

dynamisk quorum forhindrer imidlertid at dette skjer. Det totale antall stemmer som kreves for quorum, bestemmes nå basert på antall tilgjengelige noder. Så, med dynamisk quorum, vil klyngen holde seg oppe selv om du mister tre noder.

scenariet ovenfor gjelder for en generell klynge Som Ikke har Direkte Lagringsområder aktivert. Når Lagringsområder Direkte er aktivert, kan klyngen imidlertid bare støtte to nodefeil. Dette forklares mer i pool quorum-delen.

Eksempler

To noder uten vitne.

en nodes stemme er nullet, så flertallsstemmen bestemmes ut av totalt 1 stemme. Hvis noden som ikke stemmer, går ned uventet, har overlevende 1/1 og klyngen overlever. Hvis stemme noden går ned uventet, overlevende har 0/1 og klyngen går ned. Hvis stemmenoden er elegant slått av, overføres avstemningen til den andre noden, og klyngen overlever. Derfor er det viktig å konfigurere et vitne.

• kan overleve en serverfeil: Femti prosent sjanse.
• kan overleve en serverfeil, deretter En annen: Nei.
• kan overleve to serverfeil samtidig: Nei.

To noder med et vitne.

begge nodene stemmer, pluss vitnenes stemmer, så flertallet bestemmes ut av totalt 3 stemmer. Hvis enten node går ned, har overlevende 2/3 og klyngen overlever.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter En annen: Nei.
• kan overleve to serverfeil samtidig: Nei.

Tre noder uten et vitne.

alle noder stemmer, så flertallet bestemmes ut av totalt 3 stemmer. Hvis noen node går ned, er de overlevende 2/3 og klyngen overlever. Klyngen blir to noder uten et vitne – på det tidspunktet er Du I Scenario 1.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter En Annen: Femti prosent sjanse.
• kan overleve to serverfeil samtidig: Nei.

Tre noder med et vitne.

alle noder stemmer, så vitnet stemmer ikke i utgangspunktet. Flertallet er bestemt ut av totalt 3 stemmer. Etter en feil har klyngen to noder med et vitne – som er tilbake Til Scenario 2. Så, nå de to noder og vitnet stemme.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: Ja.
• kan overleve to serverfeil samtidig: Nei.

Fire noder uten vitne

en nodes stemme er nullet, så flertallet er bestemt ut av totalt 3 stemmer. Etter en feil blir klyngen tre noder, og Du er I Scenario 3.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: Ja.
• kan overleve to serverfeil samtidig: Femti prosent sjanse.

Fire noder med et vitne.

alle noder stemmer og vitnet stemmer, så flertallet bestemmes ut av totalt 5 stemmer. Etter en feil er Du i Scenario 4. Etter to samtidige feil, hopper du ned Til Scenario 2.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: Ja.
• kan overleve to serverfeil samtidig: Ja.

Fem noder og videre.

alle noder stemmer, eller alle unntatt en stemme, uansett hva som gjør summen merkelig. Storage Spaces Direct kan ikke håndtere mer enn to noder ned uansett, så på dette punktet er det ikke nødvendig med noe vitne eller nyttig.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: Ja.
• kan overleve to serverfeil samtidig: Ja.

nå som vi forstår hvordan quorum virker, la oss se på typene quorumvitner.

quorumvitnetyper

Failover-Klynger støtter tre Typer Quorumvitner:

• Cloud Witness-Blob-lagring i Azure tilgjengelig for alle noder i klyngen. Det opprettholder clustering informasjon i et vitne.loggfil, men lagrer ikke en kopi av klyngedatabasen.
• File Share Witness – EN smb-fildeling som er konfigurert på en filserver som kjører Windows Server. Det opprettholder clustering informasjon i et vitne.loggfil, men lagrer ikke en kopi av klyngedatabasen.
• Disk Witness – en liten gruppert disk som er I Klyngen Tilgjengelig Lagringsgruppe. Denne disken er svært tilgjengelig og kan failover mellom noder. Den inneholder en kopi av klyngedatabasen. Et Diskvitne støttes Ikke Med Lagringsplasser Direkte.

Oversikt Over Bassengkvorum

Vi snakket nettopp Om Klyngekvorum, som opererer på klyngenivå. La oss nå dykke inn I Pool Quorum, som opererer på bassengnivå (dvs.du kan miste noder og stasjoner og få bassenget til å holde seg oppe). Lagringsbassenger ble designet for å brukes i både grupperte og ikke-grupperte scenarier, og derfor har de en annen quorumsmekanisme.

tabellen nedenfor gir en oversikt over Utvalgskvorumsresultatene per scenario:

Servernoder	kan overleve en servernodefeil	kan overleve en servernodefeil, og en annen	kan overleve to samtidige servernodefeil
2	Nei	Nei	Nei
2 + Vitne	Ja	Nei	Nei
3	Ja	Nei	Nei
3 + Vitne	Ja	Nei	Nei
4	Ja	Nei	Nei
4 + Vitne	Ja	Ja	Ja
5 og over	Ja	Ja	Ja

hvordan utvalgskvorum fungerer

når stasjoner mislykkes, eller når noen delsett av stasjoner mister kontakten med et annet delsett, må overlevende stasjoner bekrefte at de utgjør flertallet av utvalget for å forbli tilkoblet. Hvis de ikke kan bekrefte det, vil de gå offline. Utvalget er enheten som kobles fra eller forblir tilkoblet basert på om den har nok disker for quorum (50% + 1). Ressurseieren for utvalget (aktiv klyngenode) kan være +1.

men utvalgskvorum fungerer annerledes enn klyngekvorum på følgende måter:

• utvalget bruker en node i klyngen som vitne som avgjørende for å overleve halvparten av stasjonene som er borte (denne noden som er ressurseieren for utvalget)
• utvalget har ikke dynamisk quorum
• utvalget implementerer IKKE sin egen versjon av å fjerne en stemme

Eksempler

Fire noder med symmetrisk layout.

Hver av de 16 stasjonene har en stemme og node to har også en stemme(siden det er bassengressurseieren). Flertallet er bestemt ut av totalt 16 stemmer. Hvis noder tre og fire går ned, har den overlevende delmengden 8 stasjoner og bassengressurseieren, som er 9/16 stemmer. Så overlever bassenget.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: Ja.
• kan overleve to serverfeil samtidig: Ja.

Fire noder med symmetrisk layout og stasjonsfeil.

Hver av de 16 stasjonene har en stemme og node 2 har også en stemme(siden det er bassengressurseieren). Flertallet er bestemt ut av totalt 16 stemmer. Først går stasjon 7 ned. Hvis noder tre og fire går ned, har den overlevende delmengden 7 stasjoner og bassengressurseieren, som er 8/16 stemmer. Så, bassenget har ikke flertall og går ned.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter En annen: Nei.
• kan overleve to serverfeil samtidig: Nei.

Fire noder med en ikke-symmetrisk layout.

Hver av de 24 stasjonene har en stemme og node to har også en stemme(siden det er bassengressurseieren). Flertallet er bestemt ut av totalt 24 stemmer. Hvis noder tre og fire går ned, har den overlevende delmengden 8 stasjoner og bassengressurseieren, som er 9/24 stemmer. Så, bassenget har ikke flertall og går ned.

• kan overleve en serverfeil: Ja.
• kan overleve en serverfeil, deretter en annen: * * Avhenger * * (kan ikke overleve hvis begge noder tre og fire går ned, men kan overleve alle andre scenarier.
• kan overleve to serverfeil samtidig: ** Avhenger * *(kan ikke overleve hvis begge noder tre og fire går ned, men kan overleve alle andre scenarier.

Utvalgskvorumsanbefalinger

• Kontroller at hver node i klyngen er symmetrisk (hver node har samme antall stasjoner)
• Aktiver treveisspeil eller dobbel paritet, Slik at du kan tolerere nodefeil og holde de virtuelle diskene tilkoblet. Se vår volumveiledningsside for mer informasjon.
• hvis mer enn to noder er nede, eller to noder og en disk på en annen node er nede, kan det hende at volumene ikke har tilgang til alle tre kopiene av dataene, og derfor blir frakoblet og være utilgjengelige. Det anbefales å bringe serverne tilbake eller erstatte diskene raskt for å sikre mest mulig fleksibilitet for alle dataene i volumet.