Avamar: Replikační pár zobrazuje různé úrovně využití kapacity. Jak prošetřit příčiny.

Příčiny a možné důvody rozdílů mezi hodnotami využití serveru:

Logické nebo fyzické rozdíly mezi mřížkami:

• Různý počet datových uzlů ve zdrojové a cílové mřížce.
• Datové uzly každé mřížky mají různé konfigurace disků.
• Adekvátně vyvážená distribuce prokládání napříč datovými uzly v rámci každého systému (s přesností na 2 %).
• Požadavky na úložiště a paritu se u jednotlivých verzí systému Avamar liší. Pokud se liší zdrojová a cílová verze softwaru, může dojít k rozdílu ve využití.
• Úroveň disku serveru Avamar jen pro čtení se může u jednotlivých mřížek lišit.   
• Jedna mřížka může být nakonfigurována pro paritu RAIN, druhá nemusí.

Konfigurace replikace:

• Zálohy replikované do cílového systému mohou mít v porovnání se zdrojem jiné zásady uchovávání informací. Další informace najdete v příznaku expiredelta. Případně mohou replikované zálohy pokrývat pouze určité časové období. Například poslední 4 týdny záloh ze zdroje.
• Replikace může být nakonfigurována tak, aby replikovala pouze podmnožinu klientů ze zdrojového do cílového systému. Zkontrolujte, zda jsou použita nastavení pro „zahrnutí“ či „vyloučení“.
• Klienti a jejich přidružené zálohy mohli být odstraněni ze zdrojového systému. Odstranění klienta nebo záloh na zdroji neodebere stejné zálohy z cílového systému. Zálohy zůstanou v cíli, dokud nevyprší jejich platnost podle nastavení uchovávání.
• Zásady uchovávání informací je možné změnit pro zálohy nebo klienty ve zdrojovém systému. Změna zásad uchovávání informací má vliv pouze na nové zálohy. Nové zálohy se replikují do cíle a dodržují aktualizované zásady uchovávání informací. Zálohy, které v cíli již existují, si zachovají zásady uchovávání informací, které na ně byly použity při replikaci.

Předchozí aktivita správy kapacity:

• Není neobvyklé, že si zákazníci všimnou, že se jeden ze systémů páru replikace Avamar blíží naplnění kapacity a poté podniknou kroky ke snížení kapacity. Pamatujte, že pár replikace Avamar se skládá ze dvou nezávisle spravovaných systémů. Pokud provedete nějaké akce na jednom systému, je nutné je provést také na druhém. 
• Pokud odstraníte zálohy nebo snížíte počet uchování ve zdrojovém systému, je nutné provést stejné změny i v cíli. Nejlepší způsob, jak spravovat kapacitu tímto způsobem, je pomocí skriptu modify-snapups. Tento proces lze spustit na obou serverech Avamar se stejnými možnostmi pro úpravu nebo odstranění zálohy.  

Odlišná struktura prokládání (například více paritních prokládání v jednom systému):

• Jelikož jsou oba systémy Avamar nezávislé, mohou mít různé struktury prokládání. Systémy s více uzly mohou vykazovat rozdíly, protože k ochraně dat používají paritní prokládání. V závislosti na historii kapacity obsahují dva systémy s více uzly stejné zálohy, ale jeden může mít více paritního prokládání než druhý.
• Stejně jako u pravidelného prokládání i paritní prokládání po vytvoření vždy zůstává v systému. Na rozdíl od běžného prokládání vždy spotřebovává pevně dané množství místa v rámci serveru Avamar. To platí i v případě, že bezpečné prokládání skupiny parity neobsahuje žádná data. Sběr odpadu nemá na toto chování žádný vliv.
• Cílový systém replikace je nepřímo chráněn před závažnými problémy s kapacitou ve zdroji replikace. K této situaci však může dojít na libovolném systému, pokud je kapacita jednoho z nich špatně spravována.
• Související článek: Systém Avamar vykazuje až ~30% využití i po odstranění všech záloh a provedení funkce Garbage Collection

Zálohy jsou stále ve stavu MC_DELETED:

• Jedním ze vzácných případů je, že dojde k odstranění klienta ze zdroje, ale jeho zálohy jsou zachovány. To může mít za následek, že zdroj bude mít vyšší využití než cíl, kde by se očekávalo, že zálohy přirozeně vyprší. Použití skriptu dump_root_hashes.rb s možností backupcompare pomáhá tuto situaci zkontrolovat.

Data v cílovém systému z nereplikovaných záloh:

• Pokud systém provádí replikaci *pouze jedním směrem*, zkontrolujte na cíli, zda žádní klienti nejsou mimo doménu /REPLICATE a MC_SYSTEM.

Další chování:

• Úlohy replikace se nemusí spolehlivě dokončit. Data odeslaná do cíle mohou „zaostávat“ za zdrojem o několik dní.
• Oba systémy obsahují stejné množství deduplikovaných dat, ale množství paritní režie na každém z nich se liší. Dochází k tomu za následujících podmínek: 
  • Zdrojový systém Avamar je téměř plný. 
  • Ze zdrojového systému se odstraní mnoho záloh, aby se snížila jeho úroveň kapacity. 
  • Replikace deduplikovaných dat pak probíhá ze zdrojového systému na cílový. 
  • Množství deduplikovaných dat je v obou systémech stejné.
  • Zdrojový systém zpočátku ukládá více paritní režie než cílový.
• Replikace nekopíruje fyzické prokládání ze zdrojové do cílové mřížky. Místo toho může cílová mřížka sama určit, kam se uloží prokládání bloky dat.
• Někdy mohou cílové systémy Avamar ukládat data efektivněji než zdrojová síť, kde jsou data původně zálohována.

Vysvětlení prostředí replikace:

• Poznamenejte si úplný název hostitele zdrojové mřížky Avamar.
• Zkontrolujte konfiguraci replikace dotčených systémů, abyste zjistili, které systémy replikují jaká data a kam. 
  • Může pomoci nakreslit si schéma, pokud je prostředí složitější než u replikace z jednoho serveru Avamar na druhý.
• Pokud se zdroj integruje se systémem Data Domain (DD), zjistěte, zda se obavy zákazníka týkají záloh replikovaných mezi zařízeními DD.
• Poznamenejte si úplný název hostitele cílové sítě Avamar a všech přidružených zařízení DD, která přijímají replikované zálohy.

Kontrola celkového stavu a situace mřížky:

• Spusťte proaktivní skript kontroly na obou mřížkách, pořiďte si kopii souboru hc_results.txt a zkontrolujte ji, abyste pochopili celkovou situaci v systému. 

Jak závažný je rozdíl v kapacitě?

• Zákazník by měl poskytnout snímek obrazovky toho, co ho vede k domněnce, že existuje rozdíl v zaplnění kapacity mezi zdrojovým a cílovým systémem.
• Pokud je rozdíl v kapacitě menší než 5 %, nepovažovali bychom to za důvod k obavám.
• Informace o úrovních kapacity serveru Avamar a (pokud je integrovaná platforma Data Domain) kapacity metadat naleznete v uživatelském rozhraní Avamar Administrator.
• Uvědomte si, jak funguje zobrazení kapacity uživatelského rozhraní (popsáno v části Řídicí panel uživatelského rozhraní Avamar ve verzi 7.2 a novějších zobrazuje využití metadat namísto využití serveru Avamar).
• V obou systémech spusťte následující příkaz. Hodnota využití serveru udává celkovou úroveň kapacity serveru Avamar (nikoli však systému Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Zkontrolujte, zda je v obou mřížkách stejný hardware:

• Rozdíly v kapacitě má smysl porovnávat pouze u stejných systémů. 
• Pomocí výstupu proaktivní kontroly si poznamenejte typ uzlů v systému.
• Následující příkaz zobrazí celkové množství, velikost a zaplnění místa na fyzických uzlech:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Tento výstup usnadňuje určení počtu a velikosti uzlů v systému. Mají 23,3 / 3 = ~7,8 TB. 
• Tomu musí odpovídat počet a velikost oddílů pevného disku v každém uzlu.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• S těmito informacemi zkontrolujte následující:

Zkontrolujte verzi a konfiguraci softwaru:

• Pomocí výstupu příkazu status.dpn porovnejte verzi softwaru Avamar v jednotlivých systémech.
• U systémů s více uzly ověřte, zda jsou oba nakonfigurovány s paritou RAIN podle částí Avamar – Jak zjistit, zda server je či není typu RAIN.
• Zkontrolujte a porovnejte parametry konfigurace serveru Avamar související s kapacitou obou systémů. Například:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Zkontrolujte vyvážení prokládání:

• Zkontrolujte výstup příkazu status.dpn a poznamenejte si celkový počet prokládání na každém datovém uzlu. Počet prokládání je uveden v závorkách (např onl:xxx). 
• Mezi celkovým počtem prokládání na každém datovém uzlu by měl být rozdíl menší než 2 %.  

Kontrola, zda funkce Garbage Collection funguje správně v obou systémech:

• Pokud funkce Garbage Collection neběží konzistentně a efektivně, neodebere data, jejichž platnost vypršela. Systém hlásí vyšší využití kapacity, než byste očekávali. 
  • Informace najdete v článku Cesta řešení GC v poznámkách s omezeným přístupem.  

Potvrzení, že se replikace úspěšně dokončí:

• Ujistěte se, že všechny úlohy replikace ze zdroje do cíle byly úspěšně dokončeny. Pokud tomu tak není, je možné, že stále existují data, která je třeba replikovat ze zdroje na cíl.  

Kontrola konfigurace replikace:

• Zkontrolujte, zda konfigurace replikace (v uživatelském rozhraní, rozhraní příkazového řádku nebo protokolech) neobsahuje některý z následujících příznaků:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Kontrola míry příjmu a odstranění dat u obou systémů:

• Spusťte příkaz proactive_check.pl --capacity na obou systémech a porovnejte míry příjmu zdrojového i cílového systému.
• Pokud je cílem čistě cílový systém a přijímá VŠECHNY zálohy ze zdroje, jeho míra příjmu dat by měla úzce sledovat rychlost příjmu dat zdroje.
• Sloupce Avamar NEW nebo DDR NEW zobrazují, kolik nových dat se do těchto systémů přidává.
• Věnujte také velkou pozornost sloupcům „removed“, „mins“ a „pass“, abyste porozuměli chování funkce Garbage Collection v obou systémech.
• Tyto informace poskytují jasný přehled o tom, co se děje v obou systémech.
• Další informace o interpretaci výstupu naleznete v části Avamar: Jak spravovat kapacitu pomocí skriptu capacity.sh  

Výpis seznamu záloh v každém systému:

• Skript dump_root_hashes.rb je nástroj, který pomáhá porovnat rozdíl v zálohách uložených mezi zdrojem Avamar a cílovým systémem. To platí i v případě, že zálohy jsou hostovány v úložišti Data Domain.   
• Viz článek Avamar: Avamar: Jak pomocí skriptu dump_root_hashes.rb vygenerovat seznam klientů a záloh, kde najdete informace o stažení nástroje a případech použití, včetně porovnání obsahu dvou systémů Avamar.
  • Spusťte nástroj. Zkontrolujte, zda jsou počty záloh na všech klientech konzistentní. Věnujte pozornost rozdílům ±2.  
• Jak je popsáno v části Příčiny, asymetrická správa kapacity vede k rozdílům mezi dvěma systémy. Zkontrolujte výstup a zjistěte, zda by se mohlo jednat o tento případ.
• Také:
  • Zkontrolujte, zda cíl obsahuje data v cílovém systému z nereplikovaných záloh.
  • Zkontrolujte, zda zdroj obsahuje data, která nebyla replikována do cíle.  

Kontrola odlišných struktur prokládání (například více paritních prokládání v jednom systému):

• Jelikož jsou oba systémy Avamar nezávislé, mohou mít různé struktury prokládání. Systémy s více uzly mohou vykazovat rozdíly, protože k ochraně dat používají paritní prokládání. V závislosti na historii kapacity obsahují dva systémy s více uzly stejné zálohy, ale jeden může mít více paritního prokládání než druhý.  
• Stejně jako u pravidelného prokládání i paritní prokládání po vytvoření zůstává v systému. Na rozdíl od běžného prokládání vždy zabírá pevně dané místo v systému Avamar, i když jeho bezpečné prokládání skupiny parity neobsahuje žádná data. Sběr odpadu nemá na toto chování žádný vliv.
• Cílový systém replikace je nepřímo chráněn před závažnými problémy s kapacitou ve zdroji replikace. K této situaci však může dojít na libovolném systému, pokud je kapacita jednoho z nich špatně spravována.
• Související článek:  Systém Avamar vykazuje až ~30% využití i po odstranění všech záloh a provedení funkce Garbage Collection  

Zálohy jsou stále ve stavu MC_DELETED:

• Jedním ze vzácných případů je, že dojde k odstranění klienta ze zdroje, ale jeho zálohy jsou zachovány. To může mít za následek, že zdroj bude mít vyšší využití než cíl, kde by se očekávalo, že zálohy přirozeně vyprší. Použití skriptu dump_root_hashes.rb s možností backupcompare by mělo pomoci tuto situaci zkontrolovat.