Feltolerans och lagringseffektivitet i Azure Stack HCI- och Windows Server-kluster
Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server 2019
Den här artikeln beskriver tillgängliga återhämtningsalternativ och beskriver skalningskrav, lagringseffektivitet och allmänna fördelar och kompromisser för var och en.
Översikt
Lagringsdirigering ger feltolerans, som ofta kallas "återhämtning", för dina data. Implementeringen liknar RAID, förutom att den distribueras över servrar och implementeras i programvara.
Precis som med RAID finns det några olika sätt Lagringsutrymmen kan göra detta, vilket gör olika kompromisser mellan feltolerans, lagringseffektivitet och beräkningskomplexitet. Dessa faller i stort sett i två kategorier: "spegling" och "paritet", den senare kallas ibland "raderingskodning".
Spegling
Spegling ger feltolerans genom att behålla flera kopior av alla data. Detta liknar RAID-1. Hur dessa data är randiga och placerade är icke-trivialt (se den här bloggen för att lära dig mer), men det är helt sant att säga att alla data som lagras med spegling skrivs, i sin helhet, flera gånger. Varje kopia skrivs till olika fysiska maskinvara (olika enheter på olika servrar) som antas misslyckas oberoende av varandra.
Du kan välja mellan två varianter av spegling – "tvåvägs" och "trevägs".
2-vägsspegling
Dubbelriktad spegling skriver två kopior av allt. Lagringseffektiviteten är 50 procent – för att skriva 1 TB data behöver du minst 2 TB fysisk lagringskapacitet. På samma sätt behöver du minst två "feldomäner" för maskinvara – med Lagringsdirigering innebär det två servrar.
Varning
Om du har fler än två servrar rekommenderar vi att du använder trevägsspegling i stället.
3-vägsspegling
Trevägsspegling skriver tre kopior av allt. Lagringseffektiviteten är 33,3 procent – för att skriva 1 TB data behöver du minst 3 TB fysisk lagringskapacitet. På samma sätt behöver du minst tre maskinvarufeldomäner – med Lagringsdirigering innebär det tre servrar.
Trevägsspegling kan på ett säkert sätt tolerera minst två maskinvaruproblem (enhet eller server) åt gången. Om du till exempel startar om en server när plötsligt en annan enhet eller server misslyckas förblir alla data säkra och kontinuerligt tillgängliga.
Paritet
Paritetskodning, som ofta kallas "raderingskodning", ger feltolerans med bitvis aritmetik, vilket kan bli anmärkningsvärt komplicerat. Sättet som detta fungerar på är mindre uppenbart än spegling, och det finns många bra onlineresurser (till exempel den här dummiesguiden från tredje part för raderingskodning) som kan hjälpa dig att få idén. Det räcker med att säga att det ger bättre lagringseffektivitet utan att kompromissa med feltoleransen.
Lagringsutrymmen erbjuder två smaker av paritet – "enkel" paritet och "dubbel" paritet, den senare använder en avancerad teknik som kallas "lokala återuppbyggnadskoder" i större skala.
Viktigt
Vi rekommenderar att du använder spegling för de flesta prestandakänsliga arbetsbelastningar. Mer information om hur du balanserar prestanda och kapacitet beroende på din arbetsbelastning finns i Planera volymer.
Enkel paritet
Enkel paritet behåller bara en bitvis paritetssymbol, vilket ger feltolerans mot endast ett fel i taget. Det liknar RAID-5 mest. Om du vill använda enkel paritet behöver du minst tre maskinvarufeldomäner – med Lagringsdirigering innebär det tre servrar. Eftersom trevägsspegling ger mer feltolerans i samma skala avråder vi från att använda enkel paritet. Men det finns där om du insisterar på att använda det, och det stöds fullt ut.
Varning
Vi avråder från att använda enkel paritet eftersom det bara kan tolerera ett maskinvarufel i taget på ett säkert sätt: om du startar om en server när plötsligt en annan enhet eller server misslyckas, kommer du att uppleva stilleståndstid. Om du bara har tre servrar rekommenderar vi att du använder trevägsspegling. Om du har fyra eller fler läser du nästa avsnitt.
Dubbel paritet
Dubbel paritet implementerar Reed-Solomon felkorrigeringskoder för att behålla två bitvis paritetssymboler, vilket ger samma feltolerans som trevägsspegling (dvs. upp till två fel samtidigt), men med bättre lagringseffektivitet. Det liknar RAID-6. Om du vill använda dubbel paritet behöver du minst fyra maskinvarufeldomäner – med Lagringsdirigering innebär det fyra servrar. I den skalan är lagringseffektiviteten 50 % – för att lagra 2 TB data behöver du 4 TB fysisk lagringskapacitet.
Lagringseffektiviteten för dubbel paritet ökar ju fler maskinvarufeldomäner du har, från 50 procent upp till 80 procent. Vid sju (med Lagringsdirigering innebär det till exempel sju servrar) att effektiviteten ökar till 66,7 procent – för att lagra 4 TB data behöver du bara 6 TB fysisk lagringskapacitet.
Se avsnittet Sammanfattning för effektiviteten hos dubbelpartskoder och lokala återuppbyggnadskoder i varje skala.
Lokala återuppbyggnadskoder
Lagringsutrymmen introducerar en avancerad teknik som utvecklats av Microsoft Research som kallas "lokala återuppbyggnadskoder" eller LRC. I stor skala använder dubbel paritet LRC för att dela upp sin kodning/avkodning i några mindre grupper, för att minska de kostnader som krävs för att skriva eller återställa från fel.
Med hårddiskar (HDD) är gruppstorleken fyra symboler. med SSD (Solid State Drives) är gruppstorleken sex symboler. Så här ser layouten till exempel ut med hårddiskar och 12 maskinvarufeldomäner (vilket betyder 12 servrar) – det finns två grupper med fyra datasymboler. Den uppnår lagringseffektivitet på 72,7 procent.
Vi rekommenderar denna djupgående men ytterst läsbara genomgång av hur lokala återuppbyggnadskoder hanterar olika felscenarier, och varför de är tilltalande, av Claus Joergensen.
Speglingsaccelererad paritet
En Lagringsdirigering volym kan vara delspegling och delparitet. Skrivningar landar först i den speglade delen och flyttas gradvis till paritetsdelen senare. I praktiken använder detta spegling för att påskynda raderingskodningen.
Om du vill blanda trevägsspegling och dubbel paritet behöver du minst fyra feldomäner, vilket innebär fyra servrar.
Lagringseffektiviteten för speglingsaccelererad paritet ligger mellan vad du skulle få från att använda all spegling eller all paritet och beror på vilka proportioner du väljer. Till exempel visar demonstrationen vid 37-minutersmarkeringen i den här presentationen olika blandningar som uppnår 46 procent, 54 procent och 65 procent effektivitet med 12 servrar.
Viktigt
Vi rekommenderar att du använder spegling för de flesta prestandakänsliga arbetsbelastningar. Mer information om hur du balanserar prestanda och kapacitet beroende på din arbetsbelastning finns i Planera volymer.
Sammanfattning
Det här avsnittet sammanfattar återhämtningstyperna som är tillgängliga i Lagringsdirigering, minimikraven för skalning för att använda varje typ, hur många fel varje typ kan tolerera och motsvarande lagringseffektivitet.
Återhämtningstyper
| Återhämtning | Feltolerans | Lagringseffektivitet |
|---|---|---|
| 2-vägsspegling | 1 | 50.0% |
| 3-vägsspegling | 2 | 33.3% |
| Dubbel paritet | 2 | 50.0% - 80.0% |
| Blandat | 2 | 33.3% - 80.0% |
Minimikrav för skalning
| Återhämtning | Minsta obligatoriska feldomäner |
|---|---|
| 2-vägsspegling | 2 |
| 3-vägsspegling | 3 |
| Dubbel paritet | 4 |
| Blandat | 4 |
Tips
Om du inte använder feltolerans för chassi eller rack refererar antalet feldomäner till antalet servrar. Antalet enheter på varje server påverkar inte vilka återhämtningstyper du kan använda, så länge du uppfyller minimikraven för Lagringsdirigering.
Dubbel paritetseffektivitet för hybriddistributioner
Den här tabellen visar lagringseffektiviteten för dubbel paritet och lokala återuppbyggnadskoder i varje skala för hybriddistributioner som innehåller både hårddiskar (HDD) och SSD (Solid State Drives).
| Feldomäner | Layout | Effektivitet |
|---|---|---|
| 2 | – | – |
| 3 | – | – |
| 4 | RS 2+2 | 50.0% |
| 5 | RS 2+2 | 50.0% |
| 6 | RS 2+2 | 50.0% |
| 7 | RS 4+2 | 66.7% |
| 8 | RS 4+2 | 66.7% |
| 9 | RS 4+2 | 66.7% |
| 10 | RS 4+2 | 66.7% |
| 11 | RS 4+2 | 66.7% |
| 12 | LRC (8, 2, 1) | 72.7% |
| 13 | LRC (8, 2, 1) | 72.7% |
| 14 | LRC (8, 2, 1) | 72.7% |
| 15 | LRC (8, 2, 1) | 72.7% |
| 16 | LRC (8, 2, 1) | 72.7% |
Dubbel paritetseffektivitet för all-flash-distributioner
Den här tabellen visar lagringseffektiviteten för dubbel paritet och lokala återuppbyggnadskoder i varje skala för all-flash-distributioner som endast innehåller SSD-enheter (Solid State Drives). Paritetslayouten kan använda större gruppstorlekar och uppnå bättre lagringseffektivitet i en helt flash-konfiguration.
| Feldomäner | Layout | Effektivitet |
|---|---|---|
| 2 | – | – |
| 3 | – | – |
| 4 | RS 2+2 | 50.0% |
| 5 | RS 2+2 | 50.0% |
| 6 | RS 2+2 | 50.0% |
| 7 | RS 4+2 | 66.7% |
| 8 | RS 4+2 | 66.7% |
| 9 | RS 6+2 | 75.0% |
| 10 | RS 6+2 | 75.0% |
| 11 | RS 6+2 | 75.0% |
| 12 | RS 6+2 | 75.0% |
| 13 | RS 6+2 | 75.0% |
| 14 | RS 6+2 | 75.0% |
| 15 | RS 6+2 | 75.0% |
| 16 | LRC (12, 2, 1) | 80.0% |
Exempel
Om du inte bara har två servrar rekommenderar vi att du använder trevägsspegling och/eller dubbel paritet, eftersom de ger bättre feltolerans. Mer specifikt säkerställer de att alla data förblir säkra och kontinuerligt tillgängliga även när två feldomäner – med Lagringsdirigering, det vill säga två servrar – påverkas av samtidiga fel.
Exempel där allt förblir online
Dessa sex exempel visar vad trevägsspegling och/eller dubbel paritet kan tolerera.
- 1. En enhet har förlorats (inklusive cacheenheter)
- 2. En server har förlorats
- 3. En server och en enhet har förlorats
- 4. Två enheter förlorade på olika servrar
- 5. Fler än två enheter har förlorats, så länge högst två servrar påverkas
- 6. Två servrar förlorade
... i varje fall kommer alla volymer att vara online. (Kontrollera att klustret har kvorum.)
Exempel där allt går offline
Under sin livstid kan Lagringsutrymmen tolerera valfritt antal fel, eftersom det återställs till fullständig återhämtning efter var och en, givet tillräckligt med tid. Högst två feldomäner kan dock säkert påverkas av fel vid en viss tidpunkt. Följande är därför exempel på vad trevägsspegling och/eller dubbel paritet inte kan tolerera.
- 7. Enheter som förlorats på tre eller flera servrar samtidigt
- 8. Tre eller flera servrar förlorade samtidigt
Användning
Kolla in Skapa volymer.
Nästa steg
Mer information om ämnen som nämns i den här artikeln finns i följande:
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för