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 |
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.
3 komentarze:
Maro,
Bardzo fajnie, że opisałeś te testy.
Zarówno zachowanie 3PARa jak i XIV, które testowaliśmy dają bardzo dobre wyniki. Ja jednak doszedłem do wniosku, że jest tak po części dlatego, że te macierze są dobrze zaprojektowane od strony architektury. Ja robiłem testy na innym produkcie z dyskami SATA i otrzymałem mizerne wyniki, niestety nie mogę ich publikować. Jeszcze ciekawszy pomysł zaprezentował SUN w swoich macierzach NAS, gdzie korzysta się wyłącznie z dysków SSD i SATA. Na SSD macierz przechowuje log transakcyjny dla zapisów i cache dla odczytów. Wszystko jest zintegrowane w ramach wspólnej platformy OpenStorage - lada dzień będę posiadał wyniki testów tego urządzenia - zobaczymy jak sobie poradzi w porównaniu do innych graczy na rynku.
Dear All,
Stoimy przed wyborem macierzy XIV (6 półek) do zastosowania w Hurtowni Danych. Jak Wasze testy (czy w ogóle możecie coś o xiv opublikować) wyglądają w kontekście takiego zastosowania tej macierzy, czy po tych kilku miesiącach, Wasza w sumie pozytywna ocena się nie zmieniła ?
Planuję napisać o tym jak w praktyce sprawuje się nasz 3PAR z dyskami SATA. Ogólnie macierz spełnia moje oczekiwania. Jej najsłabszą stroną są oczywiście stosunkowo mało wydajne dyski SATA. Trzeba uważać z uruchamianiem bezpośrednio na macierzy operacji typu: migracje danych, usuwanie dużych wolumenów, tuning wolumenów. Są one wykonywane z niskim priorytetem co może mieć wpływ na wydajność udostępnianych zasobów. Długi czas odpowiedzi dysków SATA powoduje, że niektóre job'y synchroniczne, głównie raporty, nie wykonują się tak szybko jak bym chciał. Mimo, że macierz nie jest obciążona, to taki raport generuje mało i/o (1500 iops, a mógłby 10000 iops). Testy XIV, które robiliśmy z Suchym dały dobre wyniki. Niezadowalający był jednak test pisania na macierz dużym blokiem przy wysokim Write Hit Ratio. Test mający mało wspólnego z rzeczywistością, ale wykazuje jakieś problemy z obsługą pamięci cache.
Prześlij komentarz