Czy potrzebuję macierzy obiektowej?

O macierzach obiektowych pisałem już wcześniej w tym artykule. Ponieważ jednak jest to jedno z moich ulubionych zagadnień, dlatego nie mogę pozwolić na to, aby zakończyć temat tym jednym materiałem. Zapraszam Cię zatem na kolejny odcinek "obiektowej sagi" , w którym spróbuję odpowiedzieć na pytanie, czy macierze obiektowe są rzeczywiście potrzebne w Twojej organizacji.

Ale zacznijmy od początku...

 

A na początku były dane. Dane te przechowywane były w macierzach blokowych i plikowych. I żadne z tych urządzeń nie były ani złe, ani dobre. Były odpowiednie dla swoich zastosowań.

Macierze blokowe.

Podłączane do serwera bezpośrednio jako przestrzenie DAS (Direct Attached Storage) lub instalowane w sieci SAN (Storage Area Network). Szybkie i pozwalające zagwarantować krótkie czasy odpowiedzi oraz duże przepustowości dla aplikacji. Przestrzeń dyskową udostępniają systemom operacyjnym i zainstalowanym na nich aplikacjom. Ale przestrzeń ta oferowana jest tylko jednemu serwerowi (lub klastrowi serwerów). W rezultacie takiej blokowej komunikacji, realizowanej za pomocą protokołów m.in. FC, iSCSI i FICON serwer otrzymuje do wykorzystania zasób w postaci dysku (inaczej wolumenu lub urządzenia blokowego).

 

Macierze plikowe.

Określane często jako głowice lub serwery NAS (Network Attached Storage). Korzystają z protokołów m.in. CIFS i NFS. I w ten sposób udostępniają dysk sieciowy, z którego korzystać może wielu użytkowników jednocześnie. Eksport lub udział sieciowy posiada swój adres, a ten wskazuje na określony system plików, zbudowany na dyskach macierzy plikowej. Tutaj komunikacja realizowana jest na poziomie plików i ich podstawowych metadanych systemowych.

 

Z jednej strony mamy zatem wydajny wolumen blokowy, który jest udostępniany jednemu serwerowi lub klastrowi serwerów. Z drugiej – elastyczny dysk sieciowy z równoczesnym dostępem dla wielu użytkowników, ale najczęściej już nie aż tak wydajny jak w przypadku bezpośredniego dostępu na urządzeniu blokowym.

 

I widząc te zalety i ograniczenia każdego z tych urządzeń, Użytkownik rozdzielił swoje dane. Dane strukturalne (m.in. przechowywane w wierszach, kolumnach i w bazach danych) postanowił umieścić w macierzach blokowych. Dane niestrukturalne (m.in. pliki audio, video, zdjęcia, dokumenty) – w macierzach plikowych.

Tak minęły lata i dekady.

 

Ilość danych w świecie niestrukturalnym urosła do ogromnych rozmiarów i zaczęła stanowić nawet 80% wszystkich danych w organizacji. Użytkownik nie chciał lub nie mógł usuwać tych danych, dlatego przechowywał i zabezpieczał wszystkie. Czas wykonywania kopii zapasowych środowiska danych niestrukturalnych wydłużał się coraz bardziej. A zarządzanie dużymi wolumenami wraz z utrzymywaniem pokaźnego zbioru kopii danych dla różnych środowisk i różnych odbiorców biznesowych stawało się coraz bardziej pracochłonne. Przechowywanie wszystkich danych narażało Użytkownika na konsekwencje związane z niedotrzymaniem niektórych regulacji prawnych (np. RODO). Użytkownik w wielu przypadkach nie miał jednak wiedzy na temat tego co znajduje się w przechowywanych plikach. Nie potrafił ich nie tylko przeszukiwać, ale tym bardziej analizować oraz czerpać z nich wiedzę i w rezultacie monetyzować.

 

Niestety, klienci biznesowi coraz częściej wymagali takiej analizy. Zależało im na zwiększaniu konkurencyjności produktów i usług oraz obniżaniu kosztów. A analiza tradycyjnych – strukturalnych środowisk operacyjnych zaczynała być niewystarczająca. Aby jednak móc sięgnąć po informacje przechowywane w świecie danych niestrukturalnych, należało je najpierw w odpowiedni sposób opisać oraz efektywnie przechowywać. Użytkownik wiedział, że sam plik i jego metadane systemowe to za mało. Poza tym większa ilość danych oraz interakcji z nimi przez użytkowników końcowych oznaczała konieczność przeprojektowania aplikacji i użycia bardziej nowoczesnych interfejsów, korzystających z architektury REST.

 

Środowisko plikowe Użytkownika urosło z kilku do setek terabajtów. Trend wzrostu zaczął coraz bardziej przypominać krzywą wykładniczą z perspektywą na szybkie przekroczenie pierwszego petabajta danych. Należało zacząć przechowywać dane niestrukturalne w sposób inny, niż do tej pory. W inny, ale w jaki?

 

Użytkownik przeczytał wtedy w tym artykule o obiektowych macierzach dyskowych. Pojawiła się nadzieja na rozwiązanie problemu i sprostanie wymaganiom biznesu.

 

Macierze obiektowe.

Dostęp do danych realizowany jest tutaj również za pomocą protokołów sieciowych, tak jak w przypadku urządzeń plikowych. Macierz obiektowa korzysta jednak najczęściej z bramek typu HTTP, S3, SWIFT lub zwyczajnie z RESTowego API. Dlatego, oprócz samych plików i podstawowych metadanych systemowych, przekazywane są tutaj również metadane własne (custom). A dzięki temu, istnieje możliwość opisania (wewnątrz tego samego urządzenia obiektowego, a nie w zewnętrznej bazie danych) np. co się dzieje z plikiem w trakcie jego przechowywania lub co się w nim znajduje. Obiekty przechowywane są w przestrzeniach nazw (lub inaczej w bucketach) i dostęp do nich może mieć wielu użytkowników jednocześnie (tak, jak w przypadku macierzy plikowej). Zmienia się jednak sposób komunikacji aplikacji z plikiem. Interfejs REST API pozwala na wykorzystanie takich funkcji, jak: GET, PUT, POST i HEAD. A programiście wystarczy znajomość adresu URI obiektu.

W macierzach obiektowych można skupić się na samej treści, w oderwaniu nie tylko od systemu operacyjnego, ale również od aplikacji, która tę treść produkuje. Łatwo w związku z tym udostępnić ten sam obiekt różnym aplikacjom, z których każda będzie korzystała i dopisywała do jego metadanych informacje istotne tylko dla niej (bez duplikowania pliku dla różnych systemów czy środowisk).

 

Przykład.

Na zdjęciu z miejsca wypadku w metadanych takiego zdjęcia możemy chcieć przechowywać informacje o numerze sprawy, aucie, kierowcy, czy panującej tego dnia pogodzie, aby w przyszłości móc analizować podobne zdarzenia. I nawet jeżeli taka analiza zdjęcia miałaby być realizowana za pomocą technik rozpoznawania obrazów i uczenia maszynowego, to część kluczowych informacji otrzymanych w wyniku takiego przetwarzania można zawsze zapisać w metadanych własnych obiektu, aby unikać ponownego przetwarzania i analizy przy każdej interakcji użytkownika końcowego.

Metadane własne można również wykorzystać na potrzeby klasyfikacji (np. plik zawiera lub nie zawiera danych osobowych) oraz wyszukiwania informacji. Macierze obiektowe posiadają wewnętrzne silniki indeksowania i przeszukiwania. A ponieważ wbudowane wyszukiwarki są wyposażone w interfejs API, dlatego silniki te można wykorzystać również wewnątrz swojej aplikacji.

 

Brzmi interesująco, ale... po co mi te metadane?

Czy przypominasz sobie może piramidę informacyjną? Jeżeli zaczynałeś(aś) studia techniczne około 20 lat temu, to pewnie pamiętasz takie zagadnienie właśnie z tamtych czasów. Przypuszczam, że dzisiaj taka piramida jest rysowana przez nauczycieli informatyki już w liceum. Przypomnijmy sobie jak ona wygląda.

   

U podstawy – dane. Są fizyczną, zapisaną reprezentacją informacji, wiedzy i rezultatów naszych obserwacji. Dane są procesowane i zorganizowane w taki sposób, aby móc dostarczać informacji. A samo procesowanie jest realizowane przez urządzenia elektroniczne. Na tym poziomie posługujemy się językiem komputerów i systemów pamięci masowych.

 

Dalej – informacje. Konkretne interpretacje określonych porcji danych. Inaczej mówiąc, są to dane wraz z ich znaczeniem. Niosą jakąś wartość, która może się zmieniać wraz z upływem czasu. Często są towarem i mogą być kupowane oraz sprzedawane. Informacje są nadrzędne w stosunku do danych. Nie przechowujemy informacji, aby otrzymać z nich dane, ale przechowujemy dane, aby zachowywać i przekazywać informacje. Wartość informacji może być różna dla różnych osób, a ten sam zestaw danych może być różnie zinterpretowany przez różne osoby.

 

Wiedza. Posiadanie określonej wiedzy o opisywanym świecie i o języku, w którym dane są zapisane jest niezbędne w procesie interpretacji tych danych. Zatem wiedza jest potrzebna w procesie nadawania znaczenia danym, czyli w procesie powstawania informacji.

 

I na samym szczycie piramidy – mądrość, czyli wiedza, która niesie ze sobą jakąś określoną wartość. To tutaj następuje monetyzacja danych, pod warunkiem, że jest to mądrość, z której możemy czerpać korzyści.

 

W dzisiejszej rzeczywistości IT bardzo popularnym hasłem (i coraz częściej, nie tylko hasłem) jest transformacja centrum przetwarzania danych z takiego jakie znaliśmy do dzisiaj, zorientowanego na kosztach i w którym najważniejsze są budżety, do nowoczesnego i bardziej konkurencyjnego, które jest zorientowane na przynoszeniu zysków i w którym najważniejsze są inwestycje.

Wbrew pozorom opisana wcześniej piramida, a konkretnie droga na jej szczyt z wykorzystaniem odpowiednich narzędzi jest znakomitym przykładem, jak taką transformację można sobie wyobrazić. I nie tylko wyobrazić, ale również przeprowadzić.

   

W wielu organizacjach w zakresie zbiorów danych niestrukturalnych często nadal ograniczamy się jedynie do ich przechowywania i zabezpieczania. Inaczej mówiąc, mamy ogromne zbiory assetów (w postaci DANYCH), z których nie „wyciągamy” żadnych wniosków (INFORMACJI). A przez to nie WIEMY jaka jest ich wartość (MĄDROŚĆ).

 

Ale, aby zacząć monetyzować, musimy przede wszystkim zadbać o właściwą podstawę piramidy.

 

Przechowywanie i ochrona – korzystaj z rozwiązań, które:

• są przystosowane do przechowywania niestrukturalnych zbiorów danych w sposób efektywny (kompresja i de-duplikacja) i elastyczny (wsparcie dla wielu protokołów działających jednocześnie),
• posiadają mechanizmy ochrony danych (lokalne synchroniczne mechanizmy zabezpieczania danych oraz zdalna replikacja w wielu różnych topologiach, pomiędzy wieloma ośrodkami),
• gwarantują niezmienność przechowywanych danych (sumy kontrolne, technologia WORM, retencja), a dzięki temu nie potrzebują być backupowane (ogromne oszczędności związane z kosztami backupu, kluczowe szczególnie dla dużych środowisk),
• posiadają wbudowane mechanizmy automatycznego tieringu danych pomiędzy różnymi klasami pamięci masowej (optymalizacja kosztów),
• pozwalają na ustawianie retencji danych oraz automatycznie usuwają dane po upływie tej retencji (zgodność z regulacjami i przechowywanie tylko potrzebnych danych we właściwym i wymaganym czasie).

 

Wzbogacanie – korzystaj z rozwiązań, które:

• rozumieją co to są metadane własne i potrafią je przechowywać wewnątrz obiektu (w tym samym urządzeniu),
• nie mają ograniczeń dotyczących ilości atrybutów, jakimi możesz opisać swoje dane (lub mają ograniczenia, które są postawione bardzo wysoko),
• potrafią ustawić retencję nie tylko dla danych, ale również dla metadanych,
• posiadają wbudowane silniki indeksowania i wyszukiwania metadanych (w tym również metadanych własnych).

 

Im więcej takich funkcjonalności (w tym przede wszystkim tych związanych z przechowywaniem metadanych własnych) będzie posiadało Twoje przyszłe rozwiązanie obiektowe, tym łatwiej będzie Ci wdrożyć narzędzia na kolejnych stopniach schodów, które prowadzą na szczyt piramidy informacyjnej.

 

Kto produkuje macierze obiektowe?

Ostatni raport IDC pokazuje liderów oraz głównych graczy w zakresie tych rozwiązań.

   

Lista ta pokrywa się w części z producentami macierzy plikowych i blokowych. Czy w takim razie można przyjąć tezę, że urządzenia te nie konkurują z macierzami blokowymi i plikowymi, ale raczej są uzupełnieniem tej oferty?

 

W przypadku macierzy blokowych – na pewno tak.

Jeżeli natomiast chodzi o macierze plikowe, to sytuacja jest nieco bardziej skomplikowana. Dla niektórych działających dzisiaj aplikacji i zastosowań typowy serwer plików może być nadal lepszym rozwiązaniem niż macierz obiektowa. Jest jednak coraz więcej takich scenariuszy, gdzie zastąpienie tego serwera urządzeniem obiektowym przyniesie wiele korzyści. A liczba tych scenariuszy rośnie wraz ze zmianami w architekturze aplikacji i zastępowaniem typowych plikowych protokołów komunikacyjnych (CIFS i NFS), protokołami zgodnymi z architekturą REST (S3 i HTTP).

Dlatego urządzenia obiektowe oprócz tego, że konkurują pomiędzy sobą, powoli zabierają również rynek tradycyjnym macierzom plikowym.

 

Kiedy jedna, a kiedy druga?

No właśnie. Kiedy zatem warto pomyśleć o urządzeniu obiektowym, a kiedy lepszym rozwiązaniem będzie typowy serwer plików? W dużej mierze zależeć to będzie od aplikacji, która przechowuje dane na dyskach macierzy oraz od wykorzystywanego przez nią protokołu komunikacyjnego.

 

Przykład.

Aktualnie dane niestrukturalne przechowuję w macierzach plikowych (NAS). Pliki te udostępniam użytkownikom i aplikacjom za pomocą interfejsów CIFS i/lub NFS. Nadal używam również zasobów udostępnionych za pomocą poczciwego FTPa. Wydajność aplikacji, które korzystają z NASa jest zadowalająca. Aplikacje te wraz z ich danymi zabezpieczam wewnętrznymi mechanizmami kopii lokalnych i zdalnych. A dodatkowo dane backupują się bez problemu i (póki co) „mieszczę się” w wyznaczonych oknach backupowych. Gdy potrzeba dodatkowej przestrzeni instaluję kolejne dyski wewnątrz NASa, dodaję kolejne węzły (jeżeli potrafi się on skalować horyzontalnie) lub po prostu kupuję kolejne urządzenie.

 

Jeżeli wszystko działa jak należy, to kiedy oraz dlaczego miałbym kupować macierz obiektową?

 

Kiedy?	Dlaczego?
Mam aplikację zaprojektowaną do pracy w chmurze, która korzysta z nowoczesnych protokołów S3, HTTP lub z REST API.	Chcę, aby dane i metadane przechowywane i zabezpieczone były retencją i WORMem w tym samym urządzeniu. Nie chcę korzystać z dodatkowych baz danych, w których z reguły przechowywane są metadane. Niech będą one przechowywane w bazie danych wewnątrz macierzy obiektowej i niech będą powiązane z plikiem (z danymi) z wykorzystaniem wewnętrznej architektury tej macierzy (struktura obiektu). Chcę uprościć pracę programistów, którzy zamiast operować na plikach, będą mogli zacząć operować na treści (danych i metadanych) w oderwaniu od aplikacji i będą mogli korzystać ze zdecydowanie szybszych (bo działających równolegle) protokołów „RESTfull-owych”.
Wbrew pozorom, macierze obiektowe mogę wykorzystywać również w scenariuszach, gdy moja aplikacja lub moi użytkownicy komunikują się z urządzeniem za pomocą protokołów CIFS i NFS.	Roadmapa mojej aplikacji nie przewiduje w najbliższym czasie rozszerzenia wsparcia o dodatkowe protokoły (HTTP, S3) i nadal muszę używać CIFSa i NFSa, ale już teraz chciałbym skorzystać przynajmniej z niektórych zalet macierzy obiektowej. Poza tym to jest tylko jedna z wielu aplikacji. Zamierzam podzielić moją macierz obiektową na wiele wirtualnych urządzeń, z których każde będzie niezależnie wykorzystywane przez różne departamenty, linie biznesowe, wewnętrznych i zewnętrznych klientów. I w ten sposób chcę stworzyć jeden centralny magazyn danych obiektowych, którego zasoby będą wykorzystywane przez wiele różnych aplikacji jednocześnie. Urządzenia obiektowe zbudowane są zazwyczaj w oparciu o architektury horyzontalne (typu scale-out). To pozwala na łatwą rozbudowę urządzenia wraz ze wzrostem ilości obiektów w środowisku. Dodaję przestrzeń, gdy rośnie ilość danych. Dodaję kolejne węzły w macierzy obiektowej, gdy dostarczam przestrzeni dla nowych aplikacji i gdy potrzebuję większej wydajności. Dzięki temu konsoliduję oraz upraszczam zarządzanie i zabezpieczanie danych. W jednym miejscu zarządzam retencjami danych. Korzystam ze wspólnego silnika wyszukiwania (mogę przeszukiwać magazyn horyzontalnie i szukać danych z różnych aplikacji za pomocą jednego zapytania). Automatyzuję procesy związane z retencją i niszczeniem danych oraz ich przechowywanie w odpowiednich warstwach macierzy we właściwym czasie. I „na koniec dnia” – obniżam koszty utrzymania. Dodatkowo, nawet w przypadku aplikacji, która komunikuje się za pomocą protokołów plikowych (CIFS i NFS) istnieją rozwiązania, które pozwalają na budowę „obiektowego NASa”: dla przestrzeni (dysków sieciowych), z których korzystają aplikacje – użyj dedykowanej dla macierzy obiektowej bramy plikowej, która zagwarantuje natywną wydajność CIFSa i NFSa. Brama ta na zewnątrz dostarczy tradycyjnych interfejsów plikowych dla aplikacji, a w back-endzie będzie w sposób zautomatyzowany komunikować się z macierzą obiektową za pomocą protokołów obiektowych (HTTP, S3). dla przestrzeni (dysków sieciowych), z których korzystają użytkownicy – zastanów się, czy nie warto zmienić sposobu współdzielenia plików pomiędzy użytkownikami na nieco bardziej nowoczesny. Dostarczasz użytkownikom usług współdzielenia i synchronizacji plików, które są realizowane w Twojej prywatnej chmurze (w Twoim centrum przetwarzania). Pliki użytkowników przechowywane i zabezpieczone są w macierzy obiektowej. Usługi synchronizacji pomiędzy urządzeniami użytkowników oraz współdzielenia wewnątrz i na zewnątrz organizacji (linki prywatne i publiczne) realizowane są poprzez dodatkowe urządzenie, ściśle zintegrowane z macierzą obiektową.
Zastanawiam się nad macierzą obiektową, która posiada wewnętrzne mechanizmy ochrony w postaci sum kontrolnych, technologii WORM oraz polityk retencji. I dodatkowo pozwala na wykonywanie wewnętrznych synchronicznych kopii danych oraz zdalnej replikacji.	Wówczas wystarczy, że będę replikował dane do drugiego ośrodka, aby zabezpieczyć się na wypadek awarii np. całego centrum przetwarzania. Nie muszę już natomiast wykonywać lokalnego backupu danych. Ale jak to, bez backupu? Technologia WORM gwarantuje niezmienność danych. Nie ma zatem możliwości zmiany zapisanego pliku w takim urządzeniu. Jeżeli użytkownik, aplikacja lub złośliwe oprogramowanie typu ransomware będą próbowały zmienić zapisany obiekt, otrzymają komunikat o błędzie. Ewentualnie, w przypadku włączonego wersjonowania, utworzą kolejną wersję tego obiektu. W jednym i w drugim scenariuszu oryginał pozostanie bez zmian. Dodatkowo polityka retencji gwarantuje, że w określonym czasie nie ma możliwości usunięcia plików. To oznacza, że scenariusze, na wypadek których w każdym innym przypadku korzystam z backupu danych, tutaj po prostu nie występują. Zatem jedyny scenariusz, przed którym muszę się zabezpieczyć to awaria centrum przetwarzania lub awaria całego urządzenia. A do tego wykorzystuję zdalną replikację do drugiego ośrodka. Co to oznacza? Często ogromne oszczędności związane z brakiem konieczności budowania środowiska backupowego dla takiej macierzy. Jest to szczególnie ważne dla organizacji, w których środowiska plikowe liczone są w setkach terabajtów, czy tym bardziej w petabajtach danych. W takim przypadku wspomniane oszczędności są często jedynym i wystarczającym argumentem migracji danych z macierzy plikowej na macierz obiektową.

                   

Daj proszę znać w komentarzach, jeżeli chciałbyś/chciałabyś rozszerzyć tę listę o dodatkowe "kiedy" i dodatkowe "dlaczego".

 

Liczę, że powyższy materiał pomoże Ci:

• usystematyzować informacje o tym, jakie są różnice pomiędzy macierzami blokowymi, plikowymi i obiektowymi oraz
• podjąć decyzję, albo przynajmniej rozpocząć dyskusję o przydatności macierzy obiektowych w Twojej organizacji.

 

A jeżeli jeszcze nie przeczytałeś mojego poprzedniego artykułu na temat macierzy obiektowych – zrób to teraz i tutaj .