Cesta řešení pro Avamar GSAN nebo kapacitu uživatele

Počáteční koncepty a pochopení kapacity operačního systému (OS) naleznete v článku Avamar: Obecné školení o kapacitě – postup řešení

Často je nejjednodušší uvažovat GSAN o kapacitě jako o prostoru a využití pro zálohování klientů.

• Základní znalost deduplikace
• Základní znalost kontrolního bodu, ověření kontrolního bodu (hfscheck) a procesu Garbage Collection a důležitost každého z nich.
• Rozdíl mezi GSAN (nebo uživatelskou) kapacitou a kapacitou operačního systému
• Míra změn
• Ustálený stav

• Selhání zálohování nebo replikace, když se stav přístupu k mřížce změní na „režim správce“

  • Úloha zálohování klienta může selhat se zprávou podobnou této:  „avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Automatické vypnutí plánovače zálohování (dokud jej někdo nepotvrdí a nevymaže)

• 80 % – Upozornění na kapacitu
• 95 % – Bylo dosaženo limitu kontroly stavu (to někdy může zakázat plánovač zálohování, alespoň dokud nedojde k ručnímu potvrzení)
• 100 % – Bylo dosaženo limitu serveru pouze pro čtení (mřížka přejde do režimu správce)

1. Díky deduplikaci potřebuje software Avamar ukládat a uchovávat pouze drobné změny a rozdíly mezi jednotlivými zálohovacími úlohami klientů. Při spuštění nových záloh (nebo příchozí replikace) lze přidat nová data a zvýšit kapacitu nebo využití softwaru Avamar. 
2. Po určité době vyprší platnost záloh na základě jejich nakonfigurované doby uchovávání a vypršení platnosti a již nejsou k dispozici v mřížce Avamar pro obnovení. 
3. Když se spustí úloha údržby Avamar s názvem Garbage Collection (GC), najde všechny jedinečné části nebo bloky dat, které již nejsou potřebné z důvodu vypršení platnosti těchto záloh. Garbage Collection ověří, že žádná jiná aktuální záloha nesdílí stejná data (z důvodu deduplikace), a poté odstraní nebo uvolní bloky dat, které již nejsou potřeba, aby se snížila kapacita nebo využití serveru Avamar.

Pokud je množství denně přidaných příchozích dat přibližně stejné jako množství denně vymazaných dat, nazývá se to „ustálený stav“. To je cílem každé nainstalované mřížky Avamar.

Před nastavením a konfigurací nové mřížky Avamar se provádějí obecné výpočty velikosti před instalací, aby se určila kapacita potřebná pro uložení záložních dat. Tyto výpočty vycházejí z požadavků zákazníků na uchovávání dat a z množství dat, která mají být zálohována. Odhaduje se také, kolik z těchto dat lze v průměru deduplikovat atd.

1. Nekonzistentním prováděním procesu Garbage Collection.
2. Pomalým výkonem procesu Garbage Collection nebo jejím nedostatečně dlouhým spuštěním.
3. Nedostatečně přesnými odhady deduplikace před instalací mřížky Avamar.
4. Zálohováním dat na tento server Avamar, která se liší od dat vypočítaných před instalací mřížky Avamar.
5. Jiné důvody

Ověřte, zda jsou jednotlivé níže uvedené kroky odstraňování problémů platné pro vaše prostředí:

1. krok Shromažďování dat:

Ujistěte se, že v mřížce Avamar nejsou žádné další problémy, které nesouvisejí s kapacitou. Pokud jsou, je třeba je vyřešit PŘED řešením problémů s kapacitou.

Patří sem chyby hardwaru, problémy s integritou dat (včetně offline uzlů), offline prokládání, selhání ověření kontrolních bodů nebo selhání úloh údržby. Pokud se jedná o některý z těchto problémů, je nutné zastavit odstraňování problémů s kapacitou a vyřešit ostatní problémy. Jakmile jsou ostatní problémy vyřešeny, lze se vrátit k řešení problémů s kapacitou.

Spusťte kontrolu stavu (Avamar: Jak spustit skript kontroly stavu proactive_check.pl v serveru Avamar, při nejmenším však status.dpn příkaz může poskytnout rychlý přehled a ověření většiny stejných problémů. Viz článek Avamar: Jak porozumět výstupu vytvořenému pomocí příkazu „status.dpn“

Další informace naleznete v článku znalostní databáze: Avamar: Jak správně použít přístup „Hierarchie odstraňování problémů Avamar“.

Pokud potřebujete pomoc s řešením jakýchkoli problémů, které se netýkají kapacity, vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar.

2. krok Shromažďování informací o kapacitě: 

Všechny požadované informace potřebné k odstraňování problémů s kapacitou systému Avamar naleznete v následujících dokumentech: Avamar: Jak shromáždit informace pro odstraňování problémů s kapacitou

Přinejmenším status.dpn příkaz nebo hodnoty v uživatelském rozhraní pro správu Avamar zobrazují GSAN kapacitu.

3. krok Zkontrolujte, zda je kapacita operačního systému plná:

Následující příkaz vám pomůže zobrazit aktuální hodnotu kapacity operačního systému pro každý oddíl disku. Pokud některá z hodnot dosáhla nebo překročila 85 %, jako ve druhém ukázkovém výstupu, považuje se za vysokou kapacitu operačního systému:

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Ukázkové výstupy:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Pouze v případě, že je kapacita operačního systému nižší než 85 %, byste měli pokračovat GSAN v odstraňování problémů s kapacitou. 

4. krok Problémy nesouvisející s kapacitou, které mohou být někdy mylně považovány za problémy s kapacitou:

Je možné, že zálohování klientů selže nikoli z kapacitních důvodů, ale z důvodu kvóty. To může být někdy mylně chápáno jako záležitost kapacity.

Tuto situaci může potvrdit pomocí příkazu status.dpn nebo jiného shromážděného výstupu vykazujícího nižší kapacitu.

Je také možné, že zálohování klienta selhalo nebo se nespustilo kvůli jiným Non-GSAN kapacitním důvodům. Shromážděné informace by to měly potvrdit, nebo je lze také zobrazit v uživatelském rozhraní pro správu Avamar.

• Avamar: Cesta řešení problémů s kapacitou metadat
• Data Domain: Vysoká kapacita z cesty řešení integrace Avamar

V případě, že GSAN je kapacita vysoká a tyto další kapacity jsou také vysoké, odstraňování problémů lze provádět v libovolném pořadí (kromě kapacity operačního systému, která musí být vždy na prvním místě).

5. krok Vyvážení prokládání a místa na disku operačního systému:

„Prokládání" v systému Avamar jsou soubory kontejneru, ve kterých jsou zálohovaná data uložena v datových uzlech (s výjimkou mřížky Avamar s jedním uzlem).

Očekává se, že prokládání je „vyvážené“ nebo rovnoměrně rozložené na různých discích a uzlech v mřížce, někdy však může být nevyvážené.

Pokud jde o kapacitu systému Avamar, největší uzel nebo diskový oddíl systému Avamar je omezujícím faktorem.

To je záměrné, aby žádný z disků nebo uzlů nevytvářel více prokládání, než kolik je schopen zpracovat (nebo kolik je povoleno), proto pro kapacitu je důležité mít vyvážené prokládání.

Například při přidávání dalších datových uzlů pro rozšíření mřížky Avamar je nutné provést vyvážení, aby se prokládání rovnoměrně rozdělilo mezi nové uzly, a snížilo se tak celkové procento využití kapacity Avamar.

Dalším typem vyvážení, které je potřeba pochopit, je vyvážení disku s operačním systémem. To je omezeno pouze na datové oddíly ve stejném uzlu, nikoli na oddíly na více uzlech. 

Pokud je na stejném datovém uzlu jeden oddíl mnohem větší nebo menší než jiný oddíl stejného uzlu, může být překročen limit s názvem „freespaceunbalance“. I když to se obecně děje v operačním systému, a ne GSAN u kapacity, může se to hlásit jako GSAN problém s kapacitou.

6. krok Zkontrolujte, zda se operace Garbage Collection dokončuje: 

Spuštěním následujícího příkazu získáte informace o procesu Garbage Collection:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

V ideálním případě bude výstup ukazovat, že proces Garbage Collection byl dokončeno za posledních 30 dnů:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

Zprávy o selhání Garbage Collection mohou mimo jiné obsahovat následující:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Pokud proces Garbage Collection selhává, vyřešte to nejprve pomocí následujícího článku: Avamar: Odstraňování problémů se selháním Garbage Collection (GC) (cesta řešení)
(Pokud již byly některé problémy vyřešeny, přejděte k dalšímu kroku.)

7. krok Běží proces Garbage Collection dostatečně dlouho?

a. Spuštěním následujícího příkazu zkontrolujte maximální povolenou dobu pro proces Garbage Collection:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Ukázkový výstup:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Poznamenejte si maxtime hodnotu, což je v tomto příkladu 14400 (sekund).
(Hodnota 0 znamená neomezenou dobu)

b. Spuštěním následujícího příkazu určete, jak dlouho je proces Garbage Collection spuštěný a kolik cyklů se úspěšně dokončí:
(Cykly mají co do činění s vrstvami uložených zálohovaných dat. Uvažujte GSAN o kapacitě jako o vrstvách cibule. Aby byly vidět vnitřní vrstvy, je nutné odstranit vnější vrstvy. Každý cyklus je vrstvou GSAN uložených dat.)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Ukázkový výstup:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Poznamenejte si počet cyklů a elapsed-time (sekund).

c. Za předpokladu, že maxtime je nenulová, vypočítejte 2/3 z maxtime, a porovnejte s uplynulou dobou.
(Ve výše uvedeném příkladu 2/3 z 14400 činí 9600 a všechny výstupy za uplynulý čas jsou výrazně pod tímto číslem.)

Různé problémy mohou způsobit, že proces Garbage Collection bude probíhat pomalu nebo že nebude skenovat vše. Může se jednat například o nedostatek času na spuštění po významnou dobu nebo dny v minulosti, nesprávnou konfiguraci, chyby a další.

Pokud máte obavy ohledně maxtimenebo počtu cyklů, vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar, který provede další šetření.

8. krok Pokud existuje podezření, že proces Garbage Collection neodebral dostatek data nebo očekávaná data:

Pokud se potvrdí, že proces Garbage Collection běží dostatečně dlouho, je možné, že data nejsou shromažďována z důvodů mimo kontrolu procesu Garbage Collection. Toto je seznam zdokumentovaných důvodů, které byste měli obecně zkontrolovat:

a. Ověřte, zda jsou zálohy nakonfigurovány tak, aby alespoň časem nebo pravidelně vypršely. Pokud k vypršení platnosti záloh nedochází často, proces Garbage Collection nebude mít moc práce.

b. Pomocí tohoto článku vyhledejte klienty s nejvyšší mírou změn: Avamar: Jak spravovat kapacitu pomocí skriptu capacity.sh. (Zkontrolujte jak „% OF TOTAL“ tak i „CHGRATE“.)

c. Zkontrolujte přeskočené hashe u každého systému Avamar: Avamar Garbage Collection hlásí „skipped-hashes“, které nelze vymazat. Pokud k tomu dochází jen vzácně, je to normální a lze to přeskočit.

d. Existuje příznak nebo možnost, která přinutí server Avamar, aby uchovával poslední a nejnovější zálohu od každého klienta. To se používá z bezpečnostních důvodů, aby klientovi omylem nevypršela platnost všech záloh. To však může způsobit další problémy, pokud jde o mazání dat a proces Garbage Collection. Tým podpory Dell Technologies Avamar může ověřit, zda je tato funkce povolena.

e. Pokud byly zálohy nedávno přepnuty z GSAN do backendu DD nebo došlo k nehodě GSAN zálohy, ale kapacita GSAN se nesníží, vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar a požádejte jej o další prošetření.

9. krok Mřížka Avamar je poddimenzovaná na množství aktuálních nebo očekávaných přidávaných dat:

Jakmile budou všechna ostatní řešení a možné příčiny zkontrolovány z hlediska vysoké kapacity, a nejedná se o problém s konfigurací nebo náhodnými daty:

To znamená, že může být nutné data smazat nebo zvážit různé možnosti, jako je přesun určitých klientů do jiných mřížek Avamar, přidání nových datových uzlů atd.

10. krok Potvrďte všechny události kapacity a v případě potřeby obnovte plánovač zálohování:

a. Po vyřešení problémů s kapacitou potvrďte všechny události související s kapacitou v uživatelském rozhraní pro správu Avamar.

b. Znovu spusťte plánovač zálohování:

dpnctl start sched

V případě dalších dotazů týkajících se kapacity, školení, odstraňování problémů a dalších otázek týkajících se kapacity systému Avamar si přečtěte následující článek: Avamar: Odstraňování problémů s kapacitou, problémy a dotazy – veškerá kapacita (postup řešení)

• Toto opatření samo o sobě může „maskovat“ a skrýt skutečné problémy, které se pak za několik dní nebo týdnů znovu objeví, což znamená, že tato ruční práce byla zbytečná.
• Ruční proces Garbage Collection navíc nemusí běžet tak efektivně, protože běží mimo plán.
  • Občas to může zhoršit další problémy. Další informace naleznete zde: Avamar: Informace o použití ručního procesu Garbage Collection

• Tato změna nebo akce se obecně neprovádí a neměla by být považována za výchozí. Tuto změnu musí schválit technik Avamar L2 nebo odborník na danou problematiku (SME).
• Bohužel takové akce mohou často způsobit trvalé poškození mřížky Avamar různými způsoby, které lze vyřešit pouze přidáním dalších úložných uzlů nebo opětovným nasazením.

Upozorňujeme, že žádná z výše uvedených akcí není prováděna proto, že tým podpory chce pomoci vyřešit problémy s kapacitou nejvýhodnějším způsobem.