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

Brak komentarzy:

Prześlij komentarz