Cała prawda o wydajności twardych dysków i (część prawdy o) SSD.

Zapraszam do lektury mojego nowego artykułu na storagefocus.pl - Cała prawda o wydajności twardych dysków i SSD. W oryginalnym tytule było "... i część prawdy o SSD". Nie znam jeszcze SSD tak dobrze jak HDD. Jak widać Krzysztof zmienił tytuł - pewnie za długi.

Tekst ten pierwotnie pisałem na zamówienie innego wydawnictwa. Został on jednak oceniony przez redakcję jako nieatrakcyjny dla czytelników. Próbowałem też w innych poczytnych serwisach z równie miernym skutkiem. Szkoda, że z tą wiedzą tak trudno się przebić do rynku masowego. W zamian za to ludzie otrzymują informacje i porady o wątpliwej przydatności.

Czytając to, odniesiecie wrażenie, że uważam mój artykuł za wartościowy materiał. Tak też jest. Na podstawie doświadczeń, dociekań, szperania i podpytywania napisałem tekst, który jest sprzeczny z powszechnie przedstawianą "prawdą" o wydajności pamięci masowej. Niestety wiedza w nim zawarta ciągle dostępna jest tylko dla wąskiego grona specjalistów. Sorry, zazwyczaj jestem bardziej skromny :)

Dzięki Krzysztofie za itfocus.pl, jedno z nielicznych miejsc na obiektywne dziennikarstwo techniczne.

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)

Pierwsze wyniki SPC-1C - dyski SATA 1TB

Storage Performance Council - organizacja, która opracowała i wykonuje testy wydajnościowe systemów pamięci masowej opublikowała niedawno (15 października) pierwsze wyniki SPC-1C i SPC-2C. Testy z C jak component na końcu jak sama nazwa sugeruje zostały opracowane do sprawdzenia wydajności pojedynczych komponentów środowiska storage, takich jak karty HBA, czy też, jak w tym przypadku, dyski HDD. 

Sponsorem akcji był Seagate. Firma ta jednak nie ograniczyła się do udostępnienia tylko swoich dysków. Do testów trafił również sprzęt konkurencji - Hitachi, Samsung i Western Digital. 

Z mojego punktu widzenia, punktu, którym jest biurko admina storage w firmie z niezliczoną ilością baz danych, najciekawszy jest SPC-1C. Oparty na swoim starszym, większym bracie bez C na końcu ma za zadanie zmierzyć wydajność komponentu w warunkach przetwarzania danych w typowej aplikacji biznesowej (baza danych, system pocztowy). Operacje i/o w takim systemie charakteryzują się dużo losowością i małym blokiem danych. Przestrzeń na testowanym sprzęcie dzielona jest na trzy części (ASU). Każda z nich odpowiada różnym typom danych - Data Store, User Store, Log Store. Na każdym z ASU uruchamiane są sesje (i/o stream) realizujące przetwarzanie zgodne z typem ASU. Wynik podawany jest w jednosce określonej jako SPC-1C IOPS™. W dokładną specyfikację SPC nigdy  nie chciało mi się wnikać. Uznaję, że skoro testy opracowały mądre głowy, to ma to sens. Nie rozumiem jednak dlaczego benchmark był wykonywany tylko na  połowie dostępnej powierzchni każdego z urządzeń, co na pewno pozytywnie wpłynęło na osiągnięte rezultaty (mniejsze opóźnienia w związku z krótszym ruchem głowicy). 

SPC nie publikuje wyników w postaci tabelki z konkretnymi liczbami. Dlatego też przygotowałem stosowne  zestawienie.

Wyniki jak widać mocno rozstrzelone. Nie ma też wątpliwości dlaczego to Seagate zdecydował się na sponsorowanie testu. 

Liczymy, liczymy ...

W poprzednim wpisie wspomniałem o average random IOPS dla dysku twardego. Z tego względu, że z oczywistych powodów parametr ten nie jest podawany w żadnych folderach, broszurach itp. warto wiedzieć jak go policzyć samodzielnie. 

Potrzebujemy do tego informacji, które są jawnie publikowane przez producentów: RPM dysku (ilość obrotów na minutę) oraz średniego czasu przesunięcia/pozycjonowania głowicy (seek time). Weźmy dysk Seagate Cheetah 15k.6 - 15000 RPM, 3,65 ms średni seek time. Liczymy ile trwa pół obrotu dysku (o tyle bowiem średnio dysk musi się zakręcić, aby dotrzeć do wskazanego sektora z danymi):

1/(15000/60)/2 = 2ms

Dodajemy do tego średni seek time (jest to wartość średnia bowiem seek time jest różny zależnie od tego czy operacją jest odczyt, czy też zapis):

2 ms + 3,65 ms = 5,65 ms

W ten sposób uzyskujemy czas jaki średnio potrzebuje dysk na obsługę jednej losowej operacji i/o. Teraz wystarczy tylko wyliczyć ile takich operacji jest w stanie wykonać w ciągu sekundy i mamy nasze średnie IOPS dla operacji losowych:

1/5,65 ms =~ 174 IOPS

Niska wartość tego parametru wynika z opóźnień mechanicznych elementów dysku - ruch głowicy i obroty dysku.  I to właśnie jest największą wadą dysków twardych. Nie można jej wyeliminować. Co więcej nie ma pomysłu jak w dysku zmniejszyć opóźnienia mechaniczne. Bez tego ilość IOPS, wartość mająca zasadnicze znaczenia dla wydajności HDD, nie wzrośnie.

Poniżej przykład kilka dysków z wyliczonym IOPS i wielkości transferów w kB dla różnych wielkości bloku.

Wcześniej do przykładów brałem dyski Hitachi. Okazało się jednak, że ta firma cwanie publikuje tylko seek time dla operacji odczytu - krótszy niż dla zapisu.

Dysk vs. macierz dysków

No i znowu. Kolejny raz muszę odpowiedzieć na TO pytanie. Pytanie, które pada zaraz po tym jak wymieniam kwotę, którą musi wyłożyć biznes za przestrzeń dyskową dla ich aplikacji. Brzmi ono mniej więcej tak: Czy nie lepiej kupić do serwera dysk 1TB ? albo tak: Może podłączymy nowy dysk po USB? Pytanie to może przybierać jeszcze różne inne formy, ale zawsze chodzi o to samo - o potrzebę zrozumienia faktu, że przestrzeń w macierzy kosztuje średnio 20x tyle co przestrzeń na dysku twardym i co on (biznes) za te pieniądze tak naprawdę dostaje. 

Kiedyś, w takiej sytuacji opowiadałem o przeróżnych wspaniałych cechach tych wielkich szaf wypakowanych dyskami, o RAID-ach, redundacji, replikacji, snapshotach ... Zainteresowany przy tym potoku nie zawsze zrozumiałych dla niego nazw i pojęć potakiwał głową i w końcu wykładał pieniądze na kolejne terabajty na swój ukochany system. Niestety odchodził nie do końca przekonany. Wiem o tym, bo po kilku tygodniach, czy miesiącach pytanie w lekko zmienionej formie powracało.

Teraz mam inną metodę - metodę szoku opartego na odsłonięciu zakamuflowanego przez producentów najbardziej istotnego parametru dysku - average random IOPS - średniej ilości losowych operacji zapisu/odczytu możliwych do wykonania w ciągu jednej sekundy. Kryje się on za innymi eksponowanymi, wielkimi liczbami: tysiące RPM, dziesiątki i setki megabajtów transferu, terabajty pojemności ... Jak tymczasem wygląda przy tym IOPS? Weźmy dla przykładu jeden z najszybszych dysków SATA na rynku - Hitachi Ultrastar A7K10000 - liczymy, liczymy i wychodzi 81. Słownie: osiemdziesiąt jeden. Dysk FC jest lepszy? Jasne, przecież kosztuje kilka razy więcej, mimo, że pojemność kilka razy mniejsza - Hitachi Ultrastar 15K300 - raptem 185 IOPS. 

I teraz na pytanie o możliwość zastosowania dysku "z giełdy na Batorego" w środowisku produkcyjnym odpowiadam np. tak: Owszem, ale oznacza to dla systemu transfery na poziomie 650 kB/s (81 x średnia wielkość operacji I/O, w tym przykładzie 8kB). Ten argument kończy dyskusję, pieniądze na macierz się pojawiają, a TO pytanie już nie wraca.