DiskSPD gebruiken om de opslagprestaties van workloads te testen

Artikel
11/23/2024

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

Belangrijk

Azure Stack HCI maakt nu deel uit van Azure Local. De naam van productdocumentatie wordt nog steeds bijgewerkt. Oudere versies van Azure Stack HCI, bijvoorbeeld 22H2, blijven verwijzen naar Azure Stack HCI en geven de naamwijziging niet weer. Meer informatie.

Dit onderwerp bevat 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 parameters begrijpt, uitvoer interpreteert en een algemeen inzicht krijgt in de variabelen die van invloed zijn op de prestaties van de 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. Het kan zijn om een webhostingomgeving in te stellen of virtuele bureaubladen uit te voeren voor werknemers. Wat het praktijkgebruik 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 binnenkomt.

DISKSPD is een hulpprogramma dat u kunt aanpassen om uw eigen synthetische workloads te maken en uw toepassing te testen vóór de implementatie. Het handige van het hulpprogramma is dat u de vrijheid krijgt 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 kijkje geven in wat uw systeem kan doen vóór de implementatie. In de kern geeft DISKSPD eenvoudig een aantal lees- en schrijfbewerkingen uit.

Nu weet u wat DISKSPD is, maar wanneer moet u deze gebruiken? DISKSPD heeft een moeilijke tijd bij het emuleren van complexe werkbelastingen. DISKSPD is echter geweldig wanneer uw werkbelasting niet nauwkeurig wordt geschat door een kopie van een bestand met één thread en u een eenvoudig hulpprogramma nodig hebt dat acceptabele basislijnresultaten produceert.

Snel aan de slag: DISKSPD installeren en uitvoeren

Als u DISKSPD wilt installeren en uitvoeren, opent u PowerShell als beheerder op uw beheercomputer en voert u de volgende stappen uit:

Voer de volgende opdrachten uit om het ZIP-bestand voor het hulpprogramma DISKSPD te downloaden en uit te vouwen:

# Define the ZIP URL and the full path to save the file, including the filename
$zipName = "DiskSpd.zip"
$zipPath = "C:\DISKSPD"
$zipFullName = Join-Path $zipPath $zipName
$zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName

# Ensure the target directory exists, if not then create
if (-Not (Test-Path $zipPath)) {
New-Item -Path $zipPath -ItemType Directory | Out-Null
}
# Download and expand the ZIP file
Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName
Expand-Archive -Path $zipFullName -DestinationPath $zipPath

Voer de volgende opdracht uit om de map DISKSPD toe te voegen aan uw $PATH omgevingsvariabele:

$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

Voer DISKSPD uit met de volgende PowerShell-opdracht. Vervang vierkante haken door de juiste instellingen.
```
diskspd [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 uitvoerbestand DISKSPD.

Sleutelparameters opgeven

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

Notitie

DISKSPD-parameters zijn hoofdlettergevoelig.

-t2: Dit geeft het aantal threads per doel-/testbestand aan. Dit aantal is vaak gebaseerd op het aantal CPU-kernen. In dit geval werden twee threads gebruikt om alle CPU-kernen te benadrukken.

-o32: Dit geeft het aantal openstaande I/O-aanvragen per doel per thread aan. Dit wordt ook wel de diepte van de wachtrij genoemd, en in dit geval werden 32 gebruikt om de CPU te benadrukken.

-b4K: Dit geeft de blokgrootte in bytes, KiB, MiB of GiB aan. 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 afgestemd op de opgegeven grootte in bytes, KiB, MiB, Gib of blokken (overschrijft de parameter -s ). De gemeenschappelijke grootte van 4K-byte 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% leesbewerkingen). In dit geval werden 0% schrijfbewerkingen gebruikt voor een eenvoudige test.

-d120: Hiermee geeft u de duur van de test aan, niet inclusief afkoelen of opwarmen. De standaardwaarde is 10 seconden, maar we raden u aan ten minste 60 seconden te gebruiken voor elke ernstige workload. In dit geval werden 120 seconden gebruikt om uitbijters te minimaliseren.

-Suw: Hiermee schakelt u caching van software- en hardware-schrijfbewerkingen uit (equivalent 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

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, node1, node2, node3 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 CLUSTER Shared Volume (CSV) biedt (C:\ClusteredStorage) om de hele groep stations te gebruiken.

Notitie

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

Zoals u ziet, is het volledig mogelijk om onafhankelijk het IOPS- of bandbreedtelimiet op de VM of stationslimiet te bereiken. Daarom is het belangrijk om inzicht te krijgen in uw VM-grootte en -stationstype, omdat beide een maximale IOPS-limiet en een bandbreedtelimiet hebben. Deze kennis helpt knelpunten te vinden en inzicht te verkrijgen in uw prestatieresultaten. Zie de volgende bronnen voor meer informatie over de grootte die geschikt kan zijn voor uw workload:

Inzicht in de uitvoer

Gewapend met uw begrip 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 zonder rekening te houden met latentie. Op deze manier kunt u visueel zien of u de limiet voor kunstmatige IOPS binnen Azure bereikt. Als u het totale aantal 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. Hier ziet u een voorbeeld van een MiB-schrijfbewerking van een niet-coördinatorknooppunt. De tolerantiestructuur in drie richtingen, samen met de bewerking van 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 krijgt hier informatie over in de sectie Dingen die u moet overwegen . De rode vierkantjes vertegenwoordigen de Knelpunten van de VIRTUELE machine 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 wordt de opdracht beschreven die u hebt uitgevoerd, de invoerparameters en aanvullende informatie over de testuitvoering.
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 met een gemiddelde van ongeveer 4,67% gebruik.
Totaal aantal I/O's

Deze sectie heeft drie subsecties. In de eerste sectie worden de algemene prestatiegegevens gemarkeerd, waaronder lees- en schrijfbewerkingen. De tweede en derde sectie splitsen de lees- en schrijfbewerkingen op in afzonderlijke categorieën.

In dit voorbeeld ziet u dat het totale aantal I/O's gedurende de duur van 120 seconden is 234408. 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 1953.30 IOPS bijna de IOPS-beperking van 1920 voor onze Standard_B2ms VM hebben. 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 worden beperkt tot dit aantal.

In de laatste drie kolommen wordt de standaarddeviatie van IOPS weergegeven op 17,72 (van de parameter -D), de standaarddeviatie van de latentie op 20,994 milliseconden (van de parameter -L) en het bestandspad.

In de resultaten kunt u snel vaststellen dat de clusterconfiguratie verschrikkelijk is. U kunt zien dat deze de VM-beperking van 1920 heeft bereikt vóór de SSD-beperking van 5000. Als u wordt beperkt door de SSD in plaats van de virtuele machine, zou u kunnen profiteren van maximaal 20000 IOPS (4 stations * 5000) door het testbestand over meerdere stations te strekken.

Uiteindelijk moet u bepalen welke waarden acceptabel zijn voor uw specifieke workload. In de volgende afbeelding ziet u enkele belangrijke relaties om rekening te houden met de afwegingen:

De tweede relatie in de afbeelding is belangrijk en wordt soms ook wel Little's Law genoemd. De wet introduceert het idee dat er drie kenmerken zijn die het gedrag van processen bepalen en dat u er slechts een hoeft te wijzigen om de andere twee te beïnvloeden, en dus het hele proces. En dus, als je ongelukkig bent met de prestaties van je systeem, heb je drie dimensies van vrijheid om het te beïnvloeden. De wet van Little bepaalt dat IOPS in ons voorbeeld de 'doorvoer' is (invoeruitvoerbewerkingen per seconde), latentie de 'wachtrijtijd' is en dat de wachtrijdiepte de 'inventaris' is.
Percentielanalyse van latentie

In deze laatste sectie worden de percentiellatenties per bewerkingstype van de opslagprestaties van de minimumwaarde 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 waar het niet langer zinvol is om de latentiewaarden serieus te nemen. In dit geval ziet u dat de latentiewaarden constant blijven na '4-negens'. Op dit moment is de latentiewaarde gebaseerd op slechts één I/O-bewerking uit de 234408 bewerkingen.

Punten die u moet in acht nemen

Nu u aan de slag bent met DISKSPD, zijn er verschillende dingen die u moet overwegen om echte testresultaten te krijgen. Hiertoe moet u goed letten op de parameters die u instelt, de status van opslagruimte en variabelen, het eigendom van CSV 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 begrijpen dat synthetische workloads tijdens de implementatie nooit perfect de echte workload van uw toepassing vertegenwoordigen.

Voorbereiding

Voordat u een DISKSPD-test uitvoert, zijn er enkele aanbevolen acties. Dit omvat het controleren van de status van de opslagruimte, het controleren van het resourcegebruik, zodat een ander programma de test niet verstoort en performance manager voorbereidt als u extra gegevens wilt verzamelen. Omdat het doel van dit onderwerp echter is om snel DISKSPD uit te voeren, wordt niet ingegaan op de specifieke kenmerken van deze acties. Zie Test Opslagruimten Performance Using Synthetic Workloads in Windows Server (Test Opslagruimten Performance Using Synthetic 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 van invloed kunnen zijn op de prestaties. Het is dus waarschijnlijk dat u een getal tegenkomt dat inconsistent is met uw verwachtingen. Hieronder ziet u enkele van de variabelen die van invloed zijn op de prestaties, hoewel dit geen uitgebreide lijst is:

Netwerkbandbreedte
Keuze voor tolerantie
Opslagschijfconfiguratie: NVME, SSD, HDD
I/O-buffer
Cache
RAID-configuratie
Netwerkhops
Harde schijf spindel snelheden

CSV-eigendom

Een knooppunt wordt een volumeeigenaar of het coördinatorknooppunt genoemd (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 CSV (Cluster Shared Volume) ook een 'eigenaar'. Een CSV is echter 'dynamisch' in de zin dat het omgaat en het eigendom verandert telkens wanneer u het systeem opnieuw opstart (RDP). Als gevolg hiervan is het belangrijk om te bevestigen dat DISKSPD wordt uitgevoerd vanaf het coördinatorknooppunt dat eigenaar is van het CSV-bestand. Zo niet, dan moet u mogelijk het CSV-eigendom handmatig wijzigen.

Csv-eigendom 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 eigenaar is 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 geloven dat ze opslagprestaties kunnen testen door een gigantische bestand te kopiëren en plakken en te meten hoe lang dat proces duurt. De belangrijkste reden voor deze aanpak is waarschijnlijk omdat het eenvoudig en snel is. Het idee is niet verkeerd in de zin dat er een specifieke workload wordt getest, maar het is moeilijk om deze methode te categoriseren als 'opslagprestaties testen'.

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

In de volgende korte samenvatting wordt uitgelegd waarom het gebruik van bestandskopie om de opslagprestaties te meten mogelijk niet de resultaten biedt die u zoekt:

Bestandskopieën zijn mogelijk niet geoptimaliseerd, er zijn twee niveaus van parallelle uitvoering, één intern en de andere extern. Als de bestandskopie intern naar een extern doel gaat, past de CopyFileEx-engine enige parallelle uitvoering toe. Extern zijn er verschillende manieren om de CopyFileEx-engine aan te roepen. Kopieën uit Bestandenverkenner zijn bijvoorbeeld één thread, maar Robocopy is meerdere threads. Om deze redenen is het belangrijk om te begrijpen of de gevolgen van de test zijn wat u zoekt.
Elke kopie heeft twee zijden. Wanneer u een bestand kopieert en plakt, gebruikt u mogelijk twee schijven: de bronschijf en de doelschijf. Als de ene langzamer is dan de andere, meet u in wezen de prestaties van de tragere schijf. Er zijn andere gevallen waarin de communicatie tussen de bron, het doel en de kopieer-engine op unieke manieren van invloed kan zijn op de prestaties.

Zie Bestandskopie gebruiken om de 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, ziet u, als de VM die u momenteel test, geen eigenaar is van het CSV-bestand, een daling van de prestaties (IOPS, doorvoer en latentie) in plaats van deze te testen wanneer het knooppunt eigenaar is van het CSV-bestand. Dit komt doordat telkens wanneer u een I/O-bewerking uitvoert, het systeem een netwerkhop uitvoert naar het coördinatorknooppunt om die bewerking uit te voeren.

Voor een gespiegelde situatie met drie knooppunten maken schrijfbewerkingen altijd een netwerkhop omdat deze gegevens op alle stations op de drie knooppunten moet opslaan. Schrijfbewerkingen maken daarom een netwerkhop, ongeacht. Als u echter een andere tolerantiestructuur gebruikt, kan dit veranderen.

Hier volgt een voorbeeld:

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

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

OLTP-workload (Online Transaction Processing)

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

U kunt een OLTP-workloadtest ontwerpen om te focussen op willekeurige, kleine I/O-prestaties. Voor deze tests moet u zich richten op de mate waarin u de doorvoer kunt pushen terwijl acceptabele latenties behouden blijven.

De basisontwerpkeuze voor deze workloadtest moet minimaal het volgende omvatten:

8 kB blokgrootte => 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 richten zich 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 benadrukken het in de wachtrij plaatsen van veel bewerkingen zonder veel te zorgen over bandbreedte. Als gevolg hiervan leiden OLAP-workloads vaak tot langere verwerkingstijden.

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