Zavřít
Wprowadź Śledź nas

3S.cz

Sekcja specjalistyczna

JAK WYBRAĆ MACIERZ – część 3

08.10.2015, 15:12

Podczas gdy w poprzednich dwóch odcinkach naszego popularnego on-line serialu poświęciliśmy się technicznym parametrom możliwych rozwiązań, w dzisiejszym odcinku poznacie praktyczne zalecenia, których dotrzymanie by miało eliminować rozczarowanie z wybranego. Jak zatem ogłosić zadanie?

Powiedzmy, że teraz już jest CIO (Chief Information Officer) we fazie, że się wie, co się chce – czy raczej już wie, czego się nie chce. Zwrócono się już do różnych dostawców, a każdy z nich prezentuje to swoje jako absolutny hit. Jak się w tym zorientować i nie dać się nabrać?

 

USTALIĆ PEWNE PARAMETRY MOŻLIWE DO ZMIERZENIA

Do nich należą wymagane pojemności, wydajność oraz funkcjonalność oprogramowania, jako: Automatyczny Tiering, Dynamiczne Przydzielanie (Dynamic Provisioning), Migawki (Snapshoty), Klony, Replikacje…

Z punktu widzenia architektury jest również dobre ustalić zestaw testów akceptacyjnych sprawdzających, czy macierze są naprawdę redundantne i czy awaria jednego z komponentów nie spowoduje braku dostępu do danych.

Wróćmy znowu do wydajności, z nią jest największy problem. Jeśli będziemy mierzyć odczyt lub zapis, przypadkowe lub sekwencyjne operacje, w małych lub dużych blokach, na jednym lub wielu strumieniach (stream) itd., to zmierzymy zupełnie inne parametry wydajności w macierzy.   

Jeśli jako zleceniodawca nie sprecyzujecie rodzaju działania, potem to sam dostawca wybierze warunki testu, które mu w pełni odpowiadają, a później już jest tylko jeden mały krok od tego, aby przetarg wygrało to, co już na samym starcie będzie samo w sobie wielkim kompromisem.

 

JAK USTALIĆ TESTY WYDAJNOŚCI

Jest to możliwe najlepiej dzięki dokładnemu ustaleniu, jaki program będzie wykorzystany w ramach testu oraz jakie będzie miał ustalone parametry. Istnieje cała masa programów do wyboru, np. IOMeter, IOZone, a jeśli ktoś chce program, który posiada autorytet, tak wybierze np. Microsoft i jego narzędzie testowe SQLIO.

Ważne jest, aby test przebiegał nie tylko na jednym, ale na całym szeregu konkurencyjnych LUNów, a to w taki sposób, aby na opracowaniu obciążenia brały udział wszystkie procesory i kontrolery. Jedynie tak się wykaże, jaki wpływ będą miały na siebie poszczególne LUNy w trakcie planowanej ostrej eksploatacji. 

Testy by miały respektować logikę eksploatacji, które generują bieżące aplikacje – te w większości komunikują wielkością bloku 4-16 kB dla przypadkowych operacji i >64 kB dla operacji sekwencyjnych.

Jednak narzędziem, które jest w stanie solidnie zapełnić macierz, jest już wcześniej wspomniane  SQLIO. Dlatego następujące wyniki testów opierają się właśnie na nim, nadszedł czas, aby go przedstawić. Chodzi o urządzenie, które tworzy obciążenie pracą (workload) wobec macierzy. Jest możliwe tak definiować wielkość bloków, typ eksploatacji (random/sequential), ilość konkurencyjnie testowanych plików itd.

Przykład składni:

Sqlio.exe –kR –s360 – frandom – o8 – b8 – LS – Fparam.txt

Gdzie – kR: random eksploatacja, -s360: czas testu v sekundach, -b8: wielkość bloku 8 kB, -Fparam.txt: odniesienie do testowanych dokumentów.

Wyliczenie parametrów nie jest kompletne, szczegóły można wyszukać w instrukcji. Wynikiem oprócz IOPs i MB/s jest przede wszystkim Histogram latencji. Chodzi o kompletną informację, która podpowie dużo o przyszłym zachowaniu się storage. Histogram nie mówi tylko o osiągniętej wydajności, ale również o jej stabilności. A mianowicie, czy latencja się trzyma blisko średniej wartości lub wręcz przeciwnie chaotycznie od niej ucieka – a to jest właśnie niestabilność dana architekturą macierzy.

 

TESTY WYDAJNOŚCI W PRAKTYCE

Do przetargu, który się naprawdę odbył, zgłosiły się 3 macierze dyskowe klasyfikujące się do kategorii Enterprise:

-          Hitachi HUS-VM (Flash + dyski)

-          Konkurencyjna macierz 1 (SSD + dyski)

-          Konkurencyjna macierz 2 (Full Flash Array)

Na początek trzeba powiedzieć, że wszystkie trzy macierze osiągnęły podobne wyniki z punktu widzenia ilości obsłużonych operacji za sekundę (IOPs). Również wszystkie trzy macierze poradziły sobie 100% operacji obsłużyć w czasie do 5 milisekund.

Pomimo to istotna informacja jest ukryta w szczegółach – a to w stabilności wyników:

-       Najlepsze wyniki osiągnęła macierz HUS-VM, 75% operacji obsłużyła pod 1 ms, 100% operacji pod 2 ms.

-          Ani konkurencyjna macierz 1 nie była taka zła – 71% operacji obsłużyła pod 1 ms. Jednak wyniki nie były w pełni stabilne a z powodu wewnętrznych nakładów pracy z metadanymi, latencja czasem odskoczyła na granicę 3-4 ms.

-         Konkurencyjna macierz 2 (Full Flash Storage) nie była w stanie obsłużyć żadnej transakcji pod 1 ms.

 

PODSUMOWUJĄC, CO POWIEDZIEĆ NA KONIEC?

Swoja przewagę potwierdziła macierz HITACHI HUS-VM a to przede wszystkim w trakcie testów nad realnymi danymi.  W odróżnieniu od testów syntetycznych w trakcie rzeczywistej eksploatacji się potwierdziło, jak istotną rolę spełnia wielkość cache, która w przypadku HUS-VM była 256 GB. Nie tylko sam stosunkowo duży rozmiar cache, ale przede wszystkim zaawansowana logika jego kierowania, kiedy się odzwierciedla jedynie WRITE operacje (nie READ, te można w momencie awarii modułu cache wczytać bezpośrednio z dysku), spowodowały wysoki procent operacji obsłużonych bezpośrednio z cache.

Podczas gdy testy syntetyczne uczyniły z macierzy Hitachi HUS-VM lekkiego faworyta w procesie przetargu, tak praktyczne testy z porcjami operacji baz danych w pełni potwierdziły jej pierwszeństwo.

Zamawiający dzięki jasnemu i niedyskryminującemu ustaleniu wymaganych właściwości i charakterystyk wydajności, otrzymał wysokiej jakości sprzęt komputerowy, który spełnia wymagania jego businessu z potencjałem wydajności, który jest w stanie rozwiązywać wymagania odnośnie rozszerzenia wydajności oraz pojemności na następnych 5 lat.