Testování výkonu úložiště úloh s využitím nástroje DISKSPD

Článek
03/08/2025

Platí pro: Azure Stack HCI, verze 22H2 a 21H2; Windows Server 2022, Windows Server 2019

Důležité

Azure Stack HCI je teď součástí Azure Local. Starší verze Azure Stack HCI, například 22H2, ale budou dál odkazovat na Azure Stack HCI a nebudou odrážet změnu názvu. Další informace.

Toto téma obsahuje pokyny k testování výkonu úložiště úloh pomocí nástroje DISKSPD. Váš cluster Azure Stack HCI je nastavený a připravený k použití. Skvěle, ale jak víte, jestli máte k dispozici přislíbené metriky výkonu, ať už se jedná o latenci, propustnost nebo IOPS? Právě v tuto chvíli můžete využít nástroj DISKSPD. Po přečtení tohoto tématu budete vědět, jak spustit diskSPD, porozumět podmnožině parametrů, interpretovat výstup a získat obecný přehled o proměnných, které ovlivňují výkon úložiště úloh.

Co je DISKSPD?

DISKSPD je nástroj příkazového řádku pro generování vstupně-výstupních operací pro mikro benchmarking. Skvělé, tak co znamenají všechny tyto termíny? Každý, kdo nastaví cluster Azure Stack HCI nebo fyzický server, má důvod. Může to být nastavení prostředí pro webhosting nebo provozování virtuálních ploch pro zaměstnance. Bez ohledu na případ skutečného použití pravděpodobně budete chtít před nasazením skutečné aplikace simulovat test. Testování aplikace ve skutečném scénáři je ale často obtížné – jedná se o místo, kde přichází diskSPD.

DISKSPD je nástroj, který si můžete přizpůsobit a vytvořit vlastní syntetické úlohy a otestovat aplikaci před nasazením. Skvělá věc o nástroji je, že vám dává svobodu konfigurovat a upravovat parametry tak, aby vytvořil konkrétní scénář, který se podobá vaší skutečné úloze. DiskSPD vám může poskytnout přehled o tom, co váš systém dokáže před nasazením. V jádru DISKSPD jednoduše provádí spoustu operací čtení a zápisu.

Teď víte, co je DISKSPD, ale kdy byste ho měli použít? DiskSPD má potíže při emulaci složitých úloh. DiskSPD je ale skvělý v případě, že vaše úloha není přesně odpovídá jednovláknovému kopírování souborů a potřebujete jednoduchý nástroj, který vytváří přijatelné základní výsledky.

Rychlý start: Instalace a spuštění nástroje DISKSPD

Pokud chcete nainstalovat a spustit DISKSPD, otevřete PowerShell jako správce na počítači pro správu a pak postupujte takto:

Pokud chcete stáhnout a rozbalit soubor ZIP pro nástroj DISKSPD, spusťte následující příkazy:

# 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

Pro přidání adresáře DISKSPD do proměnné prostředí $PATH, spusťte následující příkaz:

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

Spusťte diskSPD pomocí následujícího příkazu PowerShellu. Nahraďte hranaté závorky odpovídajícím nastavením.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Tady je ukázkový příkaz, který můžete spustit:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Poznámka:

Pokud nemáte testovací soubor, vytvořte ho pomocí parametru -c . Pokud použijete tento parametr, nezapomeňte při definování cesty zahrnout název testovacího souboru. Příklad: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. V ukázkovém příkazu IO.dat je název testovacího souboru a test01.txt je název výstupního souboru DISKSPD.

Zadání klíčových parametrů

No, to bylo jednoduché, že? Bohužel je toho víc. Pojďme rozbalit to, co jsme udělali. Nejprve existují různé parametry, se kterými můžete tinkerovat, a to může být specifické. Použili jsme ale následující sadu základních parametrů:

Poznámka:

V parametrech DISKSPD se rozlišují malá a velká písmena.

-t2: Označuje počet vláken na cílový/testovací soubor. Toto číslo je často založeno na počtu jader procesoru. V tomto případě byla použita dvě vlákna k zatížení všech jader procesoru.

-o32: Označuje počet nevyřízených vstupně-výstupních požadavků pro každý cíl a vlákno. To se také označuje jako hloubka fronty a v tomto případě se k zatížení procesoru použilo 32.

-b4K: Označuje velikost bloku v bajtech, KiB, MiB nebo GiB. V tomto případě se k simulaci náhodného vstupně-výstupního testu použila velikost bloku 4K.

-r4K: Označuje náhodné vstupně-výstupní operace zarovnané k zadané velikosti v bajtech, KiB, MiB, Gib nebo blocích (přepíše parametr -s ). Společná velikost 4K bajtů byla použita k správnému zarovnání s velikostí bloku.

-w0: Určuje procento operací, které jsou požadavky na zápis (-w0 odpovídá 100% čtení). V tomto případě se pro účely jednoduchého testu použilo 0 % zápisů.

-d120: Určuje dobu trvání testu, bez zahrnutí chlazení nebo zahřátí. Výchozí hodnota je 10 sekund, ale pro každou závažnou úlohu doporučujeme použít alespoň 60 sekund. V tomto případě se použilo 120 sekund k minimalizaci odlehlých hodnot.

-Suw: Zakáže ukládání do mezipaměti softwarového a hardwarového zápisu (ekvivalentní příkazu -Sh).

-D: Zaznamenává statistiky IOPS, jako je směrodatná odchylka, v intervalech milisekund (na vlákno, pro každý cíl).

-L: Měří statistiky latence.

-c5g: Nastaví velikost ukázkového souboru použitého v testu. Dá se nastavit v bajtech, KiB, MiB, GiB nebo blocích. V tomto případě se použil cílový soubor o velikosti 5 GB.

Úplný seznam parametrů najdete v úložišti GitHub.

Pochopit prostředí

Výkon výrazně závisí na vašem prostředí. Tak co je naše prostředí? Naše specifikace zahrnuje cluster Azure Stack HCI s úložištěm a Přímým přístupem k úložišti (S2D). Konkrétně existuje pět virtuálních počítačů: DC, node1, node2, node3 a uzel pro správu. Samotný klastr je tříuzlový klastr s třícestnou zrcadlenou strukturou zajištění odolnosti. Proto jsou zachovány tři kopie dat. Každý uzel v clusteru je virtuální počítač Standard_B2ms s maximálním limitem IOPS 1920. V každém uzlu jsou čtyři jednotky SSD úrovně Premium P30 s maximálním limitem IOPS 5000. Každá jednotka SSD má nakonec 1 TB paměti.

Vygenerujete testovací soubor v jednotném oboru názvů, který poskytuje sdílený svazek clusteru (CSV) (C:\ClusteredStorage), abyste využili celý pool jednotek.

Poznámka:

Ukázkové prostředí nemá hyper-V ani vnořenou strukturu virtualizace.

Jak vidíte, je zcela možné narazit na limit IOPS nebo šířky pásma nezávisle na virtuálním počítači nebo na limitu jednotky. Proto je důležité pochopit velikost virtuálního počítače a typ jednotky, protože oba mají maximální limit IOPS a strop šířky pásma. Tyto znalosti pomáhají najít kritické body a porozumět výsledkům výkonu. Další informace o velikosti, která může být pro vaši úlohu vhodná, najdete v následujících zdrojích informací:

Porozumění výstupu

S pochopením parametrů a prostředí jste připraveni interpretovat výstup. Nejprve bylo cílem předchozího testu dosáhnout maximálního počtu vstupně-výstupních operací za sekundu bez ohledu na latenci. Tímto způsobem můžete vizuálně zjistit, jestli dosáhnete limitu umělého počtu IOPS v Rámci Azure. Pokud chcete graficky vizualizovat celkový počet vstupně-výstupních operací za sekundu, použijte Buď Centrum pro správu Windows, nebo Správce úloh.

Následující diagram znázorňuje, jak proces DISKSPD vypadá v našem ukázkovém prostředí. Ukazuje příklad operace zápisu 1 MiB z neordinátorového uzlu. Odolnostní struktura se třemi cestami a provoz z nekoordinátorského uzlu vedou ke dvěma skokům v síti, což snižuje výkon. Pokud vás zajímá, co je koordinační uzel, nemějte obavy! O tom se dozvíte v části Věci, které je potřeba vzít v úvahu . Červené čtverečky představují úzká místa u virtuálních počítačů a disků.

Teď, když máte vizuální znalosti, pojďme se podívat na čtyři hlavní části výstupu souboru .txt:

Nastavení vstupu

Tato část popisuje příkaz, který jste spustili, vstupní parametry a další podrobnosti o testovacím spuštění.
Podrobnosti o využití procesoru

Tato část zvýrazňuje informace, jako je doba testování, počet vláken, počet dostupných procesorů a průměrné využití každého jádra procesoru během testu. V tomto případě existují dvě jádra procesoru, která průměrovala kolem 4,67 % využití.
Celkový počet vstupně-výstupních operací

Tato část obsahuje tři pododdíly. První část zvýrazní celkové údaje o výkonu, včetně operací čtení i zápisu. Druhá a třetí část rozdělí operace čtení a zápisu do samostatných kategorií.

V tomto příkladu vidíte, že celkový počet vstupně-výstupních operací byl 234408 během 120sekundové doby trvání. IOPS = 234408 /120 = 1953,30. Průměrná latence byla 32,763 milisekund a propustnost byla 7,63 MiB/s. Z předchozích informací víme, že 1953.30 IOPS se blíží omezení 1920 IOPS pro náš virtuální počítač Standard_B2ms. Nevěříte tomu? Pokud tento test znovu spustíte pomocí různých parametrů, jako je zvýšení hloubky fronty, zjistíte, že výsledky jsou stále omezené na toto konkrétní číslo.

Poslední tři sloupce zobrazují směrodatnou odchylku IOPS při hodnotě 17,72 (od parametru -D), směrodatnou odchylku latence při 20,994 milisekundách (parametr -L) a cestu k souboru.

Z výsledků můžete rychle zjistit, že konfigurace clusteru je hrozná. Vidíte, že narazil na omezení virtuálního počítače 1920 dříve než na omezení SSD 5000. Pokud byste byli omezeni disky SSD místo virtuálním strojem, mohli jste využít až 20 000 IOPS (4 jednotky × 5000) rozdělením testovacího souboru po několika jednotkách.

Nakonec musíte rozhodnout, jaké hodnoty jsou pro vaši konkrétní úlohu přijatelné. Následující obrázek znázorňuje některé důležité vztahy, které vám pomůžou zvážit kompromisy:

Druhý vztah na obrázku je důležitý a někdy se označuje jako Littleův zákon. Zákon zavádí myšlenku, že existují tři charakteristiky, které řídí chování procesu, a že potřebujete změnit pouze jeden, aby ovlivnil druhé dva, a proto celý proces. Takže pokud nejste spokojeni s výkonem svého systému, máte tři dimenze volnosti, kterými můžete ovlivnit jeho výkon. Malý zákon určuje, že v našem příkladu je IOPS "propustnost" (vstupní výstupní operace za sekundu), latence je "doba fronty" a hloubka fronty je "inventory".
Analýza percentilu latence

Tato poslední část podrobně popisuje procentilové latence podle typu operace výkonu úložiště od minimální po maximální hodnotu.

Tato část je důležitá, protože určuje "kvalitu" vašeho IOPS. Zjistí, kolik vstupně-výstupních operací bylo schopno dosáhnout určité hodnoty latence. Záleží na vás, abyste se rozhodli přijatelnou latenci pro daný percentil.

Kromě toho "devítky" odkazují na počet devítek. Například "3-nines" je ekvivalentní 99. percentilu. Počet devítek zveřejňuje, kolik vstupně-výstupních operací běželo na daném percentilu. Nakonec dosáhnete bodu, kdy už nemá smysl brát hodnoty latence vážně. V tomto případě vidíte, že hodnoty latence zůstávají po 4 devítkách konstantní. V tomto okamžiku je hodnota latence založena pouze na jedné vstupně-výstupní operaci mimo operace 234408.

Aspekty, které je třeba zvážit

Teď, když jste začali používat DISKSPD, je potřeba zvážit několik věcí, které byste měli zvážit, abyste získali výsledky testů z reálného světa. Patří mezi ně věnování pozornosti parametrům, které nastavíte, zdraví úložného prostoru a proměnné, vlastnictví sdíleného svazku clusteru a rozdíl mezi DISKSPD a kopírováním souborů.

DISKSPD vs. reálný svět

Umělý test DISKSPD poskytuje relativně srovnatelné výsledky pro vaši skutečnou úlohu. Musíte ale věnovat pozornost parametrům, které nastavíte a jestli odpovídají vašemu skutečnému scénáři. Je důležité si uvědomit, že syntetické úlohy nebudou během nasazování nikdy dokonale reprezentovat skutečnou úlohu vaší aplikace.

Příprava

Před spuštěním testu DISKSPD existuje několik doporučených akcí. Patří mezi ně ověření stavu prostoru úložiště, kontrola využití prostředků tak, aby jiný program nerušil test, a přípravu správce výkonu, pokud chcete shromáždit další data. Vzhledem k tomu, že cílem tohoto tématu je rychle spustit DISKSPD, neprobírá podrobnosti těchto akcí. Další informace najdete v tématu Testování výkonu prostor úložiště pomocí syntetických úloh ve Windows Serveru.

Proměnné, které ovlivňují výkon

Výkon úložiště je citlivá věc. To znamená, že existuje mnoho proměnných, které mohou ovlivnit výkon. A tak je pravděpodobné, že narazíte na číslo, které je nekonzistentní s vašimi očekáváními. Níže jsou zvýrazněny některé proměnné, které ovlivňují výkon, i když se nejedná o komplexní seznam:

Šířka pásma sítě
Volba odolnosti
Konfigurace disku úložiště: NVME, SSD, HDD
I/O vyrovnávací paměť
Mezipaměť
Konfigurace RAID
Síťové skoky
Rychlosti vřetene pevného disku

Vlastnictví CSV

Uzel se označuje jako vlastník svazku nebo koordinační uzel (nekoordinační uzel by byl uzel, který nevlastní určitý svazek). Každému standardnímu svazku je přiřazen uzel a ostatní uzly mohou k němu přistupovat prostřednictvím přeskoků v síti, což má za následek pomalejší výkon (vyšší latence).

Podobně sdílený svazek clusteru (CSV) má také "vlastníka". Nicméně, CSV je „dynamický“ v tom smyslu, že při každém restartu systému může měnit umístění a vlastnictví (RDP). Proto je důležité ověřit, že DISKSPD běží z toho koordinačního uzlu, který vlastní sdílený svazek clusteru. Pokud ne, možná budete muset ručně změnit vlastnictví souboru CSV.

Chcete-li potvrdit vlastnictví souboru CSV:

Zkontrolujte vlastnictví spuštěním následujícího příkazu PowerShellu:
```
 Get-ClusterSharedVolume
```
Pokud je vlastnictví sdíleného svazku clusteru nesprávné (například jste na Node1, ale Node2 vlastní sdílený svazek clusteru), přesuňte sdílený svazek clusteru na správný uzel spuštěním následujícího příkazu PowerShellu:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Kopírování souborů vs. DISKSPD

Někteří lidé věří, že můžou "otestovat výkon úložiště" zkopírováním a vložením obrovského souboru a měřením, jak dlouho tento proces trvá. Hlavním důvodem tohoto přístupu je s největší pravděpodobností to, že je to jednoduché a rychlé. Myšlenka není špatná v tom smyslu, že testuje konkrétní úlohu, ale je obtížné kategorizovat tuto metodu jako "testování výkonu úložiště".

Pokud vaším skutečným cílem je otestovat výkon kopírování souborů, může to být naprosto platný důvod k použití této metody. Pokud ale vaším cílem je měřit výkon úložiště, doporučujeme tuto metodu nepoužívat. Proces kopírování souborů si můžete představit jako použití jiné sady "parametrů" (například fronty, paralelizace atd.), které jsou specifické pro souborové služby.

Následující krátký souhrn vysvětluje, proč použití kopírování souborů k měření výkonu úložiště nemusí poskytovat výsledky, které hledáte:

Kopie souborů nemusí být optimalizované, existují dvě úrovně paralelismu, jedna interní a druhá externí. Interně platí, že pokud kopírování souboru směřuje do vzdáleného cíle, použije modul CopyFileEx určité paralelizace. Externě existují různé způsoby vyvolání modulu CopyFileEx. Například kopie prováděné pomocí Průzkumníka souborů jsou jednovláknové, ale Robocopy je vícevláknový. Z těchto důvodů je důležité pochopit, jestli jsou důsledky testu to, co hledáte.
Každá kopie má dvě strany. Při kopírování a vkládání souboru možná používáte dva disky: zdrojový a cílový disk. Pokud je jedna pomalejší než druhá, v podstatě změříte výkon pomalejšího disku. Existují i jiné případy, kdy komunikace mezi zdrojem, cílem a modulem kopírování může ovlivnit výkon jedinečnými způsoby.

Další informace najdete v tématu Použití kopírování souborů k měření výkonu úložiště.

Experimenty a běžné úlohy

Tato část obsahuje několik dalších příkladů, experimentů a typů úloh.

Potvrzení koordinačního uzlu

Jak už jsme zmínili dříve, pokud virtuální počítač, který aktuálně testujete, nevlastní sdílený svazek clusteru, zobrazí se pokles výkonu (IOPS, propustnost a latence) na rozdíl od jeho testování, když uzel vlastní sdílený svazek clusteru. Důvodem je to, že pokaždé, když vydáte vstupně-výstupní operaci, systém provede směrování sítě do koordinačního uzlu, aby tuto operaci provedl.

V případě tříuzlového, třícestného zrcadlení operace zápisu vždy vyžadují přesun v síti, protože je potřeba ukládat data na všech discích napříč třemi uzly. Proto operace zápisu znamenají síťový skok bez ohledu na cokoliv. Pokud ale použijete jinou strukturu odolnosti, může se to změnit.

Tady je příklad:

Spuštěno na místním uzlu: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Spouští se na nelokálním uzlu: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

Z tohoto příkladu můžete jasně vidět na výsledcích následujícího obrázku, že došlo ke snížení latence, nárůstu počtu vstupně-výstupních operací za sekundu a zvýšení propustnosti, když koordinační uzel vlastní sdílený svazek clusteru (CSV).

Úloha OLTP (Online Transaction Processing)

Dotazy na úlohy online transakčního zpracování (OLTP) (aktualizace, vložení, odstranění) se zaměřují na úlohy orientované na transakce. Ve srovnání s online analytickým zpracováním (OLAP) je OLTP závislá na latenci úložiště. Vzhledem k tomu, že každá operace vykonává málo vstupů/výstupů, záleží na tom, kolik operací za sekundu můžete udržet/splňovat.

Test úlohy OLTP můžete navrhnout tak, aby se zaměřoval na náhodný, malý vstupně-výstupní výkon. U těchto testů se zaměřte na to, jak můžete zvýšit propustnost při zachování přijatelných latencí.

Základní volba návrhu pro tento test úloh by měla obsahovat minimálně:

Velikost bloku 8 kB => se podobá velikosti stránky, kterou SQL Server používá pro své datové soubory
70% čtení, 30% zápis => připomíná typické chování OLTP

Zátěž OLAP (Online Analytical Processing)

Úlohy OLAP se zaměřují na načítání a analýzu dat a umožňují uživatelům provádět složité dotazy k extrakci multidimenzionálních dat. Na rozdíl od OLTP tyto úlohy nejsou citlivé na latenci úložiště. Kladou důraz na řazení do fronty mnoha operací, bez obav o šířku pásma. V důsledku toho úlohy OLAP často vedou k delší době zpracování.

Test úlohy OLAP můžete navrhnout tak, aby se zaměřoval na sekvenční a velký výkon vstupně-výstupních operací. U těchto testů se zaměřte na objem zpracovaných dat za sekundu, a ne na počet vstupně-výstupních operací za sekundu. Požadavky na latenci jsou také méně důležité, ale to je subjektivní.