Förstå kluster och poolkvorum
Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server
Windows Server-redundansklustring ger hög tillgänglighet för arbetsbelastningar som körs i Azure Stack HCI- och Windows Server-kluster. Dessa resurser anses ha hög tillgänglighet om noderna som är värdar för resurserna är igång. Klustret kräver dock vanligtvis att mer än hälften av noderna körs, vilket kallas för att ha 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 undermängder av noder inte kan kommunicera med varandra. Detta kan göra 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-konceptet kvorum, vilket tvingar endast en av dessa nodgrupper att fortsätta vara aktiva, så att endast en av dessa grupper förblir online.
Kvorum avgör hur många fel klustret kan klara av och ändå vara online. Kvorum är utformat för att hantera scenariot när det uppstår ett problem med kommunikationen mellan delmängder av klusternoder, så att flera servrar inte försöker att samtidigt vara värdar för en resursgrupp och skriva till samma disk samtidigt. Genom att ha det här begreppet kvorum stoppar klustret klustertjänsten på något av nodernas delmängder för att säkerställa att det bara finns en verklig ägare till en specifik 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å (dvs. du kan förlora noder och låta klustret vara kvar)
- Pool Quorum: Detta fungerar på poolnivå (dvs. du kan förlora noder och enheter och få poolen att stanna kvar). 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 servernodfel | Kan överleva ett servernodfel och sedan ett annat | Kan ö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 uppåt | Ja | Ja | Ja |
Rekommendationer för klusterkvorum
- Om du har två noder krävs ett vittne .
- Om du har tre eller fyra noder rekommenderas vittne starkt.
- Om du har fem noder eller fler behövs inget vittne och ger inte ytterligare återhämtning.
- Om du har internetåtkomst, använd molnvittne.
- Om du är i en IT-miljö med andra datorer och fildelningar bör du använda ett vittne för fildelning.
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 majoritet 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 kluster med fem noder). Så, hur är det med kluster med ett jämnt antal noder (till exempel ett kluster med fyra noder)?
Det finns två sätt som klustret kan göra det totala antalet röster till ett udda tal.
- Först kan det gå upp genom att addera ett vittne med en extra röst. Detta kräver att användaren konfigureras.
- Eller så kan det gå ner med att nollställa rösten för en olycksdrabbad nod (sker automatiskt efter behov).
När överlevande noder framgångsrikt verifierar att de är majoritet, uppdateras definitionen av majoritet till att vara endast bland de överlevande. Detta gör att klustret kan förlora en nod, sedan en annan, sedan en annan och så vidare. Detta begrepp om det totala antalet röster som anpassar sig efter upprepade 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 vittnesfel. Klustret bestämmer om vittnesrösten 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 en även antal noder och inget vittne får en nod sin röst nollad. 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 betraktas som en 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 ett vittne, där vittnet röstar, så att det totala antalet är udda.
- Om du har ett udda antal noder plus ett vittne, då röstar inte vittnet.
Dynamiskt kvorum möjliggör dynamisk tilldelning av röster till noder för att undvika att förlora majoriteten av rösterna och möjliggör för klustret att köra med endast en nod (känd som 'sista mannen som står'). 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 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 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 Storage Spaces Direct är aktiverat kan klustret bara stödja två nodavbrott. Detta förklaras mer i avsnittet poolkvorum.
Exempel
Två noder utan vittne
En nods röst nollställs, så majoritet röst bestäms av totalt 1 röst. Om noden som inte röstar oväntat slutar fungera har den överlevande 1/1 och klustret överlever. Om röstningsnoden oväntat slutar fungera har den överlevande 0/1 och klustret går ned. Om röstningsnoden stängs av ordentligt ö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 procents chans.
- Kan överleva ett serverfel och sedan ett annat: Ingen.
- Kan överleva två serverfel samtidigt: Ingen.
Två noder med ett vittne
Båda noderna röstar, plus vittnesrösterna, så majoritet 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 och sedan ett annat: Ingen.
- Kan överleva två serverfel samtidigt: Ingen.
Tre noder utan vittne
Alla noder röstar, så majoritet 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 procents chans.
- Kan överleva två serverfel samtidigt: Ingen.
Tre noder med ett vittne
Alla noder röstar, så vittnet röstar inte från början. Den majoriteten bestäms av totalt 3 röster. Efter ett fel har klustret två noder med ett vittne, vilket innebär att vi är tillbaka i scenario 2. Nu röstar alltså de två noderna och vittnet.
- Kan överleva ett serverfel: Ja.
- Kan överleva ett serverfel och sedan ett annat: Ja.
- Kan överleva två serverfel samtidigt: Ingen.
Fyra noder utan vittne
En nods röst nollställs, så majoritet 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 och vittnena röstar, så majoritet fastställs utifrån 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 mer
Alla noder röstar, eller alla utom en röst, vad som än gör det totala antalet udda. Storage Spaces Direct kan ändå inte hantera mer än två noder som inte fungerar, så det är vare sig nödvändigt eller användbart med ett vittne i det här läget.
- 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
Failover-kluster stöder tre typer av kvorumvittnen:
- Cloud Witness – Blob Storage i Azure som är tillgängligt för alla noder i klustret. Den underhåller klustringsinformation i en witness.log fil, men lagrar inte en kopia av klusterdatabasen.
- Filvittnesresurs – en SMB-filresursdelning som har konfigurerats på en filserver som kör Windows Server. Den underhåller klustringsinformation i en witness.log fil, men lagrar inte en kopia av klusterdatabasen.
- Disk Witness – en liten klustrad disk som finns i gruppen Cluster-Available Storage. Den här disken är mycket tillgänglig och kan växla över mellan noder. Den innehåller en kopia av klusterdatabasen. Ett diskvittne stöds inte med Storage Spaces Direct.
Översikt över poolkvorum
Vi har just pratat om klusterkvorum, som fungerar på klusternivå. Nu ska vi gå in på poolkvorum, där det fungerar på poolnivå (dvs. du kan förlora noder och enheter och ändå ha poolen 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.
Tabellen nedan ger en översikt över resultaten för poolkvorum för varje scenario.
| Servernoder | Kan överleva ett servernodfel | Kan överleva ett servernodfel och sedan ett annat | Kan överleva två samtidiga servernodfel |
|---|---|---|---|
| 2 | Ja | 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 uppåt | Ja | Ja | Ja |
Så fungerar poolkvorum
När enheter misslyckas, eller när en delmängd av enheter förlorar kontakten med en annan delmängd, måste kvarvarande enheter som är värdar för metadata verifiera att de utgör majoritet 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 kvorate.
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 sin 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 noden två har också en röst (eftersom det är poolresursägaren). Den majoriteten bestäms av totalt 16 röster. Om noderna 3 och 4 går ner har den överlevande delmängden 8 hårddiskar 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 diskfel
Var och en av de 16 enheterna har en röst och nod 2 har också en röst (eftersom den är poolresursägaren). Den majoriteten fastställs utifrån totalt 16 röster. Först går drive 7 ner. Om noderna tre och fyra går ner har den överlevande delmängden 7 enheter och poolresursägaren, vilket ger 8 av 16 röster. Så poolen har inte majoritet och minskar.
- Kan överleva ett serverfel: Ja.
- Kan överleva ett serverfel och sedan ett annat: Ingen.
- Kan överleva två serverfel samtidigt: Ingen.
Rekommendationer för poolquorum
- Kontrollera att varje nod i klustret är symmetrisk (varje nod har samma antal diskar)
- 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 vara otillgängliga. Vi rekommenderar att du tar tillbaka servrarna eller byter ut diskarna snabbt för att säkerställa största möjliga återhämtning för alla data i volymen.