forståelse af klyngens og poolens kvorum

• 01/18/2019
• 11 minutter at læse
• • a
  • e
  • v
  • C
  • J
  • +3

gælder: vinduer Server 2019, vinduer Server 2016

vinduer Server Failover Clustering giver høj tilgængelighed for arbejdsbyrder. Disse ressourcer betragtes som meget tilgængelige, hvis de noder, der er vært for ressourcer, er op; klyngen kræver dog generelt, at mere end halvdelen af knudepunkterne kører, hvilket er kendt som beslutningsdygtigt.

kvorum er designet til at forhindre split-hjerne scenarier, der kan ske, når der er en partition i netværket, og delmængder af noder ikke kan kommunikere med hinanden. Dette kan medføre, at begge undergrupper af noder forsøger at eje arbejdsbyrden og skrive til den samme disk, hvilket kan føre til mange problemer. Dette forhindres dog med Failover Clustering ‘ s kvorumskoncept, som kun tvinger en af disse grupper af noder til at fortsætte med at køre, så kun en af disse grupper forbliver online.

Kvorum bestemmer antallet af fejl, som klyngen kan opretholde, mens den stadig er online. Kvorum er designet til at håndtere scenariet, når der er et problem med kommunikation mellem delmængder af klyngenoder, så flere servere ikke forsøger samtidig at være vært for en ressourcegruppe og skrive til den samme disk på samme tid. 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.

i vinduer Server 2019 og vinduer Server 2016 er der to komponenter i systemet, der har deres egne kvorumsmekanismer:

• Klyngekvorum: dette fungerer på klyngeniveau (dvs. du kan miste noder og få klyngen til at holde op)
• Pool Kvorum: dette fungerer på poolniveau, når lagerpladser direkte er aktiveret (dvs.du kan miste noder og drev og få poolen til at holde op). Opbevaringspuljer blev designet til at blive brugt i både grupperede og ikke-grupperede scenarier, hvorfor de har en anden kvorumsmekanisme.

oversigt over klyngens kvorum

nedenstående tabel giver en oversigt over klyngens Kvorumsresultater pr. scenarie:

Server noder	kan overleve en server node fiasko	kan overleve en server node fiasko, så en anden	kan overleve to samtidige server node fejl
2	50/50	Nej	Nej
2 + vidne	Ja	Nej	Nej
3	Ja	50/50	Nej
3 + vidne	Ja	Ja	Nej
4	Ja	Ja	50/50
4 + vidne	Ja	Ja	Ja
5 og derover	Ja	Ja	Ja

anbefalinger til Klyngekvorum

• hvis du har to noder, kræves et vidne.
• hvis du har tre eller fire noder, anbefales vidne stærkt.
• hvis du har internetadgang, skal du bruge et cloud-vidne
• hvis du er i et IT-miljø med andre maskiner og fildeling, skal du bruge et file share-vidne

Sådan fungerer klyngekvorum

når noder mislykkes, eller når en delmængde af noder mister kontakten med en anden delmængde, skal overlevende noder kontrollere, at de udgør størstedelen af klyngen for at forblive online. Hvis de ikke kan bekræfte det, går de offline.

men begrebet flertal fungerer kun rent, når det samlede antal noder i klyngen er ulige (for eksempel tre noder i en fem knudeklynge). Så hvad med klynger med et lige antal noder (siger en fire node klynge)?

der er to måder klyngen kan gøre det samlede antal stemmer ulige:

1. for det første kan det gå op ved at tilføje et vidne med en ekstra stemme. Dette kræver brugeropsætning.
2. eller det kan gå ned en ved at nulstille en uheldig nodes stemme (sker automatisk efter behov).

når overlevende noder med succes bekræfter, at de er flertallet, opdateres definitionen af flertal til kun at være blandt de overlevende. Dette gør det muligt for klyngen at miste en knude, derefter en anden, derefter en anden osv. Dette begreb om det samlede antal stemmer, der tilpasser sig efter successive fiaskoer, kaldes dynamisk beslutningsdygtighed.

dynamisk vidne

dynamisk vidne skifter vidnets stemme for at sikre, at det samlede antal stemmer er ulige. Hvis der er et ulige antal stemmer, har vidnet ikke afstemning. Hvis der er et lige antal stemmer, har vidnet en afstemning. Dynamisk vidne reducerer risikoen for, at klyngen vil gå ned på grund af vidne fiasko. Klyngen beslutter, om vidneafstemningen skal bruges baseret på antallet af stemmeknuder, der er tilgængelige i klyngen.

dynamisk kvorum arbejder med dynamisk vidne på den måde, der er beskrevet nedenfor.

dynamisk kvorumsadfærd

• hvis du har et lige antal noder og intet vidne, får en node sin stemme nulstillet. For eksempel får kun tre af de fire noder stemmer, så det samlede antal stemmer er tre, og to overlevende med stemmer betragtes som et flertal.
• hvis du har et ulige antal noder og intet vidne, får de alle stemmer.
• hvis du har et lige antal noder plus vidne, stemmer vidnet, så summen er ulige.
• hvis du har et ulige antal noder plus vidne, stemmer vidnet ikke.

dynamisk kvorum gør det muligt at tildele en stemme til en node dynamisk for at undgå at miste flertallet af stemmerne og tillade klyngen at køre med en node (kendt som sidste mand stående). Lad os tage en fire-node klynge som et eksempel. Antag, at beslutningsdygtighed kræver 3 stemmer.

i dette tilfælde ville klyngen være gået ned, hvis du mistede to noder.

dynamisk kvorum forhindrer dog, at dette sker. Det samlede antal stemmer, der kræves for beslutningsdygtighed, bestemmes nu ud fra antallet af tilgængelige noder. Så med dynamisk kvorum forbliver klyngen op, selvom du mister tre noder.

ovenstående scenario gælder for en generel klynge, der ikke har lagerplads direkte aktiveret. Men når Storage Spaces Direct er aktiveret, kan klyngen kun understøtte to knudefejl. Dette forklares mere i afsnittet pool kvorum.

eksempler

to noder uden vidne.

en nodes stemme nulstilles, så flertalsafstemningen bestemmes ud af i alt 1 stemme. Hvis den ikke-stemmeberettigede knude går uventet ned, har den overlevende 1/1, og klyngen overlever. Hvis stemmeknudepunktet går uventet ned, har overlevende 0/1, og klyngen går ned. Hvis stemmeknudepunktet er yndefuldt slået ned, overføres afstemningen til den anden knude, og klyngen overlever. Derfor er det vigtigt at konfigurere et vidne.

• kan overleve en serverfejl: halvtreds procent chance.
• kan overleve en serverfejl, så en anden: Nej.
• kan overleve to serverfejl på en gang: Nej.

to noder med et vidne.

begge noder stemmer, plus vidnet stemmer, så flertallet bestemmes ud af i alt 3 stemmer. Hvis en af knuderne går ned, har den overlevende 2/3, og klyngen overlever.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Nej.
• kan overleve to serverfejl på en gang: Nej.

tre noder uden vidne.

alle noder stemmer, så flertallet bestemmes ud af i alt 3 stemmer. Hvis nogen knude går ned, er de overlevende 2/3, og klyngen overlever. Klyngen bliver to noder uden vidne – på det tidspunkt er du i Scenario 1.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: halvtreds procent chance.
• kan overleve to serverfejl på en gang: Nej.

tre noder med et vidne.

alle noder stemmer, så vidnet stemmer ikke oprindeligt. Flertallet bestemmes ud fra i alt 3 stemmer. Efter en fejl har klyngen to noder med et vidne – som er tilbage til Scenario 2. Så nu stemmer de to knudepunkter og vidnet.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Ja.
• kan overleve to serverfejl på en gang: Nej.

fire noder uden vidne

en nodes stemme nulstilles, så flertallet bestemmes ud af i alt 3 stemmer. Efter en fejl bliver klyngen tre noder, og du er i Scenario 3.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Ja.
• kan overleve to serverfejl på en gang: halvtreds procent chance.

fire noder med et vidne.

alle noder stemmer og vidnet stemmer, så flertallet bestemmes ud af i alt 5 stemmer. Efter en fejl er du i scenarie 4. Efter to samtidige fejl springer du ned til Scenario 2.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Ja.
• kan overleve to serverfejl på en gang: Ja.

fem noder og videre.

alle noder stemmer, eller alle undtagen en stemme, uanset hvad der gør det samlede ulige. Opbevaringspladser direkte kan alligevel ikke håndtere mere end to noder, så på dette tidspunkt er der ikke behov for noget vidne eller nyttigt.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Ja.
• kan overleve to serverfejl på en gang: Ja.

nu hvor vi forstår, hvordan kvorum fungerer, lad os se på typerne af kvorum vidner.

Kvorumsvidnetyper

Failover Clustering understøtter tre typer Kvorumsvidner:

• Cloud vidne-Blob opbevaring i blå tilgængelig af alle knudepunkter i klyngen. Det opretholder klyngedannelse oplysninger i et vidne.logfil, men gemmer ikke en kopi af klyngedatabasen.
• fil Del vidne – en SMB fil del, der er konfigureret på en filserver kører vinduer Server. Det opretholder klyngedannelse oplysninger i et vidne.logfil, men gemmer ikke en kopi af klyngedatabasen.
• Disk vidne – en lille grupperet disk, som er i klyngen tilgængelig opbevaring gruppe. Denne disk er meget tilgængelig og kan fejleover mellem noder. Den indeholder en kopi af klyngedatabasen. En disk vidne understøttes ikke med Storage Spaces Direct.

Pool kvorum oversigt

vi talte lige om Klyngekvorum, der opererer på klyngeniveau. Lad os nu dykke ned i Pool kvorum, som opererer på poolniveau (dvs.du kan miste noder og drev og få poolen til at holde op). Opbevaringspuljer blev designet til at blive brugt i både grupperede og ikke-grupperede scenarier, hvorfor de har en anden kvorumsmekanisme.

nedenstående tabel giver et overblik over puljens Kvorumsresultater pr. scenarie:

Server noder	kan overleve en server node fiasko	kan overleve en server node fiasko, så en anden	kan overleve to samtidige server node fejl
2	Nej	Nej	Nej
2 + vidne	Ja	Nej	Nej
3	Ja	Nej	Nej
3 + vidne	Ja	Nej	Nej
4	Ja	Nej	Nej
4 + vidne	Ja	Ja	Ja
5 og derover	Ja	Ja	Ja

hvordan pool kvorum fungerer

når drev mislykkes, eller når en delmængde af drev mister kontakten med en anden delmængde, skal overlevende drev kontrollere, at de udgør størstedelen af puljen for at forblive online. Hvis de ikke kan bekræfte det, går de offline. Puljen er den enhed, der går offline eller forbliver online baseret på, om den har nok diske til beslutningsdygtighed (50% + 1). Pool ressource ejer (aktiv klynge node) kan være +1.

men poolkvorum fungerer forskelligt fra klyngekvorum på følgende måder:

• puljen bruger en knude i klyngen som vidne som en tie-breaker for at overleve halvdelen af drev væk (denne knude, der er poolressourceejeren)
• puljen har ikke dynamisk kvorum
• puljen implementerer ikke sin egen version af fjernelse af en stemme

eksempler

fire noder med et symmetrisk layout.

hver af de 16 drev har en stemme, og node to har også en stemme (da det er poolressourceejeren). Flertallet bestemmes ud fra i alt 16 stemmer. Hvis noder tre og fire går ned, har den overlevende delmængde 8 drev og poolressourceejeren, hvilket er 9/16 stemmer. Så puljen overlever.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Ja.
• kan overleve to serverfejl på en gang: Ja.

fire noder med et symmetrisk layout og drevfejl.

hver af de 16 drev har en stemme, og node 2 har også en stemme (da det er poolressourceejeren). Flertallet bestemmes ud fra i alt 16 stemmer. Først kører 7 ned. Hvis noder tre og fire går ned, har den overlevende delmængde 7 drev og poolressourceejeren, hvilket er 8/16 stemmer. Så puljen har ikke flertal og går ned.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: Nej.
• kan overleve to serverfejl på en gang: Nej.

fire noder med et ikke-symmetrisk layout.

hver af de 24 drev har en stemme, og node to har også en stemme (da det er poolressourceejeren). Flertallet bestemmes ud fra i alt 24 stemmer. Hvis noder tre og fire går ned, har den overlevende delmængde 8 drev og poolressourceejeren, hvilket er 9/24 stemmer. Så puljen har ikke flertal og går ned.

• kan overleve en serverfejl: Ja.
• kan overleve en serverfejl, så en anden: **afhænger **(kan ikke overleve, hvis begge noder tre og fire går ned, men kan overleve alle andre scenarier.
• kan overleve to serverfejl på en gang: ** Afhænger **(kan ikke overleve, hvis begge noder tre og fire går ned, men kan overleve alle andre scenarier.

pool kvorum anbefalinger

• sørg for, at hver node i din klynge er symmetrisk (hver node har det samme antal drev)
• aktiver tre-vejs spejl eller dobbelt paritet, så du kan tolerere en node fejl og holde de virtuelle diske online. Se vores volumenvejledningsside for flere detaljer.
• hvis mere end to noder er nede, eller to noder og en disk på en anden knude er nede, har volumener muligvis ikke adgang til alle tre kopier af deres data og tages derfor offline og er utilgængelige. Det anbefales at bringe serverne tilbage eller udskifte diske hurtigt for at sikre den mest elasticitet for alle data i lydstyrken.