PowerStore: Efektivní metody hodnocení výkonu diskového pole

Poznámka: Srovnávací testy jsou platné pouze v případě, že je vše nastaveno podle vzorových postupů pro zařízení PowerStore a nejsou žádné problémy s připojením nebo konfigurací. V opačném případě test pravděpodobně vytvoří irelevantní data.

• Otestujte pomocí proměnných, které se podobají tomu, jaká bude skutečná úloha nebo prostředí. Pamatujte, že většina nástrojů jsou simulátory a nikdy nedosáhnou 100 % skutečné simulované produkční úlohy.
• Pokud je úloha velmi rozsáhlá, zvažte provedení několika iterací testů čtení a zápisu s různými velikostmi bloků a vzory přístupu.
• Pomocí vícevláknových a asynchronních operací nebo testů zajistěte možnosti paralelního nebo souběžného výkonu a zajistěte, aby byl uplatněn celkový potenciál agregované propustnosti. 
• Zvažte a zkontrolujte standardní oborové srovnávací testy pro posuzované zařízení, protože se vztahují k produkčnímu zatížení vaší firmy.
• Vyhněte se testování prázdného systému souborů nebo svazkům s nízkým využitím místa. Pokud předem nepřidělíte místo u úloh zápisu, zobrazí se latence z důvodu přidělování místa za běhu během testu.
• Nezapomeňte otestovat operaci čtení I/O, protože ve většině prostředí je obvykle dominantní. Během testování dávejte pozor na ztrátu balíčků nebo rámců v síťové infrastruktuře.
• Ověřte, že provádíte testování na více zařízeních, abyste mohli simulovat typické prostředí s mnoha hostiteli nebo klienty. Například v zařízení PowerStore je dobrým počtem 16 svazků. Počet svazků se obvykle shoduje s počtem použitých hostitelů nebo klientů (fyzických nebo virtuálních). To je místo, kde je dosaženo souběžnosti.

 

Nástroje a simulátory
pro benchmarkingMějte na paměti, že většina nástrojů jsou simulátory a pravděpodobně se nikdy nesimuluje 100 % skutečné produkční úlohy. Tyto nástroje pro srovnávací testy se používají k získání představy o tom, jaký by mohl být, měl nebo by byl výkon v určitých situacích. Společnost Dell tyto nástroje nevlastní a není zodpovědná za žádné problémy s nimi spojené.

U jakékoli situace testování výkonu se ujistěte, že se používají nástroje s asynchronními a multithreadingovými možnostmi. Příklady těchto nástrojů:

• Flexible I/O Tester (FIO)
• Iometer
• Vdbench (vyžaduje účet Oracle)
• NFSometr (Pouze Fedora/NFS)
• Kontrolní seznam výkonu NAS společnosti Intel

 

Vyhněte se následujícím typům testů:

• Kopírování a vkládání
• Přetažení
• Zálohování jednoho systému souborů na disk
• Testy DD
• Rlarge
• Wlarge
• Mkfile
• Rozbalení, extrahování a komprese

Ve většině scénářů srovnávacího testování je třeba si uvědomit určité věci. Tato část nenahrazuje pochopení velikosti a charakteristik pracovní zátěže. Pokud však nemáte k dispozici data z minulosti a potřebujete hrubý odhad chování aplikace pro srovnávací testování schopností řešení PowerStore (nikoliv výkonnost konkrétní pracovní zátěže), zvažte následující faktory:

 

 

IODepth (hloubka fronty)
Nízká hloubka IO (nebo ne dostatečně vysoká) může v závislosti na situaci omezit potenciální propustnost. Proto vždy ověřte, zda je hodnota IOdepth dostatečně vysoká, aby odrážela nebo emulovala požadavky na souběžnost pracovní zátěže. Příliš nízká hloubka IOdepth nemusí správně využívat plný potenciál zařízení. Dávejte si také pozor na příliš vysokou hloubku IOdepth. Ta může způsobit značné fronty na zařízení a v závislosti na servisní době zařízení může dojít k delší době odezvy. To může odrážet to, jak by přetížený systém mohl vypadat.

U tohoto testu jsou čísla výrazně nižší, když je IOhloubka 1 ve srovnání s IOhloubkou něčeho reálnějšího, například 64. Mějte na paměti, že se jedná o all-flash pole, a proto je tento koncept viděn ve své extrémní, ale stále běžnější podobě."

IOdepth=1", to je přibližně ~30 000 vstupních a výstupních operací za sekundu (IOPS) v průměru pro test.

 

Hodnota „IOdepth=64“ představuje pro daný test průměrně ~107 000 operací IOPS.

 

 

Hodnota „IOdepth=256“ představuje pro daný test průměrně ~142 000 operací IOPS.

 

 

Jak již bylo zmíněno, výkon se ve většině konfigurací vyrovnává při určité hloubce IOdepth. Zde je hloubka fronty 512 a dochází pouze k malému nárůstu operací IOPS z hloubky IOdepth 64.

„IOdepth=512“ je pro daný test průměrně ~146 000 operací IOPS.

 

 


Asynchronní vs. synchronizační
Používají se dva hlavní odlišné motory. Nejoblíbenější a zdaleka nejefektivnější z hlediska výkonu jsou asynchronní operace I/O. Méně účinným a méně výkonným typem modulu jsou synchronní operace I/O a obvykle se používají u aplikací, které mají přísné požadavky na integritu a zajištění dat. Synchronní operace I/O lze nalézt také v technologiích replikace s téměř nulovým cílem RPO (Recovery Point Objective). Při testování výkonu a srovnávacích testech z pohledu hostitele asynchronní znamená, že aby bylo možné požádat o další operaci I/O, není potřeba potvrzení pro jednu operaci I/O. V synchronních operacích je potřeba potvrzení pro operace I/O před vydáním další operace a potvrzení (ACK) pro každou další požadovanou operaci I/O. Proto má synchronní operace I/O obvykle frontu 1 nebo menší a nikdy plně nevyužívá zdroj z plného potenciálu. Spojení synchronních operací s nízkým nebo jedním počtem vláken může vážně omezit výkonnostní potenciál, proto vždy ověřte, zda provádíte asynchronní testování, a pokud používáte synchronní testování, ujistěte se, že používáte více vláken, pokud aplikační prostředí explicitně neodkazuje na to, že to nedělá.

Asynchronní (Libaio – nativní asynchronní Linux) = 1 synchronizace vlákna



(synchronní vstupně-výstupní operace):  

 

 

Počet vláken
Vlákna jsou důležitá. Testování by mělo být vždy prováděno pomocí více vláken, zejména v synchronních testech/úlohách. Jedná se o pokus o simulaci více iterací úlohy nebo testu na základě chování procesu podnikové aplikace. Více vláken ve spojení se souběžnou aktivitou je místo, kde je dosaženo agregované propustnosti systému. Většina asynchronních enginů využívá více vláken, takže se nemusíte tolik starat o počet vláken. Bez dostatečného počtu vláken během synchronních úloh můžete výrazně omezit celkovou potenciální propustnost zátěžového testu proti systému.

Vícevláknový" znamená více vláken, která pracují paralelně. Pokud máte například jedno zařízení, které může obsluhovat 1000 IOPS v synchronní úloze, vyjde to tak, že zařízení má dobu odezvy 1 ms bez fronty (takže bez fronty, čas služby a doba odezvy by měly být synonyma). Je zřejmé, že zařízení s dobou odezvy 1 ms mohou udělat mnohem více práce než 1000 IOPS, a toho je dosaženo stohováním více vláken nebo paralelních datových proudů stejné úlohy. Pokud tedy zvýšíte počet vláken (nebo "věcí provádějících tuto konkrétní úlohu") na 10, nyní máte 10 jednotlivých vláken, která vstupně-výstupní operace se zařízením provádějí rychlostí 1 ms. Každé jednotlivé vlákno úlohy stále získává 1 ms, což znamená, že každé vlákno stále dosahuje pouze 1000 IOPS, ale nyní celý "proces" nebo "úloha", která je spuštěna těmito více vlákny, získává 10 000 IOPS.

Existují nástroje a úlohy, které dokážou adekvátně naplnit limity zařízení pomocí jediného vlákna, a některé potřebují více. Stručně řečeno, při simulaci synchronního zatížení chcete mít co nejvíce vláken, pracovních procesů nebo datových proudů, aniž by to ovlivnilo celkovou dobu odezvy. Existuje bod, kdy zvýšení počtu vláken přestane mít pozitivní vliv (když se zařízení 100% zaneprázdní). Obecně platí, že u asynchronních úloh je počet vláken vyřešen ve výchozím nastavení. Například níže můžete stále vidět rozdíl mezi 1 vláknem a 10 pro asynchronní úlohu, i když není významný. Poučení je to, že u asynchronních úloh se nemusíte tolik starat o vlákna. 

Jedno vlákno zde může dosáhnout 68 000 operací IOPS pomocí asynchronního modulu „libaio“. 

 

Pokud zvýšíte počet vláken (numjobs) na 10, stále se zobrazí zvýšení IOPS.

 

Pokud jde o synchronní pracovní zátěž, jedná se sice o extrémní případ, ale vzhledem k synchronní povaze se může jednat o dva hlavní faktory, které z tohoto testu dělají špatně fungující test. 

odeslat I/O-1, čekat na ACK, poslat I/O-2, čekat na ACK atd.

 A nemožnost stohovat více vláken pro stejný účel. 

job1=poslat I/O-1 - job2=poslat I/O-1 - job3=poslat I/O-1..... job1=získat ack, poslat I/O-2 - job2=získat ack, poslat I/O-2 - job3= získat ack, poslat I/O-2 atd

Přímý příznak

V některých nástrojích, zejména v nástrojích/operačních systémech založených na *nix, můžete vidět možnost „Direct I/O“. To lze použít u „asynchronních“ modulů a nemělo by se to zaměňovat se „synchronními“ operacemi I/O. V některých nástrojích bez zadání tohoto příznaku můžete zapisovat do cache serveru a ne přímo na disk. Hostitel chce obejít vlastní cache a zapisovat přímo na disk. To je při testování úložiště zásadní faktor. Pokud máte nastaven příznak „direct“, technicky vzato zapisujete na disk, i když „diskem“ je v tomto případě ve skutečnosti cache úložiště. To je stále přijatelné pro účely testování, protože i se správnou úlohou stále simulujete a přesně napodobujete, jak se tato úloha chová v reálném prostředí, protože produkční zatížení také zasáhne mezipaměť před odesláním zpět potvrzení. (Neciťte se podvedeni jen proto, že se jedná o výkonová čísla mezipaměti, a ne jen back-endové spindle.)

 

Šířka pásma (MB/s) vs. propustnost (IOPS)

Existují dvě hlavní hlediska, která můžete testovat. Propustnost ve světě sítí a výkonnosti se obvykle vztahuje k přenosu dat, avšak v prostředí SAN/bloků se běžně používá „propustnost“ pro označení operací IOPS. Proto musíte nejprve porozumět charakteristikám zátěže, které testujete.

Šířka pásma (MB/s) – šířka pásma je míra dat, která se vejdou najednou (nebo v intervalu X, obvykle "za sekundu") do kanálu nebo systému. To znamená, že měří, kolik dat jste přenesli za určitý časový úsek. Ačkoli se šířka pásma a operace IOPS navzájem nevylučují, můžete mít vyšší nebo nižší čísla šířky pásma při stejném množství operací IOPS; vše závisí na velikosti bloku. Nezapomeňte, že pomocí šířky pásma neměříte rychlost, rychlost je něco úplně jiného, a i když má vliv na šířku pásma, je to obvykle něco, co nemůžete u zátěže s velkou šířkou pásma ovlivnit. Proto při testování šířky pásma vždy používejte větší bloky (v rozumných mezích), aby vaše data na vstupně-výstupní operace byla větší, než kdybyste testovali IOPS, protože obsluha větších bloků bude přirozeně trvat déle. Pokud například chcete dosáhnout rychlosti 1 MB/s, ale používáte bloky o velikosti 8 KB, musíte k dosažení tohoto cíle využít přibližně 125 operací IOPS. Pokud byste však používali bloky s kapacitou 512 kB, trvalo by to pouze dva (2) IOPS.
(Pokud byste zachovali 125 IOPS a stále zvětšili velikost bloku z 8 kB na 512 kB, nyní odesíláte 64 MB/s!)

Protože je však v rámci jednoho vstupu/výstupu více dat, "zabalení" těchto vstupně-výstupních operací obvykle trvá déle (nalezení, zřetězení atd.). Proto může být doba obsluhy přirozeně vyšší. Někdy máte menší frontu, takže doba odezvy, i když je přirozeně vyšší, by měla být poměrně blízko. Mějte na paměti, že ačkoli doba odezvy hraje roli v tom, jaké šířky pásma můžete dosáhnout, nárůst množství dat na jednu operaci I/O obvykle převáží mírný nárůst doby odezvy (RT) na daný typ operace I/O. Vzhledem k tomu, že doba odezvy je vyšší, nechcete, aby úlohy velkých bloků musely být náhodné. Úlohy související s šířkou pásma tedy bývají sekvenční. Když zavedete náhodnou povahu velkého blokového pracovního zatížení, stabilní rychlost přenosu dat se neustále přeruší a začnete pociťovat účinky mírně vyšší doby odezvy na vstupně-výstupní operace.

Propustnost (IOPS) – Propustnost/IOPS je nejběžnější perspektivou u úloh malých bloků, zejména proto, že se stávají náhodnějšími. Cokoli nad 32–64 KB lze považovat za velký blok. U propustnosti jsou nejdůležitější výše uvedené faktory (věci jako počet vláken, synchronní nebo asynchronní operace, hloubka fronty atd.) Zde se nesnažíte měřit, kolik dat celkově dokážete přenést během intervalu X, ale spíše kolik jednotlivých balíčků (požadavků I/O) nesoucích tato data se snažíte obsloužit (každý interval x). Prostředí, jako je OLTP (bankovnictví), se příliš nestarají o to, kolik dat mohou přenést, protože jejich datová stopa je obvykle malá. Tyto malé datové sady však mohou být a obvykle jsou vytížené. Tyto datové sady mají vysokou úroveň nerovnoměrné distribuce (je odkazováno na malé množství prostoru, ale agresivně a konzistentně se mění). Malé balíčky dat obvykle obsahují pouze požadavky na změnu/aktualizaci bloků s číselnými nebo menšími řetězcovými hodnotami, a proto nejsou zapotřebí velké balíčky I/O. Vzhledem k povaze transakcí a k tomu, že jich je mnoho, však chceme ověřit, zda dokážeme držet krok s každým jednotlivým požadavkem. Obvykle platí, že čím menší je velikost bloku, tím více operací IOPS lze v daném scénáři dosáhnout, a přestože jsou zátěže malých bloků většinou spojeny s náhodným přístupem, lze dosáhnout ještě větší propustnosti při sekvenčních zátěžích malých bloků. Sekvenční zátěže s malými bloky jsou však specifické a ne tak běžné, proto tyto scénáře testujte pouze v případě, že to vaše prostředí vyžaduje.