Förstå kluster- och poolkvorum

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

Windows Server-redundansklustring 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 som tvingar endast en av dessa nodgrupper att fortsätta köras, så att endast en av dessa grupper är 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. När noder som har stoppats återigen kan kommunicera med huvudgruppen med noder, kommer de 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 få poolen att stanna kvar). Storage pooler 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 Ja 50/50 Inga
3 + Vittne Ja Ja Inga
4 Ja Ja 50/50
4 + Vittne Ja Ja Ja
5 och senare Ja Ja Ja

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 befinner dig 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 majoriteten uppdateras definitionen av majoriteten 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 slutar fungera 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.

Diagram showing four cluster nodes, each of which gets a vote

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.

Diagram showing four cluster nodes, with nodes failing one at a time, and the number of required votes adjusting after each failure.

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. Det är därför det är viktigt att konfigurera ett vittne.

Quorum explained in the case with two nodes without a witness

  • Kan överleva ett serverfel: 50 procents chans.
  • Kan överleva ett serverfel och 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 kraschar har den överlevande 2/3 och klustret överlever.

Quorum explained in the case with two nodes with a witness

  • Kan överleva ett serverfel: Ja.
  • Kan överleva ett serverfel och 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 kraschar är de överlevande 2/3 och klustret överlever. Klustret blir två noder utan ett vittne – då är du i scenario 1.

Quorum explained in the case with three nodes without a witness

  • Kan överleva ett serverfel: Ja.
  • Kan överleva ett serverfel, sedan en annan: 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 – som är tillbaka i scenario 2. Nu röstar alltså de två noderna och vittnesrösten.

Quorum explained in the case with three nodes with a witness

  • 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 befinner dig i scenario 3.

Quorum explained in the case with four nodes without a witness

  • 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.

Quorum explained in the case with four nodes with a witness

  • 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 inte hantera fler än två noder i alla fall, så i det här läget behövs inget vittne eller är användbart.

Quorum explained in the case with five nodes and beyond

  • 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å de olika typerna av kvorumvittnen.

Kvorumvittnestyper

Redundansklustring stöder tre typer av kvorumvittnen:

  • Molnvittne – BlobLagring i Azure som är tillgänglig för alla noder i klustret. Den lagrar klustringsinformation i en witness.log-fil, men lagrar inte en kopia av klusterdatabasen.
  • Filresursvittne – en SMB-filresurs som har konfigurerats på en filserver som kör Windows Server. Den lagrar klustringsinformation i en witness.log-fil, men lagrar inte en kopia av klusterdatabasen.
  • Diskvittne – en liten klustrad disk som finns i gruppen Kluster tillgängligt Storage. Den här disken har hög tillgänglighet 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 igång). Storage pooler 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 fel på en servernod Kan överleva ett servernodfel och sedan ett annat Kan överleva två samtidiga servernodfel
2 Nej Inga Inga
2 + Vittne Ja Inga Inga
3 Ja Inga Inga
3 + Vittne Ja Inga Inga
4 Ja Inga Inga
4 + Vittne Ja Ja Ja
5 och senare Ja Ja Ja

Så här fungerar poolkvorum

När enheter misslyckas, eller när en delmängd av enheterna förlorar kontakt med en annan delmängd, måste kvarvarande 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 entiteten som kopplas från eller förblir online baserat på om den har tillräckligt med diskar för kvorum (50 % + 1). Poolresursens ägare (aktiv klusternod) 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 enheterna borta (den här noden som är ägare till poolresursen)
  • poolen inte har dynamiskt kvorum
  • poolen inte implementerar 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 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.

Pool Quorum 1

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

Fyra noder med 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.

Pool Quorum 2

  • 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 noderna tre och fyra går ned 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.

Pool Quorum 3

  • 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 ned, men kan överleva alla andra scenarier.
  • Kan överleva två serverfel samtidigt: Beroenden (kan inte överleva om båda noderna tre och fyra går ned, men kan överleva alla andra scenarier.

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 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

Mer information finns i följande: