Prestatieoverwegingen voor gegevensopslag in Azure VMware Solution voor Azure NetApp Files

Artikel
03/25/2024

Dit artikel bevat prestatieoverwegingen voor het ontwerp en de grootte van het gegevensarchief van Azure VMware Solution bij gebruik met Azure NetApp Files. Deze inhoud is van toepassing op een virtualisatiebeheerder, cloudarchitect of opslagarchitect.

De overwegingen die in dit artikel worden beschreven, helpen u bij het bereiken van de hoogste prestatieniveaus van uw toepassingen met geoptimaliseerde kostenefficiëntie.

Azure NetApp Files biedt een direct schaalbare, krachtige en zeer betrouwbare opslagservice voor Azure VMware Solution. De tests bevatten verschillende configuraties tussen Azure VMware Solution en Azure NetApp Files. De tests konden meer dan 10.500 MiB/s en meer dan 585.000 invoer-/uitvoerbewerkingen per seconde (IOPS) met slechts vier Azure VMware Solution/ESXi-hosts en één Azure NetApp Files-capaciteitspool besturen.

Hogere opslagprestaties voor Azure VMware Solution met behulp van Azure NetApp Files

Het inrichten van meerdere, mogelijk grotere gegevensarchieven op één serviceniveau kan minder kosten en tegelijkertijd betere prestaties bieden. De reden hiervoor is dat de belasting over meerdere TCP-streams van Azure VMware Solution-hosts naar verschillende gegevensarchieven wordt verdeeld. U kunt het Azure NetApp Files-gegevensarchief voor Azure VMware Solution TCO Estimator gebruiken om potentiële kostenbesparingen te berekenen door een RVTools-rapport te uploaden of handmatige gemiddelde VM-grootte in te voeren.

Wanneer u bepaalt hoe u gegevensarchieven configureert, is de eenvoudigste oplossing vanuit het oogpunt van beheer het maken van één Azure NetApp Files-gegevensarchief, het koppelen ervan en het plaatsen van al uw VM's. Deze strategie werkt goed voor veel situaties, totdat meer doorvoer of IOPS is vereist. Om de verschillende grenzen te identificeren, gebruikten de tests een synthetische workloadgenerator, het programma fio , om een reeks workloads voor elk van deze scenario's te evalueren. Met deze analyse kunt u bepalen hoe u Azure NetApp Files-volumes inricht als gegevensarchieven om de prestaties te maximaliseren en de kosten te optimaliseren.

Voordat u begint

Zie voor prestatiegegevens van Azure NetApp Files:

Azure NetApp Files: optimaal profiteren van uw cloudopslag

Op een Azure VMware Solution-host wordt één netwerkverbinding tot stand gebracht per NFS-gegevensarchief dat vergelijkbaar is met het gebruik van nconnect=1 de Linux-tests waarnaar wordt verwezen in sectie 6 (De afstemmingsopties). Dit is belangrijk om te begrijpen hoe De prestaties van Azure VMware Solution zo goed worden geschaald in meerdere gegevensarchieven.
Prestatiebenchmarks voor azure NetApp Files-gegevensopslag voor Azure VMware Solution

Testmethodologie

In deze sectie wordt de methodologie beschreven die wordt gebruikt voor de tests.

Testscenario's en iteraties

Deze test volgt de methodologie 'vier hoeken', waaronder zowel leesbewerkingen als schrijfbewerkingen voor elke sequentieel en willekeurige invoer/uitvoer (IO). De variabelen van de tests omvatten een-op-veel Azure VMware Solution-hosts, Azure NetApp Files-gegevensarchieven, VM's (per host) en VM-schijven (VMDK's) per VM. De volgende schaalgegevenspunten zijn geselecteerd om de maximale doorvoer en IOPS voor de opgegeven scenario's te vinden:

VMDK's schalen, elk op hun eigen gegevensarchief voor één VIRTUELE machine.
Het aantal VM's per host schalen in één Azure NetApp Files-gegevensarchief.
Het schalen van het aantal Azure VMware Solution-hosts, elk met één VM die één Azure NetApp Files-gegevensarchief deelt.
Het schalen van het aantal Azure NetApp Files-gegevensarchieven, elk met één VMDK gelijkmatig verdeeld over Azure VMware Solution-hosts.

Het testen van zowel kleine als grote blokbewerkingen en het doorlopen van opeenvolgende en willekeurige workloads zorgt ervoor dat alle onderdelen in de reken-, opslag- en netwerkstacks naar de 'edge' worden getest. Om de vier hoeken met blokgrootte en randomisatie te bedekken, worden de volgende veelgebruikte combinaties gebruikt:

64 KB sequentiële tests
- Grote werkbelastingen voor het streamen van bestanden worden vaak gelezen en geschreven in grote blokgrootten, evenals de standaardgrootte van MSSQL.
- Grote bloktests produceren doorgaans de hoogste doorvoer (in MiB/s).
8 KB willekeurige tests
- Deze instelling is de veelgebruikte blokgrootte voor databasesoftware, waaronder software van Microsoft, Oracle en PostgreSQL.
- Kleine bloktests produceren doorgaans het hoogste aantal IOPS.

Notitie

In dit artikel wordt alleen het testen van Azure NetApp Files behandeld. Het omvat niet de vSAN-opslag die is opgenomen in Azure VMware Solution.

Omgevingsdetails

De resultaten in dit artikel zijn bereikt met behulp van de volgende omgevingsconfiguratie:

Azure VMware Solution-hosts:
- Grootte: AV36
- Aantal hosts: 4
- VMware ESXi versie 7u3
Azure VMware Solution-privécloudconnectiviteit: UltraPerformance-gateway met FastPath
Gast-VM's:
- Besturingssysteem: Ubuntu 20.04
- CPU's/geheugen: 16 vCPU/64 GB geheugen
- Virtuele LSI SAS SCSI-controller met 16 GB besturingssysteemschijf in Azure VMware Solution vSAN-gegevensopslag
- Paravirtuele SCSI-controller voor test-VMDK's
- LVM-/schijfconfiguraties:
  - Eén fysiek volume per schijf
  - Eén volumegroep per fysiek volume
  - Eén logische partitie per volumegroep
  - Eén XFS-bestandssysteem per logische partitie
Azure VMware Solution to Azure NetApp Files-protocol: NFS versie 3
Workloadgenerator: fio versie 3.16
Fio-scripts: fio-parser

Testresultaten

In deze sectie worden de resultaten van de uitgevoerde tests beschreven.

Schalen met één VM

Wanneer u opslag in een gegevensarchief configureert op een virtuele machine van Azure VMware Solution, moet u rekening houden met de impact van de indeling van het bestandssysteem. Het configureren van meerdere VMDK's verspreid over meerdere gegevensarchieven biedt de hoogste hoeveelheden beschikbare bandbreedte. Het configureren van een-op-veel VMDK's die in één gegevensarchief worden geplaatst, zorgt voor de grootste eenvoud als het gaat om back-ups en DR-bewerkingen, maar ten koste van een lager prestatiemaximum. De empirische gegevens in dit artikel helpen u bij de beslissingen.

Om de prestaties te maximaliseren, is het gebruikelijk om één VIRTUELE machine te schalen op meerdere VMDK's en deze VMDK's in meerdere gegevensarchieven te plaatsen. Eén VIRTUELE machine met slechts één of twee VMDK's kan worden beperkt door één NFS-gegevensarchief, omdat deze wordt gekoppeld via één TCP-verbinding met een bepaalde Azure VMware Solution-host.

Technici richten bijvoorbeeld vaak een VMDK in voor een databaselogboek en richten vervolgens een-op-veel VMDK's in voor databasebestanden. Met meerdere VMDK's zijn er twee opties. De eerste optie is het gebruik van elke VDMK als een afzonderlijk bestandssysteem. De tweede optie is het gebruik van een hulpprogramma voor opslagbeheer, zoals LVM, MSSQL-bestandsgroepen of Oracle ASM om IO te verdelen door striping over VMDK's. Wanneer VMDK's worden gebruikt als afzonderlijke bestandssystemen, is het distribueren van workloads over meerdere gegevensarchieven een handmatige inspanning en kan het lastig zijn. Het gebruik van hulpprogramma's voor opslagbeheer om de bestanden over VMDK's te verspreiden, maakt schaalbaarheid van workloads mogelijk.

Als u volumes over meerdere schijven stript, moet u ervoor zorgen dat de back-upsoftware of noodherstelsoftware ondersteuning biedt voor het maken van back-ups van meerdere virtuele schijven tegelijk. Omdat afzonderlijke schrijfbewerkingen over meerdere schijven worden gestreept, moet het bestandssysteem ervoor zorgen dat schijven 'geblokkeerd' zijn tijdens momentopname- of back-upbewerkingen. De meeste moderne bestandssystemen bevatten een bevriezen of momentopnamebewerking zoals xfs (xfs_freeze) en NTFS (volumeschaduwkopieën), waarvan back-upsoftware kan profiteren.

Als u wilt weten hoe goed één virtuele Azure VMware Solution-VM wordt geschaald naarmate er meer virtuele schijven worden toegevoegd, zijn tests uitgevoerd met één, twee, vier en acht gegevensarchieven (elk met één VMDK). In het volgende diagram ziet u één schijf met een gemiddelde van ongeveer 73.040 IOPS (schalen van 100% schrijven /0% lezen, tot 0% schrijven/100% lezen). Toen deze test werd verhoogd tot twee stations, verbeterde de prestaties met 75,8% tot 128.420 IOPS. Het verhogen tot vier stations begon te laten zien dat er minder retourneert van wat een enkele VIRTUELE machine, waarvan de grootte is getest, zou kunnen pushen. De waargenomen piek-IOPS waren 147.000 IOPS met 100% willekeurige leesbewerkingen.

Schalen met één host : één gegevensarchief

Het schaalt slecht om het aantal VM's te verhogen dat IO naar één gegevensarchief van één host leidt. Dit is het gevolg van de enkele netwerkstroom. Wanneer de maximale prestaties voor een bepaalde workload worden bereikt, is dit vaak het resultaat van één wachtrij die onderweg wordt gebruikt naar het individuele NFS-gegevensarchief van de host via één TCP-verbinding. Met behulp van een blokgrootte van 8 kB steeg het totale aantal IOPS tussen 3% en 16% bij het schalen van één VM met één VMDK naar vier VM's met 16 VMDK's (vier per VM, allemaal in één gegevensarchief).

Het verhogen van de blokgrootte (tot 64 kB) voor grote blokworkloads had vergelijkbare resultaten, waardoor een piek van 2148 MiB/s (één VM, één VMDK) en 2138 MiB/s (4 VM's, 16 VMDK's) werd bereikt.

Schalen met één host : meerdere gegevensarchieven

Vanuit de context van één Azure VMware Solution-host, terwijl één gegevensarchief de VM's toestaat om ongeveer 76.000 IOPS te besturen, hebben de workloads over twee gegevensarchieven de totale doorvoer gemiddeld met 76% verhoogd. Het verplaatsen van meer dan twee gegevensarchieven naar vier heeft geresulteerd in een toename van 163% (meer dan één gegevensarchief, een toename van 49% van twee tot vier), zoals wordt weergegeven in het volgende diagram. Hoewel er nog steeds prestatieverbeteringen waren, vertoonden meer dan acht gegevensarchieven afnemende rendementen.

Schalen met meerdere hosts : één gegevensarchief

Eén gegevensarchief van één host die meer dan 2000 MiB/s van sequentiële doorvoer van 64 KB heeft geproduceerd. Door dezelfde workload over alle vier hosts te distribueren, is een piekwinst van 135% bereikt die meer dan 5000 MiB/s berijdt. Dit resultaat vertegenwoordigt waarschijnlijk het bovenste plafond van één Azure NetApp Files-volumedoorvoerprestaties.

Het verkleinen van de blokgrootte van 64 kB tot 8 kB en het opnieuw uitvoeren van dezelfde iteraties heeft geresulteerd in vier VM's die 195.000 IOPS produceren, zoals in het volgende diagram wordt weergegeven. De prestaties worden geschaald naarmate zowel het aantal hosts als het aantal gegevensarchieven toeneemt, omdat het aantal netwerkstromen toeneemt. De prestaties nemen toe door het aantal hosts te schalen dat wordt vermenigvuldigd met het aantal gegevensarchieven, omdat het aantal netwerkstromen een factor is van hosts die vaak gegevensarchieven hebben.

Schalen met meerdere hosts - Meerdere gegevensarchieven

Eén gegevensarchief met vier VM's verspreid over vier hosts die meer dan 5000 MiB/s van 64 KB IO hebben geproduceerd. Voor veeleisendere workloads wordt elke VIRTUELE machine verplaatst naar een toegewezen gegevensarchief, dat in totaal meer dan 10.500 MiB/s produceert, zoals wordt weergegeven in het volgende diagram.

Voor kleine blok-, willekeurige workloads heeft één gegevensarchief 195.000 willekeurige IOPS van 8 KB geproduceerd. Schalen naar vier gegevensarchieven die meer dan 530.000 willekeurige 8.000 IOPS hebben geproduceerd.

Gevolgen en aanbevelingen

In deze sectie wordt beschreven waarom het spreiden van uw VM's in meerdere gegevensarchieven aanzienlijke prestatievoordelen heeft.

Zoals wordt weergegeven in de testresultaten, zijn de prestatiemogelijkheden van Azure NetApp Files overvloedig:

Testen laten zien dat één gegevensarchief een gemiddelde ~148.980 IOPS of ~4147 MiB/s met 64 KB IOPS (gemiddeld van alle schrijf%/lees% tests) van een configuratie met vier hosts kan besturen.
Eén VM in één gegevensarchief :
- Als u afzonderlijke VM's hebt die mogelijk meer dan ~75K 8-KB IOPS of meer dan ~1700 MiB/s nodig hebben, verspreidt u de bestandssystemen over meerdere VMDK's om de opslagprestaties van vm's te schalen.
Eén VIRTUELE machine in meerdere gegevensarchieven: één VM in 8 gegevensarchieven heeft een blokgrootte van 147.000 8 KB of ~2786 MiB/s met een blokgrootte van 64 kB bereikt.
Eén host: elke host kon een gemiddelde ~198.060 IOPS of ~2351 MiB/s ondersteunen als u ten minste 4 VM's per host gebruikt met ten minste 4 Azure NetApp Files-gegevensarchieven. U hebt dus de mogelijkheid om voldoende gegevensarchieven in te richten voor maximale, potentieel bursting, prestaties, versus complicatie van beheer en kosten.

Aanbevelingen

Wanneer de prestatiemogelijkheden van één gegevensarchief onvoldoende zijn, verspreidt u uw VM's over meerdere gegevensarchieven om nog verder te schalen. Eenvoud is vaak het beste, maar prestaties en schaalbaarheid kunnen de toegevoegde maar beperkte complexiteit rechtvaardigen.

Vier Azure NetApp Files-gegevensarchieven bieden maximaal 10 GBps bruikbare bandbreedte voor grote opeenvolgende IO of de mogelijkheid om maximaal 500K 8K willekeurige IOPS te stimuleren. Hoewel één gegevensarchief mogelijk voldoende is voor veel prestatiebehoeften, moet u voor de beste prestaties beginnen met minimaal vier gegevensarchieven.

Voor gedetailleerde prestaties afstemmen maken zowel Windows- als Linux-gastbesturingssystemen striping over meerdere schijven mogelijk. Als zodanig moet u bestandssystemen stripe over meerdere VMDK's verspreid over meerdere gegevensarchieven. Als de consistentie van momentopnamen van toepassingen echter een probleem is en niet kan worden opgelost met LVM of opslagruimten, kunt u Azure NetApp Files koppelen vanuit het gastbesturingssysteem of schalen op toepassingsniveau onderzoeken, waarvan Azure veel goede opties heeft.

Als u volumes over meerdere schijven stript, moet u ervoor zorgen dat de back-upsoftware of noodherstelsoftware ondersteuning biedt voor het maken van back-ups van meerdere virtuele schijven tegelijk. Omdat afzonderlijke schrijfbewerkingen over meerdere schijven worden gestreept, moet het bestandssysteem ervoor zorgen dat schijven 'geblokkeerd' zijn tijdens de momentopname- of back-upbewerkingen. De meeste moderne bestandssystemen bevatten een bevriezen of momentopnamebewerking zoals xfs (xfs_freeze) en NTFS (volumeschaduwkopieën), waarvan back-upsoftware kan profiteren.

Omdat Azure NetApp Files in rekening wordt gebracht voor ingerichte capaciteit in de capaciteitspool in plaats van toegewezen capaciteit (gegevensarchieven), betaalt u bijvoorbeeld hetzelfde voor gegevensarchieven van 4x20 TB of 20x4 TB aan gegevensarchieven. Als dat nodig is, kunt u de capaciteit en prestaties van gegevensarchieven op aanvraag dynamisch aanpassen via de Azure API/console.

Als u bijvoorbeeld het einde van een fiscaal jaar nadert, zult u merken dat u meer opslagprestaties nodig hebt in het Standard-gegevensarchief. U kunt het serviceniveau van het gegevensarchief voor een maand verhogen om ervoor te zorgen dat alle VM's in die gegevensarchieven meer prestaties beschikbaar hebben, terwijl andere gegevensarchieven op een lager serviceniveau worden onderhouden. U bespaart niet alleen kosten, maar krijgt meer prestaties door workloads te laten verspreiden over meer TCP-verbindingen tussen elk gegevensarchief en elke AVS-host.

U kunt de metrische gegevens van uw gegevensarchief bewaken via vCenter Server of via de Azure API/Console. Vanuit vCenter Server kunt u de geaggregeerde gemiddelde IOPS van een gegevensarchief bewaken in de prestatie-/geavanceerde grafieken , zolang u opslag-I/O-controlegegevensverzameling inschakelt in het gegevensarchief. De Azure-API en -console bevatten metrische gegevens voorWriteIops, ReadIopsenReadThroughput, onder WriteThroughputandere, om uw workloads te meten op het niveau van het gegevensarchief. Met metrische gegevens van Azure kunt u waarschuwingsregels instellen met acties om het formaat van een gegevensarchief automatisch te wijzigen via een Azure-functie, een webhook of andere acties.

Delen via