Volumes plannen op Azure Stack HCI en Windows Server-clusters

  • Artikel
  • 11 minuten om te lezen

Van toepassing op: Azure Stack HCI, versies 21H2 en 20H2; 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, waaronder het kiezen van het bestandssysteem, het tolerantietype en de grootte.

Controleren: Wat zijn volumes?

Volumes zijn de plaatsen waar u de bestanden die nodig zijn voor uw workloads, zoals VHD- of VHDX-bestanden voor virtuele Hyper-V-machines. Volumes combineren de stations in de opslaggroep om de fouttolerantie, schaalbaarheid en prestatievoordelen te introduceren van Opslagruimten Direct,de software-gedefinieerde opslagtechnologie achter Azure Stack HCI.

Notitie

We gebruiken de term 'volume' om gezamenlijk te verwijzen naar het volume en de virtuele schijf daar onder, inclusief functionaliteit die wordt geleverd door andere ingebouwde Windows-functies, zoals gedeelde clustervolumes (CSV) en ReFS. Kennis van deze verschillen op implementatieniveau is niet nodig om de implementatie van Opslagruimten Direct te laten verlopen.

Diagram toont drie mappen die zijn gelabeld als volumes die elk zijn gekoppeld aan een virtuele schijf met het label volumes, die allemaal zijn gekoppeld aan een gemeenschappelijke opslaggroep met schijven.

Alle volumes zijn op hetzelfde moment toegankelijk voor alle servers in het cluster. Zodra ze zijn gemaakt, worden ze op alle servers op C:\ClusterStorage\ weer geven.

Schermopname van een verkennervenster met de titel ClusterStorage met volumes met de naam Volume1, Volume2 en Volume3.

Kiezen hoeveel volumes u wilt maken

We raden u aan om van het aantal volumes een veelvoud van het aantal servers in uw cluster te maken. Als u bijvoorbeeld 4 servers hebt, zult u consistentere prestaties ervaren met 4 totaalvolumes dan met 3 of 5. Hierdoor kan het cluster het 'eigendom' van het volume verdelen (één server verwerkt de metagegevens indelen voor elk volume) gelijkmatig over servers.

We raden u aan het totale aantal volumes te beperken tot 64 volumes per cluster.

Het bestandssysteem kiezen

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

Als uw workload een functie vereist die ReFS nog niet ondersteunt, 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 in te stellen tijdens serveronderhoud, zoals software-updates.

Notitie

Welke tolerantietypen u kunt kiezen, is onafhankelijk van de typen stations die u hebt.

Met twee servers

Met twee servers in het cluster kunt u mirroring in twee punten gebruiken of geneste tolerantie gebruiken.

Mirroring in twee delen 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. Mirroring in twee punten kan veilig één hardwarefout tegelijk tolereren (één server of station).

Diagram toont volumes met gelabelde gegevens en kopieën die zijn verbonden met cirkelvormige pijlen en beide volumes zijn gekoppeld aan een bank schijven in servers.

Geneste tolerantie biedt gegevens resiliency tussen servers met mirroring in twee delen en voegt vervolgens tolerantie toe binnen een server met mirroring in twee of mirror-accelerated pariteit. Nesten biedt gegevens tolerantie, zelfs wanneer een server opnieuw wordt opgestart of niet beschikbaar is. De opslagefficiëntie is 25 procent met geneste mirroring in twee punten en ongeveer 35-40 procent voor geneste mirror-versnelde pariteit. Geneste tolerantie kan veilig twee hardwarefouten tegelijk tolereren (twee stations of een server en een station op de resterende server). Vanwege deze toegevoegde gegevens resilience raden we u aan geneste tolerantie te gebruiken in productie-implementaties van clusters met twee servers. Zie Geneste tolerantie voor meer informatie.

Diagram toont geneste versnelde gespiegelde pariteit met mirror in twee punten tussen servers die zijn gekoppeld aan een mirror in twee punten binnen elke server die overeenkomt met een pariteitslaag binnen elke server.

Met drie servers

Met drie servers moet u mirroring in drie punten gebruiken voor betere fouttolerantie en betere prestaties. Mirroring in drie delen 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 aan fysieke opslagcapaciteit in de opslaggroep nodig. Mirroring in drie punten kan veilig ten minste twee hardwareproblemen (station of server) tegelijk tolereren. Als twee knooppunten niet meer beschikbaar zijn, verliest de opslaggroep het quorum, omdat 2/3 van de schijven niet beschikbaar zijn en de virtuele schijven niet toegankelijk zijn. Een knooppunt kan echter niet actief zijn en een of meer schijven op een ander knooppunt kunnen mislukken en de virtuele schijven blijven online. Als u bijvoorbeeld één server opnieuw opstart wanneer plotseling een ander station of server uitvalt, blijven alle gegevens veilig en continu toegankelijk.

Diagram met een volume met gelabelde gegevens en twee gelabelde kopieën die zijn verbonden met cirkelvormige pijlen met elk volume dat is gekoppeld aan een server met fysieke schijven.

Met vier of meer servers

Met vier of meer servers kunt u voor elk volume kiezen of u mirroring in drie punten, dubbele pariteit (ook wel 'erasure coding' genoemd) wilt gebruiken of de twee wilt combineren met mirror-accelerated pariteit.

Dubbele pariteit biedt dezelfde fouttolerantie als mirroring in drie punten, 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 in de opslaggroep nodig. Dit verhoogt de opslagefficiëntie van 66,7 procent met zeven servers en gaat door met een opslagefficiëntie van maximaal 80,0 procent. Het afweging is dat pariteitscoderen rekenintensief is, waardoor de prestaties kunnen worden beperkt.

Diagram toont twee volumes met gelabelde gegevens en twee gelabelde pariteit verbonden door cirkelvormige pijlen met elk volume dat is gekoppeld aan een server met fysieke schijven.

Welk tolerantietype moet worden gebruikt, is afhankelijk van de behoeften van uw workload. Hier volgt een tabel waarin wordt samengevat welke workloads geschikt zijn voor elk tolerantietype, evenals de prestaties en opslagefficiëntie van elk tolerantietype.

Tolerantietype Capaciteitsefficiëntie Snelheid Workloads
Mirror Storage efficiëntie met 33%
Mirror in drie punten: 33%
Mirror in twee punten: 50%		 Prestaties met 100%
Hoogste prestaties		 Gevirtualiseerde workloads
Databases
Andere workloads met hoge prestaties
Gespiegelde pariteit Storage efficiëntie van ongeveer 50%
Afhankelijk van het aandeel mirror en pariteit		 Prestaties van ongeveer 20%
Veel langzamer dan spiegelen, maar maximaal twee keer zo snel als dubbele pariteit
Het beste voor grote sequentiële schrijf- en leesinzichten		 Archivering en back-up
Gevirtualiseerde desktopinfrastructuur
Dubbele pariteit Storage efficiëntie van ongeveer 80%
4 servers: 50%
16 servers: maximaal 80%		 Prestaties van ongeveer 10%
Cpu-gebruik met hoogste & I/O-latentie bij schrijf schrijf schrijfgegevens
Het beste voor grote sequentiële schrijf- en leesinzichten		 Archivering en back-up
Gevirtualiseerde desktopinfrastructuur

Wanneer prestaties het belangrijkst zijn

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

Tip

Spiegelen gaat sneller dan elk ander tolerantietype. We gebruiken mirroring voor bijna al onze prestatievoorbeelden.

Wanneer capaciteit het belangrijkst is

Workloads die niet vaak schrijven, zoals datawarehouses of 'koude' opslag, moeten worden uitgevoerd op volumes die gebruikmaken van dubbele pariteit om de efficiëntie van de opslag te maximaliseren. Bepaalde andere werkbelastingen, zoals traditionele bestandsservers, VDI (Virtual Desktop Infrastructure) of andere die niet veel sneldriftende willekeurige I/O-verkeer maken en/of niet de beste prestaties vereisen, kunnen naar eigen goedheid ook gebruikmaken van dubbele pariteit. Pariteit verhoogt onvermijdelijk het CPU-gebruik en de I/O-latentie, met name bij schrijfingen, in vergelijking met spiegeling.

Wanneer gegevens bulksgewijs worden geschreven

Werkbelastingen die grote, sequentiële gegevens schrijven, zoals archiverings- of back-updoelen, hebben een andere optie: één volume kan mirroring en dubbele pariteit combineren. Schrijft land eerst in het gespiegelde gedeelte en worden later geleidelijk verplaatst naar het pariteitsgedeelte. Dit versnelt de opname en vermindert het resourcegebruik wanneer grote schrijf schrijfingen binnenkomen doordat de berekeningsintensieve pariteitscoderen over een langere periode kan plaatsvinden. Houd er bij het aanpassen van de formaatgrootte van de gedeelten rekening mee dat de hoeveelheid schrijfingen die in één keer plaatsvinden (zoals één dagelijkse back-up) in het mirror-gedeelte past. Als u bijvoorbeeld 100 GB per dag opeet, kunt u overwegen om mirroring 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. Zie deze demo voor enkele voorbeelden.

Tip

Als u een plotselinge afname in schrijfprestaties ziet via gegevensingestie, kan dit erop wijzen dat het mirror-gedeelte niet groot genoeg is of dat mirror-versnelde pariteit niet geschikt is voor uw use-case. Als de schrijfprestaties bijvoorbeeld afnemen van 400 MB/s tot 40 MB/s, kunt u overwegen het mirror-gedeelte uit te breiden of over te schakelen naar mirror in drie stappen.

Over implementaties met NVMe, SSD en HDD

In implementaties met twee typen stations bieden de snellere stations caching terwijl de langzamere 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 er twee typen schijven (SSD en HDD) over zijn om capaciteit te bieden. Voor elk volume kunt u kiezen of het zich volledig op de SSD-laag bevindt, volledig op de HDD-laag, of dat deze de twee omvat.

Belangrijk

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

De grootte van volumes kiezen

U kunt het beste de grootte van elk volume beperken tot 64 TB in Windows Server 2019.

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 werkbelastingen van bestandsservers, verbetert het beperken van de volumegrootte tot 10 TB de prestaties en betrouwbaarheid. Back-upoplossingen die gebruikmaken van de nieuwere Hyper-V RCT API en/of ReFS-blok klonen en/of de systeemeigen SQL-back-up-API's presteren goed tot maximaal 32 TB en daarna.

Voetafdruk

De grootte van een volume verwijst naar de bruikbaar capaciteit, de hoeveelheid gegevens die kan worden opgeslagen. Dit wordt geleverd door de parameter -Size van de cmdlet New-Volume en wordt vervolgens weergegeven in de eigenschap Size wanneer u de cmdlet Get-Volume uitvoeren.

De grootte verschilt van de footprint van hetvolume, de totale fysieke opslagcapaciteit die het in beslag neemt voor de opslaggroep. De footprint is afhankelijk van het tolerantietype. Volumes die gebruikmaken van mirroring in drie delen hebben bijvoorbeeld een footprint die drie keer zo groot is.

De footprints van uw volumes moeten in de opslaggroep passen.

Diagram met een volume van 2 TB vergeleken met een footprint van 6 TB in de opslaggroep met een vermenigvuldiger van drie opgegeven.

Capaciteit reserveren

Als u een deel van de capaciteit in de opslaggroep niet-toegewezen laat, krijgen volumes ruimte om 'in-place' te herstellen na het uitvallen van stations, waardoor de veiligheid en prestaties van de gegevens worden verbeterd. Als er voldoende capaciteit is, kan een onmiddellijke, in-place, parallelle reparatie volumes herstellen naar 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 goedheid meer reserveren, maar deze minimale aanbeveling garandeert een onmiddellijke, in-place, parallelle reparatie kan slagen na het uitvallen van een station.

Diagram met een volume dat is gekoppeld aan verschillende schijven in een opslaggroep en niet-gekoppelde schijven die als reserve zijn gemarkeerd.

Als u bijvoorbeeld twee servers hebt en u capaciteitsstations van 1 TB gebruikt, moet u 2 x 1 = 2 TB van de pool als reserve 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 het equivalent van één SSD plus één HDD per server te reserveren, maximaal 4 stations van elk.

Voorbeeld: Capaciteitsplanning

Overweeg één cluster met vier servers. Elke server heeft enkele cachestations plus 2 TB schijven voor capaciteit.

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

Van deze 128 TB in de opslaggroep hebben we vier stations gereserveerd, ofte wel 8 TB, zodat in-place reparaties kunnen plaatsvinden zonder enige druk om stations te vervangen nadat ze uitvallen. Hierdoor blijft er 120 TB aan fysieke opslagcapaciteit over in de pool 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 bewaren. Omdat we vier servers hebben, gaan we vier volumes maken.

Laten we de virtuele machines op de eerste twee volumes, Volume1 en Volume2, zetten. We kiezen ReFS als het bestandssysteem (voor het sneller maken en controlepunten) en mirroring in drie delen voor tolerantie om de prestaties te maximaliseren. Laten we de koude opslag op de andere twee volumes, Volume 3 en Volume 4, zetten. We kiezen NTFS als het bestandssysteem (voor gegevensverdubbeling) en dubbele pariteit voor tolerantie om de capaciteit te maximaliseren.

We zijn niet verplicht om alle volumes dezelfde grootte te geven, maar om het eenvoudig te houden, laten we ze bijvoorbeeld allemaal 12 TB maken.

Volume1 en Volume2 nemen elk een efficiëntie van 12 TB x 33,3 procent in beslag = 36 TB aan fysieke opslagcapaciteit.

Volume3 en Volume4 nemen elk een efficiëntie van 12 TB x 50,0 procent in beslag = 24 TB aan fysieke opslagcapaciteit.

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

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

Diagram toont twee mirrorvolumes van 12 TB in drie stappen die elk zijn gekoppeld aan 36 TB aan opslag en twee volumes van 12 TB voor dubbele pariteit die elk zijn gekoppeld aan 24 TB, die allemaal 120 TB in een opslaggroep in gebruik nemen.

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 (basis-10) gebruikt, wat betekent 1 TB = 1.000.000.000.000 bytes. Opslaghoeveelheden in Windows worden echter weergegeven in binaire eenheden (base-2). Elk station van 2 TB wordt bijvoorbeeld weergegeven als 1,82 TiB in Windows. Op dezelfde manier wordt de opslaggroep van 128 TB weergegeven als 116,41 TiB. Dit is normaal.

Gebruik

Zie Volumes maken in Azure Stack HCI.

Volgende stappen

Zie voor meer informatie ook: