Rozwiązywanie problemów z niską deduplikacją i współczynnika kompresji plików na funkcjach przywracania domeny danych (DDR)

Narzędzia Data Domain Restorers (DDR) są przeznaczone do przechowywania dużych ilości danych logicznych (wstępnie skompresowanych) przy minimalnym miejscu na dysku fizycznym (postcompressed). Można to osiągnąć za pomocą:

• Deduplikacja połknięcia danych w celu usunięcia zduplikowanych fragmentów danych, które są już przechowywane na dysku w DDR, pozostawiając tylko dane unikatowe
• Kompresja danych unikatowych przed fizycznym zapisaniem tych danych na dysku.

Ogólny współczynnik kompresji danych, który może uzyskać DDR, różni się w zależności od kilku czynników, takich jak:

• Przykład zastosowania
• Połknięcie typów danych
• Konfiguracja aplikacji do tworzenia kopii zapasowych

Po optymalnym skonfigurowaniu DDR zazwyczaj uzyskuje się ogólny współczynnik kompresji 10–20x (a czasami współczynniki są wyższe). Jednak w niektórych środowiskach ogólny współczynnik kompresji może być niższy niż ten, co może spowodować:

• DDR szybko wyczerpuje swoją użyteczną pojemność
• Wpływ na wydajność tworzenia kopii zapasowych, przywracania lub replikacji
• Awaria DDR w celu spełnienia oczekiwań klientów

Celem tego artykułu jest omówienie:

• Krótki przegląd deduplikacji i kompresji danych w DDR
• Określanie ogólnego współczynnika kompresji dla systemu i poszczególnych plików
• Czynniki, które mogą powodować pogorszenie ogólnego współczynnika kompresji

W jaki sposób funkcja przywracania domeny danych gromadzi nowe dane?

• Aplikacja do tworzenia kopii zapasowych wysyła dane (czyli pliki) do DDR.
• DDR dzieli te pliki na fragmenty o rozmiarze 4-12 Kb — każdy fragment jest postrzegany jako "segment".
• W zależności od danych zawartych w segmencie moduł DDR generuje unikatowy "odcisk palca" (podobny do sumy kontrolnej) dla każdego segmentu.
• Odciski palców nowo nowych segmentów są sprawdzane pod kątem indeksów dysków w DDR, aby sprawdzić, czy moduł DDR posiada już segment z tym samym odciskiem palca.
• Jeśli DDR posiada już segment z tym samym odciskiem palca, odpowiedni segment nowo otrzymanych danych jest duplikatem i można go upuścić (deduplikowany).
• Po usunięciu wszystkich zduplikowanych segmentów z nowo dostępnych danych pozostają tylko unikatowe lub nowe segmenty.
• Te unikatowe lub nowe segmenty są pogrupowane w 128 Kb "regiony kompresji", a następnie skompresowane (domyślnie przy użyciu algorytmu lz ).
• Regiony kompresji skompresowanej są spakowane do 4,5 Mb pamięci masowej, zwanej dalej "kontenerami", które są następnie zapisywane na dysku twardym.

W jaki sposób DDR śledzi, które segmenty składają się na określony plik?

Oprócz deduplikacji/kompresji nowo dostarczanych danych, DDR tworzy również "drzewo segmentów" dla każdego połknięcia pliku. Jest to w istocie lista segmentowych "odcisków palców" składających się na ten plik. Jeśli DDR musi później odczytać plik z powrotem, oznacza to:

• Określ położenie drzewa segmentów plików.
• Przeczytaj drzewo segmentów, aby uzyskać listę wszystkich odcisków palców segmentu składających się na region odczytywanego pliku.
• Użyj indeksów dyskowych, aby określić lokalizację fizyczną (kontener) danych na dysku.
• Odczytaj dane segmentu fizycznego z podstawowych kontenerów na dysku.
• Użyj danych segmentu fizycznego, aby odtworzyć plik.

Drzewa segmentów plików są również przechowywane w kontenerach 4,5 Mb na dysku i stanowią większość "metadanych" plików (omówionych w dalszej części tego artykułu).

W jaki sposób można określić ogólny współczynnik kompresji DDR?

Ogólne wykorzystanie DDR (i współczynnik kompresji) można sprawdzić za pomocą polecenia "filesys show space". Na przykład:

warstwa aktywna:
gib rozmiaru zasobów używany GiB Avail GiB Użyj% czyszczenie GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - - -
/data: post-comp 679 4,2 6242,4 551,8 92% 202,5
/ddvar 49,2 9,1 37,6 20% -


---------------- -------- -------- --------- ---- --------------W tym przypadku widać, że:

• Wstępnie skompresowane lub logiczne dane przechowywane w DDR: 115367,8 Gb
• Przestrzeń postkompresowana lub fizyczna używana w DDR: 6242,4 Gb
• Ogólny współczynnik kompresji wynosi 115367,8 / 6242,4 = 18,48x

Wynik polecenia "filesys show compression" potwierdza dane, które są w posiadaniu, używane miejsce i współczynnik kompresji. Oto przykład:

                   Czynnik czynnika współczynnika pre-comp post-comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor (Redukcja %)
---------------- -------- --------- ----------- ---------- -------------
odparcie używane:*
   115367.8 6242.4 - - 18.5x (94.6) <=== UWAGA
:                                                                          
  Ostatnie 7 dni: 42214,7 1863,2 11,0x 2,1x 22,7x (95,6)
  Ostatnie 24 godziny 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

własne dane dotyczące wykorzystania pamięci DDR są obliczane w następujący sposób:

• Łączna liczba wstępnie skompresowanych danych: Suma wstępnie skompresowanego (logicznego) rozmiaru wszystkich plików przechowywanych w DDR.
• Łączna liczba danych postkompresowanych: Liczba używanych "kontenerów" na dysku pomnożona przez 4,5 Mb (rozmiar pojedynczego kontenera).
• Całkowity rozmiar postcompressed: Liczba maksymalnych "kontenerów", które zostały utworzone, daje dostępne miejsce na dysku w systemie.

Statystyki dotyczące maksymalnego wykorzystania kontenerów są dostępne w automatycznych usługach. Na przykład:

kontener 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== rozmiar kontenera w bajtach
...
    attrs.max_containers = 1546057 <=== maksymalna liczba możliwych kontenerów
attrs.free_containers = 125562 <=== obecnie wolne kontenery
attrs.used_containers = 1420495 <=== obecnie używane kontenery
...

Zobacz to:
 
W jaki sposób można ustalić współczynniki deduplikacji i kompresji dla pojedynczego pliku, katalogu lub drzewa katalogów?

Po połknięciu pliku DDR rejestruje statystyki dotyczące pliku, w tym:

• Wstępnie skompresowane (logiczne) bajty
• Rozmiar unikatowych segmentów po deduplikacji
• Rozmiar unikatowych segmentów po deduplikacji i kompresji
• Rozmiar metadanych pliku (czyli drzewa segmentów itd.)

Istnieje możliwość zrzutu niektórych z tych statystyk za pomocą polecenia "filesys show compression [path]" — na przykład do raportowania statystyk dla pojedynczego pliku:

SE@DDVE60_JF## filesys show compression /data/coll1/backup/testfile
Total files: 1;  bajtów/storage_used: 2,9
oryginalnych bajtów:        3 242 460 364
skompresowanych na całym świecie:        1 113 584 070
lokalnie skompresowanych:        1 130 871 915
metadanych:            4 772 672

Aby zgłosić statystyki całego drzewa katalogów:SE@DDVE60_JF## filesys show compression /data/coll1/backup
Total files:

3;  bajtów/storage_used: 1.4
oryginalne bajty:        7 554 284 280
skompresowanych na całym świecie:        5 425 407 986 lokalnie skompresowanych:
        5 510 685 100
metadanych:           23 263 692

Należy jednak pamiętać, że korzystanie z tych statystyk wiąże się z kilkoma zastrzeżeniami:

• Statystyki są generowane w momencie pobierania plików lub danych i nie są aktualizowane. Ze względu na to, jak działa DDR, przyswożenie nowych plików lub usunięcie plików odnoszących się do tych samych danych itd. może zmienić sposób deduplikacji pliku w czasie, powodując ze starość tych statystyk.
• Ponadto niektóre przypadki użycia na DDR (takie jak szybki zakres pliku, a następnie usunięcie oryginalnego pliku) mogą spowodować, że statystyki te staną się mylące lub nieprawidłowe.

W rezultacie dane te należy traktować tylko jako dane szacunkowe.

Wstępnie skompresowane bajty nie muszą mieć wstępnie skompresowanego/logicznego rozmiaru pliku. Zamiast tego jest to całkowita liczba bajtów zapisanych w pliku w okresie istnienia. W rezultacie w niektórych środowiskach istniejące pliki są często nadpisywane (na przykład w przypadku korzystania z funkcji wirtualnej biblioteki taśmowej), rysunek ten może być większy niż rozmiar logiczny odpowiednich plików.

Czy pozyskiwanie danych o niskiej jakości może spowodować pogorszenie ogólnego współczynnika kompresji?

Tak— aby DDR uzyskała dobry ogólny współczynnik kompresji danych połknięcia, musi być w stanie deduplikować i skompresować te dane. Istnieją różne rodzaje danych, które mogą temu zapobiec, jak opisano poniżej:

dane wstępnie skompresowane/wstępnie zaszyfrowane:

są to typy danych, które są skompresowane lub zaszyfrowane w systemie klienckim lub aplikacji do tworzenia kopii zapasowych. Może to również obejmować pliki specyficzne dla aplikacji, które są skompresowane lub zaszyfrowane według projektu (na przykład plików multimedialnych) i plików bazy danych, które są skompresowane lub zaszyfrowane lub osadzone obiekty binarne, takie jak pliki multimedialne.

Ze względu na to, w jaki sposób algorytm kompresji lub szyfrowania działa stosunkowo niewielką zmianę w danych bazowych pliku, powoduje zmianę "zgiełku" w pliku. Na przykład klient może pomieścić plik zaszyfrowany 100 Mb, w ramach którego zmodyfikowano 10 KB. Zazwyczaj wynikowy plik będzie identyczny przed modyfikacją i po jej modyfikacji, z wyjątkiem sekcji 10 KB, która uległa zmianie. W przypadku korzystania z szyfrowania, mimo że tylko 10 Kb nieszyfrowanych danych uległo zmianie przed modyfikacją i po jej modyfikacji, algorytm szyfrowania powoduje zmianę całej zawartości pliku.

Gdy takie dane są regularnie modyfikowane i okresowo wysyłane do DDR, efekt ten powoduje, że każda generacja pliku wygląda inaczej niż poprzednie generacje tego samego pliku. W rezultacie każda generacja zawiera unikatowy zestaw segmentów (i linii papilarnych segmentów), dzięki czemu wykazuje niski współczynnik deduplikacji.

Należy również pamiętać, że zamiast wstępnie skompresowanych plików algorytm lz prawdopodobnie nie będzie w stanie dalej kompresować danych segmentu skompresowanego, więc danych nie można skompresować przed zapisaniem na dysku.

Ogólne wskazówki dotyczące prekompresji/wstępnego szyfrowania powodują następujące problemy:

• Dane wstępnie zaszyfrowane: Niski współczynnik deduplikacji, ale dopuszczalny współczynnik kompresji
• Wstępnie skompresowane dane: Niski współczynnik deduplikacji i niski współczynnik kompresji

Gdy te same (bez zmian) wstępnie szyfrowane/wstępnie zaszyfrowane dane są wielokrotnie przytwierdzone przez DDR, współczynnik deduplikacji danych ulega poprawie, ponieważ pomimo użycia algorytmów kompresji lub szyfrowania podczas każdej kopii zapasowej jest widoczny podobny zestaw segmentów (i odcisków palców segmentów).

Jeśli możliwe dane przesyłane do DDR nie powinny być szyfrowane ani skompresowane — może to wymagać wyłączenia szyfrowania lub kompresji na kliencie końcowym lub w ramach odpowiedniej aplikacji do tworzenia kopii zapasowych.

Aby uzyskać pomoc w sprawdzaniu, modyfikowaniu ustawień szyfrowania lub kompresji w określonej aplikacji kopii zapasowej, aplikacji klienckiej lub systemie operacyjnym, skontaktuj się z odpowiednim dostawcą pomocy technicznej.

Pliki multimedialne:

Niektóre typy plików zawierają wstępnie szyfrowane lub wstępnie zaszyfrowane dane według projektu. Oto przykład:

• Pliki PDF
• Niektóre pliki audio (mp3, wma, ogg itd.)
• Pliki wideo (avi, mkv itd.)
• Pliki obrazów (png, bmp, jpeg itd.)
• Pliki specyficzne dla aplikacji (Microsoft Office, Open Office, Libre Office itd.)

Dane w plikach są skompresowane lub szyfrowane przez kodek pliku, w związku z czym powodują te same problemy podczas wczytywania do DDR, jak opisano powyżej w przypadku wstępnie szyfrowanych lub wstępnie zaszyfrowanych danych.

Pliki o wysokiej "unikatowości":

Uzyskanie dobrego współczynnika deduplikacji zależy od wielokrotnego oglądania przez DDR tego samego zestawu segmentów (i linii papilarnych segmentów). Niektóre typy danych zawierają jednak tylko unikatowe dane transakcyjne, które z założenia zawierają "unikatowe" dane.

Jeśli pliki te są wysyłane do DDR, każda generacja kopii zapasowej zawiera unikatowy zestaw segmentów lub linii papilarnych segmentów, w związku z czym widzi obniżony współczynnik deduplikacji.

Przykłady takich plików:

• Dzienniki transakcji bazy danych (na przykład dzienniki archiwów Oracle).
• Dzienniki transakcji Microsoft Exchange

Pierwsza kopia zapasowa "nowego" klienta do DDR może również powodować ten problem (ponieważ dane nie były wcześniej widoczne przez DDR, dlatego odpowiednie segmenty lub odciski linii papilarnych segmentów w kopii zapasowej są unikatowe). Jednak w miarę jak przyszłe generacje tych samych kopii zapasowych są wysyłane do DDR, współczynnik deduplikacji kopii zapasowych zwiększa się, ponieważ liczba segmentów w każdej nowej kopii zapasowej jest unikatowa. W związku z tym oczekuje się, że ogólny współczynnik deduplikacji lub kompresji nowo zainstalowanej pamięci DDR otrzymującej głównie nowe kopie zapasowe zostanie obniżony, ale z biegiem czasu zostanie poprawiony.

Małe pliki:

Małe pliki powodują różne problemy podczas zapisu w DDR. Należą do nich m.in.:

• Nadęcie metadanych — moduł DDR zaczyna utrzymywać wyższą niż oczekiwaną ilość metadanych plików w porównaniu z danymi fizycznymi.
• Słabe wykorzystanie kontenera — zgodnie z projektem (ze względu na układ segmentu informowanego o strumieniu domeny danych lub architekturę SISL — poza zakresem tego dokumentu) kontener o rozmiarze 4,5 Mb na dysku przechowuje tylko dane z jednego pliku. W rezultacie utworzenie kopii zapasowej pojedynczego pliku 10 Kb powoduje na przykład zapisanie co najmniej jednego pełnego kontenera 4,5 Mb dla tego pliku. Może to oznaczać, że w przypadku takich plików pamięć DDR wykorzystuje znacznie więcej przestrzeni postskompresowanego (fizycznego) niż odpowiednia ilość wstępnie skompresowanych (logicznych) danych, co z kolei powoduje negatywny ogólny współczynnik kompresji.
• Niski współczynnik deduplikacji — pliki mniejsze niż 4 Kb (minimalny obsługiwany rozmiar segmentu w DDR) składają się z jednego segmentu, który jest dodawany do 4 Kb. Takie segmenty nie są deduplikowane, ale są zapisywane bezpośrednio na dysku. Może to spowodować, że DDR będzie pomieścić wiele kopii tego samego segmentu (widocznych jako zduplikowane segmenty).
• Niska wydajność kopii zapasowej, przywracania lub czyszczenia — podczas tworzenia kopii zapasowych, przywracania lub czyszczenia występują duże obciążenie podczas przechodzenia z jednego pliku do następnego (ponieważ kontekst używanych metadanych musi zostać przełączony).

Zobacz to:

• Wpływ na wydajność czyszczenia podczas korzystania z małych plików został w pewnym stopniu ograniczony przez wprowadzenie fizycznego czyszczenia lub zbierania śmieci w DDOS 5.5 i nowszych.
• Czyszczenie próby "cofnięcia" słabego wykorzystania kontenera poprzez agregację danych z kontenerów o niskim wykorzystaniu do bardziej szczelnie zapakowanych pojemników podczas fazy kopiowania.
• Czyszczenie próby usunięcia nadmiernej liczby zduplikowanych segmentów podczas fazy kopiowania.

Pomimo powyższych informacji należy unikać używania dużej liczby małych plików lub obciążeń roboczych składających się głównie z małych plików. Lepiej jest połączyć dużą liczbę małych plików w jedno nieskompresowane/niezaszyfrowane archiwum przed utworzeniem kopii zapasowej niż wysłanie małych plików do DDR w stanie macierzystym. Na przykład o wiele lepiej jest utworzyć kopię zapasową pojedynczego pliku 10 Gb zawierającego 1048576 pojedynczych plików 10 Kb niż wszystkie 1048576 pliki indywidualnie.

Nadmierne multipleksowanie przez aplikacje do tworzenia kopii zapasowych:

Aplikacje do tworzenia kopii zapasowych mogą być skonfigurowane do obsługi multipleksowania danych przez strumienie wysyłane do urządzenia kopii zapasowej, czyli danych ze strumieni wejściowych (czyli różnych klientów) wysyłanych w jednym strumieniu do urządzenia kopii zapasowej. Funkcja ta jest głównie używana podczas pisania na fizycznych urządzeniach taśmowych jako:

• Fizyczne urządzenie taśmowe może obsługiwać tylko jeden przychodzący strumień zapisu.
• Aplikacja do tworzenia kopii zapasowych musi utrzymywać wystarczającą przepustowość urządzenia taśmowego, aby zapobiec uruchamianiu, zatrzymywaniu lub przewijaniu taśmy (zwanej również rozświetlaniem wrzeszczu) — jest to łatwiejsze, jeśli strumień przechodzący do urządzenia taśmowego zawiera dane odczytywane z więcej niż jednego klienta.

Jednak w przypadku DDR powoduje to, że pojedynczy plik w DDR zawiera dane z wielu klientów przeplatanych w dowolnej kolejności lub rozmiarach fragmentów. Może to spowodować obniżenie współczynnika deduplikacji, ponieważ DDR może nie być w stanie dokładnie zauważyć zduplikowanych segmentów z każdej generacji kopii zapasowej danego klienta. Ogólnie rzecz biorąc, im mniejsza szczegółowość multipleksowania, tym gorszy wpływ na współczynnik deduplikacji.

Ponadto wydajność przywracania może być niska, ponieważ w celu przywrócenia danych niektórych klientów DDR musi odczytać wiele plików lub kontenerów, w których większość danych w plikach lub kontenerach jest zbędna w odniesieniu do innych kopii zapasowych klientów.

Aplikacje do tworzenia kopii zapasowych nie muszą używać multipleksowania podczas zapisu do DDR, ponieważ DDR obsługują większą liczbę strumieni przychodzących niż fizyczne urządzenia taśmowe, przy czym każdy strumień może pisać ze zmienną prędkością. W rezultacie multipleksowanie przez aplikacje do tworzenia kopii zapasowych powinno być wyłączone. Jeśli po wyłączeniu multipleksowania wpływa na wydajność kopii zapasowej, wykonaj następujące czynności:

• Aplikacje do tworzenia kopii zapasowych korzystające z CIFS, NFS lub OST (DDBoost) powinny zwiększać liczbę strumieni zapisu (aby można było zapisać więcej plików równolegle na DDR).
• Środowiska korzystające z VTL powinny dodawać dodatkowe dyski do DDR, ponieważ każdy dysk umożliwia obsługę dodatkowego strumienia zapisu równoległego.

Jeśli wymagana jest pomoc w wyłączaniu multipleksowania lub chcesz omówić zalecaną konfigurację multipleksowania dla konkretnej aplikacji do tworzenia kopii zapasowych, skontaktuj się z zakontraktowanym dostawcą pomocy technicznej.

Aplikacje do tworzenia kopii zapasowych wkładające nadmierne znaczniki taśmowe:

Niektóre aplikacje do tworzenia kopii zapasowych mogą wprowadzać powtarzające się struktury danych do strumienia kopii zapasowych, znanego jako "znaczniki". Znaczniki nie reprezentują danych fizycznych w kopii zapasowej, ale są używane przez aplikację do tworzenia kopii zapasowych jako system indeksowania lub pozycjonowania.

W niektórych okolicznościach włączenie znaczników do strumienia kopii zapasowej może obniżyć współczynnik deduplikacji, na przykład:

• W pierwszej generacji kopii zapasowej znajdowało się 12 Kb danych, które były ciągłe — zostało to rozpoznane przez DDR jako pojedynczy segment.
• Jednak w drugiej generacji kopii zapasowej te same 12 Kb danych jest dzielone przez dodanie znacznika kopii zapasowej, który może być reprezentowany przez 6 Kb danych, znacznik kopii zapasowej, 6 Kb danych.
• W rezultacie segmenty utworzone w drugiej generacji kopii zapasowej nie są zgodne z segmentami wygenerowanymi w pierwszej generacji kopii zapasowej, dlatego nie deduplikują się prawidłowo.

Im bardziej rozmieszczone są znaczniki, tym gorszy wpływ na współczynnik deduplikacji (na przykład aplikacja do tworzenia kopii zapasowych wkładająca znaczniki co 32 Kb powoduje więcej problemów niż aplikacja do tworzenia kopii zapasowych wkładająca znaczniki co 1 Mb).

Aby uniknąć tego problemu, DDR wykorzystuje technologię rozpoznawania znaczników, która umożliwia:

• Wykonaj kopię zapasową znaczników, które mają zostać usunięte w sposób przezroczysty ze strumienia kopii zapasowej podczas pobierania kopii zapasowej.
• Tworzenie kopii zapasowej znaczników, które mają być ponownie wprowadzone do strumienia kopii zapasowych podczas przywracania kopii zapasowej

Pomaga to zapobiec fragmentacji danych lub segmentów przez znaczniki kopii zapasowych i poprawia współczynnik deduplikacji odpowiednich kopii zapasowych.

Aby w pełni wykorzystać tę technologię, ważne jest, aby moduł DDR mógł prawidłowo rozpoznawać wsuwane znaczniki do strumieni kopii zapasowych. Moduł DDR wyszukuje znaczniki w zależności od ustawienia opcji "typ znacznika", na przykład:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Znacznik typu auto
...


-------------------------------- -------- należy pozostawić ustawienie "auto", ponieważ umożliwia to automatyczne dopasowyowanie najczęściej spotykanych typów znaczników przez DDR. Jeśli system gromadzi dane tylko z jednej aplikacji do tworzenia kopii zapasowych, która wstawia znaczniki, może wystąpić korzyść z określenia określonego typu znacznika, czyli:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Zobacz, że:

• Jakiekolwiek korzyści dla wydajności wynikające z wyboru określonego typu znacznika mogą być minimalne.
• Wybranie nieprawidłowego typu znacznika może spowodować znaczne dodatkowe pogorszenie wydajności kopii zapasowych lub przywracania danych i współczynnika deduplikacji.

W rezultacie Data Domain zazwyczaj zaleca pozostawienie typu znacznika ustawionego na "auto". Aby uzyskać więcej informacji na temat modyfikowania typu znacznika, skontaktuj się z zakontraktowanym dostawcą pomocy technicznej.

W przypadku systemów pobieranie danych z aplikacji korzystających z znaczników kopii zapasowych, które nie są rozpoznawane przez technologię automatycznej obsługi znaczników (takich jak produkty z oprogramowania BridgeHead), należy skontaktować się z zakontraktowanym dostawcą pomocy technicznej, który może następnie współpracować z działem pomocy technicznej Data Domain w celu określenia wymaganych ustawień na DDR w celu wykrycia niestandardowego znacznika.

Wskaźniki "niskiej jakości" danych odbieranych przez DDR:

W poniższej tabeli przedstawiono oczekiwane współczynniki deduplikacji i kompresji dla różnych typów danych wymienionych powyżej. Lista ta nie jest wyczerpująca i oczywiście mogą wystąpić pewne różnice w dokładnych danych, które są widoczne w danym systemie ze względu na obciążenie robocze lub dane pozyskowane przez DDR:
 

Kompresja globalna	Kompresja lokalna	Prawdopodobna przyczyna
Niski (1x – 4x)	Niski (1x – 1,5x)	Wstępnie skompresowane lub zaszyfrowane dane
Niski (1x – 2x)	Wysoki (>2x)	Unikatowe, ale kompresowalne dane, takie jak dzienniki archiwów baz danych
Niski (2x –5x)	Wysoki (>1,5x)	Nie wykryto znaczników, a także wysoką szybkość zmiany danych lub multipleksowanie strumienia.
Wysoki (>10x)	Niski (<1,5x)	Kopie zapasowe tych samych skompresowanych lub zaszyfrowanych danych. Jest to rzadko spotykane.

Czy istnieją pewne czynniki dotyczące DDR, które mogą mieć wpływ na ogólny współczynnik deduplikacji?

Tak. Istnieje kilka czynników, które mogą spowodować zachowanie starych/zbędnych danych na dysku w DDR, co powoduje wzrost ilości miejsca na dysku postkompresowanym (fizycznym) i spadek ogólnego współczynnika kompresji. Takie czynniki zostały omówione poniżej.

Niepowodzenie regularnego czyszczenia systemu plików:

Czyszczenie systemu plików jest jedynym sposobem fizycznego usunięcia starych/nadpłatnych danych z dysku, do których nie są już odwołania przez pliki w DDR. W rezultacie użytkownik może usunąć kilka plików z systemu (powodując spadek wykorzystania wstępnie skompresowanego), ale nie uruchamia się w sposób czysty (pozostawienie wysokiego wykorzystania postcompressed/physical). Powoduje to spadek ogólnego współczynnika kompresji.

Data Domain zaleca zaplanowanie czyszczenia do uruchomienia w regularnych odstępach czasu w następujący sposób:

• Normalna DDR: Raz w tygodniu
• DDR z rozszerzonym przechowywaniem: Co dwa tygodnie

Czyszczenie nie powinno być uruchamiane więcej niż raz w tygodniu, ponieważ może to spowodować problemy z fragmentacją danych na dysku, co przejawia się niską wydajnością przywracania/replikacji.

Nadmierna liczba starych migawek w systemie:

DDR mogą tworzyć migawki m-drzew, które reprezentują zawartość m-drzewa w momencie tworzenia migawki. Należy jednak pamiętać, że pozostawienie starych migawek w systemie może spowodować wzrost wykorzystania postskompresowanego/fizycznego, powodując spadek ogólnego współczynnika kompresji. Oto przykład:

• M-drzewo zawiera wiele plików (dlatego wstępnie skonfigurowane wykorzystanie jest wysokie).
• Utworzono migawkę m-drzewa.
• Wiele plików jest usuwanych (powodując spadek wykorzystania prekompresowanego).
• Czyszczenie systemu plików jest uruchamiane — należy jednak pamiętać, że minimalna ilość miejsca na dysku twardym jest zwalniana, ponieważ kopia usuniętych plików pozostaje w migawce m-drzewa, co oznacza, że danych, do których odnoszą się te pliki, nie można usunąć z dysku.
• W rezultacie wykorzystanie postkompresowane/fizyczne pozostaje wysokie

Domena danych zaleca, aby w przypadku korzystania z migawek m-drzewa (na przykład do odzyskiwania danych po przypadkowym usunięciu danych) zarządzano nimi przy użyciu zautomatyzowanych harmonogramów migawek, takich jak migawki tworzone w regularnych odstępach czasu ze zdefiniowanym okresem ważności (czas przed automatycznym usunięciem migawki). Ponadto okres ważności powinien być jak najkrótszy (jednak może to oczywiście zależeć od przypadku użycia migawek lub poziomu ochrony zapewnianych przez te migawki). Zapobiega to gromadzeniu starych migawek z długim okresem ważności.

Dodatkowe informacje na temat pracy z migawkami i harmonogramami migawek są dostępne w następującym artykule: Domena danych — zarządzanie harmonogramami migawek

Nadmierne opóźnienie replikacji:

Replikacja natywnej domeny danych używa dziennika replikacji lub migawek m-drzewa (w zależności od typu replikacji) do śledzenia plików lub danych oczekujących na replikację do zdalnej DDR. Opóźnienie replikacji jest koncepcją, że replika pozostaje w tyle za zmianami w źródłowej DDR. Może to nastąpić z powodu różnych czynników, takich jak:

• Wyłączanie kontekstów replikacji
• Niewystarczająca przepustowość sieci między DDR
• Częste rozłączanie sieci.

Duże opóźnienie replikacji może spowodować, że dziennik replikacji będzie nadal zawierać odwołania do plików, które zostały usunięte ze źródłowej DDR lub starych lub starych migawek m-drzewa na źródłowych i docelowych DDR. Zgodnie z powyższym opisem danych, do których odwołania są te migawki (lub dziennik replikacji), nie można fizycznie usunąć z dysku w DDR, nawet jeśli odpowiednie pliki zostały usunięte z systemu. Może to spowodować zwiększenie wykorzystania DDR po kompresji lub fizycznej, co powoduje pogorszenie się współczynnika deduplikacji.

Jeśli DDR ma duże wykorzystanie, a jest to uważane za spowodowane opóźnieniem replikacji, skontaktuj się z zakontraktowanym dostawcą pomocy technicznej, aby uzyskać dalszą pomoc.

Czy w pamięci DDR występują zmiany konfiguracji lub pewne czynniki, które mogą zwiększyć ogólny współczynnik kompresji?

Tak— usunięcie lub rozwiązanie problemów, które zostały omówione wcześniej w tym dokumencie, powinno umożliwić modułowi DDR zwiększenie ogólnego współczynnika kompresji w czasie. Istnieją również różne czynniki lub obciążenia robocze modułu DDR, co może prowadzić do zwiększenia współczynnika deduplikacji. Zwykle obejmują one:

• Zmniejszenie ilości miejsca na dysku twardym używanym przez pliki w DDR (na przykład zwiększenie agresywności algorytmu kompresji używanego przez DDR)
• Nagłe zwiększenie ilości wstępnie skompresowanych (logicznych) danych w DDR bez odpowiedniego wzrostu wykorzystania postcompressed/physical

Modyfikacja algorytmu kompresji:

Domyślnie DDR kompresuje dane zapisywane na dysku przy użyciu algorytmu lz . Jak wspomniano wcześniej, LZ jest używany, ponieważ ma stosunkowo niskie obciążenie w zakresie procesora wymaganego do kompresji lub dekompresji, ale wykazuje uzasadnioną skuteczność w zmniejszaniu rozmiaru danych.

Możliwe jest zwiększenie agresywności algorytmu kompresji w celu zapewnienia dalszych oszczędności wykorzystania postkompresowanego lub dysku twardego (w rezultacie poprawy ogólnego współczynnika kompresji). Obsługiwane algorytmy kompresji, w kolejności od niskiego do wysokiego, są następujące:

• Lz
• gzfast
• Gz

Ogólne porównanie poszczególnych algorytmów jest następujące:

• LZ w porównaniu z gzfast zapewnia o ok. 15% lepszą kompresję i korzysta z 2 procesorów.
• LZ w porównaniu z gz zapewnia o ok. 30% lepszą kompresję i zużywa procesor 5x.
• Gzfast w porównaniu z gz zapewnia kompresję o ok. 10–15%.

Można również całkowicie wyłączyć kompresję (określić algorytm braku), jednak nie jest ona obsługiwana w systemach klienta i służy wyłącznie do testowania wewnętrznego.

Zgodnie z powyższą tabelą algorytm kompresji jest bardziej agresywny, tym więcej procesorów jest wymaganych podczas kompresji lub dekompresji danych. Z tego względu zmiany bardziej agresywnego algorytmu należy wprowadzać tylko w systemach, które są lekko ładowane w normalnym obciążeniu roboczym. Zmiana algorytmu w mocno obciążonych systemach może doprowadzić do skrajnego pogorszenia wydajności kopii zapasowych lub przywracania oraz ewentualnych błędów systemu plików lub ponownego uruchomienia (powodując awarię DDR).

Aby uzyskać więcej informacji na temat zmiany typu kompresji, zapoznaj się z następującym artykułem: Wpływ konwersji na kompresję GZ

systemu data domain i wydajności czyszczeniaZe względu na potencjalny wpływ zmiany algorytmu kompresji zaleca się, aby klienci zainteresowani tą usługą kontaktowali się ze swoim zakontraktowanym dostawcą pomocy technicznej w celu omówienia zmiany przed kontynuowaniem.

Korzystanie z funkcji fastcopy systemu plików:

DDR umożliwiają użycie polecenia "file system fastcopy", aby szybko skopiować plik (lub drzewo katalogów). Ta funkcja tworzy plik poprzez klonowanie metadanych istniejącego pliku (lub grupy plików), tak aby nowe pliki nie były fizycznie podłączone do oryginalnego pliku, odnoszą się do dokładnie tych samych danych na dysku co oryginalny plik. Oznacza to, że niezależnie od rozmiaru oryginalnego pliku nowy plik zużywa niewiele miejsca na dysku (ponieważ deduplikuje się doskonale w stosunku do istniejących danych).

W wyniku tego zachowania szybko wzrasta, ale postcompressed/physical utilization of the DDR (Logiczny) rozmiar danych na DDR szybko wzrasta, ale postcompressed/physical utilization of the DDR remains static.

Na przykład, następujące DDR ma następujące wykorzystanie (wskazujący ogólny współczynnik kompresji ~1,8x):

warstwa aktywna:
gib rozmiaru zasobów używany GiB Avail GiB Użyj% czyszczalnego GiB*
---------------- -------- -------- --------- ---- --------------
/danych: przed comp - 12.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Zawiera duży plik (/data/col1/backup/testfile):

!!! DDVE60_JF DANE SĄ ZAGROŻONE !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 29 lipca 04:20 /data/col1/backup/testfile

Plik jest kilkakrotnie

kopiowany: sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/coll1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data/miejsce docelowe col1/backup/testfile /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/coll1/backup/testfile destination /data/coll1/backup/testfile_copy3

Powoduje to zwiększenie prekompresowanego wykorzystania w celu niewielkiej zmiany wykorzystania po kompresji:

warstwa aktywna:
gib rozmiaru zasobów używany GiB Avail GiB Użyj% czystego GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

W rezultacie DDR pokazuje teraz ogólny współczynnik kompresji wynoszący ~3,1x.

Jak wspomniano powyżej, statystyki kompresji kopii pokazują, że deduplikują perfekcyjnie:

sysadmin@DDVE60_JF# filesys pokazują kompresję /data/coll1/backup/testfile_copy1
Łączna liczba plików: 1;  bajtów/storage_used: 21331976.1
Oryginalne bajty:        3 242 460 364
skompresowanych na całym świecie:                    0
Lokalnie skompresowane:                    0
metadanych:                  152

Funkcja fastcopy nie może być wykorzystana do poprawy ogólnego współczynnika kompresji poprzez zmniejszenie fizycznego wykorzystania pamięci DDR, jednak może to być przyczyną wysokiego ogólnego współczynnika kompresji (zwłaszcza w środowiskach, które intensywnie wykorzystują szybkość, np. Avamar 6.x).