Avamar-Data Domain: Vysoké využití DD v cíli: Analýza a doporučené postupy

Cílový systém Data Domain zobrazuje vyšší využití než zdrojový systém Data Domain.

Z pohledu systému Avamar:

Rollback
V případě rollbacku na zdrojovém systému Data Domain může cílový systém Data Domain v závislosti na době rollbacku obsahovat další dny dat. Tato nesrovnalost bude existovat, dokud nevyprší platnost dalších záloh v cílovém umístění.

Příklad: DD1 se replikuje na DD2. Protože rollback je 2 dní zpět, vidíme, že ve zdroji jsou 3 zálohy, ale do cíle je replikováno pět záloh.

Částečné replikace
V případě, že replikace nebyla úspěšně dokončena, jsou data, která již byla replikována, uložena po dobu minimálně 7 dnů a vyčištěna čištěním Data Domain.  Částečné replikace obsahují data a otisky, které umožňují rychlejší opakovaný pokus o replikaci dat.
Režie částečné replikace může být stejně vysoká jako počet replikovaných dat, pokud replikace selže těsně před dokončením.

Rozdíl v uchovávání
V konfiguraci serveru Avamar je možné nastavit, aby repliky na cílovém serveru byly uchovány déle než zdroj. To způsobí rozdíly ve využití kapacity.

Rozdíly v konfiguraci Avamar
Zálohování checkpointu na serveru Avamar může být výrazně velké. Pokud je nakonfigurováno pouze na cílovém systému Avamar, zvýší se využití systému Data Domain v cílovém zařízení.

Z pohledu systému Data Domain:

Otisk prstu.

Když jsou data během replikace odeslána do systému Data Domain, dochází k jejich deduplikaci. Nejprve se odešle otisk dat do cílového systému Data Domain pro kontrolu, zda cíl obsahuje data.

• Pokud se v systému Data Domain zobrazí zpráva, že je zde otisk prstu, není nutné data znovu odesílat.

• Pokud systém Data Domain neodpoví, že otisk nebyl nalezen, znamená to, že:

  • Otisk zde není.

  • Cílový systém Data Domain má otisk, ale přesto chce odeslat data, aby se vylepšila speciální oblast v systému Data Domain.

  • Systém Data Domain je zaneprázdněný a nechce dokončit celé vyhledávání.

Pokud jsou do systému Data Domain odeslána duplicitní data, budou data během čištění deduplikována odstraněním přebytečných kopií dat.
Cílový systém Data Domain bude mít vyšší využití, ale odchylka by neměla být velká.

Režie metadat.
Každý zálohovaný soubor se dodává s metadaty informací o souboru a obsahuje také otisky pro každý soubor.

Příklad: U 1TB souboru jsou náklady na využití 0,3 % velikosti souboru.

U průměrného bloku dat 8 kB jsou metadata 82 B.  To je přibližně 0,01 % režie pro kapacitu po zpracování.
Tato režie se díky integraci softwaru Avamar dále zvyšuje, protože Avamar kombinuje zálohy, aby při každém dokončení zálohování získal syntetickou kompletní zálohu z přírůstkové zálohy.
Také můžeme pozorovat, že režie metadat se zvyšuje, pokud jsou zálohy přeskočeny nebo jsou data replikována mimo pořadí.
Jediné zálohy, které nevytvářejí tyto režijní náklady, jsou zálohy virtuálních počítačů. Náklady na metadata jsou minimalizovány.

Příklad: Když je záloha replikována mimo pořadí, vytváří v cíli zálohu L0, která má mnohem větší zátěž metadat než přírůstková. Řekněme, že máme 5 dní záloh.

Replikace od nejstarší po nejnovější:

První replikace bude L0, všechny následující budou přírůstkové.
1xL0 + 4xInc

Replikace od nejnovější po nejstarší:

Replikace přeskočí zálohu:

Sledování souborů
Systém Data Domain musí vědět, jak vytvořit každý soubor z deduplikovaných bloků. V případě, že systém Data Domain tyto informace nemá, musí je znovu vytvořit a znovu vytvořit řetězec otisků. To může vést k výraznému zvýšení kapacity.
Existují dva scénáře, které mohou v cílovém systému Data Domain způsobit výrazné zvýšení kapacity:

Příklad: Pokud je v systému DNS nastaven cílový system Data Domain s více IP adresami a IP adresy jsou distribuovány v kruhovém dotazování, zdrojový systém Data Domain se pokaždé připojí k různým IP adresám. Kopie dat odeslaných včera nebude rozpoznána a bude odesláno více dat, což také zvýší náklady na metadata.

K tomuto problému může dojít, když je po dokončení vrácení serveru Avamar zpět SFS_BFT_ENABLED ponecháno jako false.

To může vést k velmi velkému nesouladu.  Po vypršení platnosti zálohy bude místo znovu uvolněno.

In-line deduplikace
Systém Data Domain požádá o duplicitní data až do 6 % logické velikosti dat za účelem optimalizace jejich in-line deduplikace.

Rozdíl v deduplikaci a kompresi.
Systémy Data Domain provádí vlastní deduplikaci a kompresi dat na svém místním úložišti nezávisle a podle toho, jak jsou cílová data uložena, nebude to mít stejný vliv na využití.

Čištění systému Data Domain
Pokud se čištění zdrojových a cílových systémů Data Domain spouští v různých dnech nebo pokud je na některém ze systémů Data Domain spuštěno čištění častěji nebo déle, bude existovat rozdíl ve využité kapacitě.

Doporučené postupy:

Protože mezi dvěma systémy Data Domain, zdrojem a cílem, existují nesrovnalosti ve využití, existují osvědčené postupy, které mohou pomoci rozdíl minimalizovat:

1. Minimalizujte možnost rollbacku tím, že vyřešíte chyby kontroly hfscheck a selhání hardwaru ihned po jejich výskytu.

2. Ujistěte se, že se replikace úspěšně dokončí. Pokud máte přetrvávající problém s dokončením replikace, obraťte se na podporu společnosti Dell Technologies a zkontrolujte konfiguraci.

3. Pokud potřebujete zachovat oba systémy Data Domain při podobném využití, zachovejte stejné uchování na zdrojových a cílových kopiích záloh a ujistěte se, že je zálohování checkpointu nastaveno na obou serverech Avamar stejně.

4. Ujistěte se, že replikace jsou vždy od nejstarších po nejnovější a že nejsou vynechány žádné zálohy.

5. Pokud je systém Data Domain nakonfigurován s více IP adresami, ujistěte se, že IP adresy nejsou distribuovány v režimu kruhového dotazování.

6.  Nastavte čištění na obou systémech Data Domain, zdrojovém i cílovém, na stejný den a stejný čas.

7. Mějte SFS_BFT_ENABLED nastavenou na true.  To musí být povoleno technickou podporou (Založení servisního požadavku & reference KB# – 182755)