Volumes plannen 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.
Notitie
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.
Controleren: Wat zijn volumes?
Volumes zijn de plaats waar u de bestanden plaatst die uw workloads nodig hebben, zoals VHD- of VHDX-bestanden voor virtuele Hyper-V-machines. Volumes combineren de stations in de opslaggroep om fouttolerantie, schaalbaarheid en prestatievoordelen te introduceren van Opslagruimten Direct, de softwaregedefinieerde opslagtechnologie achter Azure Stack HCI en Windows Server.
Notitie
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 succesvol te plannen en implementeren.
Alle volumes zijn tegelijkertijd toegankelijk voor alle servers in het cluster. Zodra ze zijn gemaakt, worden ze weergegeven op C:\ClusterStorage\ op alle 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 'eigendom' distribueren (één server verwerkt metagegevensindeling voor elk volume) gelijkmatig over servers.
U wordt aangeraden het totale aantal volumes te beperken tot 64 volumes per cluster.
Het bestandssysteem kiezen
We raden u aan om 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 stations- of serverfouten, en om continue beschikbaarheid mogelijk te maken tijdens serveronderhoud, zoals software-updates.
Notitie
Welke tolerantietypen u kunt kiezen, is onafhankelijk van welke typen stations u hebt.
Met twee servers
Met twee servers in het cluster kunt u spiegeling in twee richtingen gebruiken of geneste tolerantie gebruiken.
Spiegeling in twee richtingen bewaart twee kopieën van alle gegevens, één kopie op de stations op 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 tolereren (één server of station).
Geneste tolerantie biedt gegevenstolerantie tussen servers met spiegeling in twee richtingen en voegt vervolgens tolerantie toe binnen een server met spiegeling in twee richtingen of pariteit met versnelling op basis van spiegeling. Nesten biedt gegevenstolerantie, zelfs wanneer één server opnieuw wordt opgestart of niet beschikbaar is. De opslagefficiëntie is 25 procent met geneste spiegeling in twee richtingen en ongeveer 35-40 procent voor geneste pariteit met gespiegelde versnelling. Geneste tolerantie kan veilig twee hardwarefouten tegelijk tolereren (twee stations of een server en een station op de resterende server). Vanwege deze toegevoegde gegevenstolerantie raden we u aan geneste tolerantie te gebruiken voor productie-implementaties van clusters met twee servers. Zie Geneste tolerantie voor meer informatie.
Met drie servers
Met drie servers moet u spiegeling in drie richtingen gebruiken voor betere fouttolerantie en prestaties. Spiegeling in drie richtingen bewaart drie kopieën van alle gegevens, één kopie op de stations op 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 spiegeling in drie richtingen, dubbele pariteit (ook wel 'erasure coding' genoemd) wilt gebruiken of de twee wilt combineren met pariteit met versnelling op basis van spiegeling.
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 u wilt gebruiken, is afhankelijk van de behoeften van uw workload. Hier volgt een tabel waarin wordt samengevat welke workloads geschikt zijn voor elk tolerantietype en de prestaties en opslagefficiëntie van elk tolerantietype.
| Tolerantietype | Capaciteitsefficiëntie | Snelheid | Workloads |
|---|---|---|---|
| Spiegel |  Spiegel in drie richtingen: 33% Tweerichtingsspiegeling: 50% |
 Hoogste prestaties |
Gevirtualiseerde workloads Databases Andere workloads met hoge prestaties |
| Pariteit met versnelling met spiegeling |  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 |
Archivering en back-up Gevirtualiseerde bureaubladinfrastructuur |
| Dubbele pariteit |  4 servers: 50% 16 servers: tot 80% |
 Hoogste I/O-latentie en CPU-gebruik voor schrijfbewerkingen Geschikt voor grote sequentiële schrijf- en leesbewerkingen |
Archivering en back-up Gevirtualiseerde bureaubladinfrastructuur |
Wanneer de prestaties het belangrijkst zijn
Workloads met strikte latentievereisten of die veel gemengde willekeurige IOPS nodig hebben, zoals SQL Server-databases of prestatiegevoelige Hyper-V-vm's, moeten worden uitgevoerd op volumes die gebruikmaken van spiegeling om de prestaties te maximaliseren.
Tip
Spiegeling is sneller dan elk ander tolerantietype. 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), VDI (Virtual Desktop Infrastructure) of andere die niet veel snel afwijkend willekeurig IO-verkeer maken en/of waarvoor de beste prestaties niet nodig zijn, kunnen naar eigen goeddunken ook dubbele pariteit gebruiken. 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 implementaties met NVMe, SSD en HDD
In implementaties met twee typen stations bieden de snellere stations caching terwijl de tragere stations 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 stations: de capaciteitsstations.
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.
Belangrijk
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 goed tot 32 TB en hoger.
Voetafdruk
De grootte van een volume verwijst naar de bruikbare capaciteit, de hoeveelheid gegevens die het kan opslaan. Dit wordt geleverd door de parameter -Size van de cmdlet New-Volume en wordt vervolgens weergegeven in de eigenschap Grootte wanneer u de cmdlet Get-Volume uitvoert.
De grootte verschilt van de voetafdruk van het volume, de totale fysieke opslagcapaciteit die deze in beslag neemt voor de opslaggroep. De footprint is afhankelijk van het tolerantietype. Volumes die gebruikmaken van spiegeling in drie richtingen hebben bijvoorbeeld drie keer hun grootte.
De footprints van uw volumes moeten in de opslaggroep passen.
Reservecapaciteit
Als sommige capaciteit in de opslaggroep niet is toegewezen, is er ruimte voor volumes om 'in-place' te herstellen nadat stations mislukken, waardoor de veiligheid en prestaties van gegevens worden verbeterd. Als er voldoende capaciteit is, kan parallel herstel volumes direct en in-place herstellen tot volledige tolerantie, zelfs voordat de mislukte stations 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 mislukken 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 1 TB capaciteitsstations hebt, moet u 4 x 1 = 4 TB reserveren.
Notitie
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 stations of 8 TB opzij, zodat in-place reparaties kunnen plaatsvinden zonder haast stations te vervangen nadat ze mislukken. 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 Virtuele Hyper-V-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.
Laten we de virtuele machines op de eerste twee volumes, Volume1 en Volume2, plaatsen. We kiezen ReFS als bestandssysteem (voor de snellere creatie en controlepunten) en spiegeling in drie richtingen voor tolerantie om de prestaties te maximaliseren. Laten we de koude opslag op de andere twee volumes, Volume 3 en Volume 4 plaatsen. 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 en Volume2 nemen elk 12 TB x 33,3 procent efficiëntie in beslag = 36 TB aan fysieke opslagcapaciteit.
Volume3 en Volume4 nemen elk 12 TB x 50,0 procent efficiëntie in beslag = 24 TB aan fysieke opslagcapaciteit.
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). Elk station van 2 TB 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 is normaal.
Gebruik
Zie Volumes maken in Azure Stack HCI.
Volgende stappen
Zie ook voor meer informatie: