Odborná sekce
JAK VYBRAT DISKOVÉ POLE – 3. díl
08.10.2015, 15:12
Zatímco v předchozích dvou dílech našeho populárního on-line seriálu jsme se věnovali technickým parametrům možných řešení, v dnešním díle se dozvíte praktická doporučení, jejichž dodržení by mělo eliminovat zklamání z vybraného. Jak tedy vypsat zadání?
Řekněme, že nyní je již CIO ve fázi, že ví se, co se chce – či spíše má jasno v tom, co se nechce. Jsou osloveni různí dodavatelé a každý prezentuje to svoje jako naprostou špičku. Jak se v tom vyznat a nenaletět?
STANOVTE JASNĚ KVANTIFIKOVATELNÉ PARAMETRY
Těmi jsou požadované kapacity, výkonnosti a softwarové funkcionality jako Automatický Tiering, Dynamic Provisioning, Snapshoty, Klony, Replikace…
Z hlediska architektury je pak dobré stanovit sadu akceptačních testů ověřujících, zda diskový systém je opravdu redundantní a výpadek jedné komponenty nezpůsobí nedostupnost dat.
Ale zpět k výkonnosti, s tou je největší potíž. Zcela jiné výkonnostní parametry na diskovém poli změříte, když bude měřeno čtení či zápis, náhodné či sekvenční operace, v malých či velkých blocích, na jednom či mnoha streamech atd. Pokud jako zadavatel nespecifikujete druh provozu, potom si dodavatel zvolí podmínky testu, které mu hrají do karet a pak už je jen krok k tomu, aby se vysoutěžilo něco, co hned na startu bude samo o sobě velkým kompromisem.
JAK STANOVIT VÝKONNOSTNÍ TESTY
Lze tak učinit nejlépe přesným stanovením, jaký program se na testování použije a jak bude mít nastavené parametry. Programů je na výběr celá řada - např. IOMeter, IOZone a kdo chce posvěcení nějakou autoritou - např. Microsoftem, zvolí testovací utilitu SQLIO.
Důležité je testovat ne pouze na jednom, ale na řadě konkurenčních LUNů tak, aby se na zpracování zátěže podílely všechny procesory a controllery. Jen takto se prokáže, jak se v plánovaném ostrém provozu budou jednotlivé LUNy vzájemně ovlivňovat.
Testy by měly respektovat logiku provozu, které generují běžné aplikace - ty většinou komunikují velikostí bloku 4-16 kB pro náhodné operace a >64 kB pro sekvenční operace.
Utilitou, která však dokáže spolehlivě zahltit diskové pole, je zmíněné SQLIO. Protože následující výsledky testů jsou postaveny právě na něm, je na místě si jej představit. Jde o nástroj, který vytváří workload vůči diskovému poli. Lze definovat velikosti bloků, typ provozu (random/sequential), počty konkurenčně testovaných souborů atd.
Příklad syntaxe:
Sqlio.exe – kR – s360 – frandom – o8 – b8 – LS – Fparam.txt
Kde – kR: random provoz, - s360: délka testu v sekundách, - b8: velikost bloku 8 kB, - Fparam.txt: odkaz na testované sbory.
Výčet parametrů není úplný, podrobnosti lze dohledat v manuálu. Výsledkem je krom IOPs a MB/s zejména Histogram latencí. Jde o komplexní informaci, která napoví mnohé o budoucím chování storage. Histogram nevypovídá pouze o dosaženém výkonu, ale i o jeho stabilitě. Tedy zda se latence poslušně drží okolo průměrné hodnoty, nebo zda naopak od ní chaoticky ustřelují – což je právě nestabilita daná architekturou diskového pole.
VÝKONNOSTNÍ TESTY V PRAXI
Na startovní čáru tendru, který skutečně proběhl, se postavily 3 diskové systémy pozicující se do kategorie Enterprise:
- Hitachi HUS-VM (Flash + disky)
- Konkurenční systém 1 (SSD + disky)
- Konkurenční systém 2 (Full Flash Array)
Na úvod je třeba říci, že všechny tři systémy dosáhly podobných výsledků z hlediska množství obsloužených operací za sekundu (IOPs). Všechny tři systémy také zvládly 100% operací obsloužit v čase do 5 milisekund.
Nicméně podstatná informace je skryta v detailech – a to ve stabilitě výsledků:
- Nejlepších výsledků dosáhl systém HUS-VM, 75% operací obsloužil pod 1 ms, 100% operací pak pod 2 ms.
- Ani konkurenční systém 1 si nevedl špatně – 71% operací obsloužil pod 1 ms. Výsledky však nebyly zcela stabilní a z důvodu interní režie práce s metadaty latence občas odskakovaly na hranici 3-4 ms.
- Konkurenční systém 2 (Full Flash Storage) nedokázal žádnou transakci obsloužit pod 1 ms.
CO ŘÍCI ZÁVĚREM?
Svůj náskok potvrdil systém HITACHI HUS-VM zejména při testech nad reálnými daty. Oproti syntetickým testům se u skutečného provozu potvrdilo, jak významnou roli hraje velikost cache, která v případě HUS-VM byla 256 GB. Nejen samotná relativně vysoká velikost cache, ale zejména pokročilá logika jejího řízení, kdy se zrcadlí pouze Write operace (nikoliv Read, ty lze v případě výpadku cache modulu načíst přímo z disku), způsobily vysoké procento operací odbavených přímo z cache.
Zatímco syntetické testy učinily systém Hitachi HUS-VM mírným favoritem v procesu výběrového řízení, tak praktické testy nad dávkami databázových operací jasně potvrdily jeho prvenství.
Objednatel díky jasnému a nediskriminujícímu stanovení požadovaných vlastností a výkonnostních charakteristik získal kvalitní hardware, který pokrývá potřeby jeho businessu s výkonnostním potenciálem schopným řešit požadavky na rozšíření výkonů a kapacit pro následujících 5 let.