förstå kluster och poolkvorum

• 01/18/2019
• 11 minuter att läsa
• • a
  • e
  • v
  • C
  • J
  • +3

gäller för: Windows Server 2019, Windows Server 2016

Windows Server Failover Clustering ger hög tillgänglighet för arbetsbelastningar. Dessa resurser anses vara mycket tillgängliga om noderna som värdresurser är uppe; klustret kräver emellertid i allmänhet att mer än hälften av noderna körs, vilket är känt som att ha kvorum.

Quorum är utformat för att förhindra split-brain-scenarier som kan hända när det finns en partition i nätverket och delmängder av noder inte kan kommunicera med varandra. Detta kan leda till att båda delmängderna av noder försöker äga arbetsbelastningen och skriva till samma disk vilket kan leda till många problem. Detta förhindras dock med Failover Clustering koncept av kvorum som tvingar bara en av dessa grupper av noder att fortsätta springa, så bara en av dessa grupper kommer att stanna online.

kvorum bestämmer antalet fel som klustret kan upprätthålla medan det fortfarande är online. Quorum är utformat för att hantera scenariot när det finns ett problem med kommunikation mellan delmängder av klusternoder, så att flera servrar inte försöker samtidigt vara värd för en resursgrupp och skriva till samma disk samtidigt. Genom att ha detta kvorumbegrepp kommer klustret att tvinga klustertjänsten att stanna i en av delmängderna av noder för att säkerställa att det bara finns en sann ägare till en viss resursgrupp. När noder som har stoppats kan återigen kommunicera med huvudgruppen av noder, kommer de automatiskt att ansluta sig till klustret och starta sin klustertjänst.

i Windows Server 2019 och Windows Server 2016 finns det två komponenter i systemet som har sina egna kvorummekanismer:

• Klusterkvorum: detta fungerar på klusternivå (dvs. du kan förlora noder och ha klustret uppe)
• Pool Quorum: detta fungerar på poolnivån när Storage Spaces Direct är aktiverat (dvs. du kan förlora noder och enheter och få poolen uppe). Lagringspooler utformades för att användas i både grupperade och icke-grupperade scenarier, varför de har en annan kvorummekanism.

översikt över Klusterkvorum

tabellen nedan ger en översikt över Klusterkvorumresultaten per scenario:

servernoder	kan överleva ett servernodfel	kan överleva ett servernodfel, sedan kan en annan	överleva två samtidiga servernodfel
2	50/50	Nej	Nej
2 + vittne	Ja	Nej	Nej
3	Ja	50/50	Nej
3 + vittne	Ja	Ja	Nej
4	ja	Ja	50/50
4 + vittne	Ja	Ja	Ja
5 och över	Ja	Ja	Ja

rekommendationer för Klusterkvorum

• om du har två noder krävs ett vittne.
• om du har tre eller fyra noder rekommenderas witness starkt.
• om du har tillgång till Internet, Använd ett molnvittne
• om du befinner dig i en IT-miljö med andra maskiner och filresurser, använd ett fildelningsvittne

hur klusterkvorum fungerar

när noder misslyckas, eller när någon delmängd av noder förlorar kontakt med en annan delmängd, måste överlevande noder verifiera att de utgör majoriteten av klustret för att förbli online. Om de inte kan verifiera det går de offline.

men begreppet majoritet fungerar bara rent när det totala antalet noder i klustret är udda (till exempel tre noder i ett fem nodkluster). Så vad sägs om kluster med ett jämnt antal noder (Säg Ett Fyra nodkluster)?

det finns två sätt som klustret kan göra det totala antalet röster udda:

1. först kan det gå upp en genom att lägga till ett vittne med en extra röst. Detta kräver användarinställning.
2. eller det kan gå ner en genom att nollställa en otur nodens röst (händer automatiskt efter behov).

när överlevande noder framgångsrikt verifierar att de är majoriteten, uppdateras definitionen av majoritet för att vara bland bara de överlevande. Detta gör att klustret kan förlora en nod, sedan en annan, sedan en annan, och så vidare. Detta begrepp av det totala antalet röster som anpassar sig efter successiva misslyckanden kallas dynamiskt kvorum.

dynamiskt vittne

dynamiskt vittne växlar vittnets röst för att se till att det totala antalet röster är udda. Om det finns ett udda antal röster har vittnet ingen röst. Om det finns ett jämnt antal röster har vittnet en omröstning. Dynamic witness minskar risken för att klustret kommer att gå ner på grund av vittnesfel. Klustret bestämmer om vittnets röst ska användas baserat på antalet röstnoder som är tillgängliga i klustret.

dynamiskt kvorum arbetar med dynamiskt vittne på det sätt som beskrivs nedan.

dynamiskt kvorumbeteende

• om du har ett jämnt antal noder och inget vittne får en nod sin röst nollställd. Till exempel får endast tre av de fyra noderna röster, så det totala antalet röster är tre och två överlevande med röster anses vara majoritet.
• om du har ett udda antal noder och inget vittne får de alla röster.
• om du har ett jämnt antal noder plus vittne, röstar vittnet, så summan är udda.
• om du har ett udda antal noder plus vittne, röstar inte vittnet.

dynamiskt kvorum möjliggör möjligheten att tilldela en röst till en nod dynamiskt för att undvika att förlora majoriteten av rösterna och att låta klustret köras med en nod (känd som sista man stående). Låt oss ta ett kluster med fyra noder som ett exempel. Antag att beslutförhet kräver 3 röster.

i det här fallet skulle klustret ha gått ner om du förlorade två noder.

dynamiskt kvorum förhindrar dock att detta händer. Det totala antalet röster som krävs för kvorum bestäms nu baserat på antalet tillgängliga noder. Så med dynamiskt kvorum kommer klustret att stanna upp även om du förlorar tre noder.

ovanstående scenario gäller för ett allmänt kluster som inte har lagringsutrymmen direkt aktiverat. Men när Storage Spaces Direct är aktiverat kan klustret bara stödja två nodfel. Detta förklaras mer i avsnittet poolkvorum.

exempel

två noder utan vittne.

en nods röst nollställs, så majoritetsröstningen bestäms av totalt 1 röst. Om den icke-röstande noden går ner oväntat har den överlevande 1/1 och klustret överlever. Om röstnoden går ner oväntat har den överlevande 0/1 och klustret går ner. Om röstnoden är graciöst avstängd överförs omröstningen till den andra noden och klustret överlever. Det är därför det är viktigt att konfigurera ett vittne.

• kan överleva ett serverfel: femtio procent chans.
• kan överleva ett serverfel, sedan ett annat: Nej.
• kan överleva två serverfel samtidigt: Nej.

två noder med ett vittne.

båda noderna röstar, plus vittnesrösterna, så majoriteten bestäms av totalt 3 röster. Om någon nod går ner har den överlevande 2/3 och klustret överlever.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Nej.
• kan överleva två serverfel samtidigt: Nej.

tre noder utan vittne.

alla noder röstar, så majoriteten bestäms av totalt 3 röster. Om någon nod går ner är de överlevande 2/3 och klustret överlever. Klustret blir två noder utan vittne – då är du i Scenario 1.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: femtio procent chans.
• kan överleva två serverfel samtidigt: Nej.

tre noder med ett vittne.

alla noder röstar, så vittnet röstar inte initialt. Majoriteten bestäms av totalt 3 röster. Efter ett misslyckande har klustret två noder med ett vittne – vilket är tillbaka till Scenario 2. Så nu röstar de två noderna och vittnet.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Ja.
• kan överleva två serverfel samtidigt: Nej.

fyra noder utan vittne

en nods röst nollställs, så majoriteten bestäms av totalt 3 röster. Efter ett fel blir klustret tre noder, och du är i Scenario 3.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Ja.
• kan överleva två serverfel på en gång: femtio procent chans.

fyra noder med ett vittne.

alla noder röster och vittnet röster, så majoriteten bestäms av totalt 5 röster. Efter ett misslyckande är du i Scenario 4. Efter två samtidiga fel hoppar du ner till Scenario 2.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Ja.
• kan överleva två serverfel samtidigt: Ja.

fem noder och därefter.

alla noder rösta, eller alla utom en röst, Vad gör den totala udda. Storage Spaces Direct kan inte hantera mer än två noder i alla fall, så vid denna tidpunkt behövs inget vittne eller användbart.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Ja.
• kan överleva två serverfel samtidigt: Ja.

nu när vi förstår hur kvorum fungerar, låt oss titta på typerna av kvorumvittnen.

Kvorumvittnestyper

Failover Clustering stöder tre typer av Kvorumvittnen:

• Cloud Witness-Blob-lagring i Azure tillgänglig för alla noder i klustret. Det upprätthåller klusterinformation i ett vittne.loggfil, men lagrar inte en kopia av klusterdatabasen.
• File Share Witness – en SMB-fildelning som är konfigurerad på en filserver som kör Windows Server. Det upprätthåller klusterinformation i ett vittne.loggfil, men lagrar inte en kopia av klusterdatabasen.
• Disk Witness-en liten klustrad disk som finns i gruppen Cluster Available Storage. Den här skivan är mycket tillgänglig och kan misslyckas mellan noder. Den innehåller en kopia av klusterdatabasen. Ett Diskvittne stöds inte med Storage Spaces Direct.

översikt över poolkvorum

vi pratade just om Klusterkvorum, som fungerar på klusternivå. Låt oss nu dyka in i Pool Quorum, som fungerar på poolnivån (dvs du kan förlora noder och enheter och få poolen att stanna upp). Lagringspooler utformades för att användas i både grupperade och icke-grupperade scenarier, varför de har en annan kvorummekanism.

tabellen nedan ger en översikt över Poolkvorumresultaten per scenario:

servernoder	kan överleva ett servernodfel	kan överleva ett servernodfel, sedan kan en annan	överleva två samtidiga servernodfel
2	Nej	Nej	Nej
2 + vittne	Ja	Nej	Nej
3	Ja	Nej	Nej
3 + vittne	Ja	Nej	Nej
4	ja	Nej	Nej
4 + vittne	Ja	Ja	Ja
5 och över	Ja	Ja	Ja

hur pool quorum fungerar

när enheter misslyckas, eller när någon delmängd av enheter förlorar kontakt med en annan delmängd, måste överlevande enheter verifiera att de utgör majoriteten av poolen för att förbli online. Om de inte kan verifiera det går de offline. Poolen är den enhet som går offline eller stannar online baserat på om den har tillräckligt med diskar för kvorum (50% + 1). Poolresursägaren (active cluster node) kan vara +1.

men poolkvorum fungerar annorlunda än klusterkvorum på följande sätt:

• poolen använder en nod i klustret som ett vittne som en tie-breaker för att överleva hälften av enheter borta (denna nod som är poolresursägaren)
• poolen har inte dynamiskt kvorum
• poolen implementerar inte sin egen version av att ta bort en röst

exempel

fyra noder med en symmetrisk layout.

var och en av de 16 enheterna har en röst och nod två har också en röst (eftersom det är poolresursägaren). Majoriteten bestäms av totalt 16 röster. Om noder tre och fyra går ner har den överlevande delmängden 8 enheter och poolresursägaren, vilket är 9/16 röster. Så överlever poolen.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Ja.
• kan överleva två serverfel samtidigt: Ja.

fyra noder med symmetrisk layout och körfel.

var och en av de 16 enheterna har en röst och nod 2 har också en röst (eftersom det är poolresursägaren). Majoriteten bestäms av totalt 16 röster. Först går kör 7 ner. Om noder tre och fyra går ner har den överlevande delmängden 7 enheter och poolresursägaren, vilket är 8/16 röster. Så poolen har inte majoritet och går ner.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: Nej.
• kan överleva två serverfel samtidigt: Nej.

fyra noder med en icke-symmetrisk layout.

var och en av de 24 enheterna har en röst och nod två har också en röst (eftersom det är poolresursägaren). Majoriteten bestäms av totalt 24 röster. Om noder tre och fyra går ner har den överlevande delmängden 8 enheter och poolresursägaren, vilket är 9/24 röster. Så poolen har inte majoritet och går ner.

• kan överleva ett serverfel: Ja.
• kan överleva ett serverfel, sedan ett annat: **beror * * (Kan inte överleva om båda noderna tre och fyra går ner, men kan överleva alla andra scenarier.
• kan överleva två serverfel samtidigt: ** Beror **(Kan inte överleva om båda noderna tre och fyra går ner, men kan överleva alla andra scenarier.

rekommendationer för poolkvorum

• se till att varje nod i ditt kluster är symmetrisk (varje nod har samma antal enheter)
• aktivera trevägsspegel eller dubbelparitet så att du kan tolerera en nodfel och hålla de virtuella diskarna online. Se vår volymvägledningssida för mer information.
• om mer än två noder är nere, eller två noder och en disk på en annan nod är nere, kan volymer inte ha tillgång till alla tre kopior av deras data och därför tas offline och vara otillgängliga. Vi rekommenderar att du tar tillbaka servrarna eller byter ut diskarna snabbt för att säkerställa maximal elasticitet för all data i volymen.