Planera volymer på Azure Stack HCI och Windows Server-kluster

Gäller för: Azure Stack HCI, versionerna 21H2 och 20H2; 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 att välja filsystem, återhämtningstyp och storlek.

Granskning: Vad är volymer?

Volymer är den plats där du lägger 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 Lagringsutrymmen Direct, den programvarudefinierade lagringstekniken bakom Azure Stack HCI.

Alla volymer är tillgängliga för alla servrar i klustret på samma gång. 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 ReFS (Resilient File System) för Lagringsutrymmen Direct. 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. 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.

Välja återhämtningstyp

Volymer i Lagringsutrymmen Direct 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.

Med två servrar

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

Tvåvägsspegling behåller två kopior av alla data, en kopia på enheterna på 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 enhet).

Kapslad återhämtning ger dataåter återhämtning mellan servrar med tvåvägsspegling och lägger sedan till återhämtning inom en server med tvåvägsspegling eller speglad paritet. Kapsling ger dataåter återhämtning även när en server startas om eller är otillgänglig. Lagringseffektiviteten är 25 procent med kapslad tvåvägsspegling och cirka 35–40 procent för kapslad speglad paritet. Kapslad återhämtning kan tolerera två maskinvarufel i taget på ett säkert sätt (två enheter eller en server och en enhet på den återstående servern). Därför rekommenderar vi att du använder kapslad återhämtning vid 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 tolerera minst två maskinvaruproblem (enhet eller server) i taget. Om 2 noder blir otillgängliga förlorar lagringspoolen kvorum eftersom 2/3 av diskarna inte är tillgängliga och de virtuella diskarna blir otillgä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 slutar fungera förblir alla data säkra och alltid tillgängliga.

Med fyra eller fler servrar

Med fyra eller fler 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 speglad paritet.

Dubbel paritet ger samma feltolerans som trevägsspegling men med bättre lagringseffektivitet. Med fyra servrar är lagringseffektiviteten 50,0 procent. Om du vill 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å din arbetsbelastnings 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
Speglad 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 %	Cpu-användning med högsta & I/O-svarstid 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.

När kapaciteten är viktigast

Arbetsbelastningar som skriver 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 traditionella filservrar, virtuell skrivbordsinfrastruktur (VDI) eller andra som inte skapar massor av snabb avdrift slumpmässig I/O-trafik och/eller som inte kräver bästa prestanda kan också använda dubbel paritet, efter eget gottfinnande. Paritet ökar oundvikligen CPU-anvä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 över en längre tid. När du storleksändring av delarna bör du tänka på att antalet skrivningar som sker samtidigt (till exempel en daglig säkerhetskopiering) bör passa in i speglingsdelen. Om du till exempel matar in 100 GB en gång per dag 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.

Om distributioner med NVMe, SSD och HDD

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

I distributioner med alla tre typer av enheter ger endast de snabbaste enheterna (NVMe) cachelagring, vilket lämnar 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 omfattar de två.

Välja storlek på volymer

Vi rekommenderar att du begränsar storleken på varje volym till 64 TB Windows Server 2019.

Fotavtryck

Storleken på en volym avser dess användbara kapacitet, mängden data som den kan lagra. Detta tillhandahålls av parametern -Size i 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 tre gånger så stort fotavtryck som storlek.

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

Reservera kapacitet

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

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

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

Exempel: Kapacitetsplanering

Överväg ett kluster med fyra servrar. Varje server har vissa cacheenheter plus sex 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 reparation på plats kan ske utan att behöva byta ut 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 måste behålla. Eftersom vi har fyra servrar ska vi skapa fyra volymer.

Nu ska vi placera de virtuella datorerna på de första två volymerna, Volume1 och Volume2. Vi väljer ReFS som filsystem (för snabbare skapande och kontrollpunkter) och trevägsspegling för återhämtning för att maximera prestanda. Vi lägger den kalla lagringen 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 till exempel göra dem alla till 12 TB.

Volume1 och Volume2 upptar var och en 12 TB x 33,3 procents effektivitet = 36 TB fysisk lagringskapacitet.

Volume3 och Volume4 upptar var och en 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. Bra!

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. Lagringskvantiteterna i Windows i binära enheter (base-2). Till exempel skulle varje enhet på 2 TB visas som 1,82 TiB i Windows. På samma sätt skulle lagringspoolen på 128 TB visas som 116,41 TiB. Detta är förväntat.

Användning

Se Skapa volymer i Azure Stack HCI.

Nästa steg

Mer information finns även i:

• Välja enheter för Lagringsutrymmen Direct
• Feltolerans och lagringseffektivitet