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:

http://www.wmarow.com/strcalc/

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

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ć.

Nie krzycz na swoje dyski!

Dziś znalazłem w sieci ciekawy film ilustrujący efekt krzyczenia na dysk. Wydaje się śmieszne, ale ma sens :)