TomaszJangas.com Obiektowa pamięć masowa zdobywa rynek w Polsce? 25 października 2017 Czy warto sobie zaprzątać głowę jakimś kolejnym rodzajem pamięci masowej? Moim zdaniem tak, a powodów, dlaczego warto jest tak samo dużo, jak scenariuszy zastosowania tego rodzaju macierzy w naszych organizacjach. Przede wszystkim ten rodzaj pamięci masowej zapewnia korzyści, o których trudno nawet wspominać w przypadku obecnie największego jej konkurenta, czyli macierzy plikowej (NAS Network Attached Storage). Wykorzystanie w architekturze macierzy obiektowej implikuje jednak zupełnie inny sposób zapisywania i odczytywania danych przez aplikację (chociaż są rozwiązania, które pozwalają połączyć zalety macierzy obiektowych z tradycyjnym sposobem udostępniania przestrzeni dla aplikacji). Ta zmiana z kolei, w wielu przypadkach jest powodem, dlaczego duża część organizacji cały czas tkwi w średniowieczu i ciągle zastanawia się czy zrobić krok w kierunku renesansu. Z moich obserwacji wynika, że coraz więcej przedsiębiorstw decyduje się na ten krok. Ale dlaczego to robią? Jeżeli uznasz, że nie znalazłeś odpowiedzi w dalszej części materiału, podziel się proszę swoim doświadczeniem w tej dziedzinie. 1 2017 Tomasz Jangas
Gdzie w architekturze korporacyjnej narysować obiektową pamięć masową? Nie zawsze i nie wszędzie macierz plikowa może zostać zastąpiona macierzą obiektową. Chociaż moim zdaniem wraz z rozwojem aplikacji przystosowanych do pracy w chmurze i działających w oparciu o mikroserwisy (gdzie do komunikacji wykorzystuje się lekkie protokoły, takie jak http), ta waga będzie się mocno przechylać na korzyść macierzy obiektowych. Gdzie w takim razie możliwe jest wykorzystanie obiektowej pamięci masowej? Zacznę od przykładu. Rysunek poniżej przedstawia system ECM (Enterprise Content Management), w którym przechowujemy między innymi dokumenty naszych klientów: umowy kredytowe, wnioski, regulaminy. Oczywiście obiektowa pamięć masowa nie zastąpi nam w tej architekturze aplikacji ECM. Z punktu widzenia tej aplikacji będzie to nadal jakaś macierz, która udostępnia przestrzeń do fizycznego przechowywania dokumentów. I to właśnie w tym miejscu należy ją umiejscowić tam, gdzie tradycyjnie w wielu przedsiębiorstwach królują nadal macierze plikowe (NAS). W takiej architekturze jak powyżej: 1. W aplikacji ECM zaszyta jest cała logika biznesowa, związana z zarządzaniem dokumentami, ich przetwarzaniem oraz określaniem atrybutów i polityk, którymi należy objąć dokument. To również tutaj udostępniamy interfejs do zarządzania całym systemem. 2 2017 Tomasz Jangas
2. Z kolei obiektowa pamięć masowa zapewnia przestrzeń dyskową, analogicznie jak macierz plikowa (NAS), ale ponadto dostarcza kilku ciekawych funkcjonalności i korzyści, których nie znajdziesz w NASie. Dziedziczy również ustawione na poziomie aplikacji ECM właściwości danych (polityki) i stosuje je na poziomie sprzętowym. Dygresja #1: Aby lepiej zobrazować obowiązującą klasyfikację pamięci masowych, posłużę się moim ulubionym przykładem: Macierz blokowa rozumie bloki 0 i 1 (protokoły: FC, iscsi, FICON) Macierz plikowa rozmawia z serwerem na poziomie plików i podstawowych metadanych systemowych (protokoły: CIFS, NFS, FTP) Macierz obiektowa operuje na jeszcze wyższym poziomie. Tutaj, jak sama nazwa wskazuje, przechowujemy obiekty, które składają się: (1) z pliku, (2) z metadanych systemowych i własnych oraz (3) z polityk, określających zachowanie obiektu w macierzy (protokoły: http, S3, SWIFT, RESTful API) Chcesz poznać więcej szczegółów na temat różnic pomiędzy tymi trzema rodzajami pamięci masowych? Polecam artykuł Krzysztofa Waszkiewicza, który ukazał się na łamach październikowego numeru ITWIZ: http://itwiz.pl/obiekt-blok-czy-plik-jak-zapisac-dane-pamieci-masowej/ Ale jakie są te korzyści? Wróćmy do przykładu aplikacji ECM. W przypadku tradycyjnych środowisk, w których wykorzystywana jest macierz plikowa, metadane dokumentu musimy przechowywać w zewnętrznej bazie danych, którą trzeba utrzymywać oraz odpowiednio zabezpieczyć. W macierzach obiektowych pojawia się możliwość przechowywania informacji opisujących dokument, czy nawet informacji o tym co się działo z tym dokumentem w trakcie jego przechowywania wewnątrz samego obiektu. Dane (dokument) i metadane (informacje o tym dokumencie) są przechowywane i zabezpieczone razem, w tym samym miejscu. Dodatkowo, ponieważ niektóre macierze obiektowe działają w oparciu o technologię WORM (Write Once Read Many), dlatego możliwe jest zapewnienie niezmienności przechowywanych w nich danych (zarówno samego dokumentu, jak i jego metadanych). A ta gwarancja jest z kolei istotna wszędzie tam, gdzie taka niezmienność wymagana jest na przykład przez różne regulacje prawne. Do gwarancji niezmienności oraz technologii WORM powrócę jeszcze za chwile. Zakończmy jednak najpierw temat metadanych. 3 2017 Tomasz Jangas
W powyższym przykładzie widzisz w jaki sposób, za pomocą metadanych można zintegrować ze sobą wiele różnych aplikacji, dla których bezpośrednia integracja jest często, albo w ogóle niemożliwa, albo bardzo kosztowna (na przykład z powodu różnych protokołów dostępu, obsługiwanych przez te aplikacje). W takim systemie jak powyżej, tworzymy centralne repozytorium dla danych pochodzących z różnych aplikacji. Rozkładamy te dane na czynniki pierwsze i udostępniamy na przykład w portalach takich, jak te na rysunku. Ale co to znaczy rozkładamy na czynniki pierwsze? Informacje zapisujemy w metadanych przechowywanych w plikach XML, które dostarczają właściwej struktury i które stanowią część obiektu. Przykład takiego rozkładu znajdziesz na rysunku poniżej. 4 2017 Tomasz Jangas
Integracja wielu aplikacji w obrębie centralnego obiektowego magazynu danych pozwala na zastosowanie jeszcze jednej ciekawej funkcji. Wyszukiwania danych i metadanych pochodzących z tych wszystkich aplikacji w jednym miejscu. Jest to realizowane w oparciu o silnik wyszukiwania metadanych dostępny wewnątrz macierzy obiektowej. Wyobraź sobie konsultanta w call center, który ma dostęp do sytemu CRM oraz wielu dodatkowych aplikacji dziedzinowych. Podczas rozmowy z klientem konsultant szuka informacji w tych wszystkich aplikacjach niezależnie. A teraz załóżmy, że ten sam konsultant korzysta z jednego portalu i za pomocą jednego zapytania (np. ID-klienta = 1234) otrzymuje w jednym miejscu wszystkie informacje powiązane z tym klientem, pochodzące z różnych aplikacji. Podsumujmy część związaną z metadanymi. 1. Umiejętność przechowywania i przetwarzania własnych metadanych jest jedną z podstawowych różnic pomiędzy macierzą obiektową, a macierzą plikową. 2. Metadane w macierzy obiektowej pozwalają na bezpieczne przechowywanie dokumentu oraz informacji o tym dokumencie w jednym miejscu w konsekwencji upraszcza to architekturę aplikacji oraz obniża koszty systemu. 3. Metadane w macierzy obiektowej mogą posłużyć do integracji danych z różnych systemów i aplikacji oraz udostępnieniu ich z jednego miejsca użytkownikowi biznesowemu i/lub klientowi. Zdarza się, że dla określonych procesów biznesowych informacje o tym co zawiera dokument (zapisane w metadanych) są tak samo ważne, jak sam dokument. Przykład? Weźmy bardzo gorący temat chyba we wszystkich przedsiębiorstwach i organizacjach, działających na terenie Unii Europejskiej. 25 maja 2018 roku wchodzi w życie Rozporządzenie o Ochronie Danych Osobowych (RODO, GDPR). Zgodnie z tym Rozporządzeniem na wniosek obywatela, przedsiębiorstwa będą zobligowane między innymi do przekazania informacji o tym, jakie dane osobowe tegoż obywatela są przetwarzane w ich systemach informatycznych. Ale, aby móc przekazać te informacje, trzeba przede wszystkim mieć możliwość ich wyszukania. W przypadku danych przechowywanych w bazach danych, zagadnienie niekoniecznie musi być problematyczne. Inaczej wygląda to jednak dla danych niestrukturalnych (plików, dokumentów) przechowywanych z reguły w macierzach plikowych. Tam znalezienie dokumentu, który zawiera dane osobowe wnioskodawcy może być trudne lub w ogóle niemożliwe do zrealizowania w wymaganym przez Rozporządzenie czasie. To z kolei wiązać się będzie z ogromnymi karami finansowymi, które w takich sytuacjach będą nakładane na przedsiębiorstwa. Rozwiązanie? Przygotowując się do wejścia w życie Rozporządzenia, możemy przeszukać zbiory dokumentów i oznaczyć je odpowiednią flagą w metadanych. Wówczas wyszukanie dokumentu na żądanie naszego przykładowego obywatela będzie zrealizowane błyskawicznie. Aby jednak mieć możliwość zapisania tej flagi, 5 2017 Tomasz Jangas
musimy pracować w systemie, który rozumie metadane i potrafi utrzymać relacje pomiędzy dokumentem, a tymi metadanymi. Macierz plikowa nie jest w stanie nam tego zagwarantować. Inne różnice, więcej korzyści. Zostańmy jeszcze przez chwilę w temacie RODO. W artykule 5 tego Rozporządzenia jest mowa między innymi o zapewnieniu bezpieczeństwa danych, a w szczególności ochronie przed ich przypadkową utratą. RODO nie jest wyjątkiem. W branży finansowej (ale nie tylko) przedsiębiorstwa pracują nad budowaniem i wdrażaniem rozwiązań, które zapewnią zgodność z takimi regulacjami jak MIFID2 i Trwały Nośnik. W tych regulacjach musimy pójść nawet jeszcze dalej i oprócz ochrony przed przypadkowym usunięciem, zagwarantować dodatkowo niezmienność przechowywanych danych. Te dwa wymagania biznesowe możemy przełożyć na świat technologii w następujący sposób: ochrona przed przypadkowym usunięciem danych ó polityka retencji danych gwarancja niezmienności danych ó technologia WORM I znowu, tych właściwości trudno szukać w macierzach plikowych. WORM wprawdzie pojawia się w niektórych urządzeniach NAS, ale tamto rozwiązanie moim zdaniem nie nadaje się do wykorzystania w tego typu scenariuszach, jak opisane powyżej (bo ustawiane jest i dotyczy całego systemu plików, a nie obiektu). Technologia WORM i fakt, że urządzenie jest w stanie zagwarantować niezmienność przechowywanych w nim danych może być wykorzystany w macierzach obiektowych również innym scenariuszu. Niekoniecznie musi to być tylko i wyłącznie przypadek zapewnienia zgodności z regulacjami prawnymi. Dygresja #2: W jaki sposób zabezpieczamy dane w systemach informatycznych. Generalnie sprowadza się to do: 1. Budowy środowiska disaster recovery (DR) ze zdalną replikacją danych pomiędzy ośrodkami zabezpieczamy się w ten sposób przed awarią urządzenia lub całego ośrodka. 2. Budowy środowiska backupu z wykonywaniem i utrzymywaniem lokalnych kopii danych zabezpieczamy się przed logicznym błędem aplikacji lub użytkownika, przypadkowym lub umyślnym skasowaniem danych, umyślnym zaszyfrowaniem danych (na przykład przez złośliwie oprogramowanie typu ransomware). 6 2017 Tomasz Jangas
I co z tego wynika? Jeżeli przechowuję swoje dane w obiektowym magazynie danych, który za pomocą technologii WORM jest w stanie zapewnić ich niezmienność, to tak naprawdę nie potrzebuję się zabezpieczać na wypadek wystąpienia tego drugiego scenariusza. A to może oznaczać (i wielu przypadkach oznacza) duże oszczędności kosztów. Szczególnie jeśli dla porównania odniesiemy się do tradycyjnego środowiska z macierzami plikowymi, które takiego backupu wymagają. Coraz bardziej zauważalnym problemem w takich środowiskach jest duży przyrost danych niestrukturalnych, który powoduje: (1) wydłużanie się procesu backupu naszego NASa oraz (2) wzrost kosztów infrastruktury backupowej. Znam środowisko plikowe, w którym ze względu na bardzo dużą ilość danych, wykonywanie kopii zapasowej nie jest w stanie zakończyć się w czasie przewidzianego dla niej okna backupowego. Znam również inne ogromne (petabajtowe, PB) środowisko, którego właściciel już dawno zdecydował się na migrację plików z macierzy plikowej na macierz obiektową nie z powodów regulacji prawnych, ale właśnie ze względu na możliwość wyeliminowania backupu oraz oszczędności z tym związane. Dygresja #3: Wbrew pozorom obiektowe pamięci masowe wcale nie są, aż tak nowe na rynku. Ich pierwsza fala pojawiła się już w latach 90-tych. Były to wówczas takie urządzania jak: FilePool (1993), kupione w 2001 przez EMC i sprzedawane pod nazwą Centera Bycast (2000), kupiony w 2010 roku przez NetAppa Persist (2002), przejęty przez HP w roku 2003 Archivas, kupiony w 2007 roku przez Hitachi Data Systems i sprzedawany do tej pory pod nazwą Hitachi Content Platform i wiele, wiele innych Równolegle, w tym czasie, rozwijały się takie systemy rozproszone jak: Google GFS (2003) Google MapReduce (2004) Hadoop HDFS w Yahoo (2006) Podsumujmy część związaną z retencją i WORMem. 1. Gwarancja niezmienności danych i ochrony przed ich skasowaniem, ważna w przypadku konieczności zaspokojenia takich regulacji jak RODO, MIFID2, Trwały 7 2017 Tomasz Jangas
Nośnik i wielu innych WORM i ustawianie czasu retencji danych i metadanych z gwarancją, że przed upływem tego czasu nie zostaną one usunięte. 2. Zabezpieczenie danych przed złośliwym oprogramowaniem szyfrującym ponieważ dane nie mogą zostać zmienione, dlatego próba ich zaszyfrowania będzie skutkować, albo utworzeniem kolejnej wersji, albo powstaniem nowego obiektu. Oryginał zawsze pozostaje bez zmian. 3. Gwarancja niezmienności danych zabezpieczamy się tylko na wypadek awarii ośrodka lub urządzenia (DR). Nie ma potrzeby backupowania danych. Upraszczamy architekturę środowiska. Obniżamy koszty operacyjne (związane z utrzymaniem środowiska backupu) i kapitałowe (związane z zakupem licencji i sprzętu dla tego środowiska). Drogi Czytelniku. Właśnie zauważyłem, że artykuł ten przybiera powoli rozmiary noweli, dlatego pozwól, że w tym miejscu go zakończę. Ponieważ jednak zagadnień wokół obiektowych pamięci masowych i scenariuszy ich wykorzystania jest bardzo wiele, to już w tej chwili mogę obiecać, że treści w tym temacie będzie na pewno więcej w kolejnych artykułach. Na zakończenie chcę zostawić Ci małą próbkę przykładów wykorzystania obiektowych pamięci masowych. Lista ta została wyprodukowana przez jedną z firm analizującą rynek IT. A przypadki zastosowania obiektowych pamięci masowych podzielono na dwie grupy. W pierwszej znajdują się scenariusze, które są już bardzo dojrzałe na rynku (w Europie i na świecie, jeszcze nie zawsze w Polsce): Archiwizacja dokumentów, poczty elektronicznej i innych systemów i źródeł danych. Zapewnienie zgodności z regulacjami prawnymi, szczególnie w ostatnim okresie w kontekście takich regulacji jak: MIFID2, RODO/GDPR, Trwały Nośnik. Budowanie środowisk usługowych dla danych (chmura dla danych). Repozytorium dla backupu. Przechowywanie plików (alternatywa dla NASa, szczególnie dla bardzo dużych środowisk plików, które coraz trudniej backupować). Repozytoria dokumentów. Współdzielenie treści wewnątrz przedsiębiorstwa oraz pomiędzy zewnętrznymi kontrahentami. W drugiej grupie możemy przeczytać o przewidywaniach oraz przypadkach, które dopiero dojrzewają na rynku: Repozytorium dla aplikacji przystosowanych do pracy w chmurze, w tym również repozytorium dla programistów piszących takie aplikacje. Wykorzystanie w procesach analityki biznesowej. Internet rzeczy (IoT). 8 2017 Tomasz Jangas
Spark, Hadoop, MapReduce, czyli wszystko co kojarzy się z dużymi zbiorami danych (big data). 9 2017 Tomasz Jangas