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.