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

Článek
03/05/2024

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

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. Výborně, takže 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. Ať už se jedná o případ použití v reálném světě, budete pravděpodobně chtít simulovat test před nasazením skutečné aplikace. Testování aplikace v reálném scénáři je ale často obtížné – právě tady přichází na řadu řešení 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é na nástroji je, že vám dává volnost při konfiguraci a úpravě parametrů a vytvoření konkrétního scénáře, 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á řadu operací čtení a zápisu.

Teď víte, co je DISKSPD, ale kdy byste ho měli použít? Nástroj DISKSPD má potíže s emulací složitých úloh. DiskSPD je ale skvělý, když se vaše úloha přesně neblíží kopírováním souboru s jedním vláknem a potřebujete jednoduchý nástroj, který vytvoří přijatelné výsledky směrného plánu.

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

Bez dalšího okolku se pusťme do práce:

Na počítači pro správu otevřete PowerShell jako správce a připojte se pomocí nástroje DISKSPD k cílovému počítači, který chcete otestovat, a pak zadejte následující příkaz a stiskněte Enter.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
V tomto příkladu používáme virtuální počítač s názvem node1.

Nástroj DISKSPD stáhnete zadáním následujících příkazů a stisknutím klávesy 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")

Pomocí následujícího příkazu rozbalte stažený soubor:

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

Přejděte do adresáře DISKSPD a vyhledejte příslušný spustitelný soubor pro operační systém Windows, který běží na cílovém počítači.

V tomto příkladu používáme verzi amd64.

Poznámka

Můžete si také stáhnout nástroj DISKSPD přímo z úložiště GitHub , které obsahuje opensourcový kód, a stránku wikiwebu, která podrobně popisuje všechny parametry a specifikace. V úložišti v části Releases (Vydané verze) vyberte odkaz pro automatické stažení souboru ZIP.

V souboru ZIP uvidíte tři podsložky: amd64 (64bitové systémy), x86 (32bitové systémy) a ARM64 (systémy ARM). Tyto možnosti umožňují spustit nástroj v každé verzi klienta nebo serveru Windows.
Pomocí následujícího příkazu PowerShellu spusťte diskSPD. Nahraďte všechno uvnitř hranatých závorek, včetně samotných závorek, příslušným nastavením.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Tady je příklad příkazu, 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 testovací soubor nemáte, 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 je IO.dat 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 než to. Pojďme rozbalit, co jsme udělali. Za prvé, existují různé parametry, se kterými si můžete porát, 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 NÁSTROJE DISKSPD se rozlišují malá a velká písmena.

-t2: Označuje počet vláken na cílový/testovací soubor. Toto číslo často vychází z počtu jader procesoru. V tomto případě se ke zátěži všech jader procesoru použila dvě vlákna.

-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 zvýšení výkonu 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 V/V testu použila velikost bloku 4K.

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

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

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

-Suw: Zakáže ukládání do mezipaměti pro zápis softwaru a hardwaru (odpovídá -Sh).

-D: Zaznamenává statistiky IOPS, jako je směrodatná odchylka, v intervalech po milisekundách (na vlákno, na cíl).

-L: Měří statistiku 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 do značné míry závisí na vašem prostředí. Jaké je tedy 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ě je k dispozici pět virtuálních počítačů: řadič domény, uzel1, uzel2, uzel3 a uzel pro správu. Samotný cluster je cluster se třemi uzly s třícestnou zrcadlenou strukturou odolnosti. Proto jsou zachovány tři kopie dat. Každý uzel v clusteru je Standard_B2ms virtuální počítač 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. Nakonec má každá jednotka SSD 1 TB paměti.

Testovací soubor vygenerujete v rámci sjednoceného oboru názvů, který poskytuje sdílený svazek clusteru (CSV) (C:\ClusteredStorage) pro použití celého fondu jednotek.

Poznámka

Ukázkové prostředí nemá Hyper-V ani vnořenou virtualizační strukturu.

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

Vysvětlení výstupu

Vybaveni znalostmi parametrů a prostředí jste připraveni interpretovat výstup. Za prvé, cílem předchozího testu bylo dosáhnout maximálního počtu IOPS bez ohledu na latenci. Tímto způsobem můžete vizuálně vidět, jestli v Rámci Azure dosáhnete limitu umělého počtu IOPS. Pokud chcete celkový počet IOPS vizualizovat graficky, použijte Windows Admin Center 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 nekoordinátorového uzlu. Třícestná struktura odolnosti spolu s operací z nekoordinátorového uzlu vede ke dvěma segmentům směrování sítě, což snižuje výkon. Pokud vás zajímá, co je koordinační uzel, nemějte obavy. Dozvíte se o tom v části Co je potřeba zvážit . Červené čtvereče představují kritické body virtuálního počítače a jednotky.

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

Nastavení vstupu

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

Tato část zvýrazňuje informace, jako je čas testu, 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á v průměru dosáhla přibližně 4,67% využití.
Celkový počet vstupně-výstupních operací

Tato část obsahuje tři dílčí části. V první části jsou zvýrazněná data o celkovém výkonu, včetně operací čtení i zápisu. Druhá a třetí část rozděluje 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 120 sekund. Počet IOPS = 234408 /120 = 1953,30. Průměrná latence byla 32,763 milisekund a propustnost byla 7,63 MiB/s. Z dřívějších informací víme, že IOPS 1953.30 se blíží omezení 1920 IOPS pro Standard_B2ms virtuální počítač. Nevěříte tomu? Pokud tento test znovu spustíte s použitím 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 ukazují směrodatnou odchylku IOPS v hodnotě 17,72 (od parametru -D), směrodatnou odchylku latence při 20,994 milisekundách (od parametru -L) a cestu k souboru.

Z výsledků můžete rychle zjistit, že konfigurace clusteru je hrozná. Vidíte, že došlo k omezení virtuálního počítače z roku 1920 před limitem 5000 disků SSD. Pokud byste byli omezeni diskem SSD místo virtuálního počítače, mohli byste využít až 20 000 IOPS (4 jednotky × 5 000) tím, že byste testovací soubor rozprostřeli na více jednotek.

Nakonec se musíte rozhodnout, jaké hodnoty jsou přijatelné pro vaši konkrétní úlohu. Následující obrázek ukazuje 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's Law (Malý zákon). Zákon zavádí myšlenku, že existují tři charakteristiky, které řídí chování procesu, a že stačí změnit pouze jednu, aby ovlivnila ostatní dvě, a tedy celý proces. Takže pokud nejste spokojeni s výkonem vašeho systému, máte tři dimenze svobody, abyste ho mohli ovlivnit. Little's Law 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 "inventář".
Analýza percentilu latence

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

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

Kromě toho "devítky" odkazují na počet devítek. Například hodnota 3-devítky odpovídá 99. percentilu. Počet devítek ukazuje, kolik vstupně-výstupních operací běželo na daném percentilu. Nakonec se dostanete do bodu, kdy už nedává 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 z 234408 operací.

Aspekty ke zvážení

Teď, když jste začali používat DISKSPD, je potřeba zvážit několik věcí, abyste získali výsledky testů z reálného světa. Mezi ně patří věnujte zvýšenou pozornost nastaveným parametrům, stavu a proměnným prostoru úložiště, vlastnictví sdíleného svazku clusteru a rozdílu mezi diskSPD a kopírováním souboru.

DISKSPD vs. real-world

Umělý test nástroje DISKSPD poskytuje relativně srovnatelné výsledky pro vaše skutečné úlohy. Musíte ale věnovat velkou pozornost parametrům, které nastavíte, a tomu, jestli odpovídají vašemu skutečnému scénáři. Je důležité si uvědomit, že syntetické úlohy nikdy nebudou během nasazení dokonale představovat skutečné úlohy 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ů, aby do testu nezasahoval jiný program, a příprava správce výkonu, pokud chcete shromáždit další data. Vzhledem k tomu, že cílem tohoto tématu je rychle zprovoznění programu 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 delikátní věc. To znamená, že existuje mnoho proměnných, které můžou ovlivnit výkon. A proto je pravděpodobné, že se můžete setkat s číslem, které neodpovídá vašim očekáváním. Následující část zvýrazňuje některé proměnné, které mají vliv na výkon, i když nejde o úplný seznam:

Šířka pásma sítě
Volba odolnosti
Konfigurace disku úložiště: NVME, SSD, HDD
V/V vyrovnávací paměť
Mezipaměť
Konfigurace RAID
Segmenty směrování sítě
Rychlosti vřetena pevného disku

Vlastnictví sdíleného svazku clusteru

Uzel se označuje jako vlastník svazku nebo koordinační uzel (nekoordinovaný uzel by byl uzel, který nevlastní 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 síťových segmentů směrování, což vede k nižšímu výkonu (vyšší latence).

Podobně má "vlastníka" i sdílený svazek clusteru (CSV). Sdílený svazek clusteru (CSV) je ale "dynamický" v tom smyslu, že při každém restartování systému (RDP) se bude měnit jeho vlastnictví. V důsledku toho je důležité ověřit, že se diskSPD spouští z koordinačního uzlu, který je vlastníkem sdíleného svazku 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 uzlu1, ale uzel 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é se domnívají, že dokáž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 jednoduchý a rychlý. Myšlenka není chybná v tom smyslu, že testuje konkrétní úlohu, ale je obtížné tuto metodu kategorizovat jako "testování výkonu úložiště".

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

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

Kopie souborů nemusí být optimalizované. Dochází ke dvěma úrovním paralelismu, jedné interní a druhé externí. Interně, pokud je kopie souboru směrovaná na vzdálený cíl, modul CopyFileEx použije určitou paralelizaci. Externě existují různé způsoby volání modulu CopyFileEx. Například kopie z Průzkumník souborů jsou jednovláknové, ale nástroj Robocopy má více vláken. 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. Když jednoduše zkopírujete a vložíte soubor, možná používáte dva disky: zdrojový disk a cílový disk. Pokud je jeden pomalejší než druhý, změříte v podstatě výkon pomalejšího disku. Existují i jiné případy, kdy komunikace mezi zdrojem, cílem a kopírovaným strojem může jedinečným způsobem ovlivnit výkon.

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

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ý soubor clusteru, uvidíte pokles výkonu (IOPS, propustnost a latence), a ne testování, když uzel vlastní sdílený svazek clusteru. Je to proto, že pokaždé, když provedete vstupně-výstupní operaci, systém provede směrování sítě do koordinačního uzlu, aby tuto operaci provedl.

V případě situace se zrcadleným se třemi uzly operace zápisu vždy vytvoří segment směrování sítě, protože potřebuje ukládat data na všech jednotkách na těchto třech uzlech. Operace zápisu proto bez ohledu na to dělají segment směrování sítě. Pokud ale použijete jinou strukturu odolnosti, může se to změnit.

Zde naleznete příklad:

Spuštěno na místním uzlu: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Běží na nemístním uzlu: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

Z tohoto příkladu jasně vidíte, že na následujícím obrázku došlo ke snížení latence, zvýšení počtu IOPS a zvýšení propustnosti, když koordinační uzel vlastní sdílený svazek clusteru.

Úloha OLTP (Online Transaction Processing)

Dotazy úloh OLTP (Update, Insert, Delete) se zaměřují na úlohy orientované na transakce. V porovnání s OLAP (Online Analytical Processing) je OLTP závislý na latenci úložiště. Vzhledem k tomu, že každá operace má málo vstupně-výstupních operací, záleží na tom, kolik operací za sekundu dokážete udržet.

Můžete navrhnout test úlohy OLTP, který se bude soustředit na náhodný a malý výkon vstupně-výstupních operací. U těchto testů se zaměřte na to, jak daleko můžete odeslat propustnost při zachování přijatelných latencí.

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

Velikost bloku 8 kB => podobá se velikosti stránky, kterou SQL Server používá pro své datové soubory.
70% čtení, 30% zápis => podobá se typickému 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 nejsou tyto úlohy citlivé na latenci úložiště. Zvýrazňují řazení mnoha operací do fronty, aniž by se příliš staraly o šířku pásma. V důsledku toho mají úlohy OLAP často za následek delší dobu zpracování.

Můžete navrhnout test úloh OLAP, který se bude soustředit na sekvenční a velký výkon vstupně-výstupních operací. U těchto testů se zaměřte spíše na objem zpracovaných dat za sekundu než na počet IOPS. Požadavky na latenci jsou také méně důležité, ale to je subjektivní.