Deduplikowanie danych – FAQ (cz. II)

0

6. Jaka jest różnica między deduplikowaniem typu inline, a deduplikowaniem typu post-process?

Deduplikowanie typu inline oznacza, że dane są deduplikowane przed zapisaniem ich na dysk. Deduplikowanie typu post-process analizuje i ogranicza ilość danych po zapisaniu ich na dysk.

Deduplikowanie inline jest najbardziej efektywną i ekonomiczną metodą deduplikowania. Deduplikowanie takie pozwala znacznie ograniczyć wymagania dotyczące pojemności dysków, ponieważ deduplikowane dane nie są na nich nigdy zapisywane. Jeśli system deduplikowania typu inline obsługuje również zadanie replikowania danych, deduplikowanie takie optymalizuje również, dużo lepiej niż inne metody, parametr time-to-DR (Disaster Recovery; czas potrzebny do odzyskania danych po awarii). Dzieje się tak dlatego, ponieważ system nie musi wtedy czekać na zaabsorbowanie wszystkich danych i następnie deduplikowanie ich, zanim zacznie je replikować przesyłając do odległej lokalizacji.

Technologie deduplikowania typu post-process czekają aż dane zostaną zapisane na dysku i dopiero wtedy przystępują do właściwego procesu ich deduplikownania. Technologie takie wymagają stosowania dużo pojemniejszych systemów pamięci masowych niż technologie deduplikowania typu inline. Proces deduplikowania oparty na metodzie post-process trwa dlatego dłużej. To samo można powiedzieć o replikowaniu danych, ponieważ przed przystąpieniem do tej operacji system musi czekać na zakończenie procesu deduplikowania, tak aby replikować do odległej lokalizacji jak najmniej danych.

W praktyce deduplikowanie typu post-process stwarza też określone problemy operacyjne, ponieważ w systemie istnieją wtedy dwie warstwy pamięci, które rządzą się innymi prawami. Ponieważ w przypadku niektórych rozwiązań tego typu warstwa pamięci redundancyjnej jest ważniejsza niż warstwa pamięci deduplikowanej, ta druga pracuje mniej niezawodnie i mniej wydajnie.

7. Czy parsingowanie (analizowanie i rozdzielanie) formatów kopii zapasowych danych przy deduplikowaniu ma jakieś zalety?

Aby system deduplikowania był niezależny od rodzaju stosowanych w danym środowisku narzędzi i obsługiwał szeroką gamę aplikacji typu nearline, powinien pracować poprawnie niezależnie od formatów używanych przez te narzędzia i aplikacje. Niektórzy dostawcy nie stosują się do tej reguły i oferują rozwiązania współpracujące z narzędziami obsługującymi tylko określone formaty kopii zapasowych danych. Są to rozwiązania, które wspierają wybrane programy do tworzenia kopii zapasowych danych; rozwiązania takie analizują i rozdzielają formaty (parsing) i budują swój wewnętrzny system plików. Dlatego gdy w systemie pojawia się nowa wersja pliku, rozwiązanie takie porównuje ten zasób z wcześniejszym wpisem znajdującym się w jego katalogu i zapisuje tylko zmiany, a więc pracuje tak jak mechanizmy kontrolujące wersje plików, towarzyszące narzędziom używanym do budowania aplikacji.

Takie podejście do zagadnienia wygląda zachęcająco – może przyczynić się np. do lepszego kompresowania określonych typów danych – ale w praktyce ma więcej wad niż zalet. Po pierwsze, opracowanie takiego rozwiązania jest kapitałochłonne. Po drugie, wymaga zawsze stosowania technik programowania zwrotnego, a programy tworzące formaty nie pracują efektywnie – dlatego rozwiązania takie nie będą nigdy uniwersalne. Po trzecie, wyszukiwanie redundancji w innych częściach przetwarzanego kodu klienta jest bardzo utrudnione; rozwiązanie porównuje tylko wersje plików z tego samego systemu plików/klienta i dlatego poziom redundancji jest dużo większy niż w przypadku rozwiązań nie stosujących technologii parsingu formatów. Rozwiązania takie są też trudne do wdrażania; należy wtedy często konfigurować dodatkowe polityki, uwzględniające różne rodzaje kopii zapasowych plików i różne typy plików. Jeśli rozwiązanie zostanie zaprojektowane poprawnie, będzie uciążliwe; jeśli zostanie zaprojektowane źle to spowoduje, że wiele redundancji będzie duplikowanych.

8. Jak deduplikowanie usprawnia procesy replikowania danych w trybie off-site i odzyskiwania danych po awarii (DR)?

Deduplikowanie może mieć znaczący wpływ na proces replikowania i odzyskiwania danych po awarii. Po pierwsze i najważniejsze, dzięki obecności mechanizmu deduplikowania, utrzymanie odległego systemu DR w aktualnym stanie nie wymaga transmitowania tak wielu danych jak pod nieobecność takiego mechanizmu. Pozwala to stosować wolniejsze i tańsze połączenia WAN.

Po drugie, proces replikowania danych przebiega szybciej, ponieważ przez połączenie WAN trzeba wtedy transmitować dużo mniej danych. Czas potrzebny do utworzenia repliki danych (od początku procesu do jego zakończenia) zależy od wielu czynników, w tym od przyjętej metody deduplikowania, wydajności całej architektury i samego procesu DR. Przy deduplikowaniu w trybie inline dane mogą być replikowane już podczas wykonywania kopii zapasowej, co znacznie skraca czas potrzebny do zdefiniowania na odległym systemie DR punktu odzyskiwania danych czyli gotowości do pracy systemu DR.

Przy wykonywaniu pełnej kopii zapasowych danych najczęściej tylko 1% zawartych w niej informacji reprezentuje nowe dane, które można od razu przesyłać przez połączenie WAN do odległego systemu. Agresywne deduplikowanie typu cross-site (co ma miejsce wtedy, gdy wiele systemów replikuje dane, przesyłając je do tego samego systemu docelowego) ma tę dodatkową zaletę, że deduplikuje dane wykorzystując wszystkie strumienie replikowania kopii zapasowej i wszystkie lokalne kopie zapasowe. Unikalne, deduplikowane segmenty, transmitowane poprzednio przez jakikolwiek odległy system, lub przechowywane w lokalnej kopii zapasowej, są wtedy wykorzystywane w procesie deduplikowania celem dalszego zwiększenia wydajności sieci, co jest możliwe dzięki ograniczaniu ilości danych, które należy przesłać przez sieć. Mówiąc inaczej, jeśli system docelowy jest już w posiadaniu sekwencji danych odebranych z odległego systemu, lub z lokalnej kopii zapasowej, i ta sama sekwencja została już utworzona na innym odległym systemie, to sekwencja taka, zanim zostanie przesłana przez sieć do systemu docelowego, zostanie już zidentyfikowana jako redundancja. Wszystkie dane zgromadzone na systemie docelowym mogą być w bezpieczny sposób przenoszone w trybie off-site do pojedynczej lokalizacji lub do wielu systemów DR.

9. Czy deduplikowanie danych jest bezpieczne?

Bardzo trudno jest wzmocnić system pamięci masowej w taki sposób, aby pracował na tyle niezawodnie, że nie odmówi nigdy świadczenia swych usług w przypadku awarii jednego z dysków lub zaniku zasilania. Należy więc upewnić się czy system deduplikowania danych stosuje technologie, dzięki którym rozwiązanie jest odporne na różne awarie i gwarantuje danym integralność. System powinien tolerować takie zdarzenia jak ubytki danych, czyszczenie danych, rekonfigurowanie dysków, zaniki zasilania czy jednoczesna awaria kilku dysków – tak aby dane nie zostały utracone lub uszkodzone. Zabezpieczenia takie są ważne w przypadku każdego systemu pamięci masowej, ale nabierają szczególnego znaczenia w rozwiązaniach chroniących dane, korzystających z mechanizmu deduplikowania. W rozwiązaniach opartych na deduplikowaniu może istnieć 1000 kopii zapasowych danych, a integralność każdej z nich może zależeć od jednej kopii danych źródłowych. Dlatego dane źródłowe muszą być zawsze dostępne.

Mechanizmy zapewniające danym integralność, stosowane w systemach pamięci masowej obsługujących deduplikowanie, oferują również nowe możliwości w obszarze weryfikowania danych.

Autorem tekstu jest Philip Turner, Regional Director, UK & Ireland at Data Domain

Pozostałe części tego przewodnika:
część I
część III

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ