Pokazywanie postów oznaczonych etykietą deduplikacja. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą deduplikacja. Pokaż wszystkie posty

sobota, 16 kwietnia 2011

Deduplikacja - kopie idą precz! (Część 7 - reszta)

Po wpisach poświęconych w całości każdemu z "dużych" graczy w obszarze deduplikacji, chciałbym wspomnieć o innych produktach posiadających taką funkcjonalność.

FalconStore:

FalconStore to duży gracz w segmencie wirtualnych bibliotek taśmowych i oczywiste jest że ma w swojej ofercie także rozwiązania deduplikacyjne. FalconStore SIR (Single Instance Repository) jest "główką" deduplikacyną, którą dołącza się do FalconStoreVTLa, a która przeprowadza usuwanie kopii danych. Sam FS SIR nie posiada swojej przestrzeni dyskowej i wymogiem jest aby na jego back-endzie umieścić macierz zewnętrzną do przechowywania zdeduplikowanych danych. Jest to rozwiązanie łatwo skalowalne pod względem wydajności ponieważ poszczególne elementy SIRa łączą się, tworząc w maksymalnej konfiguracji 4 nodowy klaster (z redundancją N+1).
Oprócz SIRa, który jest "dodatkiem" do wirtualnej biblioteki, FalconStore oferuje także rozwiązania nie wymagające środowiska VTLowego. FalconStore FDS (File Deduplication System) jest linią produktów zarówno całkowicie softwarowych (SAK - Software Application Kit) jak i dedykowanych jednostek zintegrowanych z zasobami dyskowymi (Series 100/300/600). Urządzenia te mogą wymieniać dane z serwerami za pomocą protokołów NFS/CIFS a także wykorzystując OST firmy Symantec.

Symantec:

Dwa produkty firmy Symantec umożliwiają deduplikację danych -Backup Exec i NetBackup. Obydwie aplikacje mają bardzo podobną funkcjonalność, a ich głównym zadaniem jest wykonywanie i zarządzanie backupami. Identyczna jest również technologia deduplikacji jaką stosują i nosi ona nazwę: Veritas PureDisk.
Jeżeli chodzi o różnice między tym dwoma produktami, to są one inaczej pozycjonowane: Exec jest przeznaczony do małych i średnich przedsiębiorstw, natomiast NetBackup to produkt dla największych klientów klasy enterprise. Sama deduplikacja może zachodzić w różnych miejscach - preferowane jest jej wykonanie na kliencie, zysujemy wtedy oszczędość nie tylko miejsca ale i wykorzystania łącza, ale jeżeli powoduje to zbyt duże obciążenie CPU klienta, to zarówno Exec jak i NetBackup umożliwia przeniesienie tego procesu na serwer.
Symantec ma w swojej ofercie także dedykowany sprzęt (tzw: appliance) deduplikacyjny. Jest to serwer z działającym na nim oprogramowaniem do deduplikacji. Są to dwa produkty oznaczone jako NetBackup 5000 i 5200

Oracle:

Mówiąc o deduplikacji w rozwiązaniach Oracle najlepiej jest skupić się na możliwościach jakie w tym zakresie oferuje ZFS. Co prawda Oracle ma także swojego "czysto sprzętowego" deduplikatora nazwanego StorageTek VTL Prime, ale tak naprawdę jest to "rebrandowany" FalconStore VTL + SIR.
Co do ZFSa to jest to system bardzo ciekawy i pełen bardzo interesujących rozwiązań tak że w zasadzie tylko jemu można by było poświęcić cały duży wpis, ale w tym momencie skupimy się wyłącznie na funkcjonalności deduplikacji.
Deduplikacja w ZFSie odbywa się na poziomie bloku danych i jako skróty wykorzystuje generowane przez filesystem 256bitowe sumy kontrolne. Jest to mechanizm bardzo podobny do tego znanego z Netapp-owego WAFLa, gdzie również jako skróty zastosowano, już istniejące dla celów kontroli, checksumy.
Tym co odróżnia deduplikację ZFSową od Netapp-owej jest fakt, iż odbywa się ona w czasie rzeczywistym.
Dodatkowo dla ZFSa można uruchomić specjalny tryb "Weryfikacji", który podczas deduplikowania dodatkowo sprawdza czy nie występuje kolizja skrótów. Z kolejnych "fajnych" możliwości  ZFSa jest "szacowanie" ilości miejsca, jakie zostanie zaoszczędzone w wyniku włączenia deduplikacji - niestety nie miałem możliwości sprawdzić, jak takie szacowanie działa, ale gdyby ktoś był chętny niech zainteresuje się manualem do komendy zdb a szczególnie jej przełącznikiem -S.


CommVault:

CommVault to firma specjalizująca się w oprogramowaniu do backupu i archiwizacji. Jej flagowy produkt wykorzystujący deduplikację to Simpana (obecnie w wersji 9).
CommVault wykorzystuje specyficzną metodę wykonywania deduplikacji, którą można nazwać hybrydową - klient serwera backupowego dzieli dane na paczki oraz liczy z nich skróty, nie wykonuje jednak sprawdzania czy dane się powtarzają, są one jedynie kompresowane i wszystkie wysyłane do serwera. Dopiero na serwerze przeprowadzane jest samo deduplikowanie.
Kolejną dość nietypową własnością jaką ma Simpana to możliwość deduplikownia danych na taśmach magnetycznych. Dość ciężko znaleźć zastosowanie dla takiej funkcjonalności, ale jeżeli ktoś widzi taką potrzebę, to produkt CommVaultu mu ją zapewni.


NEC:

Firma NEC ma w swojej ofercie urządzenie HydraStore, które jest macierzą zbudowaną w technice RAIN ( Redundand Array of Independent Nodes) i posiada architekturę klastrową (skalowalną do 55 osobnych węzłów). Macierz ta posiada także mechanizmy deduplikacji wykonywanej "w locie" (inline)


ExaGrid:

ExaGrid jest firmą mocno nastawioną na produkty wykorzystujące deduplikację. Jej celem są głównie przedsiębiorstwa małej i średniej wielkości, choć widać, że chciała by także mocniej zaznaczyć swoją obecność w sektorze firm obsługujących korporacje klasy enterprise. Dedykowana seria urządzeń do dedplikacji firmy ExaGrid nosi nazwę EX. Mają one budowę klastrową (do 10 węzłów) i raczej niczym się nie wyróżnia od innych rozwiązań oferujących deduplikację na celu.


Quantum:

Seria deduplikatorów firmy Quantum to modele oznaczone jako DXi i obejmują sobą zarówno sektor małych (DXi4500), średnich (DXi6700) jak i dużych (DXi7500) przedsiębiorstw. Deduplikacja odbywa się na celu a deduplikator posiada funkcję "udawania" biblioteki taśmowej. Usuwanie kopii jest wykonane na poziomie bloku danych o zmiennej długości. Z przyjemnych dodatków można wspomnieć o module Advanced Reporting, który jest obecny w każdym modelu DXi (i bez dodatkowej licencji), a pozwala na monitorowanie stanu obecnego, historycznego oraz wyznaczania trendu bardzo wielu parametrów z zakresu capacity i wydajności.


Sepaton:

Mniej znana firma, która jednak ma dość ciekawe rozwiązania deduplikacyjne. Urządzenie które ma je zaimplementowane nosi nazwę S2100-ES2 i jest biblioteką taśmową, mogącą działać w klastrze i posiadającą możliwość deduplikowania danych. Interesujący jest sam poziom na którym deduplikacja się odbywa, ponieważ można go uznać za poziom bajtów - silnik deduplikacyjny obserwuje przychodzący do niego strumień danych (nie dzieli go na porcje) i w tym ciągłym strumieniu wyszukuje fragmenty, której już ma zeskładowane. Dodatkowo wykorzystywana jest tzw: content-aware deduplikacja, czyli samo urządzenie potrafi wykryć jakiego rodzaju dane są na niego przesyłane (jaka aplikacja backupowa jest używana) i odpowiednio do tego zmodyfikować swoje parametry pracy, tak aby zapewnić jak najlepszą i najwydajniejszą deduplikację. Sam mechanizm/silnik deduplikacji nosi nazwę DeltaStor.


CA:

Firma, o niezwykle długiej nazwie CA, zaznaczyła swoją obecność w obszarze deduplikacji, dołączając taką możliwość do swojego oprogramowania backupowego: CA ArcServe Backup. Deduplikacja odbywa się na serwerze (na celu) oraz jest wykonywana "w locie" (inline)


Asigra:

Na koniec rozwiązanie trochę egzotyczne: Asigra Cloud Backup. Jest to aplikacja backupowa, która po pierwsze składuje dane w chmurze (to nie jest jakiś ewenement, podobną funkcjonalność mają np: nowe wersje NetBackupa), a po drugie jest bezagentowa - dane z klientów są ściągne po wykonaniu pewnego skanowania poprzez sieć a następnie podłączenia się do danego zasobu i zeskładowania go. Dodatkowo dane są jeszcze deduplikowane przed zaciągnięciem tak, że obciążenie sieci mocno spada.





Na tym zakończy się cykl "deduplikacyjny". Początkowo planowałem 3 albo 4 wpisy, ale temat jest tak obszerny, że mimo 7 postów dalej nie jest wyczerpany.
Ufff. Dość o dyskach, kolejny wpis będzie o bibliotekach.

    wtorek, 22 marca 2011

    Deduplikacja - kopie idą precz! (Część 6 - NetApp)

    Kolejny z graczy na rynku storage i kolejne ciekawe rozwiązania.

    Jeżeli chodzi o NetApp-a to można powiedzieć, że deduplikacja jest w tym przypadku nie dodatkową funkcjonalnością dołączona na którymś etapie, ale funkcją natywnie wbudowaną i zintegrowaną z samym systemem operacyjnym (ONTAP od wersji 7.2.2) i systemem plików (WAFL). Dlatego też NetApp nie ma dedykowanych urządzeń czy oprogramowania umożliwjającego deduplikację ale opcja ta jest dostępna we wszyskich jego produktach z głównych linii (macierze FAS3xxx i FAS6xxx oraz seria V). Sama deduplikacja (nazywana często A-SIS) mimo iż wbudowana w system jest opcją płatną i aby ją uruchomić trzeba wykupić odpowiednią licencję.


    Budowa macierzy Netapp i sposób deduplikowania:

    Patrząc na macierze NetApp z perspektywy deduplikacji oraz tego w jaki sposób obsługiwane są polecenia wejścia/wyjścia można wyróżnić w nich trzy poziomy:

    Na samej górze znajduje się system operacyjny Data ONTAP. On obsługuje żądania zapisu/odczytu oraz zapewnia dodatkowe funkcjonalności takie jak np: migawki (snapshot), mechanizmy replikacji oraz oczywiście deduplikację.
    Pod systemem operacyjnym znajduje sie system plików (lub pseudo-system plików) nazwany WAFL - Write Anywhere File System. WAFL dzieli przychodzące do niego dane na 4kb bloki i zapisuje na dyskach. Te zapisane bloki z danymi możemy uznać za trzeci i ostatni poziom.
    Kolejną cechą WAFLa jest fakt, iż z każdego bloku liczy on tzw: skrót - czyli pewną unikalną sumę kontrolną . Mechanizm ten został zaimplementowany aby wykryć potencjalną korupcję danych zapisanych na dysku. Jeżeli odczytane dane wygenerują inny skrót, niż ten który powstał przy ich zapisie, oznacza to, że zostały one uszkodzone. Ten istniejący już mechanizm generowania i przechowywania skrótów z każdego 4kb bloku danych, został w bardzo prosty sposób wykorzystany do zaimplementowania deduplikacji. Jedyny element jaki trzeba było dodać, to sprawdzanie tablicy skrótów i usuwanie z niej duplikatów.
    Sprawdzanie i redukcja powielonych bloków danych nie odbywa się w czasie rzeczywistym ale jest ustawiana cyklicznie (np: raz na dobę w nocy) lub inicjowana ręcznie, czyli NetApp wykorzystuje deduplikację  w trybie "post-process". Do czasu uruchomienia procesu, dane na dyskach są przechowywane w stanie oryginalnym. Wykorzystanie tego sposobu razem z długim czasem przechowywania danych bez deduplikacji, wynika z jednego prostego powodu: NetApp nie jest macierzą dedykowaną pod przechowywanie backupów (choć oczywiście można ją tak wykorzystać), dane jakie na nie spływają to nie są nieaktywne archiwa,.NetApp jest zwykle używany jako normalna macierz do przechowywania danych produkcyjnych i używanych do codziennej pracy aplikacji (tzw: primary storage). Deduplikowane są dane z których użytkownicy cały czas korzystają. Połączenie deduplikacji z thin provisioningiem sprawia, że uzyskujemy bardzo duże oszczędności na zajętości przestrzeni podstawowej/produkcyjnej. Oczywiście nie ma róży bez kolców, włączenie deduplikacji powoduje spadek (o kilka procent) wydajności, no i wymusza przeprowadzanie usuwania duplikatów jedynie w czasie gdy macierz jest mało obciążona (np: raz dziennie w nocy). Coś za coś.





    W sumie tyle podstawowych informacji o deduplikacji w macierzach NetApp.
    Kolejny wpis dalej będzie dotyczył rozwiązań stosowanych u poszczególnych producentów, ale całkiem możliwe że pogrupuję ich już po kilku w jednym. Zbyt dużo ich zostało, żeby każdemu poświęcać osobny wpis, a w sumie różnice między nimi to jakiś bardzo wielkich nie należą (przynajmniej jeżeli chodzi o deduplikację)

    niedziela, 13 marca 2011

    Deduplikacja - kopie idą precz! (Część 5 - IBM)

    Po opisaniu rozwiązań firmy EMC, sprawdzimy co też do zaoferowania ma IBM.
    Jeżeli chodzi o rynek storage, to polityka tych dwóch korporacji jest dość odmienna. Portfolio EMC to produkty prawie wyłącznie skierowane na rynek pamięci masowych, natomiast IBM jest gigantem oferującym usługi praktycznie w każdej dziedzinie (nie tylko IT). Jeżeli chodzi o sam storage, to podejścia także są różne: EMC wychodzi z założenia, że taśma to przeżytek i zostanie całkowicie zastąpiona składowaniami na deduplikowane dyski. IBM cały czas mocno zaznacza swoją obecność na rynku bibliotek i taśm magnetycznych. Oczywiście nie przeszkadza mu to oferować rozwiązań wykorzystujących deduplikację.

    IBM:


    ProtecTier:
    Protectier to rozwiązanie hardwarowe, oferujące deduplikację na celu. Występuje w dwóch wariantach: deduplikatora zintegrowanego z zasobami storage (np: TS7650) oraz jako gateway (np: TS7650G). Gateway to sama "główka" deduplikująca, na back-endzie której dopiero podłączamy, za pomocą FC, macierz docelową dla zeskładowanych danych. Tym co można uznać za wyróżnik Protectier-a to zastosowany algorytm deduplikacji. Nosi on nazwę HyperFactor i jest opatentowanym rozwiązaniem IBMa.
    HyperFactor nie liczy skrótów (hashy) z porcji danych i nie porównuje ich z innymi wyszukując kopii. Stosuje metodę, która nie sprawdza czy dane są identyczne, ale czy mają dużo części wspólnych/podobnych. Protectier na bieżąco sprawdza przychodzący do niego strumień danych i porównuje czy w jego repozytorium nie znajdują się dane podobne - mechanizm wyznaczania tej miary "podobieństwa" opiera się na kilku dość skomplikowanych algorytmach (którymi IBM się nie chwali) oraz na informacji o rozmieszczeniu danych, która jest przechowywana w tzw: Memory Resident Index. Po znalezieniu podobnych fragmentów system składuje jedynie różnice (deltę) między nimi, dodatkowo przed nagraniem na dysk kompresując za pomocą algorytmu LHZ.

    Tivoli Storage Manager 6.1 i 6.2
    TSM to oprogramowanie do wykonywania backupów z danych i składowania ich na taśmach, bądź innych nośnikach. Sama aplikacja jest bardzo popularna i ma kilkunastoletnią historię (przed 1999r znana była jako ADSM). Obecnie najpopularniejsza jest wersja 5.5, która nie posiada możliwości deduplikacji danych.
    Usuwanie kopii pojawiło się niedawno razem z wersją 6.1 która posiada funkcjonalność deduplikacji na targecie czyli serwerze backupowym. Kolejna wersja 6.2 dodaje deduplikację na źródle, czyli wykonywaną przez samego agenta TSMa.
    Największa zaleta - funkcjonalność wbudowana w samą aplikację backupową. Bezproblemowe wdrożenie w firmach już używających TSMa.
    Największa wada - w tej chwili wersja jeszcze mało "wygrzana" - możliwe jest pojawianie się błędów w nowym kodzie. Druga sprawa to brak deduplikacji na źródle przy składowaniu przez sieć SAN (agenci w wersji 6.2 obsługują tylko deduplikację przez LAN)





     Kolejny wpis - NetApp ( i może coś jeszcze, zobaczymy)

    piątek, 4 marca 2011

    Deduplikacja - kopie idą precz! (Część 4 - EMC)

    W kolejnym wpisie poświęconym deduplikacji odejdziemy od "teoretyzowania" i przyjrzymy się rozwiązaniom (zarówno hardwarowym jak i softwarowym) które obecnie znajdują się na rynku.
    Niektóre produkty znam lepiej (nawet z autopsji) niektóre gorzej, a informację o jeszcze innych zdobywałem dopiero przygotowując się do tego wpisu. 


    Ponieważ graczy działających w tym sektorze jest sporo, a o każdym wypadało by parę słów napisać, tak więc opis ich produktów także zajmie więcej niż jeden wpis.
    Zaczynamy od:


    EMC...


    ... i dwóch rozwiązań deduplikacyjnych jakie mają w swoim portfolio: 


    DATA DOMAIN:
    DataDomain - flagowy produkt EMC jeżeli chodzi o deduplikacje danych. Jest to rozwiązanie hardwarowe spełniające funkcję VTLa i deduplikatora. DataDomain deduplikuje dane na celu (target) oraz w czasie rzeczywistym (inline) bez wcześniejszego składowania ich na dyskach w postaci orginalnej.
    DataDomain używa deduplikacji za pomocą zmiennej długości bloku. Według EMC (choć oczywiście informacje te należy traktować z dużą dozą ostrożności) standardowy współczynnik deduplikacji dla tego rozwiązania to 20:1
    W skład rodziny DD wchodzi jedna linia produktów, skalowanych pod względem ilości dostępnej przestrzeni oraz wielkością strumienia danych jakie są w stanie deduplikować, oraz dwa rozwiązania "specjalne".
    Najnowsze modele z linii podstawowej czyli tzw: Appliance to w kolejności od najmniejszego: DD140 , DD630 , DD670 , DD860 i DD890
    W "najbogatszej" wersji (DD890) DataDomain oferuje do 384TB surowej powierzchni dyskowej i obsługę do 14,2PB przestrzeni po deduplikacji (co raczej będzie ciężkie do uzyskania ponieważ zmieszczenie takiej ilości danych na 384TB powierzchni fizycznej wymaga deduplikacji na poziomie około 40:1).
    Oprócz samej serii applianców EMC oferuje Data Domaina w wersji GDA (Global Deduplication Array). Fizycznie są to dwie maszyny DD890 połączone z sobą w ten sposób, iż oferują jedną wielką przestrzeń (pulę) na dane zdeduplikowane, dzięki temu nie tylko zwiększa się ich pojemność i wielkość strumienia danych jakie mogą przyjąć, ale także sam deduplikator może działać (jako jedna całość), a fizycznie być rozłożony na dwie lokacje.
    Drugim z produktów "specjalnych" w obrębie rodziny DataDomain jest DataDomain Archiver - całkiem nowe rozwiązanie, które od kilku tygodni jest dostępne na rynku.
    Jest to urządzenie, które ma ambicje zastąpić taśmy magnetyczne w ich ostatnim "bastionie", czyli w archiwach długoretencyjnych (kilku,kilkunastoletnie). Archiver oferuje kilka opcji, które między innymi pozwalają na obniżenie kosztów jednostkowych dla tego rozwiązania. Jest to na przykład użycie warstw (tier) o różnych parametrach, dla danych o różnej retencji. Przykładowo dane nagrane do 90 dni są trzymane na "warstwie" wyższej, a po tym okresie przerzucane na "warstwę" tańszą (choć szczerze powiedziawszy EMC na razie nie określa za bardzo na czym miały by polegać konkretne różnice między warstwami - możliwe, że nie będzie ich wcale a podział spójnej przestrzeni na "warstwy" zostanie umotywowany jakoś inaczej). Kolejnym z wyróżników Archvera ma być jego możliwość zakładania Retention Locku, czyli mechanizmu który uniemożliwia skasowanie/usunięcie pewnych danych, zanim nie minie określona ilość czasu.
    Oprócz samych maszyn, warto wspomnieć o pewnym mechaniźmie softwarowym współpracującym z DataDomainami a mianowicie o DD Boost.
    DD Boost pozwala część pracy przerzucić na serwer backupowy czyli zamienić deduplikację czysto sprzętową na targecie, na mieszankę deduplikacji na targecie z deduplikacją na źródle. Dzięki temu zarówno zwiększamy przepustowość samego DataDomaina a także odciążamy sieć LAN po której idą dane już zdeduplikowane (przynajmniej w części). 
    DD Boost oczywiście, aby zadziałał, musi być wspierany przez samą aplikację backupującą. W obecnej chwili współpracują z nim oprócz EMC Networkera także produkty firmy Symantec: Netbackup i Backup Exec.

    AVAMAR
    Avamar jest to rozwiązanie deduplikujące na źródle - może występować w wersji softwarowej lub jako Avamar Data Store mieszaniec soft/hard-ware.
    Zaletą deduplikacji Avamarowej (jak każdej deduplikacji na źródle) jest oszczędzanie nie tylko miejsca ale i łącza. Wszystkie duplikaty danych (w przypadku Avamara na poziomie bloku) zostają usunięte i przez sieć do serwera backupu wysyła się jedynie bloki unikalne. Uzysk na ilości przesyłanych danych może nie powalać przy wykonaniu pierwszego składowania ( przesłane średnio jest od 20 do 50% danych oryginalnych) ale kolejne składowania zwykle wysyłają już jedynie szczątkowe ilości danych. 
    Poprzednie stwierdzenie jest prawdziwe przy odpowiednim zastosowaniu Avamara. Użycie go do składowania baz danych (szczególnie dużych >500GB) nie specjalnie się sprawdza. Po pierwsze bardzo obciąża system, który sam musi przeprowadzić deduplikację, po drugie ilość zmian jakie się wykonują pomiędzy składowaniami jest relatywnie duża, a więc uzysk na łączu i miejscu jest niewielki. Najlepiej Avamar sprawdza się przy wykonywaniu backupów poprzez sieć WAN - dobrym przykładem są składowania laptopów czy stacji roboczych, używanych przez pracowników w domach albo biurach regionalnych - dane na większości tego typu urządzeń są podobne (ten sam OS , podobne formaty plików) , a dodatkowo składowanie wykonywane jest przez relatywnie wolną i zawodną sieć. W takich warunkach Avamar pokazuje swoją siłę.
    Do niewątpliwych plusów tego rozwiązania zaliczyć należy również sposób jego licencjonowania. Jest bardzo prosty i przejrzysty, żadnego liczenia ilości licencji w zależności od typu procesora, ilości rdzeni, wątków itd..., brak podziału na licencje "zwykłe" i "bazodanowe", jedynym kryterium jest ilość danych po zdeduplikowaniu. Kupując daną licencję otrzymujemy wielkość danych po deduplikacji jaką możemy utrzymać, a w jaki sposób ją uzyskamy ( z ilu stacji , jakie dane itd...) jest zupełnie dowolny.
    Sam Avamar posiada jeszcze kilka innych ciekawych rozwiązań, takich jak np: szyfrowanie danych ale 
    dokładniejsze ich wszystkich opisanie wykracza poza ramy tego wpisu.






    Tyle o EMC, w kolejnym wpisie IBM i jego deduplikatory ProtecTier oraz TSM 6.1/6.2

    niedziela, 20 lutego 2011

    Deduplikacja - kopie idą precz! (Część 3 - Hash collisions)

    Kontynuujemy tematy związane z deduplikacją , tym razem odchodzimy trochę od rozważań dotyczących jej zastosowania a skupimy się na pewnym aspekcie technicznym. Chodzi o sam mechanizm tworzenia skrótów (hash-y) i niebezpieczeństwo, że dwa odrębne pakiety danych wygenerują ten sam skrót.

    Szybka powtórka:


    Dane są wysyłane do systemu deduplikującego. Ten dzieli je na części/paczki (w zależności do poziomu na którym działa są to np: pliki, bloki danych różnej wielkości itd...), a następnie z każdej takiej pojedynczej części wyznacza jej skrót. Skrót (hash) jest, w założeniu, pewnym "odciskiem palca" jednoznacznie identyfikującym daną paczkę (chunk) danych. System deduplikujący sprawdza w swojej bazie hashy czy ten wygenerowany przed chwilą już się w niej znajduje. Jeżeli nie, to jest dopisywany, a dane które go opisują zeskładowane, jeżeli tak, to oznacza to, iż te dane zostały już wcześniej zapisane, a ich kolejne wystąpienie jest zastępowane wskaźnikiem do zeskładowanej kopii.


    W jaki sposób liczony jest hash i sprawdzane duplikaty danych:

    Są trzy podstawowe metody sprawdzania czy dane przychodzące do dedpulikatora zostały już na nim wcześniej zeskładowanie:

    1. Wykorzystuje się algorytmy kryptograficzne  (używane np: przy generowaniu podpisów cyfrowych) do tworzenia skrótów (hashy) z przychodzących danych. Przykładowe algorytmami, które są stosowane to SH1 i MD5. Hash tworzony za pomocą SH1 ma 160 bitów długości, przy wykorzystaniu MD5 - 128bitów. Jeżeli paczki danych są różne, powinny generować różne skróty.
    2. Wykorzystuje się algorytmy stworzone/zmodyfikowane przez producenta danego systemu. Podobnie jak w metodzie 1 z danych przychodzących generowany jest skrót. Zarówno długość skrótu jak i mechanizm jego tworzenia może być różny, w zależności od producenta danego rozwiązania.
    3. Porównanie bit po bicie - najpewniejszą metodą sprawdzenia czy dana paczka danych jest już zeskładowana jest wykonanie jej porównia bit po bicie do istniejących już danych. Oczywiście metoda ta jest także najbardziej czasochłonna i wymaga wykonania największej ilości operacji.


    Hash Collision (kolizja skrótów):

    Do kolizji skrótów dochodzi kiedy dwie różne paczki danych wygenerują ten sam hash.

    Jakie są konsekwencje takiego wydarzenia?

    Przede wszystkim dla systemu obydwa te różne pakiety danych będą wyglądały identycznie co spowoduje, że zeskładowany zostanie tylko jeden z nich a drugi zostanie zastąpiony wskaźnikiem. Dla samego deduplikatora wszystko będzie w porządku i wykonana operacja będzie po prostu usunięciem zduplikowanych danych. Gorzej sytuacja wygląda przy odtworzeniu - dane dla których wystąpił hash collision mogły zostać usunięte i zastąpione innymi. System odtworzy te inne dane, przez co spowoduje korupcję całego backupu i w rezultacie jego utratę.
    Problem z wystąpieniem kolizji hashy nie dotyczy jednak pojedynczego backupu. Typowy współczynnik deduplikacji jest równy około 10:1 - oznacza to, że (średnio) do każdej paczki danych zapisanych przez deduplikator prowadzi 10 odnośników. Idąc dalej - dla danych przy których wystapiła kolizja hashy, połowa z tych wskaźników będzie prowadziła do danych innych niż orginalne.
    Summa summarum dla pojedyńczej kolizji skrótów możemy mówić o mniej więcej 5 utraconych backupach.

    Czy jest to duży problem? To wszysko zależy od częstotliwości jego występowania. Jeżeli kolizja skrótów występuje raz na sto paczek danych wtedy skutki mogą być tragiczne. Jeżeli raz na miliard, to może da się ją zignorować?

    Jakie jest prawdopodobieństwo wystąpienia kolizji skrótów?

    Rozważmy metodę nr 1 z opisanych wcześniej sposobów wyznaczania hashy, czyli zastosowanie algorytmów SH1 i MD5. Prawdopodobnieństwo, że dwie różne paczki danych wygenerują ten sam skrót zależne jest od długości samego skrótu i równe 1/2^160 dla SH1 i 1/2^128 dla MD5.
    Są to liczby niewyobrażalnie małe - gdyby wszystkie dane przechowywane na całym świecie przepuścić przez jeden system deduplikujący to ryzyko, że któreś z dwóch paczek wygenerują taki sam skrót było by miliony razy mniejsze niż szansa wygrania głównej nagrody w lotto. Można powiedzieć, iż wystąpienie kolizji skrótów wydaje się pomijanie małe.
    Niektórzy zwracają jednak uwagę na fakt, iż obliczenia te mogą niedokładnie odzwierciedlać stan rzeczywisty. Metoda liczenia, której użycie może radykalnie zwiększyć prawdopodobieństwo wystąpienia kolizji znana jest jako "Paradoks dnia urodzin".
    Jeżeli znajduję się w pomieszczeniu z 30 osobami to szansa, że jest wśród nich ktoś kto ma urodziny w tym samym dniu co ja, jest mniejsza niż 10% , natomiast prawdopodobieństwo, dość podobnego (wydaje się) zdarzania, że w tej grupie znajdują się dowolne dwie osoby mające urodziny w tym samym dniu jest sporo większe niż połowa. Wynika to z faktu że dowolnych par z dwóch osób pośród 30 można złożyć o wiele więcej niż par w których ja stanowię jedną z tych osób - im większą grupę weźmiemy tym te dwa prawodpodobieństwa będą się bardziej od siebie różniły. Podobna zależność występuje przy wyliczaniu prawdopodobieństwa wystąpienia kolizji skrótów. Jeżeli badamy szansę na wystąpienie kolizji między dwoma wybranymi paczkami danych, to jest ona praktycznie zerowa , jeżeli jednak weźmiemy pod uwagę całą pulę danych gdzie ilość paczek (np: bloków) idzie w dziesiątki milionów to szanse na uzyskanie kolizji wśród którejkolwiek z par paczek danych prezentuje się zupełnie inaczej.
    Czy dalej szansa wystąpienia kolizji danych jest pomijalnie mała?
    Nie zamierzam tutaj przedstawiać dokładnych wyliczeń (wpis na blogu backupcentral.com który to wyznacza, jest w sekcji do poczytania), w każdym razie aby prawdopodobieństwo wystąpienia kolizji hashy było większe niż 0.000000000000001% musimy mieć conajmniej 50EB danych (1EB=1024PB).
    Znowu wielkość, która praktycznie nie ma żadnego znacznia.
    Czy ktoś z Was przechowuje 50EB danych? A może chociaż 1EB?
    W każdym razie nawet gdyby ktoś chciał uznać takie ryzyko za znaczące, to warto aby wiedział, że zagrożenie wystąpieniem niewykrytego błędu zapisu na taśmie LTO jest większe ( mimo, iż także niewyobrażalnie nikłe).
    Wydaje mi się, że gdyby ktoś podjął się oszacowania ryzyka, że w ziemską atmosferę wpadnie meteor i rozpadnie się w niej na 4 części z których każda trafi dokładnie w nasze centra komputerowe rozsiane po całej kuli ziemskiej i zniszczy fizycznie przechowywane cztery kopie danych - to prawdopodobieństwo takiego zdarzenia i tak okaże się wyższe niż pradowpodobieństwo wystąpienia kolizji skrótów.

    I tym akcentem zakończę ten wpis...


    Do poczytania:

    Paradoks dnia urodzin
    Hash Collisions: The real odd
    When hashes collide
    What do hash collisions really mean
    The skinny on data deduplication

    poniedziałek, 7 lutego 2011

    Deduplikacja - kopie idą precz! (Część 2 - Primary Storage Dedupe)

    Ten wpis dalej pozostaje w temacie deduplikcji, ale dotyczy pewnego wyjątkowego jej zastosowania, rzadziej spotkanego i nieco bardziej "egzotycznego", a mianowicie deduplikacji primary storage.
    Notka będzie raczej krótka i stanowi jedynie zarysowanie tematu, niż jego głęboką analizę.

    Standardowe zastosowanie deduplikacji polega na wykorzystaniu jej dla zmniejszenia objętości danych backupowanych. Nie wchodząć w szczegóły i nie rozpatrując różnych wariantów, typowy proces deduplikacji polega na tym, iż strumień danych wysyłany przez serwer wykonujący składowanie trafia do wirtualnego urządzania taśmowego (VTL), zostaje zdeduplikowany, a nastepnie zapisany na dyski. Uzystkujemy znaczną oszczędność jeżeli chodzi o zajmowaną przestrzeń, ale dotyczy to jedynie danych zeskładowanych, czyli nieaktywnych. Można się zastanowić, czy podobnego uzysku nie można by było osiągnąć dla tzw: primary storage, czyli tych danych, które są wykorzystywane produkcyjnie i z których na bieżąco korzystają użytkownicy naszego systemu/aplikacji.
    Dwie sprawy mogą nasuwać się kiedy rozważamy deduplikację primary storage. Po pierwsze jak wpływa to na wydajność samego systemu dyskowego, a po drugie czy możemy oczekiwać takich samych współczynników redukcji jak przy deduplikowaniu składowań.

    Na drugie pytanie odpowiedź brzmi - nie.
    Przy przewidywaniu współczynnika deduplikacji na primary storage bardzo dużo zależy od typu danych i charakterystyce aplikacji jaka na nim działa. Zwykle bazy danych (czyli dane struktruralne) bardzo słabo dają się deduplikować - wiąże się to z ich architekturą i samym sposobem w jaki są używane. Ich budowa to przeważnie pojedyńcze, bardzo duże pliki, na których ciągle dokonywane są zapisy w różnych (losowych) miejscach. Dodatkowo często sam silnik bazy dokonuje usunięcia z niej redundantnych fragmentów, co oczywiście obniża sprawność (i sensowność stosowania) mechanizmu deduplikcji.
    Inne dane, które nie powinny być deduplikowane na primary storage to np: formaty zawierające już wbudowane mechanizmy pre-kompresji ( jak np pdf) oraz pliki zaszyfrowane.
    Jeżeli  chodzi o dane "aktywne", to oczywiście wiele z nich jest powtórzonych, szczególnie jeżeli mówimy o sprawdzaniu duplikatów na poziomie bloków danych. Nie ma tutaj jednak pozytywnego efektu zwiększającego redukcję zajętości, występującego w backupach i archiwach, które bardzo dobrze się deduplikują, między innymi dlatego, iż są cyklicznie robione, a między kolejnymi kopiami stosunkowo niewielka ilość danych się zmieniła.

    Jeżeli mówimy o wpływie na wydajność systemu dyskowego z włączoną deduplikacją, to wbrew pozorom nie jest ona znacząca. Trzeba jednak być świadomym jednej sprawy - dane nie są deduplikowane w locie (in-line) w momencie ich zapisywania. Zapis odbywa się "normalnie" bez usuwania kopii. Sam proces deduplikowania odbywa się cyklicznie (np: raz dziennie) i zwykle jest uruchamiany w momencie gdy sam storage jest najmniej obciążony.
    Co prawda zaczynają pojawiać się przymiarki do rozwiązań deduplikujących primary storage "w locie" ale w tej chwili ciężko jeszcze coś konstruktywnego na ten temat powiedzieć.

    Z innych spraw, które warto mieć na uwadze przy wyborze optymalnego systemu deduplikacji primary storage to jego współpraca z naszą aplikacją do backupu. Optymalnie było by gdyby nasze środowisko backupowe wspierało składowanie danych już zdeduplikowanych. Jeżeli przeprowadzenie backupy wymaga przywrócenia danych do postaci oryginalnej przed wysłaniem do nośnika backupowego to działanie takie jest stratą czasu i zasobów.

    Co do konkretnych rozwiązań i produktów wspierających ten rodzaj deduplikacji napiszę innym razem. Jeden z ostatnich postów w temacie deduplikacji będzie takim przeglądem rozwiązań występujących na rynku razem z opisem ich możliwości.

    Do poczytania:
    Primary storage deduplication
    Six requirements for deploying primary storage optimization
    De-duplicating primary storage
    Disk Deduplication For Primary Storage

    środa, 12 stycznia 2011

    Deduplikacja - kopie idą precz! (Część 1 - podstawy)

           W ostatnich latach obserwujemy bardzo intensywny przyrost ilości gromadzonych i składowanych danych, zjawisko te doczekało się nawet swojej nazwy: "data explosion". Przyczyny takiego stanu rzeczy to po pierwsze, coraz większy "apetyt" firm i przedsiębiorstw na informacje, a po drugie łatwość w tworzeniu dużych ilości danych ( filmy w jakości HD , zdjęcia cyfrowe itd...). Dodatkowo, jeżeli chodzi o wymagania dotyczące składowań i odtworzeń danych, to niezależnie od wzrostu ich wolumenu, bardzo często zaostrzają się także wymagania dotyczące parametrów związanych z czasami wykonywania tych operacji  - skróceniu ulegają okna backupowe, a odtworzenia także powinny odbywać się dużo szybciej. Wymagany jest coraz mniejszy RTO (Recovery Time Obejctive).
      
            Biorąc pod uwagę te wymagania, standardowy backup danych na taśmę, może nie spełnić swojego zadania, a bezpośrednie składowanie danych na dyskach twardych jest dość kosztowne. Jednym z rozwiązań pozwalającym spełnić wymagania dotyczące szybkości wykonywania składowań/odtworzeń a jednocześnie utrzymać koszty na dość niskim poziomie (porównywanym lub nawet niższym niż backup na taśmach) jest DEDUPLIKACJA.


    Czym jest deduplikacja?

    Jest to metoda polegająca na usunięciu wszystkich powtarzających się danych i zastąpieniu ich wskaźnikami do jednego "oryginalnego" egzemplarza. Dzięki takiemu podejściu eliminujemy nadmiarowość w składowanych danych, co może przynieść znaczące oszczędności. Jest to związane z faktem, że bardzo często zapisujemy wielokrotnie dokładnie te same dane (np: wykonując co miesiąc pełny backup jakiegoś zasobu), a dodatkowo poszczególne składowania także zawierają wiele zwielokrotnionych informacji (np: w zasobie będącym katalogiem z dokumentami, informacje dotyczące struktury i budowy samych plików - *.doc , *.pdf są takie same dla każdego z nich ).


    Jaka jest różnica pomiędzy deduplikacją a kompresją?

              Podstawowa różnica pomiędzy deduplikacją a kompresją to fakt, że kompresja działa "lokalnie" natomiast deduplikacja "globalnie". Pisząc lokalnie i globalnie nie mam na myśli żadnej formalnej definicji tych pojęć, jest to pewien "skrót myślowy", który postaram się dokładniej wytłumaczyć.
    Kompresja zminiejsza wielkość pliku usuwając w nim nadmiarowe fragmenty. Często występujące ciągi danych są eliminowane, wszystko to jednak odbywa się w obrębie jednego obiektu (np: pliku). Kompresowanie wielu plików naraz, daje ten sam rezultat co ich kompresowanie oddzielne.
    Deduplikacja, w przeciwieństwie do tego podejścia, dotyczy całości objętych nią danych. Proces ten sprawdza, na różnym poziomie, czy dane, które za jego pomocą są przetwarzane (składowane), nie powtórzyły się już wcześniej - jeżeli taka sytuacja ma miejsce, to cały powtarzający się fragment jest usuwany, i zastępowany wskaźnikiem do już istniejącego zeskładowanego egzemplarza.
    Obrazowo różnicę (i przewagę) deduplikacji nad kompresją można pokazać na dwóch przykładach:

    1. Składowanie zasobu na którym znajduje się kilkadziesiąt maszyn wirtualnych. Kompresja - usunie nadmiarowość z każdej z tych maszyn osobno, powodując redukcję wielkości każdej z nich ( i sumarycznie wszystkich danych po zeskładowaniu) o jakieś 20 do 50%. Deduplikacja - usunie wszystkie duplikacje danych w całym zasobie. Ponieważ maszyny wirtualne są do siebie bardzo podobne ( ta sama struktura i większość danych wewnątrz) tak więc zachowanie jedynie pojedynczych egzemplarzy każdej informacji spowoduje, że wielkość zdeduplikowanego zasobu zostanie zmniejszona kilkunastoktrotnie - do wielkości jednej maszyny wirtualnej + niewielki dodatek zawierający unikalne dane z każdej z VMek.
    2. Wykonanie kilku pełnych backupów (np: w tygodniowych odstępach czasu) z tego samego zasobu. Przy kompresji otrzymujemy kilkudziesięcio procentową oszczędność na każdym ze składowań ( wykorzystując np zapis na taśmy możemy uzyskać kompresję 2:1 lub 3:1 w zależności od wykorzystanego napędu). Stosując deduplikację - mimo iż wykonujemy składowania pełne, zapisywane są jedynie zmienione i unikalne fragmenty (podobnie, choć nie całkiem tak samo jak przy backupach inkrementalnych)



    Jak działa deduplikacja?

             Sam proces deduplikacji może być wykonywany wieloma sposobami, jednak idea i główny schemat działanie pozostaje ten sam. Utrzymywane są dwie struktury - pierwsza z nich to zdeduplikowane dane , druga to tzw: tabela skrótów (lub hashy). Z każdej porcji danych (chunk) wpadająca do systemu deduplikującego, liczony jest tzw skrót - jest on generowany za pomocą funkcji hashujących i ma długość kilkudziesięciu bajtów. Skrót ten jest czymś w rodzaju "odcisku palca" konkretnej porcji danych - jeżeli jest identyczny dla dwóch ciągów danych, oznacza to, ze te ciągi także są identyczne. Jeżeli skrót, z danych które przybyły do systemu deduplikującego, nie został znaleziony w tablicy skrótów, to jest on tam dopisywany, a dane zostają zeskładowane. Jeżeli jednak skrót już był obecny w systemie, to dane nie są składowane a jedynie zastępowane wskaźnikiem do już istniejącejącego w systemie deduplikacyjnym ich egzemplarza.


    Poziomy działania deduplikacji:

    Podstawowa kwestia to na jakim poziomie szukamy kopii danych do usunięcia. Można wyróżnić kilka wariantów:


    • Deduplikacja na poziomie pliku - sprawdzenie odbywa się, jak sama nazwa wskazuje, na poziomie pliku. Jeżeli znajdowane są indentyczne co do zawartości i uprawnień pliki to przechowywany jest jedynie jeden egzemplarz. Często systemy stosujące ten typ deduplikacji nazywa się SIS (Single Instance Storage). Jest to najmniej efektywny, ale jednocześnie najprostszy i wymagający najmniejszych nakładów sprzętowych mechanizm deduplikacji.
    •  Deduplikacja na poziomie bloku stałej wielkości (fixed block level) - w tej metodzie jednostką danych, co do której generuje się skrót i sprawdza czy jest unikalna, jest blok. Im krótszy blok jest używany, tym większa ilość kopii może być odnaleziona i większy uzysk na przestrzeni. Deduplikacja na poziomie bloku wykorzystuje fakt, że bardzo wiele plików różni się od siebie tylko w małej części (np: wspomniane już pliki maszyn wirtualnych, czy dwóch plików doc).
    • Deduplikacja na poziomie bloku o zmiennej wielkości (variable block level) - wykorzystuje podobny mechanizm jak metoda nr 2 , jednak w tym przypadku bloki, na jakie dzielone są dane, nie mają stałej wielkości, ale są dopasowywane tak aby wyłapać jak najwięcej i jak największych ciągów danych do zdeduplikowania - dzięki temu metoda deduplikacji zmiennym blokiem jest bardziej efektywna niż jej wersja operująca blokiem o stałej wartości
    • Deduplikacja na pozimie bajtów (byte-level deduplication) - polega na porównywaniu bajt po bajcie przychodzącego do silnika deduplikacyjnego strumienia danych i wyszukiwania wszystkich powtarzających się fragmentów. Zwykle taka metoda jest połączona z tzw deduplikacją "content-aware" - czyli przystosowaną i zoptymalizowaną do pracy z pewnymi typami danych ( pliki .jpg , .doc itd...)


    Współczynnik deduplikacji:

    Efektywność samego procesu jest opisywana jednym współczynnikiem zwanym, po prostu, współczynnikiem deduplikacji. Jest to stosunek pojemności danych oryginalnych, do pojemności zajmowanej przez dane zdeduplikowane. Przykładowo jeżeli 100GB zasób danych po zddeduplikowaniu zajmuje 10GB , to współczynnik deduplikacji jest równy 10:1
    Wartość tego współczynnika zależy zarówno do algorytmu który wyszukuje kopie i duplikaty, jak i od poziomu na jakim deduplikcja przebiega (plik, blok , itd...) a także (a raczej przede wszystkim) od samych danych jakie temu procesowi podlegają.
    Biorąc pod uwagę tą ostatnią zależność, bardzo ciężko jest precyzyjnie wyznaczyć współczynnik deduplikacji dal konkretnych danych, inaczej niż po prostu je deduplikując i sprawdzając. Dlatego też należy z dużą dawką ostrożności podchodzić do podawanych przez producentów wartości tego parametru dla stworzonych przez nich produktów.


    Warianty deduplikacji:

    Oprócz rozróżnienia bazującego na poziomie, na którym usuwane są kopie , systemy deduplikujące można także podzielić wegug kilku innych kryteriów:

    Podział ze względu na miejsce deduplikacji:

    • Deduplikacja na celu (target dedupliaction) - w tej metodzie proces deduplikacji odbywa się na urządzeniu przechowujących dane. Zwykle takie urządzenie  (appliance) ma także funkcję wirtualnej biblioteki taśmowej (VTL), przez co serwery backupowe składujące dane, widzą to jako zwykłą bibliotekę. Dane są przesyłane w normalny sposób ( np: po sieci LAN lub SAN) a potem deduplikowane i zapisywane na dyskach. Zaletą tego typu rozwiązania jest fakt, że proces deduplikacji nie obciąża samych klientów. Dodatkowo tego typu rozwiązanie może bardzo łatwo zostać zintegrowane z istniejącą infrastrukturą i używanym oprogramowaniem backupującym.
    • Deduplikacja na źródle (source deduplication) - w tym wariancie, dane są deduplikowane na kliencie, jeszcze przed wysłaniem ich do urządzenia na którym będą zeskładowane. Jeżeli chodzi o słabe strony to przede wszystkim to rozwiązanie wymaga zaangażowania dodatkowych zasobów po stronie CPU i pamieci do przeprowadzenie deduplikacji. Po drugie musi ono być wspierane przez agentów programu backupującego, którzy są zainstalowani na składowanych hostach. To drugie ograniczenie jest szczególnie istotne w środowiskach, gdzie aplikacja backupowa nie wspiera tego rodzaju deduplikacji - wtedy albo aplikację zmieniamy (co jest dość skomplikowane ) albo decydujemy się na rozwiązanie deduplikujące na celu. Jeżeli chodzi o zalety deduplikcji na źródle to podstawową jest otrzymanie uzysku, nie tylko na przestrzeni dyskowej, ale także na zużyciu łącza przez które przesyłamy dane - ponieważ są one już zdeduplikowane, więc wysłaniu podlega jedynie ich niewielka część. Rozwiązania tego typu są szczególnie korzystne przy wykonywaniu backupów poprzez sieć WAN lub Internet ( np: centralnie przechowywane backupy z regionalnych jednostek danej firmy)


    Podział ze względu na czas deduplikacji:

    • Deduplikacja inline - w tej metodzie dane są deduplikowane natychmiast po dotarciu do urządzenia na którym są składowane - silnik deduplikujący robi to "w locie" i na dyski zapisywane są jedynie dane unikalne, już po usunięciu duplikatów. Zaleta takiego podejścia to przede wszystkim niższy koszt związany z mniejszą ilością potrzebnych dysków( nie ma cache dyskowego na który zapisuje się dane przed ich zdeduplikowaniem). Wadą jest zagrożenie spowolnienia działania całego systemu, gdy baza skrótów urośnie i jej przeszukanie zacznie zabierać więcej czasu. System może wtedy nie być w stanie deduplikować nowo przychodzących danych z prędkością z jaką są one wysyłane przez klientów.
    • Deduplikcja post-proces - w tej metodzie, dane przychodzące do urządzenia, są najpierw zapisywane na dysk, a dopiero potem przetwarzane i zapisywane w formie zdeduplikowanej. Zaletą jest wydajność takiego rozwiązania, którą ogranicza jedynie wydajność dysków - nie ma potrzeby przeprowadzania dodatkowych czynności przed zapisaniem danych. Wada to większy koszt związany z potrzebą utrzymania dodatkowych przestrzeni na oryginalne dane.


    Sam temat deduplikacji jest bardzo obszerny i niemożliwy do wyczerpania w pojedyńczym wpisie - to co opisałem to pewna baza i podstawy aby wgłębić się w zagadnienie.
    Sprawy związane z deduplikacją będą kontynuowane w tym blogu.

    Do poczytania:

    Deduplikacja: sposob na duze oszczednosci
    Deduplikacja, czyli backup na diecie
    Data deduplication
    Data deduplication tutorial