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
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.
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.
Kommentar
Lagringsutrymmen Direct 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 Lagringsutrymmen Direct, den programvarudefinierade lagringstekniken bakom Azure Stack HCI och Windows Server.
Kommentar
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 Lagringsutrymmen Direct.
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 ReFS (Resilient File System) för Lagringsutrymmen Direct. ReFS är det främsta filsystemets specialbyggda för virtualisering och erbjuder många fördelar, inklusive dramatiska prestandaacceleration och inbyggt skydd mot datakorruption. 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.
Dricks
Volymer med olika filsystem kan samexistera i samma kluster.
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.
Kommentar
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 dubbelriktad spegling 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. om du vill 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 dataresiliensen 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 kunna 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 ä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 återhämtningstyp.
| Återhämtningstyp | Kapacitetseffektivitet | Hastighet |
|---|---|---|
| Spegel |  Trevägsspegling: 33 % Tvåvägsspegling: 50 % |
 Högsta 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 |
| 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 virtuella Hyper-V-datorer, bör köras på volymer som använder spegling för att maximera prestanda.
Dricks
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 Skalbar 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.
Dricks
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å cacheminnet i Lagringsutrymmen Direct. I sådana distributioner finns alla volymer i slutändan på samma typ av enheter – kapacitetsenheterna.
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 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.
Dricks
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 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 återhämtningstyp. 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.
Reserverad kapacitet
Att lämna viss kapacitet i lagringspoolen oallokerad ger volymer utrymme att reparera "på plats" efter att enheterna har misslyckats, vilket förbättrar datasäkerheten och prestandan. Om det finns tillräckligt med kapacitet kan en omedelbar, på plats, parallell reparation återställa volymer 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, på plats, parallell reparation kan lyckas efter fel på någon enhet.
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.
Kommentar
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 virtuella Hyper-V-datorer, men vi har också mycket 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 kontrollpunkter) och trevägsspegling för återhämtning 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. Bra!
Dricks
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.
Förbrukning
Se Skapa volymer i Azure Stack HCI.
Nästa steg
Mer information finns också: