MENU

Obiekt, blok czy plik – jak zapisać dane w pamięci masowej?

9 października 2017Architekci IT, Polecane tematy

W ostatnim czasie, obok już bardzo dobrze znanych blokowych i plikowych pamięci masowych, coraz częściej pojawiają się magazyny obiektów. Skąd taka zmiana i czy na pewno jest to potrzebne?

Jako ludzie tworzymy i przechowujemy ogromne ilości danych. Ten trend raczej się nie zmieni, a co więcej, można przypuszczać, że będzie rosła też pierwsza pochodna sumy przechowywanych danych, czyli szybkość ich wzrostu. Więcej też danych przechowujemy, czego przyczyn – oprócz spadającego kosztu 1GB dysku – można szukać w zjawisku Big Data. Powodów jest kilka, od związanych z życiem codziennym takich, jak choćby nasze zdjęcia i filmy robione za pomocą telefonów komórkowych, dane z serwisów społecznościowych, po dane specjalistyczne. Zjawiska, jakimi zajmuje się biologia, fizyka i chemia generują niewyobrażalne ilości danych a my sami zaczynamy coraz intensywniej je mierzyć znajdując coraz to nowe wielkości i parametry. Rosnącą ilość danych można także tłumaczyć rosnącym zapotrzebowaniem na rozwiązania IoT. Zrozumieliśmy, że dane pomiarowe, które możemy otrzymać mierząc zjawiska występujące dookoła nas pozwolą nam lepiej zrozumieć rzeczywistość i się do niej dopasować. Już dzisiaj w krajach Unii Europejskiej jest wymagany czujnik ciśnienia w oponach, aby wyeliminować kolejne potencjalne przyczyny wypadków. Wkrótce może okazać się, że w tych samych oponach będziemy mieli czujnik wysokości bieżnika a nawet poziomu spękania gumy.

Warto gromadzić dane, nawet z pozoru nieistotne

Przetwarzanie wielkich zbiorów danych mocno zmieniło logikę, dotychczas stosowaną w klasycznym podejściu, ponieważ mechanizmy Big Data zwykle odpowiadają na pytanie „Jak jest?”, nie zaś „Dlaczego tak jest?”. Skoro nie szukamy związku przyczynowo skutkowego, ale chcemy poznać pewną korelacje zdarzeń, potrzebujemy ogromnych ilości danych. Próbka statystyczna nie pozwoli nam na takie analizy. Oznacza to, że istnieje sens przechowywania danych archiwalnych, choć często nie wiadomo do czego zostaną użyte i jak pokazuje rzeczywistość, od jakiegoś czasu to właśnie robimy. Dla przykładu dane paragonowe przechowuje się dzisiaj nie tylko dla Urzędu Skarbowego, ale także po to, aby wyciągnąć jak najwięcej wniosków o profilu klienta, jego potrzebach, zainteresowaniach czy zwyczajach.

Jeśli na podstawie ogromnej ilości danych dowiemy się, że ktoś, kto kupuje marchewkę zapewne kupi też seler. Możemy więc rozłożyć te warzywa w dwóch różnych miejscach sklepu, bo wspomniany klient zapewne oba odwiedzi. W ten sposób przy okazji zobaczy inne towary, na które nie zwróciłby uwagi, gdyby marchew i seler leżały obok siebie. Zauważmy, że do takiego wnioskowania kompletnie nie potrzebna nam wiedza, jak się kto nazywa czy ile ma dzieci. Z drugiej zaś strony, gdyby rozszerzyć taką analizę o zmienną mówiącą o mnogości potomstwa, mogłoby się okazać np., że z jakiegoś powodu warto położyć marchewkę w pobliżu mleka. Podobnych rozważań i przykładów można przytaczać wiele, ale najważniejsze w tym momencie jest jasne potwierdzenie, że warto przechowywać dane, nawet z pozoru nieistotne. Dane są inwestycją!

Przetwarzanie wielkich zbiorów danych mocno zmieniło logikę, dotychczas stosowaną w klasycznym podejściu, ponieważ mechanizmy Big Data zwykle odpowiadają na pytanie „Jak jest?”, nie zaś „Dlaczego tak jest?”. Skoro nie szukamy związku przyczynowo skutkowego, ale chcemy poznać pewną korelacje zdarzeń, potrzebujemy ogromnych ilości danych. Próbka statystyczna nie pozwoli nam na takie analizy. Oznacza to, że istnieje sens przechowywania danych archiwalnych, choć często nie wiadomo do czego zostaną użyte i jak pokazuje rzeczywistość, od jakiegoś czasu to właśnie robimy.

Do wyżej wymienionych powodów znacznego przyrostu danych dochodzi cyfryzacja. Niemal każde przedsiębiorstwo w jakimś stopniu rezygnuje z nośników papierowych na rzecz cyfrowych. I nie jest to jedynie skanowanie dokumentów, tylko realne uwzględnienie możliwości technologicznych i zmiana procesów w organizacji w taki sposób, aby z tych samych danych mogły korzystać różne systemy w różnych celach. To byt cyfrowy – a nie, jak dotychczas, dokument w segregatorze – ma być głównym wyznacznikiem określającym stan faktyczny. To zaś powoduje, że należy tym bardziej zadbać o trwałość przechowywanych danych, a co więcej ich niezmienność. Trwały nośnik to realne wymaganie wielu regulatorów, mających zapewnić, że w erze digitalizacji możemy liczyć na wiarygodność danych prezentowanych nam za pomocą różnych systemów. To także często wymóg naszych partnerów handlowych, którzy dokumentów papierowych już nam nie przekazują. Mamy zatem do czynienia nie tylko z dynamicznym zwiększeniem ilości przechowywanych danych, ale też kolejnymi metodami ich przechowywania i dostępu.

Różne modele dostępu do danych

W dużej ogólności pamięć masowa pozwala nam na przechowywanie danych w trzech formach:

  • –                blok (macierze VSP G/F),
  • –                plik (serwery HNAS i HNAS Unified),
  • –                obiekt (HCP/HDI).

Najbardziej rozpowszechnione są blokowe pamięci masowe, które udostępniają przestrzeń systemom operacyjnych serwerów w postaci dedykowanych urządzeń zewnętrznych. Oznacza to, że system, np. Windows, rozpozna macierz dyskową jako dysk o konkretnym identyfikatorze i tak jak każdy inny dysk, przygotuje go do użycia poprzez sformatowanie i przypisanie litery lub wirtualnego katalogu. To oczywiście duże uproszczenie, które pomija wiele zagadnień technicznych, takich jak architektura i konfiguracja macierzy, protokół komunikacji, zastosowanie sieci SAN lub LAN, jej konfiguracja i wiele innych. Chodzi jednak o to, aby uzmysłowić sobie najważniejszy fakt: przestrzeń prezentowana jako urządzenie blokowe, może być wykorzystana tak samo, jak każdy inny dysk w systemie operacyjnym. Oznacza to, że to aplikacja definiuje w jaki sposób korzysta z tego zasobu. Co więcej, zawsze korzysta z niego przez system operacyjny, w którym pracuje, a zasób ten jest widoczny jedynie dla konkretnego serwera lub co najwyżej klastra. Przykładowo, jeśli SQL Server tworzy na takim dysku plik bazy danych, to jedynie on jest w stanie dotrzeć do danych tam zawartych, otworzyć tabele i uruchomić zapytania. Sam system Windows/Linux tego nie zrobi, gdyż dla niego baza jest zwykłym plikiem. Podobnie, jak serwer SQL nie może dostać się bezpośrednio do danych umieszczonych na macierzy. Zawsze robi to z pomocą systemu operacyjnego.

Serwery plików działają nieco inaczej. Najczęściej nazywane są serwerami NAS (Network Attached Storage) i choć same wykorzystują najczęściej urządzenia blokowe, to klientom udostępniają pliki, zazwyczaj za pomocą protokołów CIFS (Common Internet File System) lub NFS (Network File System). W takim przypadku system korzystający z danych jest świadomy, że udostępniany plik jest osiągalny pod konkretnym adresem sieciowym i co ważne, może z niego korzystać dowolna aplikacja, która potrafi komunikować się właściwym protokołem dostępu. Zasób sieciowy nie jest dostępny na wyłączność dla serwera lub klastra serwerów, ale dla każdego kto zna adres i posiada stosowne uprawnienia, niezależnie czy jest to system operacyjny klienta, urządzenie mobilne, czy aplikacja. Dostęp taki jest zapewne wolniejszy niż dostęp bezpośredni do pliku przechowywanym na urządzeniu blokowym, ale dalece większa jest elastyczność w pozyskaniu przechowywanych informacji.

Najbardziej rozpowszechnione są blokowe pamięci masowe, które udostępniają przestrzeń systemom operacyjnych serwerów w postaci dedykowanych urządzeń zewnętrznych. Oznacza to, że system, np. Windows, rozpozna macierz dyskową jako dysk o konkretnym identyfikatorze i tak jak każdy inny dysk, przygotuje go do użycia poprzez sformatowanie i przypisanie litery lub wirtualnego katalogu. To oczywiście duże uproszczenie, które pomija wiele zagadnień technicznych, takich jak architektura i konfiguracja macierzy, protokół komunikacji, zastosowanie sieci SAN lub LAN, jej konfiguracja i wiele innych.

Okazuje się jednak, że i to jest za mało. Dane trzeba replikować, wykonywać kopie zapasowe, przechowywać archiwum, podobnie jak to miało miejsce w klasycznym podejściu blokowym. Przecież szczególnym przypadkiem serwera NAS jest system Windows Server z włączoną rolą File Server. Podlega on takim samym prawom jak inne, często sprzętowe systemy udostępniania plików. Podobnie jak one nie jest odporny np. na ransomware i inne złośliwe oprogramowanie.

W rzeczywistości serwery HNAS – zwane czasami głowicami NAS – dzięki sprzętowej implementacji pozwalają osiągnąć znacznie większą wydajność, skalowalność, dostępność i ciągłość, niż klasyczny Windows Server korzystający z macierzy blokowej. Coraz częściej stosuje się rozwiązania Unified, co w praktyce oznacza wyposażenie klasycznej macierzy blokowej w moduł NAS w postaci karty.

Jednak nawet w przypadku głowicy NAS z macierzą blokową, zapewnienie wielodostępu – a przy okazji ciągłości zbudowanej na kilku lokalizacjach – nie jest zagadnieniem trywialnym. W dalszym ciągu obowiązują te same reguły – budowa klastrów, replikacja danych na poziomie macierzy, ilość pamięci cache i jej synchronizacja między węzłami. Wszystko to trzeba właściwie zaprojektować. To jednak nie wszystko! Kiedy przenosimy rozważania nad dostępem do danych dla aplikacji gotowych na chmurę, tworzonych w modelu atomowym, pracujących w środowiskach DevOps sytuacja dalece się komplikuje. W dzisiejszych czasach, kiedy programista ma dostępne tak bardzo rozwinięte środowiska programowania, kto chciałby skupiać się nad otwieraniem czy zamykaniem plików, kontrolowaniem ich zawartości oraz miejsca, w którym skończyliśmy czytać czy pisać dane? Szczególnie jeśli jedna aplikacja przetwarza na przykład obraz i szuka w nim twarzy, a druga przetwarzając te same zdjęcia dąży do wychwycenia potencjalnych danych osobowych, jeszcze inna zaś ma za zadanie dowiedzieć się z metadanych EXIF jakie były warunki wykonania zdjęcia i miejsce, którym zostało zrobione.

W klasycznym podejściu, przy użyciu serwera plików, należałoby rozpoznać format obrazu, a następnie wykorzystując stosowne biblioteki wczytać dane binarne do pamięci. Dzisiaj szkoda na to czasu. Wystarczy, aby w kodzie programu pobrać – np. za pomocą HTTPS – obiekty typu obraz ze wszystkimi metadanymi. Dzięki temu mamy potrzebny komplet danych do przetwarzania. I to jest właśnie trzeci model, obiektowy. W podejściu tym już całkiem odrywamy się od konkretnego systemu operacyjnego i aplikacji, skupiając się tym samym na treści, zarządzaniu nią, kontroli i ochronie przed awarią. Interesuje nas przecież umowa kredytowa, zdjęcie, dokument handlowy, certyfikat, wiadomość, a nie aplikacja, która ją generuje. Daje to przy okazji niesamowitą wolność, gdyż nawet jeśli dzisiaj chcemy przetwarzać dane jedną aplikacją, a jutro do tego samego celu użyć innej, wystarczy, że ten nowej nadamy dostęp do odpowiednich obiektów. Nie ma potrzeby wykonywania migracji, bo przecież obiekt i jego metadane pozostają te same.

Obiektowy model przechowywania danych w praktyce

Przykładem obiektowego magazynu danych jest Hitachi Content Platform (HCP). Umożliwia on przechowywanie obiektów i ich metadanych w bezpieczny sposób, wraz z zabezpieczeniem ich dostępności i niezmienności. Zastosowanie GAT (Global Access Topology) pozwala na geograficzną dywersyfikację danych z zachowaniem informacji – po stronie platformy – o tym, jak należy replikować obiekty, aby uzyskać pełną redundancję zarówno lokalnie, jak i globalnie. Oczywiście, jak każda platforma przechowywania danych, HCP wyposażone jest w mechanizmy kompresji i de-duplikacji. Nawet jeśli cena przechowania 1GB spada, to na pewno nie tak szybko, jak rośnie zapotrzebowanie na przestrzeń. Dlatego zastosowanie takich mechanizmów jest konieczne, aby móc zapewnić atrakcyjność cenową całego rozwiązania.

Serwery plików – najczęściej nazywane serwerami NAS (Network Attached Storage) – choć same wykorzystują najczęściej urządzenia blokowe, to klientom udostępniają pliki za pomocą protokołów CIFS (Common Internet File System) lub NFS (Network File System). W takim przypadku system korzystający z danych jest świadomy, że udostępniany plik jest osiągalny pod konkretnym adresem sieciowym i co ważne, może z niego korzystać dowolna aplikacja, która potrafi komunikować się właściwym protokołem dostępu. Zasób sieciowy nie jest dostępny na wyłączność dla serwera lub klastra serwerów, ale dla każdego kto zna adres i posiada stosowne uprawnienia.

Podobnie jak w klasycznych macierzach blokowych – które zresztą mogą stanowić zaplecze dla platformy HCP – stosuje się Storage Tiering, czyli mechanizmy umożliwiające przenoszenie mniej używanych danych na znacznie tańsze wolumeny dyskowe o mniejszej wydajności. W przypadku platformy Hitachi są to węzły S10 i S30, które stanowią magazyny tanich dysków. Dzięki takiej architekturze HCP można rozbudowywać do ogromnych wielkości bez angażowania niebotycznych budżetów. Jak to działa? Warto wrócić do na moment do blokowych pamięci masowych. One dalej są wymagane do zaprezentowania systemowi operacyjnemu dysków w tym często systemowych, np. w scenariuszu Boot from SAN. I rzeczywiście – te przestrzenie muszą być bardzo wydajne i charakteryzować się niskim opóźnieniem. Platforma HCP skupia się na treści, a więc ważne, aby było dużo wartościowych informacji. Jednak czas dostępu do nich często może być nieco dłuższy niż dla pliku wymiany pamięci (pagefile.sys) w Windows. Jak więc widzimy, to czysta fizyka pozwala nam stosować taką właśnie architekturę i skutecznie dostarczać treść zarówno do użytkowników, jak i aplikacji.

Z dostępu do obiektów zaczyna korzystać coraz więcej firm trzecich, które używają HCP jako potencjalnej przestrzeni na przechowywanie danych poprzez protokół REST for HTTP lub Amazon S3. Przykładem może tu być Star Storage SEAL, zapewniający trwały nośnik i obieg dokumentów, ale także Enterprise Vault czy HCP Anywhere. Istotnym katalizatorem rozwoju takich rozwiązań – i zaangażowania producentów oprogramowania w stosowanie obiektowej pamięci masowej – są regulacje prawne. Jednym z przykładów jest MiFID II. HCP nie odpowiada na wszystkie potrzeby wynikające z konieczności wprowadzenia tej dyrektywy, ale w znacznym stopniu może uprościć globalne zarządzanie umowami, ofertami i innymi dokumentami, których dotkną nowe zasady.

A co jeśli potrzebujemy klasycznego dostępu do danych w postaci CIFS/NFS? Platforma HCP wprawdzie pozwala na dostęp za pomocą tych protokołów, ale by zapewnić dużą wydajność warto zastosować Hitachi Data Ingestor. To rozwiązanie, które z jednej strony serwuje zasoby plikowe w klasyczny sposób, a z drugiej rozumie język HCP i dane, które odbierze od użytkowników i aplikacji przechowuje w postaci obiektów. Tu również można zauważyć piękno modelu obiektowego, w którym jeden system – przy użyciu HDI – zasila magazyn plikiem JPG, inny zaś – kompletnie pomijając plikowy charakter danych, wyłącznie za pomocą klasycznego HTTP GET – pobiera obiekt do zupełnie innej analizy.

Bezpieczeństwo danych obiektowych

Platforma HCP może pracować bez kopii zapasowej, ponieważ mechanizmy Erasure Coding zapewniają odpowiednią ilość redundantnych kopii danych i metadanych oraz kontrolę wersji. Nawet w przypadku ransomware, nie ma możliwości zaszyfrowania wszystkich danych, tak jak plików na klasycznym systemie FAT, NTFS, EXT czy innym. Można ustawić za pomocą odpowiednich polityk takie zachowanie, że każda kopia danego obiektu będzie stanowiła jego nową wersję. Zatem jeśli złośliwe oprogramowanie zniszczy nam aktualną zawartość istotnego DOC lub XLS, będzie mogło go zapisać jako kolejną wersję, podczas gdy poprzednia – nieuszkodzona – będzie dla nas cały czas dostępna. Istotnym aspektem bezpieczeństwa danych jest ich… niszczenie. HCP zapewnia algorytmy niszczenia przechowywanych obiektów zgodne ze standardem 5220.22-M Departamentu Obrony USA.

Kiedy przenosimy rozważania nad dostępem do danych dla aplikacji gotowych na chmurę, tworzonych w modelu atomowym, pracujących w środowiskach DevOps sytuacja dalece się komplikuje. W dzisiejszych czasach, kiedy programista ma dostępne tak bardzo rozwinięte środowiska programowania, kto chciałby skupiać się nad otwieraniem czy zamykaniem plików, kontrolowaniem ich zawartości oraz miejsca, w którym skończyliśmy czytać czy pisać dane? Szczególnie jeśli jedna aplikacja przetwarza na przykład obraz i szuka w nim twarzy, a druga przetwarzając te same zdjęcia dąży do wychwycenia potencjalnych danych osobowych, jeszcze inna zaś ma za zadanie dowiedzieć się z metadanych EXIF jakie były warunki wykonania zdjęcia i miejsce, którym zostało zrobione.

Wirtualizacja pamięci obiektowej

Jedną z wielu zalet platformy HCP jest to, że można ją uruchomić w postaci sprzętowej. Można jednak zastosować też tzw. Virtual Appliance na platformie VMware, Hyper-V lub KVM. To znacznie podnosi elastyczność rozwiązania. Przede wszystkim jednak można bardzo łatwo uruchomić pilota takiego środowiska. Rozwiązanie oparte o wirtualizację nie ogranicza się oczywiście do zastosowań testowych. Na rynku polskim, w sektorze finansowym pracują wirtualne platformy HCP w zastosowaniach biznesowych o znaczeniu krytycznym. Wspierane są zaawansowane mechanizmy wysokiej dostępności platform wirtualnych, ale co ważne można również wykorzystać mechanizmy VAAI oraz SMI-S. Dzięki temu uzyskuje się bardzo dużą elastyczność rozwiązania i w zasadzie każdy model hybrydowy jest w zasięgu ręki.

Chmura obliczeniowa a dane obiektowe

Ważną cechą rozwiązania HCP jest możliwość bezpiecznego połączenia z zewnętrzną chmurą publiczną – taką, jak Microsoft Azure lub Amazon AWS – która będzie zasobem, do którego można wysyłać dane. Dzięki temu istnieje możliwość wykorzystania elastyczności chmury obliczeniowej dla wielkich zbiorów archiwalnych, których koszt przechowywania na własnych dyskach może być dużo większy. Zastosowanie szyfrowania wszystkich obiektów w takim przypadku, to najczęściej warunek konieczny, ale i wystarczający, aby uwolnić się nieco od własnego centrum danych. Kluczowym elementem tej układanki nie jest jednak sama możliwość zapisu w publicznej chmurze obliczeniowej. Taką możliwość posiadało już wcześniej wiele narzędzi dostępnych na rynku. Najbardziej atrakcyjnym elementem tego scenariusza – realizowanego przez rozwiązania Hitachi – jest możliwość identyfikacji danych, które mogą zostać przeniesione do chmury obliczeniowej, a które nie powinny do niej trafić, np. ze względu na zawartość danych osobowych.

Algorytmy analityczne – wykorzystywane w Hitachi Content Intelligence – w połączeniu z Pentaho Data Ingestor pozwalają gromadzić i analizować dane z różnych źródeł pod kątem zgodności z wybranymi szablonami i regułami. Można w ten sposób np. szukać zwrotów grzecznościowych w nagraniu telefonicznym infolinii i analizować poziom jakości obsługi klienta. Można też szukać zdjęć twarzy czy postaci zarejestrowanych przez monitoring CCTV. W razie potrzeby zaś można sprawdzać występowanie numerów NIP, PESEL i innych w dokumentach typu DOC czy PDF. Mając już takie analizy znacznie łatwiej i bardziej odpowiedzialnie można podejmować decyzję o przechowaniu konkretnych danych w chmurze publicznej.

Tańszy SharePoint, Exchange i…

Niezależnie od rozwoju nowoczesnych aplikacji pisanych z założeniem ich uruchamiania w chmurze obliczeniowej, przez długi czas będą działały takie magazyny danych, jak SharePoint, Exchange i wiele innych. Są to rozwiązania sprawdzone przez cały świat, rozwijane, wspierane i po prostu w wielu wypadkach wygodne. Z tego samego powodu są intensywnie używane i zawierają ogromne ilości danych. Platforma HCP pozwala na znaczną optymalizację ich przechowywania poprzez zabieg przeniesienia rzeczywistej treści mało używanych, a szczególnie dużych objętościowo danych, do magazynu obiektów. W ten sposób wielostronicowy załącznik DOC czy MP4 może znaleźć się na ekonomicznym archiwum, a w oryginalnym miejscu – np. witrynie SharePoint lub wiadomości Outlook – pozostanie jedynie odnośnik. Dla użytkownika proces ten będzie całkowicie przezroczysty i nic nie zmieni się w korzystaniu z tych rozwiązań. Jednak dalece zoptymalizowana baza Exchange będzie znacznie efektywniej pracowała, mniej będzie trwało jej przeszukiwanie i szybciej będzie wykonywana kopia zapasowa.

W klasycznym podejściu, przy użyciu serwera plików, należałoby rozpoznać format obrazu, a następnie wykorzystując stosowne biblioteki wczytać dane binarne do pamięci. Dzisiaj szkoda na to czasu. Wystarczy, aby w kodzie programu pobrać – np. za pomocą HTTPS – obiekty typu obraz ze wszystkimi metadanymi. Dzięki temu mamy potrzebny komplet danych do przetwarzania. To jest model obiektowy. W podejściu tym już całkiem odrywamy się od konkretnego systemu operacyjnego i aplikacji, skupiając się tym samym na treści, zarządzaniu nią, kontroli i ochronie przed awarią.

Kopia zapasowa danych obiektowych

Skoro już mowa o kopii zapasowej, warto zauważyć, że Hitachi Content Platform nie wymaga takich mechanizmów. Wspomniany wcześniej mechanizm Erasure Coding gwarantuję redundancję na takim poziomie, żeby zawsze móc odzyskać utracone w wyniku awarii dane. To czyni z HCP nie tylko rozwiązanie tańsze w utrzymaniu, ale mogące jednocześnie stanowić docelowe archiwum dla wielu danych organizacji, które dzisiaj są zabezpieczane na kopiach zapasowych w klasyczny, często nieoptymalny sposób. I tak HCP może stanowić magazyn obiektów np. dla bardzo popularnego rozwiązania Enterprise Vault, które znane jest m.in. z szerokiej gamy wspieranych rozwiązań i dobrej pozycji wśród rozwiązań tej klasy.

Dokumenty użytkowników w postaci obiektów

Skoro nie trzeba martwić się o kopie zapasowe, to może to jest właśnie najlepsze miejsce na przechowywanie swoich danych? Każdy z nas, używając dowolnego komputera generuje niemałą ilość dokumentów, arkuszy kalkulacyjnych, zdjęć. Na części z nich pracujemy indywidualnie, umieszczając je w takich miejscach jak folder Moje Dokumenty czy Pulpit. Na innych pracujemy wspólnie z całym zespołem lub organizacją a nawet osobami z poza niej. Ten ostatni przypadek okazuje się być wyzwaniem dla wielu działów IT i bezpieczeństwa. Wspólna praca na plikach z osobami z zewnątrz, choć pozornie łatwa, po nałożeniu polityk bezpieczeństwa i innych istotnych regulatorów przestaje być problemem trywialnym.

HCP Anywhere przychodzi z pomocą w takich sytuacjach. Wykorzystując platformę HCP, rozwiązanie to umożliwia synchronizację plików i katalogów zarówno prywatnych, jak i zespołowych na wielu urządzeniach. Jest to bezpiecznie i automatycznie, a co ważne bez konieczności stosowania zewnętrznych centrów danych czy chmury publicznej.  Wszystkie nasze pliki, pliki zespołowe i te, na których pracujemy z innymi organizacjami mogą być w bezpieczny sposób dostępne, niezależnie czy pracujemy na służbowym komputerze, telefonie tablecie czy domowym PC przez przeglądarkę. Wszystko jest jedynie kwestią ustawień, które definiują jakie scenariusze chcemy dopuścić. W zamian otrzymujemy wersjonowanie dokumentów oraz skuteczny mechanizm kopii zapasowej całego komputera, a co za tym idzie nie za bardzo przejmujemy się ransomware, czy awarią dysku twardego. Ze wszystkimi plikami pracujemy tak, jakby były one na naszym komputerze. Warto dodać, że taka zmiana umożliwia organizacjom oddanie w ręce pracowników znacznie większych niż wcześniej pojemności na ich dane, przy większej elastyczności i zachowaniu wszystkich mechanizmów ich zabezpieczania. Naturalną implikacją tej sytuacji jest fakt, iż użytkownicy znacznie chętniej sięgają po dostarczone przez własną organizację rozwiązanie i nie szukają rozwiązań alternatywnych w chmurach publicznych. HCP Anywhere minimalizuje więc zjawisko Shadow IT.

W dość podobnym scenariuszu przechowywane i udostępniane są treści multimedialne. Jedną z referencji Hitachi jest świadczący usługi Video On Demand firma Netflix. Niezwykle cenna jest możliwość przechowywania nie tylko samej treści wideo, ale także metadanych umożliwiających jej przeszukiwanie oraz rekomendowanie potencjalnemu odbiorcy. Potęga Netflix została zbudowana m.in. dzięki trafnym rekomendacjom, wynikającym z analiz Big Data. Posiadanie kosztowo optymalnego magazynu na samą treść, umożliwiającego jednocześnie skuteczne opisywanie materiałów coraz to nowymi kategoriami informacji ma fundamentalne znaczenie w realnym wykorzystaniu analiz i przygotowaniu rekomendacji. Nie można osiągnąć tego efektu jedynie za pomocą płaskich plików MP4 czy MOV.

Rozwój aplikacji z dostępem do danych obiektowych

HCP stanowi magazyn obiektów nie tylko dla produktów gotowych, ale także dla zespołów deweloperskich i testowych. Dzięki zastosowaniu protokołów takich jak Amazon S3 – których popularność stale rośnie – może stanowić repozytorium kodów czy logów. Przykładowo Jenkins – bardzo popularny w środowiskach DevOps – może używać HCP jako pamięci masowej, a jej podłączenie odbywa się w GUI.

W świecie deweloperskim blokowa pamięć masowa w zasadzie nie istnieje. Macierz musi być uprzednio wyskalowana, udostępniona dla serwera w postaci wolumenu, który zostanie sformatowany przez system operacyjny. Wtedy – w zależności jaki to system – aplikacja napisana przez programistę będzie mogła otworzyć plik, odczytać i zapisać do niego. Oczywiście trzeba będzie też plik zamknąć i to wszystko w każdym systemie nieco inaczej. W przypadku HCP -dostępnego poprzez protokół Amazon S3 – wystarczy, nawet za pomocą http, pobrać obiekt i go zapisać. Jedna linia kodu i nie trzeba się specjalnie niczym przejmować. Pobranego obiektu nie trzeba otwierać ani zamykać. Między innymi dla tej prostoty wielu programistów chętnie sięga do platform programistycznych dostępnych w chmurach publicznych. One tę elastyczność dają… i to tanio. Znowu dochodzimy tu do problematyki Shadow IT. Udostępnienie takiego chmurowego magazynu wewnątrz organizacji pozwala programistom efektywniej tworzyć oprogramowanie a całej organizacji zwiększać szybkość dostarczania nowych wersji do klienta końcowego. Cenne jest jednak to, że nie tracimy przy tym kontroli nad danymi ich separacją między środowiskami, liniami produkcyjnymi, fazami wdrożeń i czynnikami istotnymi z punktu widzenia procesu zarządzania wersją. Podobnie jak w przypadku dokumentów, maleje zapotrzebowanie i ryzyko stosowania przez pracowników zasobów zewnętrznych.

Kontrola kosztów przechowywania danych

W przypadku każdej współdzielonej platformy, warto dokładnie wiedzieć, jak rozliczyć poszczególnych użytkowników z jej wykorzystania. Niezależnie czy jej właściciel wystawia faktury, czy rozliczenie następuje jedynie na poziomie budżetowania poszczególnych projektów, takie informacje są potrzebne. Dlatego platforma HCP posiada wbudowane mechanizmy Chargeback. Potrafią one same dostarczyć wiele informacji z tego zakresu. Przy odpowiedniej integracji, np. z vRealize Business, mogą także zasilać dalece bardziej skomplikowane mechanizmy kalkulacji kosztów czy współczynników TCO.

Korzystny współczynnik TCO/ROI, nowe możliwości jakie przynosi obiektowa pamięć masowa oraz coraz wyższe wymagania stawiane w regulacjach sprawiają, że tym modelem przechowywania danych interesuje się coraz więcej organizacji. Szczególnie instytucje finansowe spoglądają w stronę trwałego nośnika i możliwości łatwego przeszukiwania danych z uwagi na nowe rozporządzenie o ochronie danych osobowych RODO/GDPR.

Administracja publiczna posiada zaś w zbiorach niezliczone ilości wszelkiego rodzaju dokumentacji, których digitalizacja stała się nieunikniona i nabiera realnych rozmiarów. W Polsce dokonano tego np. w przypadku ksiąg wieczystych, a dotyczyć ma to także dokumentacji medycznej. Systemy analizy wideo, logów, nagrywania rozmów – wszystkie one stanową potencjalny obszar ulepszeń, jakie może wnieść obiektowe podejście do danych. Cena takiej pamięci jest zaś dużo atrakcyjniejsza, przynajmniej w porównaniu do klasycznej pamięci blokowej czy plikowej. Wydaje się, że zastosowanie Object Storage jest przesądzone. Pozostaje tylko pytanie w jakim zakresie, jak szybko… i co będzie następne.

Krzysztof Waszkiewicz jest architektem IT.

Podobne tematy:

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

« »