Kompresja Przechowywania w Chmurze

Pamięć masowa w chmurze

Zdjęcia, dokumenty i filmy mogą być przechowywane w usłudze określanej jako "chmura". Przechowywanie danych w chmurze oznacza dostęp do zasobów z centrów danych przez sieć. Centra te zawierają serwery, dyski twarde i dyski SSD połączone infrastrukturą sieciową. Warstwa logiczna obiektów lub plików może być oddzielona od warstwy fizycznej, w której dostawca stosuje replikację, kodowanie korekcyjne albo migrację między nośnikami. Użytkownik widzi nazwę obiektu i jego metadane, a szczegóły rozmieszczenia pozostają częścią implementacji usługi.

Po przesłaniu pliku do usługi takiej jak Dysk Google, Dropbox czy OneDrive dane trafiają przez internet do zarządzanej infrastruktury. Użytkownik otrzymuje dostęp z różnych urządzeń, bez wskazywania konkretnego serwera lub dysku. Dostawca odpowiada za rozproszenie danych, dostępność, replikację i obsługę nośników zgodnie z wybraną usługą. W modelu obiektowym plik jest zwykle identyfikowany przez klucz oraz metadane, a wersjonowanie może przechowywać kilka stanów tego samego obiektu. Kompresja dotyczy wartości danych, podczas gdy indeksy i metadane mają własny narzut.

Rozproszona infrastruktura musi obsługiwać dużą skalę. Globalne zbiory opisuje się niekiedy w zettabajtach, czyli bilionach gigabajtów. Koszt obejmuje nośniki, centra danych, energię, chłodzenie i sieci. Dlatego dostawcy stosują strategie ograniczania rozmiaru, w tym kompresję i deduplikację, zależnie od rodzaju danych oraz wymagań usługi. Optymalizacja musi zachować dostępność i możliwość odtworzenia, więc nie każda redukcja jest dopuszczalna dla każdego obiektu. Wybór warstwy gorącej, chłodnej i archiwalnej wpływa na koszt odczytu oraz czas przywrócenia.

Przestrzeń dyskowa i przepustowość sieci

Dla dostawcy chmury wydajność obejmuje koszt miejsca oraz koszt przesyłania danych. Pierwszy dotyczy nośników i ich utrzymania, drugi ruchu między klientami, usługami i centrami danych. Dochodzą koszty operacji, indeksowania, replikacji i kontroli integralności. Analiza powinna rozdzielać dane często odczytywane od archiwów, ponieważ inny jest koszt opóźnienia i obciążenia CPU.

1. Kompresja w systemach chmurowych

Jedną z metod ograniczania rozmiaru jest kompresja bezstratna ogólnego przeznaczenia. Algorytmy spotykane w systemach plików i archiwach ZIP mogą być używane także w usługach chmurowych, jeżeli format obiektów i wymagania odczytu na to pozwalają. Dokument tekstowy lub plik bazy danych zwykle daje więcej możliwości niż dane już skompresowane. System może kompresować obiekt przy zapisie, w zadaniu asynchronicznym albo dopiero w warstwie archiwalnej. Każdy wariant zmienia obciążenie klienta, serwera i ścieżki odczytu.

Przykładowe algorytmy to:

• Gzip (DEFLATE): Format gzip przenosi bezstratny strumień DEFLATE, który łączy wyszukiwanie powtórzeń z kodowaniem Huffmana. Nagłówek gzip może zawierać metadane, a stopka zawiera wartość CRC32. Kompresja nie daje korzyści na każdym typie obiektu.
• LZ4: Algorytm projektowany pod kątem krótkiego czasu kodowania i dekodowania. Zwykle daje mniejszą redukcję niż ustawienia nastawione na rozmiar, lecz ogranicza narzut procesora. Jest użyteczny przy danych gorących, dla których ważne są opóźnienia.
• Zstandard (zstd): Algorytm bezstratny z poziomami pozwalającymi wybrać kompromis między szybkością i rozmiarem. Porównanie z Gzip zależy od ustawień oraz danych. Obsługa ramek i słowników może zmienić wynik dla podobnych bloków, więc parametry powinny być częścią formatu przechowywania.

Kompresja analizuje reprezentowany strumień, zwykle w obrębie jednego obiektu lub bloku. Nie rozpoznaje sama, że wielu użytkowników przesłało identyczne dane. Redundancję wewnątrz jednego pliku usuwa kompresor, natomiast redundancję pomiędzy obiektami może usuwać deduplikacja, jeśli usługa ją stosuje.

2. Deduplikacja w systemie chmurowym

Deduplikacja porównuje fragmenty w zakresie określonym przez architekturę usługi. Jeżeli 100 użytkowników prześle to samo zdjęcie Pałacu Kultury, system wykonujący deduplikację między kontami może przechować dane zdjęcia raz i utworzyć odwołania dla pozostałych 99 kont. Rzeczywista korzyść zależy od poziomu współdzielenia, polityki prywatności i rodzaju danych. Usługa może ograniczyć deduplikację do konta, regionu, dzierżawy albo jednego repozytorium, aby nie ujawniać istnienia obiektu innym użytkownikom.

Haszowanie danych

Do wstępnego porównania fragmentów system oblicza "cyfrowy odcisk palca" o stałej długości, czyli hasz kryptograficzny. Hasz ogranicza liczbę porównań bajt po bajcie, lecz sam nie dowodzi identyczności.

Stosuje się między innymi $SHA-256$ (Secure Hash Algorithm, 256 bitów). Dla dowolnego wejścia, od małego pliku tekstowego po plik wideo, algorytm zwraca 256-bitową wartość, zwykle zapisywaną jako 64 znaki szesnastkowe. Ten sam fragment ponownie podany do $SHA-256$ daje ten sam wynik. Jest to identyfikator o bardzo małym prawdopodobieństwie kolizji, lecz nie matematycznie unikalny.

• Zmiana jednego bitu zwykle zmienia wiele bitów wartości hasza, zgodnie z właściwością lawiny.
• Odporność na kolizje utrudnia znalezienie dwóch różnych wejść o tej samej wartości, lecz system może po trafieniu hasza sprawdzić dane bezpośrednio.

Porównanie wartości pozwala szybko znaleźć kandydatów do deduplikacji. Dla danych wymagających integralności system może dodatkowo zweryfikować długość i zawartość fragmentu. Indeks musi też aktualizować odwołania oraz usuwać blok dopiero po sprawdzeniu, że nie wskazuje go żaden zachowany obiekt.

Deduplikacja na poziomie pliku i bloku

Haszowanie można zastosować na poziomie całego pliku albo jego bloków:

1. Deduplikacja na Poziomie Pliku (Single-Instance Storage): Po przesłaniu pliku system oblicza jego hasz i sprawdza indeks. Trafienie pozwala utworzyć odwołanie do istniejących danych, a nowy hasz prowadzi do zapisu pliku. Metoda dobrze rozpoznaje identyczne instalatory lub zdjęcia. Jedna zmieniona litera zmienia hasz całego pliku, więc nowa wersja dużego dokumentu musi być traktowana jako nowy obiekt.

2. Deduplikacja na Poziomie Bloku: W tym wariancie plik dzieli się na mniejsze porcje, a każdą z nich haszuje osobno. Nowy plik przechodzi ten sam podział, po czym system sprawdza, które bloki już ma. Zakres zastosowania zależy od usługi i może obejmować pojedyncze konto albo większą grupę danych. Stały rozmiar upraszcza indeksowanie, natomiast granice definiowane treścią lepiej znoszą wstawienie danych w środku pliku.

Rozważmy 500-stronicowy raport ($raport_v1.docx$) z jedną poprawioną literówką na stronie 200, zapisany jako $raport_v2.docx$. Przy odpowiednim podziale może się okazać, że 99% bloków obu wersji jest identycznych. Repozytorium zapisze wtedy nowy blok i odwołania do pozostałych. Opisana przez Dropbox architektura synchronizacji dzieli pliki na bloki i używa listy haszy do żądania brakujących bloków, co jest przykładem mechanizmu typu "Delta Sync". Wynik 99% jest założeniem przykładu, ponieważ zmiana metadanych dokumentu lub przesunięcie granic może zmienić większą liczbę bloków.

Kolejność kompresji i deduplikacji

Jednym z możliwych modeli łączenia obu strategii jest następujący proces. Kolejność dotyczy systemu, który identyfikuje surowe bloki przed ich kompresją. Model przechowuje hasze, mapę kolejności oraz informację o algorytmie użytym dla każdego nowego bloku:

1. Plik jest przesyłany do systemu.
2. Plik jest dzielony na mniejsze bloki.
3. Dla każdego bloku obliczany jest hasz (cyfrowy odcisk palca).
4. System sprawdza swój centralny magazyn haszy, aby zobaczyć, które z tych haszy już widział. To jest krok deduplikacji.
5. Dla każdego bloku, który jest nowy (jego hasza nie ma w magazynie), system stosuje szybki algorytm kompresji bezstratnej, jak LZ4 lub zstd. To jest krok kompresji.
6. Nowy, skompresowany blok jest następnie zapisywany w fizycznej pamięci masowej, a jego hasz jest dodawany do centralnego magazynu.
7. Na koniec plik na koncie użytkownika jest reprezentowany przez mapę metadanych, która jest po prostu listą wskaźników do wszystkich wymaganych bloków (zarówno starych, jak i nowych).

W tym modelu haszowanie surowych bloków przed kompresją umożliwia ponowne użycie identycznych fragmentów. Kompresja zmienia reprezentację bajtową, więc haszowanie dopiero po niej wymaga porównywania wyników z tym samym formatem, poziomem i kontekstem. Nie każda architektura stosuje identyczną kolejność. Po zapisaniu bloku system musi zachować jego hasz, długość, parametry kompresji i relację do mapy pliku, aby odczyt mógł odtworzyć kolejność.

Bezpieczeństwo i optymalizacja po stronie klienta

Deduplikacja po stronie klienta i serwera

Deduplikacja może odbywać się w dwóch miejscach:

• Po Stronie Serwera: Użytkownik przesyła cały plik, a serwer dzieli go na bloki, haszuje i porównuje. Upraszcza to klienta, lecz dane odrzucone po analizie zostały już przesłane.
• Po Stronie Klienta: Aplikacja dzieli plik i oblicza hasze przed przesłaniem. Klient wysyła listę, a serwer wskazuje brakujące bloki. Dropbox opisał rozwiązanie z blokami 4 MB i żądaniem bloków na podstawie listy haszy. Zysk zależy od kosztu obliczeń oraz zakresu indeksu. Klient musi jednak chronić listę haszy i obsłużyć zmianę pliku podczas skanowania, aby mapa odpowiadała faktycznie wysłanym blokom.

Bezpieczeństwo i prywatność

Deduplikacja może ujawniać informację o tym, że dany fragment już znajduje się w systemie. Jeżeli atakujący potrafi przewidzieć treść i obserwuje odpowiedź usługi, może próbować potwierdzić jej obecność na podstawie hasza lub zachowania protokołu. Samo potwierdzenie nie daje automatycznie dostępu do danych, lecz stanowi kanał boczny. Ryzyko rośnie przy treściach o małej przestrzeni możliwych wartości, takich jak znany dokument lub plik o przewidywalnym formacie.

Ograniczenia zależą od modelu zaufania i mogą obejmować:

• Deduplikacja w Obrębie Konta Użytkownika: System może ograniczyć indeks do jednego konta albo zaufanej grupy. Ogranicza to wyciek informacji między użytkownikami kosztem mniejszych oszczędności.
• Szyfrowanie: Dane często szyfruje się podczas transmisji i w spoczynku. Szyfrowanie po stronie klienta wykonuje operację przed wysłaniem, lecz dwa identyczne pliki zwykle dają różne szyfrogramy, więc deduplikacja między użytkownikami przestaje działać. Szyfrowanie zbieżne zachowuje możliwość deduplikacji, lecz samo w sobie nie usuwa ryzyka ataków potwierdzających. Schematy z serwerem kluczy, takie jak DupLESS, ograniczają ten problem innym modelem kluczy. Decyzja o współdzieleniu indeksu musi być więc powiązana z kluczami, autoryzacją odczytu i zasadami usuwania danych.

Projekt usługi musi więc równoważyć rozmiar, ruch, czas obliczeń, możliwość odtworzenia oraz zakres ujawnianych informacji. Kompresja i deduplikacja są elementami tej decyzji, a ich działanie zależy od formatu danych i modelu bezpieczeństwa. Konfiguracja powinna być sprawdzana na reprezentatywnych plikach. Testy powinny obejmować przesyłanie, ponowne przesyłanie, dostęp losowy, usuwanie i pełne odtworzenie. Sam korzystny współczynnik zajętości nie wystarcza, gdy indeks staje się wąskim gardłem albo ścieżka odtworzenia nie może zweryfikować każdego wskazanego bloku. Różne dzierżawy mogą mieć odmienne wzorce powtórzeń i szyfrowania, a limity operacyjne, retencja i izolacja prawna mogą ograniczać współdzielenie danych. Testy odtworzenia powinny obejmować warstwę danych i metadanych przy częściowej awarii oraz zgodnych uprawnieniach. Oprócz rozmiaru trzeba mierzyć opóźnienie dostępu, koszty indeksu i czas propagacji usuwania między replikami. Warstwa archiwalna może zmniejszyć koszt nośnika, lecz wydłużyć przywracanie. Retencja oraz izolacja prawna mogą ograniczać współdzielenie danych między dzierżawcami.