DiskSPD gebruiken om de opslagprestaties van workloads te testen

Artikel
02/26/2024

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

In dit onderwerp vindt u richtlijnen voor het gebruik van DISKSPD om de prestaties van workloadopslag te testen. U hebt een Azure Stack HCI-cluster ingesteld en wilt aan de slag. Mooi. Maar hoe weet u of u de toegezegde prestatiemetrieken krijgt, of het nu gaat om latentie, doorvoer of IOPS? Dit is wanneer u mogelijk DISKSPD kunt gebruiken. Nadat u dit onderwerp hebt gelezen, weet u hoe u DISKSPD uitvoert, een subset van parameters begrijpt, uitvoer interpreteert en een algemeen inzicht krijgt in de variabelen die van invloed zijn op de prestaties van workloadopslag.

Wat is DISKSPD?

DISKSPD is een I/O-genererend opdrachtregelprogramma voor micro-benchmarking. Geweldig, dus wat betekenen al deze termen? Iedereen die een Azure Stack HCI-cluster of fysieke server instelt, heeft een reden. Dit kan zijn om een webhostingomgeving in te stellen of om virtuele bureaubladen voor werknemers uit te voeren. Wat het echte gebruiksscenario ook is, u wilt waarschijnlijk een test simuleren voordat u uw werkelijke toepassing implementeert. Het testen van uw toepassing in een echt scenario is echter vaak moeilijk: dit is waar DISKSPD van pas komt.

DISKSPD is een hulpprogramma dat u kunt aanpassen om uw eigen synthetische workloads te maken en uw toepassing vóór de implementatie te testen. Het leuke van het hulpprogramma is dat het u de vrijheid geeft om de parameters te configureren en aan te passen om een specifiek scenario te maken dat lijkt op uw echte workload. DISKSPD kan u een idee geven van waar uw systeem toe in staat is vóór de implementatie. In de kern geeft DISKSPD gewoon een aantal lees- en schrijfbewerkingen uit.

Nu weet u wat DISKSPD is, maar wanneer moet u het gebruiken? DISKSPD heeft het moeilijk om complexe workloads na te bootsen. Maar DISKSPD is geweldig wanneer uw workload niet nauw wordt benaderd door een bestandskopie met één thread en u een eenvoudig hulpprogramma nodig hebt dat acceptabele basislijnresultaten produceert.

Snel starten: DISKSPD installeren en uitvoeren

Laten we zonder verdere ops weg aan de slag gaan:

Open PowerShell vanaf uw beheer-pc als beheerder om verbinding te maken met de doelcomputer die u wilt testen met DISKSPD. Typ vervolgens de volgende opdracht en druk op Enter.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
In dit voorbeeld wordt een virtuele machine (VM) met de naam node1 uitgevoerd.

Als u het hulpprogramma DISKSPD wilt downloaden, typt u de volgende opdrachten en drukt u op Enter:

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.1.zip")

Gebruik de volgende opdracht om het gedownloade bestand uit te pakken:

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD

Wijzig de map in de map DISKSPD en zoek het juiste uitvoerbare bestand voor het Windows-besturingssysteem waarop de doelcomputer wordt uitgevoerd.

In dit voorbeeld gebruiken we de amd64-versie.

Notitie

U kunt het hulpprogramma DISKSPD ook rechtstreeks downloaden vanuit de GitHub-opslagplaats die de opensource-code bevat, en een wikipagina waarop alle parameters en specificaties worden beschreven. Selecteer in de opslagplaats onder Releases de koppeling om het ZIP-bestand automatisch te downloaden.

In het ZIP-bestand ziet u drie submappen: amd64 (64-bits systemen), x86 (32-bits systemen) en ARM64 (ARM-systemen). Met deze opties kunt u het hulpprogramma uitvoeren in elke Windows-client of serverversie.
Voer DISKSPD uit met de volgende PowerShell-opdracht. Vervang alles binnen de vierkante haken, inclusief de vierkante haken zelf, door de juiste instellingen.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Hier volgt een voorbeeldopdracht die u kunt uitvoeren:
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Notitie

Als u geen testbestand hebt, gebruikt u de parameter -c om er een te maken. Als u deze parameter gebruikt, moet u de naam van het testbestand opnemen wanneer u het pad definieert. Bijvoorbeeld: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. In de voorbeeldopdracht is IO.dat de naam van het testbestand en test01.txt de naam van het DISKSPD-uitvoerbestand.

Sleutelparameters opgeven

Nou, dat was eenvoudig toch? Helaas is er meer dan dat. Laten we uitpakken wat we hebben gedaan. Ten eerste zijn er verschillende parameters waarmee u kunt sleutelen en het kan specifiek worden. We hebben echter de volgende set basislijnparameters gebruikt:

Notitie

DISKSPD-parameters zijn hoofdlettergevoelig.

-t2: Hiermee wordt het aantal threads per doel-/testbestand aangegeven. Dit aantal is vaak gebaseerd op het aantal CPU-kernen. In dit geval zijn twee threads gebruikt om alle CPU-kernen te belasten.

-o32: Hiermee wordt het aantal openstaande I/O-aanvragen per doel per thread aangegeven. Dit wordt ook wel de wachtrijdiepte genoemd. In dit geval werden er 32 gebruikt om de CPU te belasten.

-b4K: dit geeft de blokgrootte aan in bytes, KiB, MiB of GiB. In dit geval is 4K-blokgrootte gebruikt om een willekeurige I/O-test te simuleren.

-r4K: dit geeft de willekeurige I/O aan die is uitgelijnd met de opgegeven grootte in bytes, KiB, MiB, Gib of blocks (overschrijft de parameter -s ). De algemene 4K-bytegrootte is gebruikt om goed uit te lijnen met de blokgrootte.

-w0: hiermee geeft u het percentage bewerkingen op dat schrijfaanvragen zijn (-w0 is gelijk aan 100% lezen). In dit geval zijn 0% schrijfbewerkingen gebruikt voor een eenvoudige test.

-d120: Hiermee wordt de duur van de test opgegeven, met inbegrip van afkoeling of opwarmen. De standaardwaarde is 10 seconden, maar we raden u aan ten minste 60 seconden te gebruiken voor elke ernstige werkbelasting. In dit geval werden 120 seconden gebruikt om eventuele uitbijters te minimaliseren.

-Suw: schakelt software- en hardware-schrijfcache uit (gelijk aan -Sh).

-D: legt IOPS-statistieken vast, zoals standaarddeviatie, in intervallen van milliseconden (per thread, per doel).

-L: Meet latentiestatistieken.

-c5g: hiermee stelt u de grootte van het voorbeeldbestand in die in de test wordt gebruikt. Deze kan worden ingesteld in bytes, KiB, MiB, GiB of blokken. In dit geval is een doelbestand van 5 GB gebruikt.

Raadpleeg de GitHub-opslagplaats voor een volledige lijst met parameters.

Inzicht in de omgeving

De prestaties zijn sterk afhankelijk van uw omgeving. Wat is onze omgeving? Onze specificatie omvat een Azure Stack HCI-cluster met opslaggroep en Opslagruimten Direct (S2D). Meer specifiek zijn er vijf VM's: DC, knooppunt1, knooppunt2, knooppunt3 en het beheerknooppunt. Het cluster zelf is een cluster met drie knooppunten met een gespiegelde tolerantiestructuur in drie richtingen. Daarom worden er drie gegevenskopieën onderhouden. Elk 'knooppunt' in het cluster is een Standard_B2ms VM met een maximale IOPS-limiet van 1920. Binnen elk knooppunt zijn er vier premium P30 SSD-stations met een maximale IOPS-limiet van 5000. Ten slotte heeft elk SSD-station 1 TB geheugen.

U genereert het testbestand onder de geïntegreerde naamruimte die het CSV-volume (Cluster Shared Volume) biedt (C:\ClusteredStorage) om de hele groep stations te gebruiken.

Notitie

De voorbeeldomgeving heeft geen Hyper-V of een geneste virtualisatiestructuur.

Zoals u zult zien, is het heel goed mogelijk om onafhankelijk het IOPS- of bandbreedteplafond op de VM- of stationslimiet te bereiken. En daarom is het belangrijk om inzicht te krijgen in uw VM-grootte en schijftype, omdat beide een maximale IOPS-limiet en een bandbreedtelimiet hebben. Deze kennis helpt bij het opsporen van knelpunten en het begrijpen van uw prestatieresultaten. Zie de volgende resources voor meer informatie over de grootte die geschikt kan zijn voor uw workload:

Inzicht in de uitvoer

Met uw kennis van de parameters en omgeving bent u klaar om de uitvoer te interpreteren. Ten eerste was het doel van de eerdere test om de IOPS te beperken zonder rekening te houden met latentie. Op deze manier kunt u visueel zien of u de kunstmatige IOPS-limiet in Azure bereikt. Als u de totale IOPS grafisch wilt visualiseren, gebruikt u Windows Admin Center of Taakbeheer.

In het volgende diagram ziet u hoe het DISKSPD-proces eruitziet in onze voorbeeldomgeving. Er wordt een voorbeeld weergegeven van een schrijfbewerking van 1 MiB vanaf een niet-coördinatorknooppunt. De tolerantiestructuur in drie richtingen, samen met de bewerking vanaf een niet-coördinatorknooppunt, leidt tot twee netwerkhops, waardoor de prestaties afnemen. Als u zich afvraagt wat een coördinatorknooppunt is, hoeft u zich geen zorgen te maken. U vindt hier meer informatie over in de sectie Dingen die u moet overwegen . De rode vierkantjes vertegenwoordigen de knelpunten van de VM en het station.

Nu u een visueel begrip hebt, gaan we de vier hoofdsecties van de uitvoer van het .txt-bestand bekijken:

Invoerinstellingen

In deze sectie worden de opdracht die u hebt uitgevoerd, de invoerparameters en aanvullende informatie over de testuitvoering beschreven.
Details van CPU-gebruik

In deze sectie vindt u informatie zoals de testtijd, het aantal threads, het aantal beschikbare processors en het gemiddelde gebruik van elke CPU-kern tijdens de test. In dit geval zijn er twee CPU-kernen die gemiddeld ongeveer 4,67% gebruik hebben.
Totaal I/O

Deze sectie heeft drie subsecties. In de eerste sectie worden de algemene prestatiegegevens, inclusief lees- en schrijfbewerkingen, uitgelicht. In de tweede en derde sectie worden de lees- en schrijfbewerkingen opgesplitst in afzonderlijke categorieën.

In dit voorbeeld ziet u dat het totale aantal I/O's is 234408 tijdens de duur van 120 seconden. IOPS = 234408 /120 = 1953,30. De gemiddelde latentie was 32,763 milliseconden en de doorvoer was 7,63 MiB/s. Uit eerdere informatie weten we dat de IOPS van 1953.30 de IOPS-beperking van 1920 voor onze Standard_B2ms VM naderen. Geloof je het niet? Als u deze test opnieuw uitvoert met behulp van verschillende parameters, zoals het vergroten van de wachtrijdiepte, zult u merken dat de resultaten nog steeds beperkt zijn tot dit aantal.

De laatste drie kolommen tonen de standaarddeviatie van IOPS bij 17,72 (van parameter -D), de standaarddeviatie van de latentie bij 20,994 milliseconden (van parameter -L) en het bestandspad.

Op basis van de resultaten kunt u snel vaststellen dat de clusterconfiguratie verschrikkelijk is. U kunt zien dat het de VM-beperking van 1920 heeft bereikt vóór de SSD-beperking van 5000. Als u werd beperkt door de SSD in plaats van de VM, had u kunnen profiteren van maximaal 20000 IOPS (4 stations * 5000) door het testbestand over meerdere stations te verdelen.

Uiteindelijk moet u bepalen welke waarden acceptabel zijn voor uw specifieke workload. In de volgende afbeelding ziet u enkele belangrijke relaties die u helpen bij het overwegen van de afwegingen:

De tweede relatie in de afbeelding is belangrijk en wordt soms aangeduid als Little's Law. De wet introduceert het idee dat er drie kenmerken zijn die het procesgedrag bepalen en dat je slechts één hoeft te wijzigen om de andere twee te beïnvloeden, en dus het hele proces. En dus, als u niet tevreden bent met de prestaties van uw systeem, hebt u drie dimensies van vrijheid om dit te beïnvloeden. De wet van Little bepaalt dat IOPS in ons voorbeeld de 'doorvoer' (invoeruitvoerbewerkingen per seconde), latentie de 'wachtrijtijd' is en de wachtrijdiepte de 'inventaris'.
Percentielanalyse van latentie

In deze laatste sectie worden de percentiellatenties per bewerkingstype van opslagprestaties van de minimale waarde tot de maximumwaarde beschreven.

Deze sectie is belangrijk omdat deze de 'kwaliteit' van uw IOPS bepaalt. Het laat zien hoeveel van de I/O-bewerkingen een bepaalde latentiewaarde hebben kunnen bereiken. Het is aan u om de acceptabele latentie voor dat percentiel te bepalen.

Bovendien verwijzen de negens naar het aantal negens. '3-negens' is bijvoorbeeld gelijk aan het 99e percentiel. Het aantal negens laat zien hoeveel I/O-bewerkingen op dat percentiel zijn uitgevoerd. Uiteindelijk bereikt u een punt waarop het niet langer zinvol is om de latentiewaarden serieus te nemen. In dit geval kunt u zien dat de latentiewaarden constant blijven na '4-negens'. Op dit moment is de latentiewaarde gebaseerd op slechts één I/O-bewerking van de 234408 bewerkingen.

Aandachtspunten

Nu u bent begonnen met het gebruik van DISKSPD, zijn er verschillende dingen die u moet overwegen om echte testresultaten te krijgen. Deze omvatten het goed letten op de parameters die u instelt, de status van de opslagruimte en variabelen, csv-eigendom en het verschil tussen DISKSPD en bestandskopie.

DISKSPD versus echte wereld

De kunstmatige test van DISKSPD geeft u relatief vergelijkbare resultaten voor uw echte workload. U moet echter goed letten op de parameters die u instelt en of deze overeenkomen met uw echte scenario. Het is belangrijk om te weten dat synthetische workloads nooit perfect de werkelijke workload van uw toepassing vertegenwoordigen tijdens de implementatie.

Voorbereiding

Voordat u een DISKSPD-test uitvoert, zijn er enkele aanbevolen acties. Deze omvatten het controleren van de status van de opslagruimte, het controleren van uw resourcegebruik zodat een ander programma de test niet verstoort en het voorbereiden van Performance Manager als u aanvullende gegevens wilt verzamelen. Omdat het doel van dit onderwerp echter is om DISKSPD snel uit te voeren, wordt niet ingegaan op de details van deze acties. Zie Prestaties Opslagruimten testen met synthetische workloads in Windows Server voor meer informatie.

Variabelen die van invloed zijn op de prestaties

Opslagprestaties zijn een delicate zaak. Dit betekent dat er veel variabelen zijn die de prestaties kunnen beïnvloeden. En dus is het waarschijnlijk dat u een getal tegenkomt dat niet overeenkomt met uw verwachtingen. Hieronder ziet u enkele variabelen die van invloed zijn op de prestaties, hoewel het geen uitgebreide lijst is:

Netwerkbandbreedte
Keuze voor tolerantie
Configuratie van opslagschijf: NVME, SSD, HDD
I/O-buffer
Cache
RAID-configuratie
Netwerkhops
Spilsnelheden van harde schijf

CSV-eigendom

Een knooppunt staat bekend als een volume-eigenaar of het coördinatorknooppunt (een niet-coördinatorknooppunt is het knooppunt dat geen eigenaar is van een specifiek volume). Aan elk standaardvolume wordt een knooppunt toegewezen en de andere knooppunten hebben toegang tot dit standaardvolume via netwerkhops, wat resulteert in tragere prestaties (hogere latentie).

Op dezelfde manier heeft een gedeeld clustervolume (CSV) ook een 'eigenaar'. Een CSV is echter 'dynamisch' in die zin dat deze telkens wanneer u het systeem (RDP) opnieuw opstart, overgaat en van eigenaar verandert. Als gevolg hiervan is het belangrijk om te bevestigen dat DISKSPD wordt uitgevoerd vanaf het coördinatorknooppunt dat eigenaar is van de CSV. Zo niet, dan moet u mogelijk het csv-eigendom handmatig wijzigen.

Ga als volgende te werk om het eigendom van csv's te bevestigen:

Controleer het eigendom door de volgende PowerShell-opdracht uit te voeren:
```
 Get-ClusterSharedVolume
```
Als het csv-eigendom onjuist is (u bevindt zich bijvoorbeeld op Node1 maar Node2 is eigenaar van het CSV), verplaatst u het CSV-bestand naar het juiste knooppunt door de volgende PowerShell-opdracht uit te voeren:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Bestand kopiëren versus DISKSPD

Sommige mensen denken dat ze de opslagprestaties kunnen testen door een reusachtig bestand te kopiëren en te plakken en te meten hoe lang dat proces duurt. De belangrijkste reden achter deze aanpak is waarschijnlijk omdat deze eenvoudig en snel is. Het idee is niet verkeerd in de zin dat een specifieke workload wordt getest, maar het is moeilijk om deze methode te categoriseren als 'opslagprestaties testen'.

Als het uw werkelijke doel is om de prestaties van het kopiëren van bestanden te testen, kan dit een volkomen geldige reden zijn om deze methode te gebruiken. Als het echter uw doel is om de opslagprestaties te meten, raden we u aan deze methode niet te gebruiken. U kunt het proces voor het kopiëren van bestanden zien als het gebruik van een andere set 'parameters' (zoals wachtrij, parallellisatie, enzovoort) die specifiek is voor bestandsservices.

In de volgende korte samenvatting wordt uitgelegd waarom het gebruik van het kopiëren van bestanden om de opslagprestaties te meten mogelijk niet de resultaten oplevert die u zoekt:

Bestandskopieën zijn mogelijk niet geoptimaliseerd. Er zijn twee niveaus van parallellisme die optreden, een interne en de andere externe. Intern, als de bestandskopie naar een extern doel wordt geleid, past de CopyFileEx-engine enige parallellisatie toe. Extern zijn er verschillende manieren om de CopyFileEx-engine aan te roepen. Kopieën van Bestandenverkenner hebben bijvoorbeeld één thread, maar Robocopy heeft meerdere threads. Om deze redenen is het belangrijk om te begrijpen of de implicaties van de test zijn wat u zoekt.
Elke kopie heeft twee kanten. Wanneer u gewoon een bestand kopieert en plakt, gebruikt u mogelijk twee schijven: de bronschijf en de doelschijf. Als de ene schijf langzamer is dan de andere, meet u in feite de prestaties van de langzamere schijf. Er zijn andere gevallen waarin de communicatie tussen de bron, het doel en de kopieer-engine de prestaties op unieke manieren kan beïnvloeden.

Zie Bestandskopie gebruiken om opslagprestaties te meten voor meer informatie.

Experimenten en algemene workloads

Deze sectie bevat enkele andere voorbeelden, experimenten en workloadtypen.

Het coördinatorknooppunt bevestigen

Zoals eerder vermeld, is het zo dat als de VM die u momenteel test niet de eigenaar is van het CSV-bestand, de prestaties afnemen (IOPS, doorvoer en latentie), in tegenstelling tot testen wanneer het knooppunt eigenaar is van het CSV-bestand. Dit komt omdat telkens wanneer u een I/O-bewerking uitvoert, het systeem een netwerkhop naar het coördinatorknooppunt uitvoert om die bewerking uit te voeren.

Voor een gespiegelde situatie met drie knooppunten maken schrijfbewerkingen altijd een netwerkhop omdat er gegevens moeten worden opgeslagen op alle stations op de drie knooppunten. Schrijfbewerkingen maken daarom hoe dan ook een netwerkhop. Als u echter een andere tolerantiestructuur gebruikt, kan dit veranderen.

Hier volgt een voorbeeld:

Wordt uitgevoerd op een lokaal knooppunt: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Wordt uitgevoerd op een niet-lokaal knooppunt: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

In dit voorbeeld kunt u in de resultaten van de volgende afbeelding duidelijk zien dat de latentie is afgenomen, de IOPS zijn toegenomen en de doorvoer is toegenomen wanneer het coördinatorknooppunt eigenaar is van het CSV.

OLTP-workload (Online Transaction Processing)

Oltp-workloadquery's (Online Transactional Processing) (Update, Insert, Delete) richten zich op transactiegerichte taken. Vergeleken met Online Analytical Processing (OLAP) is OLTP afhankelijk van opslaglatentie. Omdat elke bewerking weinig I/O uitgeeft, is het belangrijk hoeveel bewerkingen per seconde u kunt volhouden.

U kunt een OLTP-workloadtest ontwerpen om u te richten op willekeurige, kleine I/O-prestaties. Voor deze tests richt u zich op hoe ver u de doorvoer kunt pushen met behoud van acceptabele latenties.

De basisontwerpkeuze voor deze workloadtest moet minimaal het volgende omvatten:

Blokgrootte van 8 kB => lijkt op het paginaformaat dat SQL Server gebruikt voor de gegevensbestanden
70% lezen, 30% schrijven => lijkt op typisch OLTP-gedrag

OLAP-workload (Online Analytical Processing)

OLAP-workloads zijn gericht op het ophalen en analyseren van gegevens, zodat gebruikers complexe query's kunnen uitvoeren om multidimensionale gegevens te extraheren. In tegenstelling tot OLTP zijn deze workloads niet opslaglatentiegevoelig. Ze leggen de nadruk op het in de wachtrij plaatsen van veel bewerkingen zonder veel om bandbreedte te hoeven doen. Als gevolg hiervan leiden OLAP-workloads vaak tot langere verwerkingstijden.

U kunt een OLAP-workloadtest ontwerpen om zich te richten op sequentiële, grote I/O-prestaties. Voor deze tests richt u zich op het volume van de verwerkte gegevens per seconde in plaats van het aantal IOPS. Latentievereisten zijn ook minder belangrijk, maar dit is subjectief.