IOps, MBps i RAID

Stanąłem ostatnio przed pytaniem – Jak to w ogóle policzyć? W internecie można znaleźć stosunkowo dużo materiałów na ten temat. Pewne publikacje skupiają się na IOps’ach, transferach, inne tylko o wpływie RAID na wydajność macierzy itd. Są to głownie opisy anglojęzyczne, dosyć rozproszone, nie wyczerpujące tematu do końca… Dla potomnych zebrałem większość tych informacji… we dwunastu księgach wierszem.

http://www.flickr.com/photos/kubina/326629411/

Myślę, że na wstępie wypada zaznaczyć, że nieważne jak bardzo skrupulatnie wszystko policzymy, to i tak jest to, jak zwykła mawiać moja babcia– nicwarte. Powodów jest kilka, głównym z nich jest parszywa rzeczywistość, która zawsze, usilnie, komplikuje nam życie. Otóż zauważmy, że laboratoryjnym sposobem liczymy tylko i wyłącznie pewien skrawek zjawiska – np. nie bierzemy pod uwagę locków SCSI, opóźnień na kartach HBA itd. To jak usiłowanie udowodnienia bozonu Higginsa bez brania pod uwagę innych elementów teorii strun. W skrócie – wyniki są oczywiście bardzo istotne, jednak trzeba podchodzić do nich z zdrowym rozsądkiem i korygować je doświadczeniem.

Do przykładów będę używać dysku SATA Seagate ST91000640SS Constellation.2. Którego specyfikacje możemy uzyskać z tej strony – http://pdfs.icecat.biz/pdf/28056374-7239-manual.pdf

Na początek trochę teorii… Nie będę was jakoś mocno zamęczał, bo pewnie każdy z Was rozmontował nie jeden dysk w swoim życiu. Powiedzmy, że będzie to szybkie przypomnienie.

Dysk to gramofon. Fakt, jest mniejszy, szybszy i nie da się zmienić płyty, ale idea jest w zasadzie taka sama. Najbardziej interesujący jest talerz wraz z ścieżkami na których znajdują się skonsolidowane w bloki dane. W związku z tym najbardziej z punktu widzenia wydajności interesują nas wartości mechaniczne. Przede wszystkim uśrednione opóźnienie obrotowe (Average Rotational Latency) oraz średni czas poszukiwania (Average Seek Time) dające nam razem średni czas odpowiedzi (Average Response Time) i ilość obrotów talerza na minutę (RPM). Wszystko jest uśrednione, ze względu na budowę dysku.

Revolutions Per Minute (RPM) – Jest to ilość obrotów na minutę talerza z danymi. Następuje tu prosta zależność – im talerz obraca się szybciej tym szybciej magnetyczne ramie głowicy jest w stanie uzyskać dostęp do danych.

Average Rotational Latency (ARL) [ms] – średnie opóźnienie obrotowe, czasami nazywane tylko opóźnieniem (latency) z grubsza wynika z czasu w jaki potrzebuje dysk aby przekręcić talerz pod głowicę w miejsce interesującego nas sektora. Parametr ten, w dyskach obrotowych związany jest z prędkością obracania się talerzy. Dla dysków SSD parametr ten jest mniej istotny, ze względu na ich odmienną budowę.

Average Seek Time (AST) [ms] – Przy dyskach obrotowych średni czas poszukiwania bierze się z czasu jaki potrzebuje zespół głowicy aby dotrzeć do ścieżki w której dane będą zapisywane lub odczytywane dane. Dla dysków SSD ten parametr również jest marginalny, można powiedzieć, że wacha się on między 0,08ms do 0,16ms. [źródło: http://www.tomshardware.com/reviews/short-stroking-hdd,2157.html]

Generalnie można przyjąć, że wartości te wahają się  w zależności od dysku w następujących przedziałach:

RPM

Average rotational latency

Average seek time
5400 5,5 7 – 14,4
7200 4,2 5,9 – 9,1
10 000 3 3,6 – 5
15 000 2 2,7 – 3,7

http://www.symantec.com/connect/articles/getting-hang-iops

Average Response Time (ART) [ms] – Jest to suma wszelkich średnich opóźnień mechanicznych zawiązanych z dostępem głowicy do interesujących nas danych, czyli:

ART = ARL + AST

Jak policzyć maksymalny transfer dysku?

Dokonanie tego jest stosunkowo proste. Należy jednak wykopać ze specyfikacji producenta jeszcze jedną informację – Recording density in BPI (bits/in max). Jest to parametr mówiący nam ile możemy zapisać bitów na cal ścieżki na talerzu. Wartość ta przy dysku ST91000640SS wynosi – 1544000 bits/inch (~0.184Mb). Aby dowiedzieć się jaki jest maksymalny transfer dysku musimy policzyć długość ścieżki. Wiemy, że dysk jest 3,5 calowy tak więc możemy policzyć jego najdłuższą ścieżkę za pomocą wzoru na obwód koła… Zbierając wszystko to do przysłowiowej kupy:

MAXMBPS = ((2pi * (R/2)) * BPI) * (RPM/60)

W naszym przypadku będzie to wyglądać tak:

MAXMBPS = ((2 *3,14 * (3,5/2)) * 0,184) * (7200/60)

MAXMBPS = ~242,66MBps

Jest to oczywiście wynik najlepszy z możliwych i w warunkach raczej niemożliwy do osiągniecia w rzeczywistości. Dla porównania można policzyć również transfer dla najkrótszej ścieżki, dla przykładu 1 cal daje już 69,33 MBps co w sumie przekłada się na średni transfer rzędu ~156 MBps. Pamiętajmy, że dalej jest to wartość jak najbardziej przybliżona i dotycząca najlepszego możliwego „ciągu”. Tak więc wypada to przyjąć jako naszą górną granicę.

Jak policzyć IOps konkretnego dysku?

Jako, że z natury jestem jednostką trudną i wątpiącą, to zawsze zastanawiałem się skąd się bierze założenie, że dysk SATA ma 100 IOps’ów, a SAS 150… Nie dawało mi to spać, więc miałem dwa wyjścia – albo urządzać do końca życia narkotyczno-alkoholowe brewerie kończące się letargiem przeradzającym się w sen, lub po prostu to wyjaśnić. Choć przyznam przez jakiś czas oddawałem się z nieposkromioną przyjemnością pierwszej opcji, to jednak postanowiłem wydorośleć i oto do czego doszedłem.

Generalnie IOps’y biorą się z dwóch parametrów:

Tak więc oba te parametry dają nam wartość IOps – czyli ilość operacji wejścia/wyjścia na sekundę. Liczymy to tak:

DisxIOps = 1/(ARL [s] + AST [s])

Aby jeszcze bardziej wyjaśnić nasze obliczenia weźmy dla przykładu prawdziwe dane, nie zapominając o zmianie jednostek z ms na s:

Dla odczytu: 1/( 0,00416+0,0087) = ~77,7605 IOps

Dla zapisu: 1/( 0,00416+0,0097) = ~72,1501 IOps

Średnio: ~74,9553 IOps

Jak przeliczyć IOps na MBps?

Kolejne pytanie, które na początku wydaje się zupełnie akademickie, jednak trzeba sobie na nie czasem odpowiedzieć. Nie musimy wierzyć żadnym badaniom, ten parametr też możemy policzyć. Poza ilością operacji na sekundę potrzebujemy również rozmiar bloku…

Block size – rozmiar bloku danych, złożonych z sekwencji bajtów, lub bitów. Przyjmuje pewne ustandaryzowane wielkości. Dla przykładu standardowo w systemach z rodziny Windows jest to 4KB dla systemów do 16TB. [źródło: http://support.microsoft.com/kb/140365]

Wzór jest następujący:

MBps = (IOps * Block size)/1024

Po podstawianiu naszych danych otrzymujemy następujące wyniki:

(74,9553 * 4KB)/1024 = 0,29279 MBps

Dlaczego tak wolno? Wynik ten dotyczy zupełnie przypadkowych operacji… w sytuacji naturalnej bardzo często zdarzają się również zapisy ciągłe, co znacząco zwiększa transfer. Według moich obserwacji, można przyjąć, że średnia z maksymalnego ciągłego odczytu, oraz przepustowość wyliczona z IOps’ów daje nam dosyć realną prędkość operacji. W naszym przypadku jest to ~78,146 MBps co faktycznie wydaje się możliwą do osiągnięcia prędkością.

Przypominam, że nie bierzemy w naszych obliczeniach opóźnień na kontrolerach, dodatkowych komend, czasu w kolejkach itd.

Jak policzyć nominalną szybkość RAID?

Wystarczy pomnożyć ilość operacji IO przez liczbę dysków. Czyli jeżeli mamy zbudować macierz składającą się z 12 dysków ST91000640SS to będzie ona miała w sumie:

ARRSumIO: 12 x 74,9553 IOps = 899,4636 IOps

MBpsrand: (899,4636 * 4KB)/1024 = 3,5135 MBps

Oczywiście są to wartości dla RAID0, który nie wpływa na wydajność zapisu…

Jak poziomy RAID wpływają na wydajność?

Znacząco. Sprawa jest prosta, wynikająca z logiki. RAID generalnie działa tak, że podczas jednego zapisu, gdzieś na macierzy dokonywany jest jeszcze przynajmniej jeden w celu zabezpieczenia danych. Ten narzut nazywa się Raid Write Penalty. Dla konkretnych poziomów RAID kształtuje się on następująco:

Raid

Raid Write Penalty

0

1

1

2

5

4

6

6

10

2

DP

2

Żródło: http://www.yellow-bricks.com/2009/12/23/iops/

Co powoduje, że dla przykładu w RAID5 zamiast jednej operacji I/O należy wykonać cztery. Czyli jak się nam wydawało, że wydajność będziemy mieli rewelacyjną… to się grubo pomyliliśmy 🙂

Podczas liczenia operacji dyskowych dla naszej macierzy RAID musimy odpowiedzieć sobie na pytanie jaką mamy charakterystykę zapisów/odczytów.

Jak sprawdzić charakterystykę zapisów/odczytów mojej infrastruktury?

Warto poszukać na internecie pewnych uśrednionych szablonów. Dla przykładu:

Źródło: http://www.symantec.com/connect/articles/getting-hang-iops

Lub wziąć to na tak zwaną chłopską logikę – serwer backupu np. będzie miał 98% zapisów, a serwer WWW 90% odczytów itd. Jeżeli jednak potrzebujemy bardzo szczegółowych informacji z pomocą mogą na przyjść następujące strony:

Jak policzyć faktyczną ilość operacji IO przy zastosowaniu RAID?

Po określeniu proporcji odczytów i zapisów w systemie korzystającym z naszej macierzy, jesteśmy w stanie policzyć faktyczną ilość operacji IO, które może ona wykonać. Dokonamy tego za pomocą tego wzoru:

ARRiops=(ARRSumIO * R%)+((ARRSumIO * W%) /Rp)

R%=5%

W%=95%

Raid Level = 5 ->  Rp= 4

(899,4636 IOps * 0,05)+((899,4636 IOps * 0,95) / 4) = ~258,596 IOps

Idąc krok dalej, możemy oczywiście nieco przebudować nasz wzór. Spróbujmy stworzyć rozwiązanie, w którym będziemy mogli podać jako dane wejściowe wymagane dla naszego system IOps a jako wynik uzyskać ilość dysków.

N = ((ARRSumIO * R%)+(ARRSumIO * W% * Rp)) / Disciops

Czyli w przypadku kiedy będziemy mieli wymaganie 500 IOps przy Raid 5 dla system backupu o charakterystyce R%=5% W%=95% to potrzebujemy co najmniej 26 dysków aby to wymaganie spełnić:

((500 IOps * 0,05) + (500 * 0,95 *4 )) / 74,9553 = 26

Mam nadzieje, że przyda Wam się takie drobne podsumowanie… i kiedy będziecie musieli policzyć sobie IOps’y, MBps’y czy RAIDy nie będziecie musieli przekopywać tak intensywnie internetu. Jeżeli jednak macie na to ochotę, oto linki, które mogą być pomocne:

Zawsze byłem straszną nogą z matematyki, wiec jak znajdziecie jakieś błędy zapraszam do komentowania! 🙂 Dodatkowo chciałbym zaznaczyć, że większości przypadków wnioski w powyższym artykule wyciągnąłem samemu. Byłbym bardzo zadowolony jeżeli doszło by do dyskusji w komentarzach w celu wymiany doświadczeń… artykuł jest otwarty, gdyż, jak wspomniałem wcześniej,  w gruncie rzeczy logika swoją drogą a doświadczenie swoją.