Współtwórca Apple'a na systemach przechowywania danych specjalnie się nie znał, ale jego pytanie było bardzo sensowne. Spróbuję Wam dziś pokazać, dlaczego budując prawdziwe chmury obliczeniowe, uznaje się, że korzystanie z systemu plików nie zawsze musi być najlepszym sposobem na przechowywanie danych, szczególnie tych o bardziej statycznej naturze.

Pamiętajcie, że w Oktawave obiektowy storage, o którym dziś opowiem, jest jednym z dwóch systemów przechowywania danych. Drugim systemem, najważniejszym z punktu widzenia przetwarzania dynamicznie zmiennych danych, jest OVS (Oktawave Volume Storage), który odpowiada za udostępnienie struktur blokowych w postaci zrozumiałej dla zwykłych systemów operacyjnych. Innymi słowy OVS widziany jest przez Waszą instancję jako standardowy dysk twardy i Oktawave taką standardową usługę oferuje niejako w pakiecie dołączanym do każdej instancji serwerowej. Dziś jednak mówimy o OCS (OCS), czyli o czymś bardziej wyspecjalizowanym.

W standardowych systemach dane przechowywane są jako obdarzone nazwą i atrybutami pliki na urządzeniu pamięci masowej (np. C:\ czy /dev/sda), w strukturze zagnieżdżonych katalogów. Tak to wygląda dla użytkownika.

System plików widzi jednak coś innego – setki czy tysiące bloków, często rozproszonych po całym dysku, adresowanych przez skomplikowany system węzłów indeksujących, przechowujących dodatkowe metadane o plikach. W praktyce pliki są bardzo mocno przywiązane do fizycznego miejsca, a wykonując na nich operacje, trzeba znać całe ścieżki dostępu do nich. Każda taka operacja to złożone operacje na blokach z przeszukiwaniem węzłów systemu plików.

Póki to wszystko się dzieje na jednym lokalnym dysku, można to znieść, ale wyobraźcie sobie teraz chmurę, w której miliony użytkowników przechowuje biliony plików... nie, lepiej sobie tego nie wyobrażajcie. Uwierzcie – systemy plików trudno przenosić z miejsca na miejsce – a przecież w chmurze dane są przenoszone między jej węzłami bardzo często. Można to zrobić w sposób tradycyjny (i tak się czasem robi w dużych systemach storage'owych dla biznesu), ale czyni to przechowywanie danych bardzo kosztowną operacją.

Jaką mamy więc alternatywę? W zaawansowanych chmurach storage'owych korzystamy z obiektowego systemu przechowywania danych. Tu podstawowym elementem jest nie plik lecz obiekt. Podobnie jak plik jest to dyskretna jednostka, przenosząca dane, ale w przeciwieństwie do pliku nie jest umieszczona w żadnej hierarchii katalogów.

Obiekty funkcjonują w płaskiej przestrzeni adresowej (tzw. puli storage'owej) i są opisane znacznie bardziej rozbudowanymi metadanymi, niż w wypadku plików. Posiadają unikatowe identyfikatory, dzięki którym możliwe jest odwołanie się do nich bez znajomości ich fizycznego położenia. Fizyczne położenie obiektu staje się bowiem w chmurze kwestią dość „mglistą”. Storage w chmurze zapewnia niezbędną redundancję i skalowalność, przechowując dane w sposób rozproszony – dane są replikowane w klastrze węzłów storage'owych, przynajmniej kilkukrotnie.

Taki obiektowy system storage'owy pozwala więc na bardzo szybki dostęp do urządzeń, na których dane są przechowywane. Tworzy obiekt, a następnie zapisuje w nim bloki o stałej wielkości, wraz z towarzyszącymi metadanymi, bez konieczności „przebijania się” przez system plików (jak to jest w urządzeniach NAS, obciążonych jeszcze dodatkowo protokołami dostępu i zarządzania danymi).

Dostęp do obiektów w chmurze możliwy jest przez standardowy interfejs REST, po ścieżce dostępu, na którą składają się raptem trzy elementy – konto użytkownika, kontener i obiekt. To wszystko: konta i kontenery są jedyną metodą na grupowanie obiektów, nie ma żadnych więcej zagnieżdżeń. Zarządzaniem, replikacją i przechowywaniem danych w takiej strukturze zajmują się trzy rodzaje serwerów – serwer kont, serwer kontenerów i serwer obiektów.

Rola tych serwerów powinna być zrozumiała:
• serwery kont (w praktyce to szybkie bazy sqlite) udostępniają listy kontenerów dla konta, bez informacji o ich położeniu,
• serwery kontenerów (również bazy sqlite) udostępniają listy obiektów dla danego kontenera, również bez wiedzy o położeniu obiektów,
• a co udostępniają serwery obiektów (w praktyce normalne serwery plików)? Oczywiście same obiekty, przechowywane jako binarne pliki, z metadanymi w rozszerzonych atrybutach pliku. Ścieżkę dostępu generuje się funkcją skrótu z nazwy pliku – i co ważne – czasoznaczkiem. Pozwala on określić, która wersja obiektu jest aktualna i zapewnić, że serwowana z wszystkich węzłów będzie wersja najnowsza.

Wspomnieliśmy, że obiektowy storage przechowuje dane w sposób rozproszony, na wielu węzłach. Jak więc znajduje je sama chmura, pozbawiona normalnego systemu plików? Niektóre rozproszone systemy storage'owe wykorzystują w tym celu centralny serwer metadanych – i nie jest to złe rozwiązanie, jeśli zapytań o obiekty jest mało. Gdy ich liczba rośnie, taki centralny serwer staje się wąskim gardłem całego systemu (każda operacja na obiekcie musi być poprzedzona odpytaniem serwera metadanych o położenie obiektu).

W skalowalnych systemach musieliśmy także rozproszyć informacje o położeniu obiektów. Utrzymujemy je w strukturze danych zwanej pierścieniem – jest to reprezentacja przestrzeni wszystkich możliwych wyliczonych wartości funkcji skrótu, która pozwala na szybkie wskazanie, na którym węźle znajdują się potrzebne dane.

Oddzielne pierścienie dla baz kont, kontenerów i obiektów replikowane są po wszystkich węzłach, i dla każdego zapytania dotyczącego konta, konteneru czy obiektu, pierścień zwraca jego fizyczną lokalizację, korzystając z algorytmu spójnych funkcji skrótu (consistent hashing). Algorytm ten pozwala nam zwiększyć wydajność całego systemu przy wszelkich operacjach na obiektach – wymagają one wówczas jedynie minimalnych zmian w zawartości pierścienia.

A jak dane ma znaleźć użytkownik? Postaraliśmy się, by było to jak najprostsze. Obiektowy storage oferuje standardowy interfejs REST, przez który można przechowywać, pobierać i aktualizować obiekty. Dzieje się to przez serwer proxy, który dla każdego zapytania sprawdza w pierścieniu lokalizację konta, konteneru i obiektu, a następnie je odpowiednio przekierowuje. Użytkownik otrzymuje swój obiekt bezpośrednio, jako strumień binarnych danych.

Obiektowy storage nie jest panaceum na wszystkie problemy z przechowywaniem plików w chmurze. Podkreślamy: to nie jest system plików (choć w naszej chmurze można obiektami zarządzać dzięki kontenerom, dla których określane są polityki przechowywania i udostępniania danych), nie jest to też system czasu rzeczywistego (pomimo że infrastruktura OCS (OCS) działa na bardzo szybkich dyskach).

To system przechowywania blobów (binary large objects), który działa zgodnie z modelem spójności eventual consistency. Oznacza to, że zapisywana informacja jest tu propagowana do wszystkich węzłów klastra, dzięki czemu dostępna jest w każdym z nich, ma to swoją cenę: przez krótki czas informacja może nie być spójna we wszystkich węzłach. Spójność zostanie osiągnięta dopiero po rozwiązaniu wszystkich niezgodności danych. Dlatego też, choć dane mogą być już wgrane do chmury, to ich pobranie od razu nie będzie możliwe.

Właśnie taki model spójności pozwala na zachowanie niezawodności chmury storage'owej, przy dowolnym jej skalowaniu. Nawet gdyby podczas zapisywania danych uszkodzeniu uległ dysk, to zaraz po tym jak zostanie on wymieniony i węzeł chmury zostanie uaktywniony, system sprawdzi spójność i przepisze aktualną kopię danych z innych węzłów, na których zapis udał się bez problemów.

Takie rozwiązanie oznacza, że obiektowy storage obywa się bez kopii zapasowych – integrując w sobie mechanizmy samoleczenia danych oraz optymalizacji ich rozkładu, i zapewniając zarządzanie poprzez metadane, czyni backup zbędnym.

Brzmi hardcore'owo, ale to jest dla ludzi!

Chyba jest już jasne, do czego chmury storage'owe nadają się najlepiej. W obiektowym storage'u dobrze się przechowuje statyczne, rzadko zmieniane dane, takie jak klipy wideo, zdjęcia, archiwa poczty elektronicznej, zapasowe obrazy maszyn wirtualnych czy kopie zapasowe serwerów.

Co dla użytkowników najważniejsze, dane te, w przeciwieństwie do skomplikowanych macierzy NAS/SAN, przechowuje się bardzo tanio. Oznacza to, że np. serwis VOD może sobie śmiało pozwolić na wgranie do chmury storage'owej całego repozytorium filmów, a dzięki rozliczaniu w modelu pay-per-use, płacić operatorowi tylko za to, co zostało przez użytkowników pobrane i obejrzane.

Tak samo storage'owa chmura sprawdzi się jako zaplecze korporacyjnego systemu obiegu dokumentów czy serwer multimediów (obrazków, klipów wideo czy audio) dla internetowego portalu.

Wszystkich tych, którzy mają takie potrzeby, zachęcamy do skorzystania z chmur oferujących obiektowy storage. Oczywiście można zbudować własną infrastrukturę serwerową, kupić drogą macierz dyskową i radzić sobie z hostingiem na zwykłym Windows czy Linuksie, ale jesteśmy przekonani, że w ten sposób uzyska się tylko jeden efekt – wyda się znacznie więcej pieniędzy na znacznie mniejszą wydajność. Zachęcamy do testów i dzielenia się z nami swoimi doświadczeniami.

P.S. Zachęcamy również Czytelników Spider's Web do zadawania pytań i pogłębiania wiedzy. Jesteśmy tutaj, by pomóc Wam w adopcji optymalnych i oszczędnych rozwiązań dla Waszych projektów.

Maciej Kuźniar - dyrektor projektu Oktawave. Pasjonat technologii związanych z przetwarzaniem i przechowywaniem danych, posiadający 10 lat doświadczenia w pracy dla klientów klasy enterprise (banki, telekomy, fmcg). Autor koncepcji technologicznie wspierających rozwój startupów oraz rozwiązań architektonicznych gwarantujących wysokie HA i SLA dla systemów IT.