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.

Anmärkning

Storage Spaces Direct stöder inte en filserver för allmänt bruk. Om du behöver köra filservern eller andra allmänna tjänster på Storage Spaces Direct, konfigurera dem 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 Hyper-V virtuella datorer. Volymer kombinerar drivarna i lagringspoolen för att introducera feltolerans, skalbarhet och prestandafördelar med Storage Spaces Direct, den programvarudefinierade lagringstekniken bakom Azure Stack HCI och Windows Server.

Anmärkning

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å skillnader på implementeringsnivå för att planera och distribuera Storage Spaces Direct framgångsrikt.

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 volymens "ägarskap" (en server hanterar metadataorkestrering för varje volym) jämnt mellan servrar.

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 Resilient File System (ReFS) för Storage Spaces Direct. ReFS är det främsta filsystemet som är specialbyggt för virtualisering och erbjuder många fördelar, inklusive dramatiska prestandaaccelerationer och inbyggt skydd mot dataskador. Den 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/Råd

Volymer med olika filsystem kan samexistera i samma kluster.

Välja återhämtningstyp

Volymer i Storage Spaces Direct tillhandahåller motståndskraft för att skydda mot maskinvaruproblem, till exempel enhets- eller serverfel, och möjliggör fortsatt tillgänglighet under serverunderhåll, till exempel programuppdateringar.

Anmärkning

Vilka motståndskraftstyper du kan välja är oberoende av vilka typer av enheter du har.

Med två servrar

När du har två servrar i ett kluster kan du använda tvåvägsspegling eller kapslad resiliens.

Dubbelriktad spegling behåller två kopior av alla data, en kopia på enheterna i varje server. Lagringseffektiviteten är 50 procent. om du vill skriva 1 TB data behöver du minst 2 TB fysisk lagringskapacitet i lagringspoolen. Tvåvägsspegling kan tolerera ett maskinvarufel i taget (en server eller hårddisk).

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 resiliens kan på ett säkert sätt tolerera två maskinvarufel i taget (två enheter, eller en server och en enhet på en återstående server). På grund av den här extra dataresiliensen rekommenderar vi att du använder nästlad motståndskraft i produktionsdriftsättningar 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 kunna skriva 1 TB data behöver du minst 3 TB fysisk lagringskapacitet i lagringspoolen. Trevägsspegling kan säkert tolerera minst två maskinvaruproblem (enhet eller server) samtidigt. Om två noder blir otillgängliga förlorar lagringspoolen kvorum eftersom 2/3 av diskarna inte är tillgängliga och de virtuella diskarna inte är tillgängliga. 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 paritetskodningen är mer beräkningsintensiv, vilket kan begränsa dess prestanda.

Vilken återhämtningstyp som ska användas beror på prestanda- och kapacitetskraven för din miljö. Här är en tabell som sammanfattar prestanda och lagringseffektivitet för varje resilienstyp.

Återhämtningstyp	Kapacitetseffektivitet	Hastighet
Spegel	Tresidig spegel: 33% Dubbelriktad spegel: 50%	Högsta prestanda
Speglingsaccelererad paritet	Beror på andelen spegling och paritet	Betydligt långsammare än spegling, men upp till dubbelt så snabbt som dubbelparitet Bäst för stora sekventiella skrivningar och läsningar
Dubbel paritet	4 servrar: 50% 16 servrar: upp till 80%	Högsta I/O-svarstid och CPU-användning vid skrivningar Bäst för stora sekventiella skrivningar och läsningar

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 Hyper-V virtuella datorer, ska köras på volymer som använder spegling för att maximera prestanda.

Tips/Råd

Spegling är snabbare än någon annan resilienstyp. 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), virtuell skrivbordsinfrastruktur (VDI) eller andra som inte skapar massor av snabbdrivande slumpmässig I/O-trafik och/eller inte kräver bästa 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 bulk

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. Skriver land först i den speglade delen och flyttas gradvis till paritetsdelen senare. Detta påskyndar inmatningen och minskar resursanvändningen 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 mängden skrivningar som sker samtidigt (till exempel en daglig säkerhetskopiering) bekvämt ska passa i speglingsdelen. Om du till exempel matar in 100 GB en gång dagligen kan 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.

Tips/Råd

Om du ser en plötslig minskning av skrivprestanda delvis 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 implementeringar finns alla volymer i slutändan på samma typ av enheter – kapacitetsdrivarna.

I distributioner med alla tre typer av enheter tillhandahåller 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 prestandakritiska arbetsbelastningar på heltäckande flashlagring.

Välja storlek på volymer

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

Tips/Råd

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 nyare Hyper-V RCT API och/eller ReFS-blockkloning och/eller interna 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, mängden 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 resilienstyp. Volymer som använder trevägsspegling har till exempel ett fotavtryck som är tre gånger så stort.

Dina volymers fotavtryck måste få plats i lagringspoolen.

Reservera kapacitet

Att lämna viss kapacitet i lagringspoolen oallokerad ger volymerna möjlighet att repareras "på plats" efter att enheterna har gått sönder, och därmed förbättrar både datasäkerheten och prestandan. Om det finns tillräcklig kapacitet kan en omedelbar, på platsen, parallell reparation återställa volymerna till full motståndskraft, redan 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 att en omedelbar, parallell reparation på platsen kan lyckas efter ett fel på någon drivenhet.

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

Anmärkning

I kluster med enheter av alla tre typerna (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 när 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 för att vara värd för några mycket aktiva Hyper-V virtuella 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.

Nu ska vi placera de virtuella datorerna på de två första volymerna , Volume1 och Volume2. Vi väljer ReFS som filsystem (för snabbare skapande och snabbare checkpunkter) och trevägsspegling för tillförlitlighet för att maximera prestanda. Vi lägger det kalla lagringsutrymmet 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 är inte skyldiga att göra alla volymer lika stora, men för enkelhetens skull, låt oss – till exempel kan vi göra dem 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 vår pool. Perfekt!

Tips/Råd

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). Till exempel visas varje 2 TB-enhet 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

Titta på Skapa volymer.

Nästa steg

Mer information finns också:

• Välja drivrutiner för Storage Spaces Direct
• Feltolerans och lagringseffektivitet