Pokazywanie postów oznaczonych etykietą macierz. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą macierz. Pokaż wszystkie posty

2012/12/20

Trzy warstwy macierzy dyskowej


Kilka miesięcy temu uczestniczyłem w spotkaniu organizowanym przez IDC. Miało ono śniadaniową formule, a tematem przewodnim miały być oszczędności w IT. Okazało się, że mowa była tylko o rozwiązaniach cloud'owych sponsora tego posiłku  Słowo "oszczędności" padło raz i to w złym kontekście. Nie ukrywam, że bylem rozczarowany, czemu nawet dałem wyraz w końcowej dyskusji (od tej pory zaproszenia  na kolejne spotkania przestały przychodzić :)). Okazało się jednak, że ten czas nie był do końca stracony. A to za sprawa Grzegorza, managera z T-mobil. W swojej prezentacji przedstawił on koncepcję 3 warstw technologii:

- standaryzacja
- wirtualizacja
- automatyzacja

Za pomocą tej koncepcji zgrabnie wyjaśnił czym dla niego jest chmura prywatna. Z czasem dotarło do mnie, że ten sam schemat sprawdza się tez w odniesieniu do innych technologi IT, w tym do macierzy dyskowych.

Standaryzacja dotyczy tu sprzętu.  Macierz zbudowana jest z fizycznych elementów tj. szafy, kontrolery, interfejsy, półki dyskowe, dyski. Aktualnie producenci stosują standardowe komponenty.  Hardware macierzy można skompletować bez problemu w sklepie typu Komputronik. W roli kontrolerów występują tu bowiem zwykle serwery, wyposażone w powszechnie używane podzespoły. Dyski dostarcza jeden z 2 producentów -  Seagate albo Hitachi, a protokół łączący wszystko to dobrze znane SCSI w wersji serial - SAS. Sprawia to, że w zasadzie hardware w rozwiązaniach rożnych producentów jest bardzo podobny. Różnice wynikają ze sposobu wykorzystywania tego żelastwa  Odpowiada za to system operacyjny macierzy. To tutaj zaszyte są te wszystkie wspaniale możliwości obiecywane przez vendorów.
standardowy sprzęt

Już od dawna jedna z podstawowych funkcji jaka realizuje oprogramowanie macierzy dyskowej jest wirtualizacja. Dzięki niej zasoby logiczne udostępniane przez macierz nie są na sztywno związane ze sprzętem  W połączeniu z redundancja  wirtualizacja daje wysoką dostępność  Awaria dysku, portu czy nawet całego kontrolera nie oznacza utraty danych ani dostępu do nich. Aktualnie nawet najprostsze rozwiązania posiadają tą funkcjonalność  Kolejnym dobrodziejstwem wirtualizacji jest możliwość reorganizacji logicznych zasobów macierzy "w locie", bez odłączania ich od serwera.  Możemy zmieniać zasobom poziom RAID, przenosić je na inne warstwy dysków (7k, 10k, 15k, SSD). Pozwala to na dopasowywanie możliwości zasobu do zmieniających się wymagań aplikacji.
wirtualizacja

Sama wirtualizacja pozwala na wykonywanie takich operacji w sposób ręczny, na podstawie decyzji administratora. Od kilku lat powstają mechanizmy, które przekazują to zadanie macierzy dyskowej. To jest własnie  trzecia warstwa pamięci masowej -  automatyzacja. Nowoczesna macierz alokuje fizyczne zasoby na podstawie rzeczywistych potrzeb wynikających z charakteru operacji generowanych przez aplikacje. Co więcej  jeżeli zmieni się charakter tych operacji to macierz sama potrafi się do tego zaadoptować  Automatyzacja sprawia, że znikają w macierzy podziały na warstwy i grupy RAID. Staje się ona jedna przestrzenią na dane. Tworząc zasób logiczny nie musimy zastanawiać się, na których dyskach powinien on leżeć  Tworzymy go po prostu na macierzy. Zajmuje on dokładnie tyle miejsca ile rzeczywiście potrzebuje. Jego bloki lezą na dyskach zgodnie z realnym zapotrzebowaniem. Jest łatwiej, wydajniej i bardzo efektywnie.
automatyzacja

Na rynku są dostępne rożne rozwiązania. Cześć przeszła wszystkie etapy rozwoju pamięci masowej. Nowe funkcjonalności są w nich wdrażane zgodnie z wymaganiami stawianymi przez zmieniającą się rzeczywistość i są opcjonalne. Na drugim biegunie stoją macierze dyskowe tworzone przez nowe start-upy takie jak Pure Storage, czy Nimbus Data. Tutaj automatyzacja jest naturalnym trybem pracy.

Standaryzacja, wirtualizacja, automatyzacja - co dalej?

2010/02/01

raid slider - zrzut wyników

Raid Slider ma nową funkcjonalność - zrzut danych do tabeli.


Możliwe jest zapamiętanie w ten sposób wyników dla 5 konfiguracji.

2010/01/29

i/o tuning - aix

Tym razem kilka informacji na temat strojenia i/o w systemie Aix (5.3 i 6.1). (Pozwolę sobie przekopiować część ogólnych informacji z poprzedniego wpisu z tej kategorii.)

- długość kolejki niepotwierdzonych operacji i/o (outstanding i/o queue depth)

Każde zlecenie z systemu operacyjnego do macierzy dyskowej wymaga potwierdzenia. Zawiera ono informacje o statusie zakończenia operacji i/o. Nie jest jednak powiedziane, że system musi czekać z wysłaniem nowego zlecenia na potwierdzenie zakończenia poprzedniego. System posiada kolejkę, w której umieszcza zlecone operacje i/o. Czekają one tam na potwierdzenie ich wykonania. Długość tej kolejki określa ile zleceń system może wysłać. (tu przeczytasz o tym więcej).
W systemie AIX kolejkę taką posiadają zarówno poszczególne lun'y jak i kontrolery (scsi, iscsi, fc). Parametry te są atrybutami tych urządzeń. W przypadku lun'ów jest to queue_depth. Jego wartość sprawdzamy tak:
# lsattr -El hdisk??
(...)
queue_depth 16 Queue DEPTH True
(...)
a zmieniamy tak:
# chdev -l hdisk?? -a queue_depth=??
Atrybut odpowiedzialny za długość kolejki na kontrolerze ma inną nazwę - num_cmd_elems. Aby sprawdzić jego wartość:
# lsattr -El fcs??
(...)
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
(...)
Przy zmianie:
# chdev -l fcs?? -a num_cmd_elems=??
Zmiany obu tych atrybutów wymagają zamknięcia dostępu do modyfikowanych urządzeń - umount systemów plików, varyoff na grupach volumenowych.
Długość kolejki decyduje o ilości operacji i/o na sekundę (iops) jaką może zlecić system operacyjny. Zwiększanie go nie ma sensu jeżeli macierz nie jest w stanie wykonać tylu IOPS. Często jednak macierz może więcej, ale system jest ograniczany krótką kolejką. Widać to po różnicy w czasie wykonania operacji i/o na macierzy (szybko) i czasie wykonania operacji i/o w systemie (długo). W takiej sytuacji wydłużenie kolejki powinno zwiększyć wydajność.


2009/09/03

Sun F5100 - macierz modułów FMod

W marcu Sun ogłosił nowy standard - Open Flash Module - pamięć flash w postaci modułu ze standardowym złączem SO-DIMM. Urządzenie zbudowane z wykorzystaniem tych modułów miało pojawić się w lipcu. Prawdopodobnie zawirowania związane z przejęciem Sun'a przez Oracle spowodowało opóźnienie. Produktu ciągle nie ma, ale chyba już niedługo się pojawi. Wnioskuje to po tym, że na stronach z dokumentacją pojawiły się manuale do Sun Storage F5100, pierwszej macierzy zbudowanej z Flash Module (FMod).
Urządzenie może zostać wyposażone w maksymalnie 80 pamięci FMod. Ich wielkość nie jest jeszcze znana. Prawdopodobnie będzie to 64GB. Daje to 5 TB surowej przestrzeni. Nie jest to macierz FC, ani iSCSI. Do łączenia z hostami przeznaczone jest 16 portów SAS, co daje możliwość podłączenia do 64 komputerów.

2009/08/07

Data Storage Directory

W ostatnich tygodniach pracowałem nad nową zawartością mojej strony www.wmarow.com. Konkretnie przygotowywałem katalog sprzętu storage'owego. Właśnie go uruchomiłem:
Docelowo chcę tam załadować informacje o produktach głównych producentów macierzy i przełączników SAN. Aktualnie jest to pierwsza wersja katalogu, nie pozbawiona błędów i nie dociągnięć. Wprowadziłem już do niego trochę informacji. Nie jestem jednak pewien, czy uwzględniłem wszystkie istotne parametry i dane. Bardzo liczę na pomoc w tym temacie. Proszę o uwagi, sugestie i informacje o błędach.

2009/06/07

Storagefocus - Jak zmierzyc wydajność macierzy dyskowej

Krzyśka, redaktora naczelnego magazynu Storagefocus znam od pierwszej klasy szkoły podstawowej. Chodziłem wtedy do kółka informatycznego, które prowadził jego tata. Krzysiek mnie pewnie nie kojarzy z tego okresu, ja go jednak dobrze pamiętam. Był jedynym "kółkowiczem", który zamiast grać wpisywał do swojego ZX Spectrum jakieś tajemnicze kody :)

Po kilkunastu latach spotkałem go na jakiejś konferencji o Storage. Był wtedy jeszcze redaktorem w IDG. Teraz współtworzy nowe, kierunkowe wydawnictwa w ramach platformy ITfocus.
Krzysztof zaproponował mi publikację tekstów o tematyce storage w ramach porad ekspertów na Storagefocus. W piątek 5 czerwca ukazał się pierwszy artykuł - Jak zmierzyć wydajność macierzy dyskowej. W dużej części zawiera on wpisy z tego bloga. Połączyłem je w jeden tekst, trochę oszlifowałem i ubarwiłem. Zapraszam do lektury.

2009/04/14

Symmetrix V-Max, a 3PAR T800

W poprzednim wpisie porównałem nową macierz EMC do IBM XIV. Jednak dużo bardziej V-Max przypomina macierz 3PAR T800. Każde z tych rozwiązań zbudowane jest z 8 równolegle pracujących węzłów/kontrolerów (u EMC moją one nazwę V-Max engine). W obu przypadkach węzeł to tak naprawdę całkiem mocny komputer zbudowany na standardowych komponentach (procesory Intel, pamięci DDR, kontrolery frontend i backend w postaci kart PCIe). Różnica jest w sposobie łączenia ich ze sobą. 3PAR wykorzystuje sztywny backplane, a EMC sieć, co daje możliwość dużo większej skalowalności (teoretycznie nawet do 256 węzłów). Dyski w każdym z rozwiązań umieszczone są w półkach i dołączane są po optycznym FC.

Okazuje się, że podczas, gdy wszyscy ewangeliści EMC wieszali koty na 3PAR'ze, inżynierowie uważnie przyglądali się tej firmie i ich produktowi. Nie sposób nie zauważyć, że architektura V-Max'a w dużej mierze czerpie z pomysłów i rozwiązań zastosowanych w macierzach S-Class i T-Class od 3PAR'a. EMC jednak mocno rozbudowało tą koncepcję. Zastosowano wspomnianą sieć, V-Max Engine jest tak naprawdę dwu-węzłowym klastrem, procesory są mocniejsze, pamięci RAM jest dużo więcej (do 1024 GB), dysków więcej (do 2400), to samo z ilością portów FC, obsługiwanych protokołów i platform serwerowych.  
Sprzęt to jednak nie wszystko. Software jest równie, a nawet bardziej istotny (przykład XIV - oni nawet nie robią swojego hardware'u). Tutaj różnica może być znacząca. W 3PAR'ze soft był od początku przygotowywany pod architekturę macierzy. Tymczasem EMC jak widać dostosowało system ze starych Symm'ów do potrzeb V-Max. Co z tego wyszło? - zobaczymy. Mam jednak nadzieję, że hypery, metavolumen'y i binfile'e znikną z nomenklatury EMC :)
Ciekawe jak wprowadzenie Symmetrix V-Max wpłynie na pozycję w sumie małej firmy jaką jest 3PAR. Z jednej strony pojawił się im wielki konkurent. Z drugiej strony potwierdziło się, że ich  wizja budowania macierzy dyskowych była właściwa. EMC stawia w tym obszarze pierwsze kroki, a 3PAR ma stabilny i solidny sprzęt, kilka lat doświadczeń i bazę zadowolonych klientów. Powinni to wykorzystać.

Symmetrix V-Max (wideo)

A oto jak wygląda nowy Symm. I uwaga, największa niespodzianka - to jest macierz modułowa! Jest to klaster wielu węzłów (do 256) połączonych siecią. Przypomina to konstrukcję IBM XIV, z tą różnicą, że EMC dostarcza swój hardware. Myliłem się. Ta macierz to bardzo mocno zmieniony Symmetrix. W zasadzie to zupełnie inna architektura. EMC odeszło od koncepcji macierzy monolitycznej z centralnym backplane'em w kierunku rozwiązania sieciowego.


Jak widać z przodu prezentuje się dużo lepiej niż od tyłu - ta plątanina kabli :(

EMC Symmetrix V-Max !

No i jest. Nadszedł oczekiwany 14 kwietnia i już wiadomo o co chodzi. EMC prezentuje nowego Symmetrix'a.



Jednak nie nazywa się DMX-5. Wprowadzone zmiany jak widać zasługiwały na większą modyfikację nazwy. Imię najnowszego dziecka EMC to V-Max. Litera V pochodzi od modnego słówka Virtual. W oficjalnym ogłoszeniu pojawiło się dużo słów na V - Virtual Matrix Architecture (nowa platforma sprzętowa), Virtual Server (lepsza integracja z VmWare), Virtualized Data Centre (wspólna wizja z Cisco i ich Unified Computing).
Oczywiście nowa macierz jest większa i szybsza - do 128 procesorów Xeon, 1 TB pamięci globalnej, 2400 napędów dyskowych lub SSD. Daje to możliwość skonfigurowania wydajnego rozwiązania o pojemności do 2 PB (peta bajtów) zabezpieczonej przestrzeni. Całkiem imponujące. Nie są to jednak informacja, na które czekałem. Miałem nadzieję na bardziej gruntowne zmiany w samej architekturze Symmetrixa. Z dostępnych danych nie jestem w stanie stwierdzić zakresu tych zmian.
Jest jednak jedna nowa technologia, na którą bardzo czekałem. Nazywa się Fully Automated Storage Tiering ("FAST"). Automatyczne przenoszenie danych między warstwami pamięci masowej. Ta funkcjonalność plus możliwość instalowania w Symm'ie różnych rodzai dysków i SSD daje możliwość efektywnego wykorzystania macierzy. Intensywnie dostępowane dane wylądują na SSD, a archiwa na dyskach SATA. Ciekawy jestem jak to będzie działało w praktyce.
Dzisiaj o 16:00 jest oficjalny webcast i może wtedy pojawi się więcej szczegółów. Póki co to tyle.

2009/04/07

3PAR F-Class - nowość w midrange

Wczoraj firma 3PAR przedstawiła nową serię macierzy typu midrange. F-Class, bo taką ma nazwę, to następca serii E. Główne różnice to nowy ASIC - Gen3 (ten sam co w serii T) oraz skalowalność do 4 node'ów/kontrolerów. Jednocześnie zwiększyła się maksymalna liczba dysków - z 128 do 256. Macierz występuje w dwóch wersjach F200 (2 node'y) i F400 (4 node'y).


3PAR reklamuje ten sprzęt jako pierwszą macierz klasy midrange, która łamie barierę 2 kontrolerów w ramach jednego urządzenia. Jest to niewątpliwie wyróżniająca cecha. Biorąc pod uwagę, że do każdego z węzłów możliwe jest skonfigurowanie aktywnego połączenia dla każdego z serwowananych wolumenów, cecha to staje się wielką zaletą tego rozwiązania. Dzięki czterem aktywnym ścieżkom zwiększa się dostępność danych. Akcje serwisowe (wymiana karty, node'a, firmware ...) można przeprowadzić na systemie bez rezygnowania z redundancji.
Najlepsze jest jednak to, że w obie serie macierzy 3PAR posiadają te same ASIC'i, ten sam system operacyjny InForm OS i te same funkcjonalności. Dzięki temu możliwe jest np. zestawienie replikacji z dużego systemu T800 do małej, midrange'owej macierzy F200. Trudno sobie to wyobrazić dla pary EMC DMX-4 i Clariion CX-4, albo HDS 9990V i AMS2100.
Nowe macierze nie supportują SSD. Ta modna technologia nie jest specjalnie lubiana w 3PAR. Zapewne konieczne są głębsze zmiany w systemie InForm, aby efektywnie wykorzystać możliwości pamięci Flash. Szum wokół SSD na rynku jest bardzo duży. Powinno to stymulować 3PAR do intensywnej pracy w tym temacie.
Poprzednia seria E-Class nie była zbyt popularna u nas w Polsce. Głównie przez cenę, która wcale nie była atrakcyjna w porównaniu do innych rozwiązań midrange. Ciekawe jaką teraz strategię cenową zaprezentuje 3PAR/Polcom.

2009/04/02

EMC zapowiada nowości

Dostałem dziś na skrzynkę zaproszenie na oficjalne ogłoszenie nowości w ofercie EMC. Wygląda na to, że szykuje się coś ciekawego. Na tą okazję została przygotowana strona - http://www.overtakethefuture.com/.


Ani z w zaproszeniu, ani na tej stronie nie ma nic konkretnego. Jestem szczerze zaciekawiony co tam wymyślili nowego. Hasło przewodnie - "Wirtualne Data Centre przyszłości". Z innego źródła wiem, że sprawa dotyczy prezentacji nowego Symmetrix'a. Może się jednak okazać, że zostaną przedstawione też inne produkty.
Symmetrix wymaga gruntownego odświeżenia. Macierz ta została zaprojektowana w latach 80'tych poprzedniego stulecia. Teraz jest szybsza, większa i ma więcej funkcjonalności, ale jej architektura jest ewidentnie stara. Powoduje to, że np. zarządzanie tym sprzętem to koszmar admina. Może mało obiektywnie, ale obrazowo przedstawiło to XIV w porównawczej reklamie swojej macierzy.

2009/03/26

Bufory i/o - czy response time jest istotny!?

System operacyjny bez mechanizmu buforowania operacji i/o działa bardzo niewydajnie. Za każdym razem gdy zapisuje lub odczytuje dane z pamięci masowej, musi czekać na potwierdzenie jej zakończenia. Dopiero wtedy kolejne zlecenie może być wysłane. Dostęp do dysków w takim systemie realizowany jest w 100% synchronicznie. Przy średnim czasie odpowiedzi na zlecenie wynoszącym 5ms, wydajność podsystemu i/o wynosi raptem 1000/5 = 200 IOPS. Całe szczęście takich systemów już chyba nie ma.

We współczesnych OS'ach wykonuje się jednocześnie wiele procesów i wątków. Wiele z nich używa pamięci masowej w tym samym momencie. Dodatkowo duża część aplikacji korzysta teraz z dysków w sposób asynchroniczny. Działa to tak, że po zgłoszeniu żądania zapisu/odczytu proces/wątek nie zatrzymuje się. Zajmuje się innym zadaniem, a do poprzedniego wraca jak dostanie od systemu informacje o wykonaniu żądania. Wszystko to powoduje, że konieczny jest mechanizm umożliwiający wysyłanie do pamięci masowej wielu operacji i/o jednocześnie. Nie oznacza to, że można zapomnieć o potwierdzeniach. Są one niezbędne dla poprawności składowanych danych.
Zależnie od systemu operacyjnego, mechanizm ten różnie się nazywa. Zasada działania jest jednak wszędzie prawie taka sama. Żądania zapisu/odczytu po wysłaniu do pamięci masowej są zapisywane w specjalnym buforze i zostają tam aż przyjdzie potwierdzenie ich wykonania. Dzięki temu system nie musi czekać z wysłaniem nowej operacji i/o na zakończenie poprzedniej. Wiele zleceń i/o może wykonywać się jednocześnie.
Opisywany mechanizm jest umiejscowiony zależnie od OS na poziomie dysku/lun'a albo portu FC/SCSI/iSCSI, albo w obu miejscach jednocześnie. Może też dotyczyć wszystkich dysków/portów lub każdego z osobna. Parametr systemowy odpowiedzialny za jego wielkość ma też różne nazwy. Przykłady:
AIX: indywidualnie dla każdego portu FC (num_cmd_elems) i dysku (queue_depth)
Solaris: globalnie dla wszystkich dysków (sdd_max_throttle)
Windows: indywidulanie dla każdego z portów FC (dla qlogic - execution throttle) globalnie dla wszystkich dysków (DriverParameter -> qd)
Wielkość tego buforu bezpośrednio wpływa na ilość IOPS jaką serwer jest w stanie zlecić do macierzy. Przykłady:
średni czas odpowiedzi=5ms, bufor=4, 1000/5 * 4 = 800 IOPS
średni czas odpowiedzi=5ms, bufor=8, 1000/5 * 8 = 1600 IOPS
Nie jest jednak powiedziane, że im większy bufor tym lepsza wydajność. Po drugiej stronie stoi bowiem macierz dyskowa, która też ma przecież swoje limity.
I teraz właśnie dochodzę do sedna sprawy. Czy czas odpowiedzi macierzy jest istotny dla jej wydajności? Nie ma wątpliwości, że tak. Dzięki buforom można jednak ograniczyć jego wpływ. Przykłady:
średni czas odpowiedzi=25ms, bufor=20, 1000/25 * 20 = 800 IOPS
średni czas odpowiedzi=25ms, bufor=40, 1000/25 * 40 = 1600 IOPS
Nie można przesadzić z wielkością buforów. Porty po stronie macierzy są w stanie obsłużyć ograniczoną liczbę niezakończonych operacji - od kilku do kilkunastu tysięcy.
Mechanizm ten nie spowoduje, że wydajność dysków wzrośnie do poziomu SSD, których czas odpowiedzi jest o rząd wielkości krótszy. Może jednak sprawić, że na dyskach 7200 RPM uda się zrobić konfigurację tak wydajną jak przy użyciu dysków 15000 RPM. Przykład dla RAID 0, 50% odczytów, 50% zapisów, 0 trafień w cache:
20 * 15000 RPM, array IOPS=3598, czas odpowiedzi=5ms, liczba buforów=18, host IOPS=3600
49 * 7200 RPM, array IOPS=3615, czas odpowiedzi=15ms, liczba buforów=55, host IOPS=3630
Cena tego rozwiązania będzie niższa, pojemność ponad 2x większa, a wydajność jak widać niemal identyczna.

2009/02/09

NearLine for Online - historia zmiany mojego nastawienia do dysków SATA

Jakiś czas temu firma 3PAR sformułowała hasło "3PAR NearLine for Online". W ten sposób przekonują, że ich macierz z dyskami SATA poradzi sobie nie tylko jako przestrzeń archiwalna, ale również jako macierz na potrzeby innych, bardziej wymagających zastosowań. Czytałem o tym jeszcze zanim 3PAR pojawił się w naszej serwerowni. Traktowałem to wtedy raczej jako hasło marketingowe, a nie realną możliwość. Dlatego też wszystkie dyski w naszym 3PAR'ze to FC 10k RPM. Po migracji danych okazało się, że macierz w szczytach obciążona jest w 20%. Teraz po blisko roku eksploatacji, podwojeniu wykorzystanej przestrzeni i ilości podłączonych serwerów utylizacja dysków ledwo dochodzi do 40%. Wydaje się, że zastosowanie tej samej ilości 2x mniej wydajnych dysków 7200 RPM miało by sens. Ta obserwacja była pierwszym etapem zmiany mojego podejścia do tematu NearLine.
We wrześniu poprzedniego roku uczestniczyłem w prezentacji nowego nabytku firmy IBM - macierzy XIV. Jest to urządzenie, w którym nawet nie ma możliwości użycia innych dysków niż SATA. Wiedząc o tym, nie miałem zbytniej ochoty tracić czas na słuchanie o tym sprzęcie. Ze spotkania wyszedłem jednak z ogromną chęcią na przetestowanie tego rozwiązania. 
Testy wykonaliśmy razem z Suchym zdalnie na box'ie ze 180 dyskami 1 TB SATA (wtedy była to jedyna możliwa konfiguracja XIV). Okazało się, że macierz całkiem nieźle sobie radzi. Po tym doświadczeniu byłem już prawie przekonany, że dyski NearLine są realną alternatywą dla FC.
Ostatnim etapem zmiany mojego nastawienia były testy jakie wykonaliśmy z Lee Angel i Billem McCormack z 3PAR na macierzy T400 wyposażonej w 80 dysków 7200 RPM 750 GB. W zasadzie to testy wykonał Bill zgodnie z moimi wymaganiami, a ja z Lee obserwowaliśmy je poprzez zdalną sesję WebEx. Użyliśmy oprogramowania vdbench  zainstalowanego na jednej maszynie x86 z Linux'em, podłączonym do macierzy 4 linkami 4 GB/s. 
O ile w przypadku XIV domyślając się oczywistej odpowiedzi IBM'a, nawet nie pytałem się o zgodę na publikację wyników testów, to w przypadku 3PAR'a nie miałem takich oporów i zgodę otrzymałem. Już kilkakrotnie wspominałem, że będę chciał o tym napisać. Chcąc zrobić to rzetelnie starałem się wyliczyć jakie są oczekiwane wyniki poszczególnych testów. Efektem tych starań jest mój kalkulator. Do wyliczeń użyłem poniższych parametrów środowiska i testów:
  • Disk capacity  - 750 GB
  • Disk rotation speed - 7200 RPM
  • Disk ave seek latency - 9 ms
  • Number of disk - 80
  • RAID level - 10
  • stripe size - 256 KiB
  • vdbench block size - 0,5 KiB
A oto parametry poszczególnych testów, ich spodziewane rezultaty i faktycznie osiągnięte wyniki:
%reads / %writes / % read cache hit ratio / %write cache hit ratio / io size | expected iops | achieved iops |
  • 70/30/80/20/8k |  9 520, 98 |  11 216, 26 |
  • 70/30/80/20/32k  |  8 726, 12 |   8 122, 95 |
  • 100/0/0/0/8k |  5 903, 01 |   9 178, 55 |
  • 0/100/0/0/8k |  2 951, 50 |   2 365, 97 |
  • 100/0/0/0/256k |  3 040, 94 |   3 973, 60 |
  • 0/100/0/0/256k |  1 520, 47 |      942, 31 |
Vdbench bardzo trafnie rozkładał operacje po wystawionej przestrzeni dzięki czemu faktyczna ilość trafień w cache odpowiadała prawie dokładnie ustawionym parametrom. Dwa pierwsze testy przedstawiają najczęściej występującą charakterystykę przetwarzania w mojej firmie. Pozostałe miały na celu sprawdzenie jak sobie macierz radzi w skrajnych sytuacjach. Z wyjątkiem testu 100% zapisów, wszystkie nietrafione w cache, blok 256 KiB, wyniki są bardzo dobre. Ten jeden wynik nie jest najlepszy, macierz osiągnęła tylko 62% spodziewanej wydajności. Nie udało mi się wyjaśnić z czego wynika takie zachowanie 3PAR'a. Test ten nie odzwierciedla jednak realnego przetwarzania dlatego też uważam, że macierz spełniła moje oczekiwania, a moje nastawienie do dysków NearLine jeszcze bardziej się poprawiło.
Co w tych dyskach SATA jest takiego fajnego, że tak bardzo staram się udowodnić tezę "NearLine for Online"? A więc tak:
  • niska, przynajmniej teoretycznie cena - w praktyce jest różnie, zależnie od producenta
  • duża pojemność - są już przecież dyski SATA 2 TB
  • niski pobór prądu
Z tego wynika, że macierz zbudowana z takich dysków będzie w porównaniu do macierzy z dyskami FC - tańsza, mniejsza, oszczędniejsza w utrzymaniu. Jedynym problemem jest wydajność. Receptą na ten problem jest jednak zastosowanie odpowiedniej macierzy, takiej jak 3PAR, XIV, Pillar czy też Compellent. Wszystkie one wykorzystują mechanizm "wide striping", czyli rozłożenia pojedynczego wolumenu na dużej ilości dysków. W ten sposób, możemy osiągnąć duże ilości IOPS nawet na dyskach SATA. 
Wszystko to jednak tylko teoria. Mam nadzieję, że będę mógł sprawdzić ją w praktyce, ale to zależy od tego kto wygra przetarg na naszą nową macierz :) 
Historia się nie kończy. Tak więc c.d.n.

2009/01/14

Disk & disk array calculator

Zakładając tego bloga nie zdawałem sobie sprawy jak bardzo przysłuży się on do pogłębienia mojej wiedzy. Jasne jest, że pisząc uporządkowuje sobie różne informacja, ale przy okazji pojawiają się pytania. "Im więcej wiem tym mocniej wiem jak wiem niewiele." - rozumiem to od dawna, ale wcześniej nie czułem potrzeby szukania odpowiedzi na takie pytania. Jednak pisanie i publiczne publikowanie tych tekstów zobowiązuje. Dzięki temu szperam w sieci i wypytuję różnych ludzi o szczegóły, które kiedyś nie miały dla mnie znaczenia. Ogólnie to po prostu zaczęło mi się chcieć.

Ten przydługi wstęp ma wyjaśnić skąd wzięła się u mnie ochota na zrobienie kalkulatora storage'owego. Myślałem już o tym wcześniej, ale dopiero teraz przelałem to w czyn i tak oto jest.


Kalkulator na podstawie podanych informacji o dyskach, macierzy i serwerze wylicza różne parametry. Zamieściłem go w sieci na swojej wskrzeszonej stronie domowej:


Jest to pierwsza wersja, zapewne nie pozbawiona błędów - zapraszam do testowania. Będę wdzięczny za uwagi.

2009/01/13

Wielkości bloków, a wydajność

Od kilku tygodni w wolnych chwilach pracuję nad wynikami testów wydajnościowych macierzy 3PAR. Głównie to zajęcie polega na wyliczeniu maksymalnych możliwych do osiągnięcia rezultatów testowanej konfiguracji. Wartości te będę chciał potem porównać z faktycznymi wynikami.  Stworzyłem formułę, która wylicza potrzebne mi dane. Okazało się jednak, że jest ona niekompletna. Nie uwzględniała ona bowiem faktu, że pojedyncza operacja I/O może wykonać się na więcej niż jednym dysku.

Wbrew pozorom nie jest to sytuacja bardzo rzadka. Zdarza się bowiem tak, że operacja IO dotyczy bloku danych, który leży na dwóch, a nawet większej ilości dysków. Koszt wykonania takiej operacji na backend'zie macierzy będzie przez to odpowiednio większy. 

Prawdopodobieństwo wystąpienia tej sytuacji zależy od dwóch parametrów - wielkości bloku jakim operuje aplikacja (block size) i  wielkości bloku jakim operuje macierz dyskowa (stripe size).  Napisałem wzór, który wylicza jaka jest szansa na trafienie jednym blokiem w więcej niż jeden dysk:

((block size * 2) - 1) / (stripe size * 2)

Jest to wzór uproszczony, w którym założyłem, że aplikacja wybiera bloki z dokładnością co do 512 bajtów. W ten sposób działa narzędzie vdbench>, którego używałem do testowania 3PAR'a.

Po dodaniu do wyniku 1, otrzymujemy średnią ilość dysków jakie zastaną zaangażowane do obsłużenia operacji IO:



Dopasowanie bloków aplikacji i macierzy jak widać jest bardzo istotnym elementem strojenia podsystemu dyskowego i warto o tym pamiętać.

2008/12/19

Liczenie wydajności macierzy

Już od tygodnia przymierzam się do opublikowania wyników testów macierzy 3PAR z dyskami NearLine. Powody przeciągającego się przygotowywania do tego aktu są dwa. Pierwszy to brak czasu spowodowany końcem roku, zbliżającymi się świętami i padniętym dyskiem w firmowym pececie (proszę się nie śmiać). Drugim powodem był brak wszystkich danych potrzebnych mi do napisania tego tekstu. Konkretnie brakowało mi formuły do wyliczenia wydajności macierzy przy zadanej charakterystyce przetwarzania. Wynik tej formuły chcę porównać z rzeczywistymi osiągami macierzy, co da mi jako-taki obraz testowanego sprzętu.

Znalazłem wolną chwilę i z pomocą Ani napisałem formułę, która wydaje się, że jest ok. Przygotowałem odpowiedni arkusz i wrzuciłem go na Google Docshttp://spreadsheets.google.com/ccc?key=p1Eb9oyys8Yahfh7yF5g8MA. W innej wolnej chwili zrobię kawałek strony WWW z tą formułą. Póki co można wyeksportować ten dokument do xls'a i edytować w Excel'u.

Sprzęt jest tak mocny jak najsłabszy jest jego element. W przypadku macierzy tym elementem jest dysk. Dlatego w moim sposobie liczenia wydajności nie biorę pod uwagę innych podzespołów macierzy. Wynik formuły to maksymalna ilość losowych operacji IO możliwa do osiągnięcia z macierzy przy zadanej charakterystyce przetwarzania, z określonej ilości dysków jednego typu, sformatowanych w jednym rodzaju RAID. Przyznaję, że jest to mocno uproszczone podejście do tematu. Jestem jednak zdania, że daje w miarę wiarygodne wyniki.  A oto parametry formuły:
W tym miejscu planowałem zamieścić wzór i jego opis, ale sobie to odpuszczę. Zainteresowani i tak pewnie sprawdzą jak to wygląda w arkuszu, a dla innych byłoby to trochę nudne. Poza tym jest już późno i idę spać.

Teraz jak już mogę wyliczyć sobie wszystkie dane to myślę, że już niedługo napiszę o wspomnianych testach.

2008/12/10

Dlaczego RAID10 jest szybszy od RAID5?

Przyznam się, że na to pytanie bardzo długo odpowiadałem w durny sposób, o tak: "Dla RAID5 kontroler macierzy musi wyliczać parzystość danych co powoduje jego słabszą wydajność." Nie mogę patrzeć na bzdurę, którą właśnie napisałem, a przecież przez wiele lat było to moje zdanie w tym temacie. Częściowo słuszne może ono było, ale do lat 90'tych poprzedniego stulecia, kiedy procesor w kontrolerze nie był dość szybki. Oto kolejny przykład na to, że uczyć się trzeba cały czas i że warto zwracać uwagę na zmieniające się warunki.

Kontrolery aktualnie to mocne maszyny, które przy liczeniu parzystości nie kucają :) Co więc powoduje, że RAID5 ze względu na swoją gorszą wydajność nie jest lubiany np. przez Oracle'a? Powodem jest jego większa zachłanność na najbardziej deficytowy towar w macierzy dyskowej - ilość operacji IO. Przy pojedynczej operacji zapisu na wolumen w RAID5 wykonywane są na dyskach 2 odczyty i 2 zapisy, podczas gdy w RAID10 zachodzą przy tym tylko 2 zapisy. Czyli np. grupa dysków w RAID5 o wydajności 800 IOPS (suma IOPS dysków) podczas zapisów będzie mogła obsłużyć tylko 200 IOPS. Raczej spory spadek wydajności. Te same dyski w RAID10 obsłużą 2x więcej IOPS - 400. Operacje odczytu będą wykonywane z pełną wydajnością grupy w obu przypadkach. Przy charakterystyce operacji 50% odczytów/50% zapisów osiągniemy w tych przypadkach odpowiednio ~320 IOPS z RAID5 i ~533 IOPS z RAID1.
W tradycyjnej macierzy gdzie grupa dyskowa to kilka, kilkanaście dysków, różnica przy zapisach na te dwa typy RAID'u jest na tyle duża, że wybór jest oczywisty. Niestety lepsza wydajność RAID1 kosztuje gorszą efektywność wykorzystania przestrzeni dyskowej. W nowych rozwiązania takich jak 3PAR czy Pillar Axiom, w których wolumeny "rozsmarowane" są po wielu dyskach większa ilość IO generowane przez RAID5 nie jest już tak istotna. Odpowiednio duża ilość dysków w takim box'ie zapewni nam wydajność wystarczającą dla niemal dowolnych systemów bez względu na typ raid'u. Tu jednak też znajdą się przypadki takich aplikacji dla których RAID5 nie będzie dość wydajny.

(korzystałem z informacji z bloga Storage Advisors)

2008/12/04

SPC-1 TOP5 w kategorii macierz

SPC nie publikuje wyników swoich benchmarków w formie ułatwiającej porównywanie testowanych sprzętów. Sprzedawcy i presalesi producentów i dystrybutorów sprzętu storage co i raz pokazują nam odpowiednio przygotowane rankingi SPC, na których to ich produkt jest najlepszy. Odpowiednio manipulując danymi i czasami lekko oszukując każdemu może to się udać. Przykład z wrześniowej konferencji SNIA: IBM pokazuje, żę ich SVC 4.3 jest na pierwszym miejscu - nieprawda! - wynik TMS RamSan-400 jest lepszy. Co prawda RamSan to zupełnie inna kategoria sprzętu - macierz DDR, ale w takim razie dlaczego SVC - appliance/wirtualizator - jest porównywane z macierzami?

Wykonałem mrówczą pracę i przepisałem wyniki SPC-1 do tabelki i teraz mogę robić swoje rankingi. Na początek TOP5 w kategorii macierz dyskowa. Wygląda to tak:



1. 3PAR T800
2. HDS USP V/HP XP24000/SUN 9900V (to samo pudło w różnych kolorach)
3. IBM DS8300 Turbo
4. Fujitsu ETERNUS8000 Model 1100
5. Fujitsu ETERNUS6000 Model 1100

DS8300 jak widać ma jeszcze niewykorzystany potencjał. Testowana macierz miała tylko 512 dysków i na każdego z nich przypadło aż 240 IOPS. Wydaje się, że większa ilość dysków mogłaby poprawić ogólny wynik.

2008/12/02

Wyniki SPC-1 w tabelce

Po firmowym wyjeździe integracyjnym jestem chory. Organizm osłabiony alkoholem nie był w stanie obronić się przed mazurskimi wirusami, czy też jakimiś bakteriami. Wziąłem zwolnienie i siedzę w domu. Trochę z nudów, ale bardziej z od dawna narastającej potrzeby postanowiłem efektywnie wykorzystać ten czas i zrobiłem tabelkę z wynikami SPC-1. Można ją obejrzeć tu: http://spreadsheets.google.com/pub?key=p1Eb9oyys8YYm0R9yJf-tRg. Siedziałem pewnie ze dwie godziny i klepałem. Starałem się sprawdzać, ale jakieś literówki mogły się przemknąć. Teraz pewnie się okaże, że w sieci taka tabelka jest już od dawna :) Trudno - ja nie mogłem znaleźć. 

Do czego mi te dane? A no na przykład do zrobienia takiego oto wykresu:


No tak - słabo widać. A więc tłumaczę - wykres pokazuje jak ilość dysków w testowanej macierzy (niebieska linia)  wpływa na liczbę SPC-1 IOPS™ przypadającą na pojedynczy dysk w tej macierzy (czerwona linia). Jak widać po linii trendu (czarna) im więcej dysków, tym z dysku mniej IOPS'ów. Z czego to może wynikać. Może z tego, że operacje IO na poszczególnych dyskach w macierzy z dużą ich ilością są bardziej losowe niż w mniejszych pudłach. Jaki z tego wniosek? Może taki, że jeżeli zależy nam na wysokiej wydajności pamięci masowej, to nie warto wypełniać macierzy dyskami do oporu, a lepiej postawić obok drugiego box'a. Oczywiście wszystko to tylko teoria. Właściwym impulsem do wykonania tego obrazka była jedna z prezentacji na ostatniej konferencji SNIA w Warszawie, ale o tym innym razem.