Het plannen van volumes op Azure Stack HCI- en Windows Server-clusters

Van toepassing op: Azure Stack HCI, versies 22H2 en 21H2; Windows Server 2022, Windows Server 2019

Dit artikel bevat richtlijnen voor het plannen van clustervolumes om te voldoen aan de prestatie- en capaciteitsbehoeften van uw workloads, zoals het kiezen van hun bestandssysteem, het tolerantietype en de grootte.

Note

Opslagruimten Direct biedt geen ondersteuning voor een bestandsserver voor algemeen gebruik. Als u de bestandsserver of andere algemene services op Opslagruimten Direct wilt uitvoeren, configureert u deze op de virtuele machines.

Review: Wat zijn volumes?

Volumes zijn de plaats waar u de bestanden plaatst die uw workloads nodig hebben, zoals VHD- of VHDX-bestanden voor Hyper-V virtuele machines. Volumes combineren de schijven in de opslaggroep om de voordelen van fouttolerantie, schaalbaarheid en prestaties van Opslagruimten Direct, de softwaregedefinieerde opslagtechnologie achter Azure Stack HCI en Windows Server, te realiseren.

Note

We gebruiken de term 'volume' om gezamenlijk te verwijzen naar het volume en de virtuele schijf eronder, inclusief functionaliteit die wordt geleverd door andere ingebouwde Windows-functies, zoals Gedeelde clustervolumes (CSV) en ReFS. Inzicht in deze onderscheid op implementatieniveau is niet nodig om Opslagruimten Direct te plannen en te implementeren.

Alle volumes zijn tegelijkertijd toegankelijk voor alle servers in het cluster. Once created, they show up at C:\ClusterStorage\ on all servers.

Kiezen hoeveel volumes u wilt maken

U wordt aangeraden het aantal volumes een veelvoud van het aantal servers in uw cluster te maken. Als u bijvoorbeeld 4 servers hebt, ervaart u consistentere prestaties met 4 totale volumes dan met 3 of 5. Hierdoor kan het cluster het volume 'eigenaarschap' distribueren (één server voert de metagegevens orkestratie uit voor elk volume) gelijkmatig over de servers.

U wordt aangeraden het totale aantal volumes te beperken tot 64 volumes per cluster.

Het bestandssysteem kiezen

We raden u aan het nieuwe Resilient File System (ReFS) te gebruiken voor Opslagruimten Direct. ReFS is het belangrijkste bestandssysteem dat speciaal is gebouwd voor virtualisatie en biedt veel voordelen, waaronder dramatische prestatieversnelling en ingebouwde bescherming tegen beschadiging van gegevens. Het ondersteunt bijna alle belangrijke NTFS-functies, waaronder Gegevensontdubbeling in Windows Server versie 1709 en hoger. Zie de vergelijkingstabel voor ReFS-functies voor meer informatie.

Als voor uw workload een functie is vereist die nog niet door ReFS wordt ondersteund, kunt u IN plaats daarvan NTFS gebruiken.

Tip

Volumes met verschillende bestandssystemen kunnen naast elkaar bestaan in hetzelfde cluster.

Het tolerantietype kiezen

Volumes in Opslagruimten Direct bieden tolerantie om te beschermen tegen hardwareproblemen, zoals schijf- of serverfouten, en om continue beschikbaarheid mogelijk te maken tijdens serveronderhoud, zoals software-updates.

Note

Welke soorten veerkracht u kunt kiezen, is onafhankelijk van welke soorten schijven u hebt.

Met twee servers

Met twee servers in het cluster kunt u gebruikmaken van spiegeling in twee richtingen of van geneste veerkracht.

Tweerichtingsspiegeling bewaart twee kopieën van alle gegevens, één kopie op de schijven van elke server. De opslagefficiëntie is 50 procent; als u 1 TB aan gegevens wilt schrijven, hebt u ten minste 2 TB fysieke opslagcapaciteit in de opslaggroep nodig. Spiegeling in twee richtingen kan veilig één hardwarefout tegelijk opvangen (één server of station).

Genest veerkracht biedt gegevensveerkracht tussen servers met spiegeling in twee richtingen en voegt daarna veerkracht toe binnen een server met spiegeling in twee richtingen of door spiegeling versnelde pariteit. Nesten biedt gegevenstolerantie, zelfs wanneer één server opnieuw wordt opgestart of niet beschikbaar is. De opslagefficiëntie is 25 procent met geneste bidirectionele spiegeling en ongeveer 35-40 procent voor geneste spiegel-versnelde pariteit. Geneste veerkracht kan veilig twee hardwareproblemen tegelijk tolereren (twee schijven of een server en een schijf op de resterende server). Vanwege deze toegevoegde gegevensveerkracht raden we aan om geneste veerkracht te gebruiken voor productie-implementaties van clusters met twee servers. For more info, see Nested resiliency.

Met drie servers

Met drie servers moet u spiegeling in drie richtingen gebruiken voor betere fouttolerantie en prestaties. Drievoudige spiegeling bewaart drie kopieën van alle gegevens, één kopie op de schijven in elke server. De opslagefficiëntie is 33,3 procent: als u 1 TB aan gegevens wilt schrijven, hebt u ten minste 3 TB fysieke opslagcapaciteit in de opslaggroep nodig. Spiegeling in drie richtingen kan veilig ten minste twee hardwareproblemen (station of server) tegelijk verdragen. Als 2 knooppunten niet beschikbaar zijn, verliest de opslaggroep quorum, omdat 2/3 van de schijven niet beschikbaar is en de virtuele schijven niet toegankelijk zijn. Een knooppunt kan echter offline zijn en een of meer schijven op een ander knooppunt mislukken en de virtuele schijven blijven online. Als u bijvoorbeeld de ene server opnieuw opstart wanneer plotseling een ander station of een andere server uitvalt, blijven alle gegevens veilig en continu toegankelijk.

Met vier of meer servers

Met vier of meer servers kunt u voor elk volume kiezen of u drievoudige spiegeling, dubbele pariteit (ook wel 'erasure coding' genoemd) wilt gebruiken of de twee wilt combineren met spiegelversnelde pariteit.

Dubbele pariteit biedt dezelfde fouttolerantie als spiegeling in drie richtingen, maar met betere opslagefficiëntie. Met vier servers is de opslagefficiëntie 50,0 procent; als u 2 TB aan gegevens wilt opslaan, hebt u 4 TB fysieke opslagcapaciteit nodig in de opslaggroep. Dit verhoogt tot 66,7 procent opslagefficiëntie met zeven servers en blijft tot 80,0 procent opslagefficiëntie. Het nadeel is dat pariteitscodering meer rekenintensief is, waardoor de prestaties kunnen worden beperkt.

Welk tolerantietype moet worden gebruikt, is afhankelijk van de prestatie- en capaciteitsvereisten voor uw omgeving. Hier volgt een tabel met een overzicht van de prestaties en opslagefficiëntie van elk tolerantietype.

Resiliency type	Capacity efficiency	Speed
Mirror	Driezijdige spiegel: 33% Two-way-mirror: 50%	Highest performance
Mirror-accelerated parity	Afhankelijk van het aandeel van spiegeling en pariteit	Veel langzamer dan spiegel, maar tot twee keer zo snel als dubbele pariteit Geschikt voor grote sequentiële schrijf- en leesbewerkingen
Dual-parity	4 servers: 50% 16 servers: maximaal 80%	Hoogste I/O-latentie en CPU-gebruik voor schrijfbewerkingen Geschikt voor grote sequentiële schrijf- en leesbewerkingen

Wanneer de prestaties het belangrijkst zijn

Workloads met strikte latentievereisten of waarvoor veel gemengde willekeurige IOPS nodig zijn, zoals SQL Server-databases of prestatiegevoelige Hyper-V virtuele machines, moeten worden uitgevoerd op volumes die gebruikmaken van spiegeling om de prestaties te maximaliseren.

Tip

Spiegeling is sneller dan elk ander resilientietype. We gebruiken spiegeling voor bijna al onze prestatievoorbeelden.

Wanneer capaciteit het belangrijkst is

Workloads die onregelmatig schrijven, zoals datawarehouses of 'koude' opslag, moeten worden uitgevoerd op volumes die dubbele pariteit gebruiken om de opslagefficiëntie te maximaliseren. Bepaalde andere werkbelastingen, zoals Scale-Out File Server (SoFS), virtual desktop infrastructure (VDI) of andere die niet veel snel afdrijvend willekeurig IO-verkeer maken en/of die niet de beste prestaties vereisen, kunnen naar eigen goeddunken ook gebruikmaken van dubbele pariteit. Pariteit verhoogt onvermijdelijk het CPU-gebruik en de IO-latentie, met name bij schrijfbewerkingen, vergeleken met spiegeling.

Wanneer gegevens bulksgewijs worden geschreven

Werkbelastingen die in grote, opeenvolgende passen schrijven, zoals archiverings- of back-updoelen, hebben een andere optie: één volume kan spiegeling en dubbele pariteit combineren. Schrijfbewerkingen komen eerst in het gespiegelde gedeelte terecht en worden later geleidelijk naar het pariteitsgedeelte verplaatst. Dit versnelt de opname en vermindert het resourcegebruik wanneer grote schrijfbewerkingen binnenkomen door de rekenintensieve pariteitscodering gedurende langere tijd te laten plaatsvinden. Houd er bij het aanpassen van de grootte van de gedeelten rekening mee dat de hoeveelheid schrijfbewerkingen die tegelijk plaatsvinden (zoals één dagelijkse back-up) comfortabel in het gespiegelde gedeelte moet passen. Als u bijvoorbeeld 100 GB eenmaal per dag opneemt, kunt u overwegen spiegeling te gebruiken voor 150 GB tot 200 GB en dubbele pariteit voor de rest.

De resulterende opslagefficiëntie is afhankelijk van de verhoudingen die u kiest.

Tip

Als u een plotselinge afname van de schrijfprestaties tijdens gegevensopname ziet, kan dit erop wijzen dat het spiegelgedeelte niet groot genoeg is of dat pariteit met versnelling van spiegeling niet geschikt is voor uw use-case. Als de schrijfprestaties bijvoorbeeld afnemen van 400 MB/s tot 40 MB/s, kunt u overwegen het spiegelgedeelte uit te breiden of over te schakelen naar spiegeling in drie richtingen.

Over uitrol met NVMe, SSD en HDD

In implementaties met twee typen schijven bieden de snellere schijven caching, terwijl de tragere schijven capaciteit bieden. Dit gebeurt automatisch. Zie Inzicht in de cache in Opslagruimten Direct voor meer informatie. In dergelijke implementaties bevinden alle volumes zich uiteindelijk op hetzelfde type schijven: de capaciteitsschijven.

In implementaties met alle drie de typen stations bieden alleen de snelste stations (NVMe) caching, waardoor twee typen stations (SSD en HDD) capaciteit kunnen bieden. Voor elk volume kunt u kiezen of het zich volledig op de SSD-laag bevindt, volledig op de HDD-laag of of het de twee omvat.

Important

We raden u aan de SSD-laag te gebruiken om uw meest prestatiegevoelige workloads op all-flash te plaatsen.

De grootte van volumes kiezen

U wordt aangeraden de grootte van elk volume te beperken tot 64 TB in Azure Stack HCI.

Tip

Als u een back-upoplossing gebruikt die afhankelijk is van de Volume Shadow Copy-service (VSS) en de Volsnap-softwareprovider, zoals gebruikelijk is bij bestandsserverworkloads, wordt de volumegrootte beperkt tot 10 TB, waardoor de prestaties en betrouwbaarheid worden verbeterd. Back-upoplossingen die gebruikmaken van de nieuwere Hyper-V RCT-API en/of ReFS-blokklonen en/of de systeemeigen SQL-back-up-API's presteren tot wel 32 TB en hoger.

Footprint

De grootte van een volume verwijst naar de bruikbare capaciteit, de hoeveelheid gegevens die het kan opslaan. This is provided by the -Size parameter of the New-Volume cmdlet and then appears in the Size property when you run the Get-Volume cmdlet.

Size is distinct from volume's footprint, the total physical storage capacity it occupies on the storage pool. De footprint is afhankelijk van het veerkrachttype. Volumes die gebruikmaken van drievoudige spiegeling verbruiken bijvoorbeeld drie keer zoveel ruimte.

De footprint van uw volumes moet in de opslagpool passen.

Reserve capacity

Als sommige capaciteit in de opslagpool niet is toegewezen, is er ruimte voor volumes om 'in-place' te herstellen nadat schijven falen, waardoor de veiligheid en prestaties van gegevens worden verbeterd. Als er voldoende capaciteit is, kan een parallelle reparatie volumes direct en ter plaatse herstellen tot volledige veerkracht, zelfs voordat de defecte schijven worden vervangen. Dit gebeurt automatisch.

We raden u aan om het equivalent van één capaciteitsstation per server te reserveren, maximaal 4 stations. U kunt naar eigen goeddunken meer reserveren, maar deze minimale aanbeveling garandeert dat een onmiddellijke, in-place, parallelle reparatie kan slagen na het uitvallen van een schijf.

Als u bijvoorbeeld 2 servers hebt en u 1 TB capaciteitsstations gebruikt, moet u 2 x 1 = 2 TB van de pool reserveren. Als u 3 servers en 1 TB capaciteitsstations hebt, moet u 3 x 1 = 3 TB als reserve reserveren. Als u 4 of meer servers en schijven met 1 TB capaciteit hebt, reserveer dan 4 x 1 = 4 TB.

Note

In clusters met stations van alle drie de typen (NVMe + SSD + HDD), raden we u aan om het equivalent van één SSD plus één HDD per server te reserveren, maximaal 4 stations van elk.

Voorbeeld: Capaciteitsplanning

Overweeg een cluster met vier servers. Elke server heeft een aantal cachestations plus zestien stations van 2 TB voor capaciteit.

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

Vanaf deze 128 TB in de opslaggroep zetten we vier schijven, of 8 TB, opzij, zodat in-place reparaties kunnen plaatsvinden zonder haast schijven te vervangen nadat ze uitvallen. Dit laat 120 TB fysieke opslagcapaciteit in de pool over, waarmee we volumes kunnen maken.

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

Stel dat we onze implementatie nodig hebben om een aantal zeer actieve Hyper-V virtuele machines te hosten, maar we hebben ook veel koude opslag: oude bestanden en back-ups die we moeten behouden. Omdat we vier servers hebben, gaan we vier volumes maken.

Let's put the virtual machines on the first two volumes, Volume1 and Volume2. We kiezen ReFS als bestandssysteem (voor de snellere creatie en controlepunten) en spiegeling in drie richtingen voor tolerantie om de prestaties te maximaliseren. Let's put the cold storage on the other two volumes, Volume 3 and Volume 4. We kiezen NTFS als bestandssysteem (voor gegevensontdubbeling) en dubbele pariteit voor tolerantie om de capaciteit te maximaliseren.

We hoeven niet alle volumes dezelfde grootte te geven, maar voor het gemak kunnen we ze bijvoorbeeld allemaal 12 TB maken.

Volume1 and Volume2 each occupy 12 TB x 33.3 percent efficiency = 36 TB of physical storage capacity.

Volume3 and Volume4 each occupy 12 TB x 50.0 percent efficiency = 24 TB of physical storage capacity.

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

De vier volumes passen precies op de fysieke opslagcapaciteit die beschikbaar is in onze pool. Perfect!

Tip

U hoeft niet meteen alle volumes te maken. U kunt volumes altijd uitbreiden of later nieuwe volumes maken.

Voor het gemak worden in dit voorbeeld decimale eenheden (grondtal 10) gebruikt, wat betekent dat 1 TB = 1.000.000.000.000 bytes. Opslaghoeveelheden in Windows worden echter weergegeven in binaire eenheden (basis-2). Elke 2 TB schijf wordt bijvoorbeeld weergegeven als 1,82 TiB in Windows. Op dezelfde manier zou de opslaggroep van 128 TB worden weergegeven als 116,41 TiB. Dit wordt verwacht.

Usage

See Creating volumes.

Next steps

Zie ook voor meer informatie:

• Schijven kiezen voor Storage Spaces Direct
• Fouttolerantie en opslagefficiëntie