Zavřít
Vstoupit Následujte nás

3S.cz

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í?

<< Předcházející díl

 

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


Následující díl >>