Data Domain, kompresja — często zadawane pytania

DOTYCZY

• Wszystkie DDR
• Wszystkie wersje

Kompresja: Najczęściej zadawane pytania:

Idealnie byłoby, gdyby to była prawda. W praktyce pełna kopia zapasowa zajmuje nieco więcej miejsca niż przyrostowa z powodów przedstawionych poniżej. Powody te wyjaśniają również, dlaczego pełna kopia zapasowa bez zmian w danych nadal zajmuje dodatnią ilość miejsca.

• Metadane zajmują około 0,5% logicznego rozmiaru kopii zapasowej. Załóżmy, że rozmiar logiczny pełnej pamięci wynosi 100 GB, a rozmiar przyrostowy 2 GB. Załóżmy, że kompresja przyrostowej wynosi 1 GB. Wtedy pełna zajmie co najmniej 1,5 GB.
• Silnik kompresji DD przepisze niektóre zduplikowane segmenty danych w celu zwiększenia wydajności. Im uboższa lokalność danych zmian, tym więcej duplikatów jest zapisywanych. Duplikaty są później odzyskiwane przez „filesys cleaning”. Zdarza się około 2% rozmiaru logicznego przepisanego jako duplikat. Zakładając ten poziom duplikatów, pełna może zająć 1 GB (skompresowana) + 0,5 GB (metadane) + 2 GB (duplikaty) = 3,5 GB. Liczbę zapisanych duplikatów można kontrolować za pomocą parametru systemowego, ale generalnie nie dostrajamy tego parametru w polu.
• Segmentacja danych może się nieco różnić w zależności od kolejności, w jakiej klient NFS wysyła dane. Porządek ten nie jest deterministyczny. Ogólnie rzecz biorąc, algorytm segmentacji toleruje przesunięcia i zmianę kolejności. Jednak tworzy również pewne „wymuszone” segmenty, które są podatne na przesunięcia i zmianę kolejności. Zazwyczaj około 0,2% segmentów jest wymuszonych, więc można się spodziewać, że wykorzystane zostanie znacznie więcej miejsca.

Polecenie „filesys show space” zapewnia współczynnik kompresji oparty na logicznym rozmiarze przechowywanych danych i miejscu na dysku używanym w momencie uruchamiania polecenia.

Polecenie „filesys show compression” zapewnia współczynnik kompresji oparty na tym, jak każdy plik został skompresowany w momencie jego utworzenia.

Polecenie „filesys show compression” jest używane głównie do obsługi i debugowania. W przypadku usunięcia plików polecenie „filesys show compression” przeszacowuje współczynnik kompresji.

Na przykład założenie jest takie, że pierwsza pełna kopia zapasowa podlega kompresji 2x. Kolejna pełna kopia zapasowa bez żadnych zmian danych podlega kompresji 200x. Pierwsza pełna kopia zapasowa zostanie usunięta. Polecenie „filesys show space” wyświetli współczynnik kompresji 2x. Polecenie „filesys show compression” będzie teraz pokazywać współczynnik kompresji 200x, ponieważ jedyny plik, który istnieje, podlega teraz kompresji 200x podczas tworzenia.

We wspomnianym przykładzie, po wykonaniu drugiej kopii zapasowej, polecenie „filesys show space” pokaże łączny współczynnik około 4x. Skumulowany współczynnik poprawiłby się asymptotycznie do 200x, gdyby nadal wykonywał więcej kopii zapasowych bez usuwania.

Jest jeszcze kilka innych drobnych różnic:

•  Polecenie „filesys show compression” nie uwzględnia marnotrawstwa na poziomie kontenera, co jeszcze bardziej przeszacowuje współczynnik kompresji
•  Polecenie „filesys show compression” nie uwzględnia eliminacji duplikatów przez kompresję globalną, a tym samym nie doszacowuje współczynnika kompresji
•  Polecenie „filesys show compression” może zawierać informacje o poszczególnych plikach lub katalogach, natomiast polecenie „filesys show space” jest ograniczone do całego systemu
•  Polecenie „filesys show compression” zawiera podział na kompresję globalną i lokalną, natomiast polecenie „filesys show space” go nie zawiera

ODNIESIENIA

• Dlaczego współczynniki kompresji są różne dla poleceń „filesys show space” i „vtl tape show summary”?

Współczynnik kompresji pokazany w „vtl tape show summary” powinien odpowiadać „filesys show compression /backup/vtc”.

Mówiąc bardziej ogólnie, to polecenie VTL może mieć opcjonalny filtr do wyboru podzbioru kaset z taśmą, a kompresja powinna odpowiadać „filesys show compression” na tym podzbiorze kaset.

Jednak ze względu na błąd w kodzie interfejsu użytkownika VTL kompresja pokazana w „vtl tape show summary” jest błędna. Jest to znany problem, który został rozwiązany w wersji 4.5.0.0.
 

• Dlaczego polecenie „filesys show compression last 24hours” nie spełnia oczekiwań dotyczących VTL?

W przypadku VTL dane wyjściowe poleceń, takich jak „filesys show compression last 24hours”, często nie spełniają oczekiwań opartych na innych źródłach, takich jak „system show performance”.

Problem występuje z powodu osobliwości w „filesys show compression” (fsc). Ogólnie rzecz biorąc, polecenie „filesys show compression” pokazuje skumulowane statystyki w wybranych plikach. Kwalifikator „last 24 hours” wybiera pliki, które zostały zaktualizowane w ciągu ostatnich 24 godzin. Statystyki są nadal skumulowane od momentu utworzenia pliku lub ostatniego obcięcia do zerowego rozmiaru. Zatem jeśli plik został dodany w ciągu ostatnich 24 godzin, „filesys show compression last 24hours” pokaże jego skumulowane statystyki przed ostatnimi 24 godzinami.

W środowiskach innych niż VTL pliki kopii zapasowych są zapisywane tylko raz, więc nie ma dużej rozbieżności między plikami zaktualizowanymi a utworzonymi. W przypadku VTL kopie zapasowe mogą być dołączane do istniejących plików taśmowych. Rozważmy na przykład taśmę o pojemności 100 GB, która jest zapełniona do 50 GB. Jeśli 10 GB danych dołączono do tej taśmy w ciągu ostatnich 24 godzin, polecenie „filesys show compression last 24hours” pokaże „oryginalne bajty” pliku zapisane w rozmiarze 60 GB.
 

• Jak obliczany jest skumulowany współczynnik kompresji?

Poszczególne współczynniki kompresji nie sumują się liniowo.

Załóżmy, że kompresja na pierwszej pełnej kopii zapasowej to 2x, a na drugiej pełnej kopii wynosi 20x. Kompresja skumulowana nie wynosi (2+20)/2 lub 11x, ale 2/(1/2+1/20) lub 3,64x.

Ogólnie rzecz biorąc, niższe współczynniki kompresji mają większy wpływ na skumulowany współczynnik kompresji niż wyższe.

Załóżmy, że i-ta kopia zapasowa ma rozmiar logiczny si i współczynnik kompresji ci. Następnie skumulowany współczynnik kompresji dla k kopii zapasowych można obliczyć w następujący sposób:

C = (całkowity rozmiar logiczny)/(całkowita użyta przestrzeń)
całkowity rozmiar logiczny = s1 + s2 + .. + sk
całkowita wykorzystana przestrzeń = s1/c1 + s2/c2 + ... + sk/ck

Często rozmiary logiczne są mniej więcej takie same. W takim przypadku powyższe obliczenie upraszcza się do następującego:

Jeśli na przykład pierwsza pełna kopia zapasowa zostanie objęta 3-krotną kompresją, a każda kolejna pełna zostanie poddana 30-krotnej kompresji, gdy okres przechowywania wynosi 30 dni, użytkownik zobaczy kumulatywną kompresję 30/(1/3+29/30) lub 23x.
 

• Jak działa kompresja Data Domain?

Szczegółowa odpowiedź na to pytanie znajduje się w osobnym artykule bazy wiedzy „Wskazówki dotyczące kompresji Data Domain” Data Domain: Wskazówki dotyczące kompresji Data Domain
 

• Czy Data Domain obsługuje multipleksację? ​​​​​​​

Multipleksowane dane z aplikacji do tworzenia kopii zapasowych powodują bardzo słabą globalną deduplikację. Aby uzyskać więcej informacji, zapoznaj się z powiązanym artykułem Multipleksacja w oprogramowaniu do tworzenia kopii zapasowych nie jest obsługiwana Data Domain: Multipleksacja w oprogramowaniu do tworzenia kopii zapasowych. 
 

• Dlaczego w przypadku replikacji katalogów 1 do 1 replika wykazuje lepszą kompresję globalną?​​​​​​​

Dzieje się tak zazwyczaj z powodu różnic w poziomie zduplikowanych segmentów zapisanych w systemie:

• Dane przechowywane w źródle zostały raz zdeduplikowane — względem poprzednich danych przechowywanych w źródle.
• Dane przesyłane za pośrednictwem sieci zostały raz zdeduplikowane — względem danych przechowywanych w replice.
• Dane przechowywane w replice zostały zdeduplikowane dwukrotnie, raz po wysłaniu danych za pośrednictwem sieci i ponownie po zapisaniu odebranych danych w replice.

Ponieważ proces deduplikacji pozostawia pewne duplikaty, dane, które zostały wielokrotnie zdeduplikowane, mają mniej duplikatów. Dane przechowywane w źródle i wysyłane za pośrednictwem sieci są deduplikowane raz, więc są w przybliżeniu takie same, przy założeniu, że dane przechowywane w źródle i replice są podobne. Dane przechowywane w replice są deduplikowane dwukrotnie, dzięki czemu są lepiej skompresowane.

Czyszczenie systemu plików usuwa większość duplikatów. W związku z tym po uruchomieniu czyszczenia w źródle i replice ilość przechowywanych tam danych powinna być mniej więcej taka sama.

• Jaka jest zmiana w kompresji w przypadku korzystania z ustawień kompresji lokalnej lz, gzfast i gz?

filesys option set compression {none | lz | gzfast | gz}
 

Ostrzeżenie: przed zmianą typu kompresji lokalnej system plików trzeba zamknąć. Następnie można go uruchomić ponownie natychmiast po ustawieniu opcji kompresji.

Ogólnie rzecz biorąc, kolejność kompresji jest następująca:

Przybliżona różnica jest następująca:

• lz do gzfast daje ~15% lepszą kompresję i zużywa 2x CPU
• lz do gz daje ~30% lepszą kompresję i zużywa 5x CPU
• gzfast do gz daje ~10–15% lepszą kompresję

Należy pamiętać, że zmiana kompresji lokalnej ma wpływ najpierw na nowe dane zapisane w Data Domain Restorer po wprowadzeniu zmiany. Stare dane zachowują poprzedni format kompresji do następnego cyklu czyszczenia. Następny cykl czyszczenia spowoduje skopiowanie wszystkich starych danych do nowego formatu kompresji. Powoduje to, że czyszczenie trwa znacznie dłużej i bardziej obciąża procesor.

Jeśli w systemie klienta jest już duże obciążenie procesora, szczególnie jeśli klient wykonuje jednocześnie kopię zapasową i replikację, może to spowolnić tworzenie kopii zapasowej i/lub replikację. Klient może chcieć dokładnie zaplanować czas na wykonanie tej konwersji.

Odniesienia do bazy wiedzy:

• Rozwiązywanie problemów związanych z migracją
• Data Domain: Wskazówki dotyczące kompresji Data Domain