Förstå kluster- och poolkvorum

Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server

Windows Server-redundanskluster ger hög tillgänglighet för arbetsbelastningar som körs på Azure Stack HCI- och Windows Server-kluster. Dessa resurser anses ha hög tillgänglighet om noderna som är värdar för resurser är igång. Klustret kräver dock vanligtvis att mer än hälften av noderna körs, vilket kallas kvorum.

Kvorum är utformat för att förhindra split-brain-scenarier som kan inträffa när det finns en partition i nätverket och delmängder av noder inte kan kommunicera med varandra. Detta kan göra att båda delmängderna av noderna försöker äga arbetsbelastningen och skriva till samma disk, vilket kan leda till många problem. Detta förhindras dock med redundansklustringskonceptet kvorum, vilket tvingar endast en av dessa nodgrupper att fortsätta köras, så endast en av dessa grupper förblir online.

Kvorum avgör antalet fel som klustret kan hantera medan det fortfarande är online. Kvorum är utformat för att hantera scenariot när det uppstår problem med kommunikationen mellan delmängder av klusternoder, så att flera servrar inte försöker vara värdar för en resursgrupp samtidigt och skriva till samma disk samtidigt. Genom att använda det här begreppet kvorum tvingar klustret klustertjänsten att stoppa i en av delmängderna av noder för att säkerställa att det bara finns en verklig ägare till en viss resursgrupp. Noder som har stoppats kan återigen kommunicera med huvudgruppen med noder och kommer automatiskt att återansluta till klustret och starta sin klustertjänst.

I Azure Stack HCI och Windows Server 2019 finns det två komponenter i systemet som har egna kvorummekanismer:

• Klusterkvorum: Detta fungerar på klusternivå (d.v.s. du kan förlora noder och låta klustret vara kvar)
• Poolkvorum: Detta fungerar på poolnivå (d.v.s. du kan förlora noder och enheter och låta poolen vara igång). Lagringspooler har utformats för att användas i både klustrade och icke-klustrade scenarier, vilket är anledningen till att de har en annan kvorummekanism.

Översikt över klusterkvorum

Tabellen nedan ger en översikt över klusterkvorumresultaten per scenario:

Servernoder	Kan överleva ett fel på en servernod	Kan överleva ett servernodfel och sedan ett annat	Kan överleva två samtidiga servernodfel
2	50/50	Inga	Inga
2 + Vittne	Ja	Inga	Inga
3	Yes	50/50	No
3 + Vittne	Ja	Ja	Inga
4	Ja	Yes	50/50
4 + Vittne	Ja	Ja	Yes
5 och senare	Ja	Ja	Yes

Rekommendationer för klusterkvorum

• Om du har två noder krävs ett vittne.
• Om du har tre eller fyra noder rekommenderas vittnet starkt.
• Om du har fem noder eller mer behövs inget vittne och ger inte ytterligare återhämtning.
• Om du har internetåtkomst använder du ett molnvittne.
• Om du är i en IT-miljö med andra datorer och filresurser använder du ett filresursvittne.

Så här fungerar klusterkvorum

När noder misslyckas, eller när en delmängd av noderna förlorar kontakten med en annan delmängd, måste kvarvarande 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 konstigt (till exempel tre noder i ett kluster med fem noder). Så, hur är det med kluster med ett jämnt antal noder (till exempel ett kluster med fyra noder)?

Klustret kan göra det totala antalet röster udda på två sätt:

1. För det första kan det gå upp ett genom att lägga till ett vittne med en extra röst. Detta kräver att användaren konfigureras.
2. Eller så kan den gå ner en genom att nollställa en olycklig nods röst (sker automatiskt efter behov).

När kvarvarande noder verifierar att de är majoritetsnoder uppdateras definitionen av majoritet så att den bara är bland de överlevande. Detta gör att klustret kan förlora en nod, sedan en annan, sedan en annan och så vidare. Det här konceptet med det totala antalet röster som anpassas efter efterföljande fel 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 röst. Dynamiskt vittne minskar avsevärt risken för att klustret kraschar på grund av ett vittnesfel. Klustret bestämmer om vittnesröstningen ska användas baserat på antalet röstningsnoder som är tillgängliga i klustret.

Dynamiskt kvorum fungerar 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 bara tre av de fyra noderna röster, så det totala antalet röster är tre och två efterlevande med röster betraktas som en majoritet.
• Om du har ett udda antal noder och inget vittne får alla röster.
• Om du har ett jämnt antal noder plus vittnet röstar vittnet, så summan är udda.
• Om du har ett udda antal noder plus ett vittne röstar inte vittnet.

Dynamiskt kvorum gör det möjligt att tilldela en röst till en nod dynamiskt för att undvika att förlora majoriteten av rösterna och tillåta att klustret körs med en nod (kallas last-man standing). Vi tar ett kluster med fyra noder som exempel. Anta att kvorum kräver 3 röster.

I det här fallet skulle klustret ha gått ned om du förlorat två noder.

Dynamiskt kvorum förhindrar dock att detta sker. Det totala antalet röster som krävs för kvorum bestäms nu baserat på antalet tillgängliga noder. Med dynamiskt kvorum förblir klustret uppe även om du förlorar tre noder.

Scenariot ovan gäller för ett allmänt kluster som inte har Lagringsdirigering aktiverat. Men när Lagringsdirigering är aktiverat kan klustret bara stödja två nodfel. Detta förklaras mer i avsnittet om poolkvorum.

Exempel

Två noder utan vittne

En nods röst nollställs, så majoritetsrösten bestäms av totalt 1 röst. Om noden som inte röstar slutar fungera oväntat har den överlevande 1/1 och klustret överlever. Om röstningsnoden slutar fungera oväntat har den överlevande 0/1 och klustret kraschar. Om röstningsnoden stängs av på ett smidigt sätt överförs omröstningen till den andra noden och klustret överlever. Därför är det viktigt att konfigurera ett vittne.

• Kan överleva ett serverfel: Femtio procents 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 av noderna går ned 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 slutar fungera ä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 procents chans.
• Kan överleva två serverfel samtidigt: Nej.

Tre noder med ett vittne

Alla noder röstar, så vittnet röstar inte från början. Majoriteten bestäms av totalt 3 röster. Efter ett fel 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 och 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 och sedan ett annat: Ja.
• Kan överleva två serverfel samtidigt: Femtio procents chans.

Fyra noder med ett vittne

Alla noder röstar och vittnesrösterna, så majoriteten bestäms av totalt 5 röster. Efter ett fel är du i scenario 4. Efter två samtidiga fel hoppar du ned till Scenario 2.

• Kan överleva ett serverfel: Ja.
• Kan överleva ett serverfel och sedan ett annat: Ja.
• Kan överleva två serverfel samtidigt: Ja.

Fem noder och senare

Alla noder röstar, eller alla utom en röst, vad som än gör det totala udda. Lagringsdirigering kan ändå inte hantera fler än två noder, så just nu behövs inget vittne eller är användbart.

• Kan överleva ett serverfel: Ja.
• Kan överleva ett serverfel och sedan ett annat: Ja.
• Kan överleva två serverfel samtidigt: Ja.

Nu när vi förstår hur kvorum fungerar ska vi titta på typerna av kvorumvittnen.

Kvorumvittnestyper

Redundansklustring stöder tre typer av kvorumvittnen:

• Molnvittne – Blob Storage i Azure som är tillgängligt för alla noder i klustret. Den underhåller klusterinformation i en witness.log-fil, men lagrar inte en kopia av klusterdatabasen.
• Filresursvittne – en SMB-filresurs som är konfigurerad på en filserver som kör Windows Server. Den underhåller klusterinformation i en witness.log-fil, men lagrar inte en kopia av klusterdatabasen.
• Diskvittne – en liten klustrad disk som finns i gruppen Klustertillgänglig lagring. Den här disken är högtillgänglig och kan redundansväxlara mellan noder. Den innehåller en kopia av klusterdatabasen. Ett diskvittne stöds inte med Lagringsdirigering.

Översikt över poolkvorum

Vi har precis talat om klusterkvorum, som fungerar på klusternivå. Nu ska vi gå in på poolkvorum, som fungerar på poolnivå (dvs. du kan förlora noder och enheter och låta poolen vara uppe). Lagringspooler har utformats för att användas i både klustrade och icke-klustrade scenarier, vilket är anledningen till att de har en annan kvorummekanism.

Tabellen nedan ger en översikt över poolkvorumresultaten per scenario:

Servernoder	Kan överleva ett servernodfel	Kan överleva ett servernodfel och sedan ett annat	Kan överleva två samtidiga servernodfel
2	Ja	Inga	Inga
2 + Vittne	Ja	Inga	Inga
3	Ja	Inga	Inga
3 + Vittne	Ja	Inga	Inga
4	Ja	Inga	Inga
4 + Vittne	Ja	Ja	Yes
5 och senare	Ja	Ja	Yes

Så här fungerar poolkvorum

När enheter misslyckas, eller när en delmängd av enheterna förlorar kontakten med en annan delmängd, måste kvarvarande enheter som är värdar för metadata 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 entiteten som går offline eller förblir online baserat på om den har tillräckligt med diskar för kvorum (50 % + 1). Klusterdatabasen kan vara +1 så länge själva klustret är quorate.

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

• Poolen väljer en delmängd av enheter per nod som värd för metadata
• Poolen använder klusterdatabasen för att bryta banden
• Poolen har inte dynamiskt kvorum
• Poolen implementerar inte en egen version av att ta bort en omröstning

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 noderna tre och fyra går ned har den överlevande delmängden 8 enheter och poolresursägaren, vilket är 9/16 röster. Så poolen överlever.

• Kan överleva ett serverfel: Ja.
• Kan överleva ett serverfel och sedan ett annat: Ja.
• Kan överleva två serverfel samtidigt: Ja.

Fyra noder med en symmetrisk layout och enhetsfel

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 kör 7 ner. Om noderna tre och fyra går ned 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.

Rekommendationer för poolkvorum

• Kontrollera att varje nod i klustret är symmetrisk (varje nod har samma antal enheter)
• Aktivera trevägsspegling eller dubbel paritet så att du kan tolerera två nodfel och hålla de virtuella diskarna online.
• Om fler än två noder är nere, eller om två noder och en disk på en annan nod är nere, kanske volymerna inte har åtkomst till alla tre kopiorna av sina data och därför tas offline och är otillgängliga. Vi rekommenderar att du tar tillbaka servrarna eller ersätter diskarna snabbt för att säkerställa största återhämtning för alla data i volymen.

Nästa steg

• Konfigurera och hantera kvorum
• Konfigurera ett klustervittne