Avamar GSAN nebo cesta řešení kapacity 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 Kapacita jako prostor a využití pro zálohování klientů.

• Základní principy deduplikace
• Základní znalost kontrolního bodu, validace kontrolního bodu (hfscheck) a uvolňování paměti a důležitost každého z nich.
• Rozdíl mezi GSAN (nebo Uživatel) Kapacita a operační systém
• Změna rychlosti
• Rovnovážný 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 (někdy může plánovač zálohování zakázat, 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. Software Avamar musí z důvodu deduplikace ukládat pouze drobné změny a rozdíly mezi jednotlivými úlohami zálohování klienta. Při spouštění nových záloh (nebo příchozí replikace) mohou přidávat nová data a zvyšovat kapacitu nebo využití softwaru Avamar. 
2. Po určité době vyprší platnost záloh na základě jejich nakonfigurovaného uchovávání a vypršení platnosti a nejsou nalezeny v mřížce Avamar dostupné pro obnovení. 
3. Když se spustí úloha údržby Avamar s názvem Garbage Collection (GC), vyhledá všechny jedinečné části nebo bloky dat, které už nejsou potřeba kvůli těmto zálohám s vypršenou platností. GC ověří, že žádná jiná aktuální záloha nesdílí stejná data (z důvodu deduplikace), a poté tyto bloky dat odstraní nebo uvolní, 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ě čištěný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é sítě Avamar jsou provedeny obecné výpočty velikosti před instalací, aby bylo možné určit kapacitu potřebnou k ukládání zálohovaných dat. Tyto výpočty jsou založeny na požadavcích zákazníků na uchovávání dat a na tom, kolik dat se má zálohovat. Odhaduje také, kolik z těchto dat by se mohlo v průměru deduplikovat a tak dále.

1. Uvolňování paměti není konzistentně spuštěno.
2. Výkon uvolňování paměti je pomalý nebo neběží dostatečně dlouho
3. Odhady deduplikace před instalací sítě Avamar nebyly dostatečně přesné
4. Na tento server Avamar se zálohují jiná data než data vypočítaná před instalací mřížky Avamar.
5. Jiné důvody

Ověřte, zda všechny níže uvedené kroky odstraňování problémů platí pro dané prostředí:

1. krok: Sběr dat:

Ujistěte se, že s mřížkou Avamar nejsou žádné další problémy s nekapacitou. Pokud ano, mohou vyžadovat pozornost PŘED odstraňováním problémů s kapacitou.

Patří sem chyby hardwaru, problémy s integritou dat (včetně offline uzlů), prokládání offline, 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 další problémy. Po vyřešení dalších problémů je možné kapacitu znovu zkontrolovat.

Měla by být spuštěna kontrola stavu (Avamar: Jak spustit skript pro kontrolu stavu proactive_check.pl na serveru Avamar, ale minimálně status.dpn 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 vygenerovanému příkazem status.dpn

Další informace najdete v následujícím článku: Avamar: Jak správně aplikovat přístup "hierarchie řešení problémů Avamar".

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

Krok 2. 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 nebo hodnoty v uživatelském rozhraní pro správu Avamar zobrazují GSAN kapacita.

Krok 3. 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 výstupu druhého vzorku, 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 %, GSAN Pokračovat v odstraňování problémů s kapacitou. 

Krok 4. Problémy s nekapacitou, které mohou být někdy mylně chápány jako kapacita:

Je možné, že zálohování klientů selže nikoli z kapacitních, ale z důvodu kvóty. Ty mohou být někdy mylně chápány jako kapacita.

Tuto situaci může potvrdit status.dpn nebo jiný shromážděný výstup vykazující nižší kapacitu.

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

• Avamar: Cesta řešení kapacity metadat
• Data Domain: Vysoká kapacita z cesty řešení integrace Avamar

V případě, že se GSAN Kapacita je 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ě).

Krok 5. Vyvážení prokládání a rozložení 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 mohou být nevyvážené.

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

Jedná se o záměr, aby žádný z disků nebo uzlů nevytvořil více prokládání, než je možné (nebo povoleno), a proto je vyvážené prokládání důležité z hlediska kapacity.

Například při přidávání dalších datových uzlů pro rozšíření sítě Avamar je nutné provést vyvažování, aby se prokládání rovnoměrně rozložilo do nových uzlů a snížilo se tak celkové procento 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ž je to obecně v operačním systému, a ne v GSAN Kapacitu, lze ji vykázat jako GSAN Problém s kapacitou.

Krok 6. Zkontrolujte, jestli se uvolňování paměti dokončuje: 

Spuštěním následujícího příkazu získáte informace o uvolňování paměti:

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

V ideálním případě bude výstup ukazovat, že uvolňování paměti bylo 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í uvolňování paměti 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 GC selhává, vyřešte to nejprve pomocí následujícího článku jako reference: Avamar: Odstraňování problémů se selháním uvolňování paměti (GC) (cesta řešení)
(Pokud již byly některé problémy vyřešeny, přejděte k dalšímu kroku.)

Krok 7. Běží GC dostatečně dlouho?

a. Spuštěním následujícího příkazu zkontrolujte maximální povolenou dobu pro uvolňování paměti:

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"/>

Vezměte na vědomí maxtime , což je v tomto příkladu 14400 (sekund).
(Hodnota 0 znamená neomezeno)

b. Spuštěním následujícího příkazu určete, jak dlouho je uvolňování paměti spuštěné a kolik úspěšných průchodů:
(Průchody mají co do činění s vrstvami uložených zálohovaných dat. Myslete na GSAN Kapacita jako vrstvy cibule. Vnější vrstvy musí být odloupnuty nebo odstraněny, než jsou vidět vnitřní vrstvy. Každý průchod je vrstvou GSAN uložená data.)

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 průchodů a elapsed-time (sekundy).

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

Různé problémy mohou způsobit, že uvolňování paměti bude probíhat pomalu nebo že nebude skenovat vše. To může zahrnovat nedostatečnou dobu nebo dny na spuštění, nesprávnou konfiguraci, chyby a další.

Existují-li obavy ohledně maxtimenebo počtu průchodů, vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar k dalšímu prošetření.

Krok 8. Pokud má podezření, že GC neodebral dostatek nebo očekávaná data:

Pokud se potvrdí, že uvolňování paměti běží dostatečně dlouho, je možné, že se data neshromažďují z důvodů mimo kontrolu uvolňování paměti. Zde je seznam zdokumentovaných důvodů, které by měly být obecně zkontrolovány:

a. Ověřte, zda jsou zálohy nakonfigurované tak, aby nakonec nebo pravidelně vypršela alespoň jejich platnost. Pokud nedochází k častému vypršení platnosti záloh, GC nebude mít mnoho práce.

b. V tomto článku vyhledejte klienty s nejvyšší mírou změn: Avamar: Jak spravovat kapacitu pomocí skriptu capacity.sh. (Zkontrolujte obě "% OF TOTAL" a "CHGRATE".)

c. Kontrola přeskočených hashů u každého nástroje Avamar: Systém Avamar Garbage Collection hlásí "přeskočené hashe", které nelze vyčistit. Pokud k nim dochází, ale jsou 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 čištění dat a uvolňování paměti. 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áloha, ale GSAN Pokud se kapacita nesnižuje, vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar a požádejte jej o další prošetření.

Krok 9. 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 data mohou vyžadovat odstranění nebo mohou být prozkoumány možnosti, jako je migrace určitých klientů do jiných mřížek Avamar, přidání nových datových uzlů atd.

Krok 10. 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í správce 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 najdete tady: Avamar: Odstraňování problémů s kapacitou, problémy a dotazy – veškerá kapacita (postup řešení)

• Tato akce sama o sobě může "maskovat" a skrývat skutečné problémy, pouze způsobit, že se o několik dní nebo týdnů později znovu objeví, což způsobí, že tato manuální práce bude ztrátou času.
• Ruční uvolňování paměti navíc nemusí běžet tak efektivně, jak běží mimo plán.
  • Příležitostně to může zhoršit další problémy. Další informace naleznete zde: Avamar: Informace o použití ručního uvolňování paměti

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

Pochopte, že žádná z výše uvedených akcí se neprovede, protože tým podpory chce pomoct vyřešit problémy s kapacitou tím nejvýhodnějším způsobem.