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

Článek
11/23/2024

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. Probíhá přejmenování dokumentace k produktu. 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í webového hostitelského prostředí nebo spouště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 vydává spoustu operací čtení a zápisu.

Teď víte, co je DISKSPD, ale kdy byste ho měli použít? DiskSPD má obtížnou dobu emulace složitých úloh. DiskSPD je ale skvělý v případě, že vaše úloha není přesně přibližná kopií souboru s jedním vláknem a potřebujete jednoduchý nástroj, který vytváří přijatelné výsledky směrného plánu.

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

Pokud chcete přidat adresář DISKSPD do proměnné prostředí, spusťte $PATH 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 parametrů směrného plánu:

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ě byly použity dvě vlákna ke zdůraznění všech jader procesoru.

-o32: Označuje počet nevyřízených vstupně-výstupních požadavků na cíl na vlákno. To se také označuje jako hloubka fronty a v tomto případě se ke zdůraznění 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, podle cíle).

-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.

Principy 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 fondem úložiště a Prostory úložiště s přímým přístupem (S2D). Konkrétně existuje pět virtuálních počítačů: DC, node1, node2, node3 a uzel pro správu. Samotný cluster je cluster se třemi uzly se třícestnou zrcadlenou strukturou 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 rámci sjednoceného oboru názvů, který sdílený svazek clusteru (CSV) poskytuje (C:\ClusteredStorage) pro použití celého fondu jednotek.

Poznámka:

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

Jak vidíte, je zcela možné nezávisle narazit na limitU IOPS nebo šířky pásma na virtuálním počítači nebo 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. Třícestná struktura odolnosti spolu s operací z neordinátorového uzlu vede ke dvěma segmentům směrování sítě a 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če představují virtuální počítač a kritické body jednotek.

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 čí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á. Před omezením 5000 SSD zjistíte, že dosáhl omezení virtuálního počítače 1920. Pokud jste místo virtuálního počítače omezili disky SSD, mohli jste využít až 2 0000 IOPS (4 jednotky × 5000), a to tak, že přeskočíte testovací soubor napříč několika jednotkami.

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. A tak, pokud jste nešťastní s výkonem systému, máte tři dimenze volnosti, aby to ovlivnilo. 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 latence percentilu na typ operace výkonu úložiště z minimální hodnoty na 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ě pozornost parametrů, které nastavíte, stav prostoru úložiště a proměnné, vlastnictví sdíleného svazku clusteru a rozdíl mezi diskSPD a kopírováním souborů.

DISKSPD vs. real-world

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, nezabředá se do specifik těchto akcí. Další informace najdete v tématu Testování Prostory úložiště výkonu 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
Vyrovnávací paměť vstupně-výstupních operací
Mezipaměť
Konfigurace RAID
Segmenty směrování sítě
Rychlosti pevného disku

Vlastnictví sdíleného svazku clusteru

Uzel se označuje jako vlastník svazku nebo koordinační uzel (nekonordinovaný uzel by byl uzel, který vlastní konkrétní svazek). Každému standardnímu svazku je přiřazen uzel a ostatní uzly mají přístup k tomuto standardnímu svazku prostřednictvím segmentů směrování sítě, což má za následek pomalejší výkon (vyšší latence).

Podobně sdílený svazek clusteru (CSV) má také "vlastníka". Sdílený svazek clusteru je ale "dynamický" v tom smyslu, že při každém restartování systému (RDP) přepne na vlastnictví a změní vlastnictví. Proto je důležité ověřit, že diskSPD běží z koordinačního uzlu, který vlastní sdílený svazek clusteru. Pokud ne, možná budete muset vlastnictví sdíleného svazku clusteru změnit ručně.

Potvrzení vlastnictví sdíleného svazku clusteru:

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 z Průzkumník souborů jsou s jedním vláknem, ale Robocopy je s více vlákny. 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řícestné zrcadlené situace operace zápisu vždy tvoří segment směrování sítě, protože potřebuje ukládat data na všech jednotkách napříč třemi uzly. Operace zápisu proto tvoří segment směrování sítě bez ohledu na to. 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
Spuštěno 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 výsledky následujícího obrázku, který snížil latenci, zvýšil počet vstupně-výstupních operací za sekundu a zvýšil propustnost, když koordinační uzel vlastní sdílený svazek clusteru.

Ú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 vystavuje málo vstupně-výstupních operací, záleží na tom, kolik operací za sekundu můžete udržet.

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 daleko můžete nasdílit propustnost a zachovat přijatelné latence.

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

Úloha 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ě. Zvýrazňují frontu mnoha operací, aniž by se museli zabývat velkou šířkou 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í.