Isilon, krótka historia o prostym a wielkim korporacyjnym storage.

Słowo „easy” jak nauczają pokolenia ewangelistów marketingu jest jednym z uwielbionych dogmatów IT. Wszystko jest easy – serwery, macierze, systemy i idee. Jakby tak na to wszystko popatrzeć przez ten pryzmat, to specjaliści IT muszą być kompletnymi idiotami i nierobami. Wszystko w końcu jest takie proste, zunifikowane, przyjemne i w zasadzie bezobsługowe… a profesjonalista IT, według 99% prezentacji marketingowych składa się wyłącznie z kawy, którą dzięki temu, że nic się nie dzieje, bo wszystko dzieje się samo może na bieżąco uzupełniać… Tak więc mamy słowo „easy” – polska wymowa „izi”, anglieska „isi”.

isilon0

Mamy również słowo „Babilon”. Bez wątpienia oznacza ono nazwę starożytnego miasta w Mezopotamii, którego ogrom i przepych nadały mu dodatkowo miano synonimu gwarnego, wulgarnego, pełnego grzechu mega miasta. W popkulturze Babilon to również synonim wysysającej jestestwo, krwiopijczej kultury korporacji… Tak więc mamy słowo „Babilon” – polska wymowa „babilon”, angielska „babylon”.

Jak zwykle korporacja VMware/EMC nie mogła sobie pozwolić na nazwę o łatwiej genezie (Przypomnijmy sobie projekt Onyx). Wpaść na coś takiego jak Isilon? Połączenie prostoty i wielkości, oraz kultury korporacyjnej? To musi się samo sprzedawać, choćby tylko ze względu na nazwę. 😉

Czym jest rzeczony EMC Isilon? Generalnie można go nazwać NAS’em… jednakże, nie było by to do końca sprawiedliwe dla samego Isilona. Tak więc możne bardziej uczciwie będzie go nazwać systemem rozproszonych NAS’ów udostępniających jeden spójny system plików oparty o OneFS. Dzięki czemu uzyskujemy szereg maszyn fizycznych, tak zwanych węzłów, serwujących jeden, logiczny system plików. Minimalnie możemy mieć 3 węzły (18TB) maksymalnie 144 (20PB). Wewnętrznie komunikują się one poprzez charakteryzujące się niskim opóźnieniem interfejsy InfiniBand, połączenia zewnętrzne realizowane są natomiast za pomocą Ethernetu 1G/10G i protokoły NFS, iSCSI, HTTP, CIFS, FTP i HDFS.

Zostawmy na chwile sprzęt i wróćmy do OneFS – jest to opracowany przez Isilon Systems (aktualnie EMC) rozproszony systemem plików. Jest on oparty o system FreeBSD wirtualizujące nam cały storage ze wszystkich Isilonów znajdujących się w naszej infrastrukturze.

isilon1

 

Dzięki temu dostajemy jeden FS rozciągnięty na wszystkie urządzenia. OneFS oparty jest na pointerach i metadanych, dzięki czemu inżynierom pracującym nad Isilonem udało się przeskoczyć problem przywiązania danych do warstwy sprzętowej. Doprowadziło to do sytuacji w której obsługa danych na fizycznych dyskach twardych, odbywa się poprzez dodatkową warstwę abstrakcji w postaci OneFS zapewniającego wydajność i niezawodność.

Prawda, że brzmi zbyt różowo? Jednakże z logicznego punktu widzenia jest to całkiem możliwe. Otóż przyjmując, że dzięki oderwaniu danych od dysków fizycznych, i pozbyciu się mechanizmów RAID na rzecz logicznego rozproszenia danych po grupie Islonów, może zdecydowanie spaść ilość faktycznych operacji IO. Na razie pomińmy czary związane z rozpraszaniem, weźmy jedynie pod uwagę rezygnację z RAID – uzysk wydajności jest ogromny… Pisałem jakiś czas temu na temat dodatkowego obciążenia które generuje RAID. Należy zwrócić uwagę, że tu tego narzutu niema.

Oczywiście, metadane też generują pewne obciążenie. Zajmuję ono według danych od producenta 1% zasobów dyskowych. Nie wydaje się to dużo, jednak przy teoretycznych 20PB to bagatelne 200TB 😉 Niestety bez nich nie uzyskalibyśmy całej infrastruktury, wiec jest to koszt „organizacyjny”, który musimy ponieść.

Dodatkowo nasuwa się pytanie czy sama obsługa, przeliczanie itd. metadanych może mieć wpływ na wydajność? Isilon korzysta z mechanizmu podziału zadań, oraz danych i metadanych. Schemat dla jednego węzła przedstawia się następująco:

isilon2

Należy się tu krótkie wyjaśnienie mechanizmu. Tak wiec nasz system IO dzielony jest na dwie połowy. Pierwszą z nich obsługuje Inicjator (Initiator) – jest to kapitan, rozdający zadania dla drugiej połowy czyli dla Uczestników (Participant). Dla jednego węzła mechanizm wydaje się jak najbardziej logiczny… i w sumie można by się nawet pokusić o stwierdzenie, że wulgarnie standardowy. Zabawa zaczyna się przy, powiedzmy trzech węzłach:

isilon3

Dane przeznaczone do zapisu wpadające do węzła pierwszego, będącego kapitanem całego procesu, rozbijane są na mniejsze porcje i rozsyłane do innych urządzeń. Warto zauważyć, że Inicjatory węzłów 2 i 3 nie są zbytnio zajęte tym procesem, dane przelatują przez nie jak jedzenie przez Polaka na wakacjach w Egipcie. Dodatkowo w tym samym czasie kapitan rozprasza między węzłami dane parzystości. Dane podczas rozrzucania są dzielone na tak zwane grupy zabezpieczeń (protection groups). Do rozrzucania pomiędzy węzłami używany jest algorytm Reed-Solomon, dla hardkorowców więcej info na Wikipedii (http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction).

Jak już wspomniałem system wie gdzie znajdują się dane i jest w stanie zapewnić ich spójność poprzez informacje zawarte w metadanych. Adresacja poszukiwanych fragmentów danych odbywa się za pomocą schematu {węzeł, dysk, offset} czyli np. {3, 2, 12345} będzie oznaczać, że poszukiwany fragment danych bytuje na węźle trzecim, drugim dysku i 12345 bloku. Standardowa wielkość bloku to 8KB, jak blok jest mniejszy to i tak wykorzystuje 8KB, natomiast jeżeli jest większy to zajmuje wielokrotność 8KB do max szesnastokrotności tej wartości czyli 128KB.

Wiemy jak wygląda zapis, pozostało nam poznać jak zachowuje się mechanizm odczytu. Rysunek poniżej przedstawia nam ten proces:

isilon4

Tak więc klient podporządkowany do węzła pierwszego odpytuje o plik. Węzeł pierwszy odczytuje metadane i sprawdza, gdzie znajdują się wszelkie bloki potrzebne do zaserwowania pliku. Sprawdza przy okazji w L1 Cache czy dane zostały zamówione i zestawia z połączenie z wszystkimi węzłami które owe fragmenty danych posiadają. Każdy z węzłów przerzuca do pamięci L2 cache zamówione fragmenty i przesyła je do L1 kapitana. Węzeł pierwszy pozwala im na umieszczanie w L1 danych jednocześnie transferując plik do klienta. Proces kompletowania strumienia danych odbywa się online, aż do zakończenia transferu pliku do klienta.

Działanie systemu wydaje się dosyć logiczne w przypadku jednego zapisu na raz, lub jednego odczytu… zdaje się jednak, że nie będzie to dosyć popularna sytuacja w środowisku do którego Isilon został stworzony. Jak więc działa zapis i odczyt na kilku węzłach na raz, oraz przede wszystkim jak zachowuje się system locków i konkurencji?

isilon5


Węzeł numer dwa zostaje wyznaczony wodzirejem. Wątek 1 z węzła 4 oraz wątek 2 z węzła 3 jednocześnie wymagają założenia współdzielonego lock’a na pliku znajdującym się na węźle 2. Węzeł 2 sprawdza czy już nie istnieje jakiś zapisowy lock na wymienionym pliku i jeżeli nie, to zostaje udzielony dostęp dla węzła 2 i 4, które spokojnie zaczynają czytać sobie wspomniany plik. W tym samym czasie wątek 3 z węzła 1 domaga się założenia lock’a zapisowego na roztrząsany plik. Koordynator sprawdza czy można już zdjąć lock’a z pliku, ale dowiaduje się, że wezły 3 i 4 jeszcze na nim ucztują więc każe czekać dla wątku 3 i węzła 1. Bo zakończeniu upiornej wieczerzy węzłów 3 i 4 koordynator umożliwia, po uprzednim zdjęciu lock’a, wątkowi 3 zapis. Myślę, że trzeba tu jeszcze powiedzieć, o fakcie wysokiej granularności locków i mechanizmie Multi-threaded IO. Jest to rozwiązanie dzięki któremu będziemy mogli pisać na raz z kilku klientów do jednego dużego pliku, a dokładnie do jednego z jego małych fragmentów. Możliwe jest to dzięki lockowaniu pewnych regionów pliku, a nie całego pliku.

Wszystko pięknie, ale co z zabezpieczeniami przed wyłączeniem prądu, awarią dysku czy całego węzła? Tracimy wszystkie dane. Nie, no żartuje 😉 Przy zastosowaniu ochrony danych na poziomie N+1 klaster Isilonów doprowadza do takiej sytuacji, że dane potrzebne do odzyskania pliku zawsze są zapisane na dwóch różnych urządzeniach. Czyli przy założeniu najmniejszego, trzy węzłowego klastra przy awarii jednego z urządzeń wszystkie dane są dostępne. Można oczywiście dostosować ochronę danych do poziomu swojej paranoi ustawiając ją na poziomie od N+2, aż do N+4.

Jest to dosyć ciekawa propozycja dla ludzi którzy nie mają czasu się bebrać w macierzach, a potrzebują łatwo rozszerzalnej powierzchni na archiwa, maszyny wirtualne itp. Więcej info znajdziecie pod tymi adresami:

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
2 Responses

Leave a Reply