Planera volymer 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 innehåller vägledning för hur du planerar klustervolymer för att uppfylla prestanda- och kapacitetsbehoven för dina arbetsbelastningar, inklusive val av filsystem, återhämtningstyp och storlek.

Anteckning

Lagringsdirigering stöder inte en filserver för allmän användning. Om du behöver köra filservern eller andra allmänna tjänster på Lagringsdirigering konfigurerar du den på de virtuella datorerna.

Granska: Vad är volymer?

Volymer är där du placerar de filer som dina arbetsbelastningar behöver, till exempel VHD- eller VHDX-filer för virtuella Hyper-V-datorer. Volymer kombinerar enheterna i lagringspoolen för att introducera feltolerans, skalbarhet och prestandafördelar med Lagringsdirigering, den programvarudefinierade lagringstekniken bakom Azure Stack HCI och Windows Server.

Anteckning

Vi använder termen "volym" för att gemensamt referera till volymen och den virtuella disken under den, inklusive funktioner som tillhandahålls av andra inbyggda Windows-funktioner som klusterdelade volymer (CSV) och ReFS. Det är inte nödvändigt att förstå skillnaderna på implementeringsnivå för att planera och distribuera Lagringsdirigering korrekt.

Alla volymer är tillgängliga för alla servrar i klustret samtidigt. När de har skapats visas de på C:\ClusterStorage\ på alla servrar.

Välja hur många volymer som ska skapas

Vi rekommenderar att du gör antalet volymer till en multipel av antalet servrar i klustret. Om du till exempel har 4 servrar får du mer konsekventa prestanda med 4 totala volymer än med 3 eller 5. Detta gör att klustret kan distribuera volymen "ägarskap" (en server hanterar metadataorkestrering för varje volym) jämnt mellan servrarna.

Vi rekommenderar att du begränsar det totala antalet volymer till 64 volymer per kluster.

Välja filsystem

Vi rekommenderar att du använder det nya ReFS (Resilient File System) för Lagringsdirigering. ReFS är det främsta filsystemet som är specialbyggt för virtualisering och erbjuder många fördelar, inklusive dramatiska prestandaacceleration och inbyggt skydd mot skadade data. Det stöder nästan alla viktiga NTFS-funktioner, inklusive Datadeduplicering i Windows Server version 1709 och senare. Mer information finns i jämförelsetabellen för ReFS-funktioner.

Om din arbetsbelastning kräver en funktion som ReFS inte stöder ännu kan du använda NTFS i stället.

Tips

Volymer med olika filsystem kan samexistera i samma kluster.

Välja återhämtningstyp

Volymer i Lagringsdirigering ger återhämtning för att skydda mot maskinvaruproblem, till exempel enhets- eller serverfel, och för att aktivera kontinuerlig tillgänglighet under serverunderhåll, till exempel programuppdateringar.

Anteckning

Vilka återhämtningstyper du kan välja är oberoende av vilka typer av enheter du har.

Med två servrar

Med två servrar i klustret kan du använda tvåvägsspegling eller använda kapslad återhämtning.

Dubbelriktad spegling behåller två kopior av alla data, en kopia på enheterna på varje server. Lagringseffektiviteten är 50 procent. för att skriva 1 TB data behöver du minst 2 TB fysisk lagringskapacitet i lagringspoolen. Dubbelriktad spegling kan på ett säkert sätt tolerera ett maskinvarufel i taget (en server eller enhet).

Kapslad återhämtning ger dataåterhämtning mellan servrar med dubbelriktad spegling och lägger sedan till återhämtning inom en server med dubbelriktad spegling eller speglingsaccelererad paritet. Kapsling ger dataresiliens även när en server startas om eller inte är tillgänglig. Lagringseffektiviteten är 25 procent med kapslad dubbelriktad spegling och cirka 35–40 procent för kapslad speglingsaccelererad paritet. Kapslad återhämtning kan på ett säkert sätt tolerera två maskinvarufel i taget (två enheter eller en server och en enhet på den återstående servern). På grund av den här extra dataåterhämtningen rekommenderar vi att du använder kapslad återhämtning i produktionsdistributioner av två serverkluster. Mer information finns i Kapslad återhämtning.

Med tre servrar

Med tre servrar bör du använda trevägsspegling för bättre feltolerans och prestanda. Trevägsspegling behåller tre kopior av alla data, en kopia på enheterna på varje server. Lagringseffektiviteten är 33,3 procent – för att skriva 1 TB data behöver du minst 3 TB fysisk lagringskapacitet i lagringspoolen. Trevägsspegling kan på ett säkert sätt tolerera minst två maskinvaruproblem (enhet eller server) åt gången. Om två noder blir otillgängliga förlorar lagringspoolen kvorum eftersom 2/3 av diskarna inte är tillgängliga och de virtuella diskarna inte kan nås. En nod kan dock vara nere och en eller flera diskar på en annan nod kan misslyckas och de virtuella diskarna förblir online. 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.

Med fyra eller fler servrar

Med fyra eller flera servrar kan du välja för varje volym om du vill använda trevägsspegling, dubbel paritet (kallas ofta "raderingskodning") eller blanda de två med speglingsaccelererad paritet.

Dubbel paritet ger samma feltolerans som trevägsspegling men med bättre lagringseffektivitet. Med fyra servrar är lagringseffektiviteten 50,0 procent. För att lagra 2 TB data behöver du 4 TB fysisk lagringskapacitet i lagringspoolen. Detta ökar till 66,7 procents lagringseffektivitet med sju servrar och fortsätter upp till 80,0 procents lagringseffektivitet. Kompromissen är att paritetskodning är mer beräkningsintensiv, vilket kan begränsa dess prestanda.

Vilken återhämtningstyp som ska användas beror på arbetsbelastningens behov. Här är en tabell som sammanfattar vilka arbetsbelastningar som passar bra för varje återhämtningstyp, samt prestanda och lagringseffektivitet för varje återhämtningstyp.

Återhämtningstyp	Kapacitetseffektivitet	Hastighet	Arbetsbelastningar
Spegling	Trevägsspegling: 33 % Tvåvägsspegling: 50 %	Högsta prestanda	Virtualiserade arbetsbelastningar Databaser Andra arbetsbelastningar med höga prestanda
Speglingsaccelererad paritet	Beror på andelen spegling och paritet	Mycket långsammare än spegling, men upp till dubbelt så snabbt som dubbel paritet Bäst för stora sekventiella skrivningar och läsningar	Arkivering och säkerhetskopiering Virtualiserad skrivbordsinfrastruktur
Dubbel paritet	4 servrar: 50 % 16 servrar: upp till 80 %	Högsta I/O-svarstid & CPU-användning vid skrivningar Bäst för stora sekventiella skrivningar och läsningar	Arkivering och säkerhetskopiering Virtualiserad skrivbordsinfrastruktur

När prestanda är viktigast

Arbetsbelastningar som har strikta svarstidskrav eller som behöver många blandade slumpmässiga IOPS, till exempel SQL Server databaser eller prestandakänsliga virtuella Hyper-V-datorer, bör köras på volymer som använder spegling för att maximera prestanda.

Tips

Spegling är snabbare än någon annan återhämtningstyp. Vi använder spegling för nästan alla våra prestandaexempel.

När kapaciteten är viktigast

Arbetsbelastningar som skrivs sällan, till exempel informationslager eller "kall" lagring, bör köras på volymer som använder dubbel paritet för att maximera lagringseffektiviteten. Vissa andra arbetsbelastningar, till exempel Scale-Out Filserver (SoFS), VDI (Virtual Desktop Infrastructure) eller andra som inte skapar massor av snabbdrivande slumpmässig I/O-trafik och/eller inte kräver bästa möjliga prestanda, kan också använda dubbel paritet efter eget gottfinnande. Paritet ökar oundvikligen processoranvändningen och I/O-svarstiden, särskilt vid skrivningar, jämfört med spegling.

När data skrivs i grupp

Arbetsbelastningar som skriver i stora, sekventiella pass, till exempel arkiverings- eller säkerhetskopieringsmål, har ett annat alternativ: en volym kan blanda spegling och dubbel paritet. Skrivningar hamnar först i den speglade delen och flyttas gradvis till paritetsdelen senare. Detta påskyndar inmatningen och minskar resursutnyttjandet när stora skrivningar tas emot genom att tillåta att den beräkningsintensiva paritetskodningen sker under en längre tid. När du ändrar storlek på delarna bör du tänka på att antalet skrivningar som sker samtidigt (till exempel en daglig säkerhetskopia) ska passa bekvämt i speglingsdelen. Om du till exempel matar in 100 GB en gång dagligen bör du överväga att använda spegling för 150 GB till 200 GB och dubbel paritet för resten.

Den resulterande lagringseffektiviteten beror på vilka proportioner du väljer. Se den här demonstrationen för några exempel.

Tips

Om du ser en plötslig minskning av skrivprestandan genom datainmatning kan det tyda på att speglingsdelen inte är tillräckligt stor eller att speglingsaccelererad paritet inte passar bra för ditt användningsfall. Om skrivprestanda till exempel minskar från 400 MB/s till 40 MB/s kan du överväga att expandera speglingsdelen eller växla till trevägsspegling.

Om distributioner med NVMe, SSD och HDD

I distributioner med två typer av enheter ger de snabbare enheterna cachelagring medan de långsammare enheterna ger kapacitet. Detta sker automatiskt – mer information finns i Förstå cachen i Lagringsdirigering. I sådana distributioner finns alla volymer i slutändan på samma typ av enheter – kapacitetsenheterna.

I distributioner med alla tre typer av enheter ger endast de snabbaste enheterna (NVMe) cachelagring, vilket ger två typer av enheter (SSD och HDD) för att tillhandahålla kapacitet. För varje volym kan du välja om den finns helt på SSD-nivån, helt på HDD-nivån eller om den sträcker sig över de två.

Viktigt

Vi rekommenderar att du använder SSD-nivån för att placera dina mest prestandakänsliga arbetsbelastningar på flash.

Välja storlek på volymer

Vi rekommenderar att du begränsar storleken på varje volym till 64 TB i Azure Stack HCI.

Tips

Om du använder en säkerhetskopieringslösning som förlitar sig på tjänsten Volume Shadow Copy (VSS) och Volsnap-programvaruleverantören , vilket är vanligt med filserverarbetsbelastningar, kommer en begränsning av volymstorleken till 10 TB att förbättra prestanda och tillförlitlighet. Säkerhetskopieringslösningar som använder det nyare Hyper-V RCT-API:et och/eller ReFS-blockkloning och/eller inbyggda API:er för SQL-säkerhetskopiering presterar bra upp till 32 TB och senare.

Fotavtryck

Storleken på en volym refererar till dess användbara kapacitet, den mängd data som den kan lagra. Detta tillhandahålls av parametern -Size för cmdleten New-Volume och visas sedan i egenskapen Storlek när du kör cmdleten Get-Volume .

Storleken skiljer sig från volymens fotavtryck, den totala fysiska lagringskapacitet som den upptar i lagringspoolen. Fotavtrycket beror på dess återhämtningstyp. Volymer som använder trevägsspegling har till exempel ett fotavtryck som är tre gånger så stort.

Fotavtrycken för dina volymer måste få plats i lagringspoolen.

Reservera kapacitet

Om du lämnar en del kapacitet i lagringspoolen oallokerad får volymerna utrymme att reparera "på plats" efter att enheter har misslyckats, vilket förbättrar datasäkerheten och prestandan. Om det finns tillräckligt med kapacitet kan en omedelbar, parallell reparation på plats återställa volymerna till fullständig återhämtning även innan de misslyckade enheterna ersätts. Detta sker automatiskt.

Vi rekommenderar att du reserverar motsvarande en kapacitetsenhet per server, upp till 4 enheter. Du kan reservera mer efter eget gottfinnande, men den här minsta rekommendationen garanterar en omedelbar, parallell reparation på plats kan lyckas efter fel på valfri enhet.

Om du till exempel har 2 servrar och du använder kapacitetsenheter på 1 TB kan du reservera 2 x 1 = 2 TB av poolen som reserv. Om du har 3 servrar och 1 TB kapacitetsenheter kan du reservera 3 x 1 = 3 TB. Om du har 4 eller fler servrar och 1 TB kapacitetsenheter kan du avsätta 4 x 1 = 4 TB som reserv.

Anteckning

I kluster med enheter av alla tre typer (NVMe + SSD + HDD) rekommenderar vi att du reserverar motsvarande en SSD plus en HÅRDDISK per server, upp till 4 enheter av varje.

Exempel: Kapacitetsplanering

Överväg ett kluster med fyra servrar. Varje server har vissa cacheenheter plus sexton 2 TB enheter för kapacitet.

4 servers x 16 drives each x 2 TB each = 128 TB

Från dessa 128 TB i lagringspoolen reserverar vi fyra enheter, eller 8 TB, så att reparationer på plats kan ske utan någon brådska att ersätta enheter efter att de har misslyckats. Detta lämnar 120 TB fysisk lagringskapacitet i poolen som vi kan skapa volymer med.

128 TB – (4 x 2 TB) = 120 TB

Anta att vi behöver vår distribution som värd för några mycket aktiva virtuella Hyper-V-datorer, men vi har också massor av kall lagring – gamla filer och säkerhetskopior som vi behöver behålla. Eftersom vi har fyra servrar ska vi skapa fyra volymer.

Vi placerar de virtuella datorerna på de två första volymerna, Volym1 och Volym2. Vi väljer ReFS som filsystem (för snabbare skapande och kontrollpunkter) och trevägsspegling för återhämtning för att maximera prestanda. Nu ska vi placera kalllagring på de andra två volymerna, volym 3 och volym 4. Vi väljer NTFS som filsystem (för Datadeduplicering) och dubbel paritet för återhämtning för att maximera kapaciteten.

Vi behöver inte göra alla volymer till samma storlek, men för enkelhetens skull kan vi göra dem till alla 12 TB.

Volym1 och Volym2 upptar vardera 12 TB x 33,3 procents effektivitet = 36 TB fysisk lagringskapacitet.

Volym3 och Volym4 upptar vardera 12 TB x 50,0 procents effektivitet = 24 TB fysisk lagringskapacitet.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

De fyra volymerna passar exakt på den fysiska lagringskapacitet som är tillgänglig i poolen. Bra!

Tips

Du behöver inte skapa alla volymer direkt. Du kan alltid utöka volymer eller skapa nya volymer senare.

För enkelhetens skull använder det här exemplet decimalenheter (base-10) i hela, vilket innebär 1 TB = 1 000 000 000 000 byte. Lagringskvantiteter i Windows visas dock i binära enheter (base-2). Varje 2 TB-enhet visas till exempel som 1,82 TiB i Windows. På samma sätt visas lagringspoolen på 128 TB som 116,41 TiB. Detta är förväntat.

Användning

Se Skapa volymer i Azure Stack HCI.

Nästa steg

Mer information finns i även:

• Välja enheter för Lagringsdirigering
• Feltolerans och lagringseffektivitet