Deduplikacja staje się stałym elementem procesów zarządzania danymi. Pozwala ograniczyć ilość danych fizycznie przechowywanych w pamięciach masowych, skraca proces wykonywania kopii zapasowych, pozwala ograniczyć pasmo w sieciach łączących ośrodek główny i zapasowy, obniża wydatki inwestycyjne na infrastrukturę i zmniejsza koszty utrzymania środowisk. Rozwiązania służące do deduplikacji różnią się między sobą nie tylko efektywnością kompresji, ale także długą listą innych parametrów istotnych z perspektywy codziennego wykorzystania. Warto przyjrzeć się im, a najlepiej przetestować je w warunkach możliwie bliskich rzeczywistym. Kupując rozwiązanie firma wiąże się z nim na 3 do 5 lat i na ten czas zawierza mu swoje najważniejsze dane. Czas i środki poświęcone na testy zwykle zwracają się wielokrotnie poprzez uniknięcie zakupu rozwiązania zbyt drogiego lub nieoptymalnego z punktu widzenia celu deduplikacji.

Dynamika przyrostu danych od dawna jest większa, niż tempo wzrostu pojemności nośników. Jeśli dane nadal mieszczą się nam na nośnikach, to tylko dlatego, że od dłuższego czasu w dużych instalacjach stosowane są rozwiązania do deduplikacji danych. Deduplikacja jest i pozostanie technologią kluczową dla efektywnego zarządzania danymi, ponieważ pozwala zapanować nad niekontrolowanym wzrostem danych i wynikającymi z niego kosztami. Aby uzyskać maksimum korzyści z deduplikacji, trzeba poznać zarówno jej możliwości, jak i ograniczenia.

Ilość danych i koszty bezpośrednie to tylko jedna z wielu perspektyw. Uwagi wymaga także wydajność deduplikacji oraz procesu odwrotnego, zwanego rehydracją danych. Już sama decyzja o zastosowaniu deduplikacji wymaga ostrożnego rozważenia, nie jest ona bowiem magicznym panaceum na wszystkie bolączki zarządzania danymi. Ponadto, architektura rozwiązania musi pasować do całościowej koncepcji środowiska – w rozważaniach nie można pominąć ciągłości biznesu, szybkości odtwarzania danych po awariach, tempa wzrostu biznesu…

Deduplikacja może być pomocnym narzędziem w rozwiązywaniu konkretnych problemów. Nie jest jednak czymś, co można po prostu odfajkować w tabelce. Jest całe mnóstwo okoliczności, które należy uwzględnić planując włączenie deduplikacji do procesów zarządzania danymi. Część z nich można poznać tylko poprzez testy, ponieważ marketing producentów nie jest nastawiony na eksponowanie słabości rozwiązań. Testowanie jest ważne, by urealnić oczekiwania dotyczące wydajności i efektywności deduplikacji z konkretnymi zestawami danych, a także by zweryfikować założenia dotyczące architektury.

„[Deduplikacja] nie jest jednak czymś, co można po prostu odfajkować w tabelce. Jest całe mnóstwo okoliczności, które należy uwzględnić planując włączenie deduplikacji do procesów zarządzania danymi. Część z nich można poznać tylko poprzez testy, ponieważ marketing producentów nie jest nastawiony na eksponowanie słabości rozwiązań. Testowanie jest ważne, by urealnić oczekiwania dotyczące wydajności i efektywności deduplikacji z konkretnymi zestawami danych, a także by zweryfikować założenia dotyczące architektury”

Deduplikacja w pigułce

Proces deduplikacji to nic innego, jak identyfikowanie i usuwanie nadmiarowych kopii danych. Gdzie występują nadmiarowe kopie? Wszędzie! Wiadomość e-mail z załącznikiem wysłana do 10 osób oznacza, że w bazie pocztowej przybywa 10 instancji załącznika. Chyba że, dzięki deduplikacji, załącznik będzie przechowywany pojedynczo, zaś pozostałe wiadomości będą jedynie wskazywać na plik źródłowy. Kopie nadmiarowe powstają także w wyniku ochrony danych na poziomie infrastruktury (np. mirroring woluminów logicznych w macierzy), wykonywania kopii zapasowych na wypadek awarii systemów, a także w wyniku przygotowania danych do analiz i raportowania.

Deduplikacja może odbywać się w trybie ciągłym, na ścieżce zapisu danych (in-line) lub też już po zapisaniu danych, w formie procedury uruchamianej cyklicznie, np. na serwerze backupowym przed zapisaniem danych do archiwum. Można ją także uruchamiać na żądanie, np. na serwerze podlegającym backupowi, tuż przed wysłaniem danych do serwera backupowego. Patrząc na to jeszcze bardziej syntetycznie, deduplikacja może odbywać się na danych źródłowych (source deduplication), lub też na danych zagregowanych (target deduplication). To, jaką architekturę przyjąć zależy ostatecznie od skali, rozproszenia, ostatecznego celu deduplikacji oraz innych ograniczeń, o czym dalej.

Dla myślenia o deduplikacji ważna jest świadomość, że wymaga ona mocy obliczeniowej. Możemy zmniejszyć pasmo wykorzystywane do transmisji w sieci, ale w zamian musimy zwiększyć obciążenie zasobów serwerów i zgodzić się na niewielki, ale jednak, wzrost opóźnienia. Nic za darmo, to zawsze jest jakiś kompromis. To dlatego w większych środowiskach w miejsce rozwiązań programowych stosowane są platformy sprzętowe z akceleracją funkcji deduplikacji. To zresztą zwykle jeden z warunków tego, by deduplikacja nie stała się słabym ogniwem w zarządzaniu danymi. Biznes zgodzi się na inwestycję, ale w zamian nie można mu fundować spadku wydajności albo mniejszej niezawodności.

„Dla myślenia o deduplikacji ważna jest świadomość, że wymaga ona mocy obliczeniowej. Możemy zmniejszyć pasmo wykorzystywane do transmisji w sieci, ale w zamian musimy zwiększyć obciążenie zasobów serwerów i zgodzić się na niewielki, ale jednak, wzrost opóźnienia. Nic za darmo, to zawsze jest jakiś kompromis”

Architektura rozwiązań deduplikacyjnych

O architekturze rozwiązania deduplikacyjnego przesądza cel biznesowy. Jeśli celem jest zmniejszenie ilości danych produkcyjnych, najlepiej sprawdzi się deduplikacja działająca jako usługa w macierzy centralnej. To zwykle oznacza, że jest to rozwiązanie w ten czy inny sposób akcelerowane sprzętowo. Alternatywą jest dedykowane urządzenie deduplikujące z akceleracją sprzętową, działające w sieci SAN tuż przed macierzą. Trzeba jednak mieć świadomość, że deduplikacja danych w trybie produkcyjnym jest przypadkiem w sumie dość skrajnym, ze względu na to, że pierwszeństwo mają zwykle wymagania wydajnościowe. Spełnienie ich wraz z jednoczesnym ograniczeniem wielkości danych jest potencjalnie bardzo kosztowne. To zaś przeczy celowi głównemu, którym zwykle są oszczędności.

Znacznie lepszym pomysłem jest zmiana architektury. Na potrzeby danych produkcyjnych przeznaczamy dedykowaną macierz, zaś wszystkie inne potrzeby, w tym kopie operacyjne, testowe, analityczne, raportowe, a także kopie bezpieczeństwa, przechowujemy w odrębnej macierzy. W takiej konfiguracji wydajności środowiska produkcyjnego nic nie zaburza, a jednocześnie wszelkie kopie danych produkcyjnych, bez względu na cel ich wykonywania, można objąć deduplikacją już w mniej kosztownym wydaniu. Niższe koszty wynikają głównie z tego, że kopie nie muszą być deduplikowane w czasie rzeczywistym.

Jeśli dane spływają z wielu systemów produkcyjnych, trzeba pomyśleć, a najlepiej upewnić się, czy jedna para serwerów deduplikujących wystarczy do obsłużenia wszystkich strumieni danych. Deduplikacja odbywa się na poziomie bloków danych, a nie plików, duża różnorodność danych nie ma więc znaczenia. Korzystne może być jednak oddzielenie od siebie strumieni danych aplikacji krytycznych dla biznesu i tych, które mają znaczenie pomniejsze – choćby ze względu na ryzyko awarii. Cztery mniejsze serwery zamiast dwóch potężnych to także większe pasmo i mniejsze opóźnienia deduplikacji.

„Deduplikacja odbywa się na poziomie bloków danych, a nie plików, duża różnorodność danych nie ma więc znaczenia. Korzystne może być jednak oddzielenie od siebie strumieni danych aplikacji krytycznych dla biznesu i tych, które mają znaczenie pomniejsze – choćby ze względu na ryzyko awarii. Cztery mniejsze serwery zamiast dwóch potężnych to także większe pasmo i mniejsze opóźnienia deduplikacji”

Czego nie wiadomo u zarania projektu

Deduplikacja to ogólna koncepcja, której realizacja w praktyce wychodzi producentom bardzo różnie. Spotkałem się z rozwiązaniami, które działają wydajnie pod typowym obciążeniem, ale „klękają”, gdy obciążenie zaczyna przekraczać 70%. Niektóre rozwiązania deduplikacyjne działają wydajnie dopóki danych jest relatywnie mało. Kiedy danych przybywa, wydajność spada, ponieważ ograniczeniem okazuje się efektywność przeszukiwania wielkich tablic zawierających skróty (hasze) bloków podlegających porównaniom. Są jednak i takie, które działają wydajnie nawet przy 100% obciążeniu procesorów i przy prawie pełnych dyskach.

Niektóre rozwiązania wykonujące deduplikację miewają poważniejsze problemy. Zarówno w przypadku rozwiązań programowych, jak i sprzętowych zdarzyło mi się natknąć na sytuacje, w których podczas odtwarzania (rehydracji) danych zgłaszane były błędy, choć podczas zapisu wszystko było niby w porządku. Producenci niejednokrotnie wiedzą o niedomaganiach i zgłoszenie problemu do wsparcia kończy się obietnicą „poprawimy to w następnym rylisie”. To może być za pół roku, albo później, albo wcale. Może się okazać, że poprawka jest dostępna dopiero w kolejnej wersji rozwiązania, która wymaga płatnej aktualizacji, albo w nowym modelu urządzenia.

Rozwiązania deduplikujące różnie zachowują się w sytuacjach awaryjnych. Wszystko może się przecież zdarzyć: przegrzanie urządzenia w wyniku awarii wentylatorów, utrata zasilania, awaria elementów elektronicznych, błąd oprogramowania… Niektóre rozwiązania potrafią w takich sytuacjach utracić dane, co jest o tyle ważne, że firma nie posiada już zwykle danych w formie surowej, niezdeduplikowanej. Inne rozwiązania, z którymi miałem do czynienia nie tracą danych, ale ich podnoszenie się po awarii trwa wiele godzin, a w skrajnych przypadkach (np. na skutek awarii dwóch dysków jednocześnie), nawet kilka dni. Klient nie ma szans wiedzieć takich rzeczy, studiując tabelki.

„Rozwiązania deduplikujące różnie zachowują się w sytuacjach awaryjnych. (…) Niektóre rozwiązania potrafią w takich sytuacjach utracić dane, co jest o tyle ważne, że firma nie posiada już zwykle danych w formie surowej, niezdeduplikowanej. Inne rozwiązania, z którymi miałem do czynienia nie tracą danych, ale ich podnoszenie się po awarii trwa wiele godzin, a w skrajnych przypadkach (np. na skutek awarii dwóch dysków jednocześnie), nawet kilka dni. Klient nie ma szans wiedzieć takich rzeczy, studiując tabelki”

Jak postępować z dostawcami

Analizując materiały produktowe dostawców rozwiązań deduplikujących należy zakładać, że postępują oni podobnie, jak producenci samochodów w przypadku danych na temat zużycia paliwa. Aby uniknąć zawodu lub wstydu przed szefami, w kwestii efektywności deduplikacji obietnice producentów proponuję standardowo dzielić na pół. Z moich doświadczeń z profesjonalnymi rozwiązaniami deduplikującymi dane mieszane wynika, że długofalowy współczynnik deduplikacji na poziomie 10-11x należy uznać za bardzo dobry. W przypadku danych skompresowanych (pliki audio/wideo, skompresowane bazy danych) współczynnik będzie zazwyczaj znacznie mniejszy, chyba że dane ze swojej natury będą do siebie bardzo podobne.

Nic nie zastąpi projektu testowego, podczas którego deduplikowane i odtwarzane będą konkretne zbiory danych. Planując testy trzeba sprawdzić jak rozwiązanie działa pod bardzo dużym obciążeniem oraz jak radzi sobie przy zapełnieniu go danymi powyżej 80%. Należy sprawdzić efekty awarii zasilania w trakcie wykonywania procesu deduplikacji. Warto zwrócić uwagę na wydajność środowisk źródłowych, które mogą być ograniczeniem dla wydajności procesu deduplikacji. Koniecznie trzeba zbadać kwestię przewidywalności procesu „odśmiecania” pamięci, by proces ten nie rujnował wydajności rozwiązań podczas intensywnej pracy. Takich kwestii jest dużo więcej.

Trzeba pamiętać, że kupując rozwiązanie firma wiąże się z nim na 3 do 5 lat i na ten czas zawierza mu swoje najważniejsze dane. Czas i środki poświęcone na testy zwykle zwracają się wielokrotnie – poprzez uniknięcie zakupu rozwiązania zbyt drogiego lub nieoptymalnego z punktu widzenia celu deduplikacji. Jedną z opcji jest wykonanie testów w prowadzonym przez nas Engave Performance Lab. Pomagamy klientom w przygotowaniu realistycznych testów oraz przeprowadzeniu ich z wykorzystaniem różnych rozwiązań deduplikacyjnych, by mogli empirycznie przekonać się, które z nich najlepiej spełnia ich oczekiwania.

„Nic nie zastąpi projektu testowego, podczas którego deduplikowane i odtwarzane będą konkretne zbiory danych. Planując testy trzeba sprawdzić jak rozwiązanie działa pod bardzo dużym obciążeniem oraz jak radzi sobie przy zapełnieniu go danymi powyżej 80%. Należy sprawdzić efekty awarii zasilania w trakcie wykonywania procesu deduplikacji. Warto zwrócić uwagę na wydajność środowisk źródłowych, które mogą być ograniczeniem dla wydajności procesu deduplikacji”

Autor jest dyrektorem technicznym w warszawskiej firmie Engave Sp. z o.o. Można się z nim skontaktować pod adresem: wojciech kropka chmielewski w domenie engave kropka pl.