Förstå kluster och poolkvorum
Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server
Viktigt!
Azure Stack HCI är nu en del av Azure Local. Namnbytet av produktdokumentation pågår. Äldre versioner av Azure Stack HCI, till exempel 22H2, fortsätter dock att referera till Azure Stack HCI och återspeglar inte namnändringen. Läs mer.
Windows Server-redundanskluster ger hög tillgänglighet för arbetsbelastningar som körs i Azure Stack HCI- och Windows Server-kluster. Dessa resurser anses vara högtillgängliga om de noder som värdresurserna är upp till. 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 scenarier med delad hjärna 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 noder 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 är online.
Kvorum avgör antalet fel som klustret kan upprätthålla medan det fortfarande är 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 tvingar klustret klustertjänsten att stoppa i någon av nodernas underuppsättningar 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 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.
Ö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 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 fler 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 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)?
Klustret kan göra det totala antalet röster udda på två sätt:
- För det första kan det gå upp ett genom att lägga till ett vittne med en extra omröstning. Detta kräver att användaren konfigureras.
- Eller så kan den gå ned en genom att nollställa en olycklig nods röst (sker automatiskt efter behov).
När överlevande 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 begreppet för det totala antalet röster som anpassar sig 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 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 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 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 vittne röstar vittnet, så summan är udda.
- Om du har ett udda antal noder plus 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 för 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 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 Lagringsutrymmen Direct aktiverat. Men när Lagringsutrymmen 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å majoritetsomröstningen 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 är korrekt avstängd ö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 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 går ned har den överlevande 2/3 och klustret överlever.
- 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 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: 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 till 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: 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 antalet udda. Lagringsutrymmen Direct kan inte hantera fler än två noder nedåt ändå, 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 – bloblagring i Azure som är tillgänglig för alla noder i klustret. Den underhåller 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 underhåller klustringsinformation 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 mycket tillgänglig och kan redundansväxlara mellan noder. Den innehåller en kopia av klusterdatabasen. Ett diskvittne stöds inte med Lagringsutrymmen Direct.
Översikt över poolkvorum
Vi pratade bara 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 få poolen att hålla sig 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 | 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 senare | Ja | Ja | Ja |
Så här 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 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 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 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 ner 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 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 och 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 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.