Avamar: Kapacita operačního systému (OS) (cesta řešení)

Jak řešit nebo odstraňovat problémy s kapacitou operačního systému v systému Avamar.

Tento článek je určen k řešení a řešení problémů s kapacitou operačního systému v systému Avamar.


Počáteční koncepty a pochopení kapacity operačního systému naleznete ve školicím článku Avamar: Koncepty a školení

v oblasti řízení kapacitJak je shrnuto ve školicím článku, aby bylo možné pokračovat ve zbývající části tohoto článku, je třeba přiměřeně porozumět následujícím tématům:

• Základní znalost kontrolních bodů (cp), validace kontrolních bodů (hfscheck)a uvolňování paměti (GC) a důležitost každého z nich
• Rozdíl mezi GSAN (neboli "Uživatelská kapacita" a kapacita operačního systému)
• režijní data kontrolního bodu.
• Pokud je některý z datových oddílů větší než 89 % celkové fyzické kapacity operačního systému, uvolňování paměti nelze spustit.
• Čím blíže je síť Avamar 100 % kapacity uživatele, tím menší kapacita operačního systému je k dispozici pro režii kontrolních bodů.
• Faktory, které přispívají k režii kontrolních bodů, včetně asynchronního drcení, počtu uložených kontrolních bodů, HFSCheck a důležitost ověření kontrolního bodu a tak dále.
• Jak najít úrovně kapacity operačního systému
• Základní opatření ke snížení kapacity operačního systému

Často je nejjednodušší považovat kapacitu operačního systému za velikost GSAN dat (konkrétně prostoru vyhrazeného pro tato data) a režie generované kontrolními body systému Avamar. Čím větší je počet kontrolních bodů a čím vyšší je rychlost změny, tím vyšší je režie kontrolních bodů.

Dopady vysoké kapacity operačního systému mohou zahrnovat:

• Selhání uvolňování paměti: GC selže s MSG_ERR_DISKFULL když kapacita operačního systému stoupne nad 89 %
• Selhání zálohy nebo replikace: Pokud kapacita operačního systému stoupne nad 90 %, zálohování nebo příchozí replikace může při MSG_ERR_STRIPECREATE selhat. (To platí pouze v případě, že je nutné vytvořit nový datový prokládání. Pokud nové prokládání není potřeba, zálohování a replikace mohou přesto proběhnout úspěšně.)
• Selhání kontrolního bodu: Kontrolní bod selže se MSG_ERR_DISKFULL, když kapacita operačního systému stoupne nad 96 %

Jak může naznačovat výše uvedené, kapacita operačního systému je často prvním typem kapacity systému Avamar, který je třeba řešit, když jsou ostatní kapacity Avamar vysoké. Uvolňování paměti nelze spustit alespoň, když kapacita operačního systému dosáhne určité úrovně, a to ani v případě, že GSAN nebo je také vysoká uživatelská kapacita.

Obecně platí, že kapacita operačního systému se považuje za vysokou, když dojde k selhání uvolňování paměti s MSG_ERR_DISKFULL pokud kapacita operačního systému stoupne nad 89 %. Pokud je kapacita operačního systému nižší než 89 %, nejsou ovlivněny žádné úlohy údržby. 

Kapacita operačního systému Avamar se může zvýšit z mnoha následujících důvodů:

• Vysoká rychlost změn zálohovaných dat, přidávání "příliš mnoho příliš rychle"
• Vysoká GSAN nebo "Uživatelská kapacita", která ponechává méně prostoru pro kapacitu operačního systému a někdy může dokonce vést k vyšší míře změn
• Kontrolní bod se nedaří úspěšně dokončit, což má za následek stav "MSG_ERR_DISKFULL", jak je vidět ve výstupu.
• Ověření kontrolního bodu (hfscheck) selhal nebo nebyl v poslední době spuštěn, takže nejstarší kontrolní body nelze odvalit nebo odstranit
• Kontrolní body nelze odebrat z jiných důvodů, včetně příliš vysokého nastavení uchovávání kontrolních bodů.

Vysoká kapacita operačního systému v jiných oddílech disku může být způsobena různými příčinami, včetně nesprávného umístění dat, příliš velkých souborů protokolu atd.

• Pro rychlé pozadí jsou kontrolní body Avamar snapshoty pouze pro čtení a odkaz na živá data. Vzhledem k tomu, že je vytvořen pomocí odkazů, bude kontrolní bod ihned po vytvoření využívat nula místa na disku navíc. Pokud nedojde k žádným změnám živých dat, kontrolní bod nevyužije další místo.
• To se mění s tím, jak se mění živá data, zatímco kontrolní bod zůstává stejný. V tomto okamžiku existuje původní kopie dat v kontrolním bodě a aktualizovaná živá kopie upravených dat. To je zcela záměrné a záměrné. To je důvod, proč je zde vyhrazený prostor kapacity operačního systému.
• Pokud se ale množství nebo rychlost změn dat drasticky a náhle zvýší, může to způsobit neobvyklý nárůst velikosti kapacity operačního systému a může to být považováno za "příliš mnoho a příliš rychlé"
• Skript capacity.sh nástroj by to zobrazil jako příčinu při porovnání výstupu za několik dní.

Pokud úlohy údržby, včetně uvolňování paměti, selhávají kvůli vysoké kapacitě operačního systému Avamar, postupujte následovně:

1. Shromážděte všechny informace o kapacitě Avamar a vytvořte si obrázek o situaci: Avamar: Jak shromáždit informace potřebné k odstraňování problémů s kapacitou.

2. Dále zkontrolujte, jak vysoká je kapacita operačního systému a jaké akce mohou být vyžadovány. Z článku o shromažďování dat to najdete pomocí následujícího příkazu: 

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

Software Avamar funguje tak, že nejvyšší zobrazená hodnota fs-percent-full je omezujícím faktorem pro aktuální kapacitu operačního systému. V závislosti na generaci a velikosti typu uzlu se může počet datových oddílů, ve kterých jsou uložena data záloh a kontrolních bodů, lišit. V operačním systému Linux se může jednat o disky nebo oddíly, například o "/data0*", kde "*" může tvořit jednu číslici. Počet datových oddílů závisí na typu uzlu, generaci hardwaru a velikosti (a nelze jej změnit).

3. Zkontrolujte počet nalezených kontrolních bodů a to, jak nedávno byly ověřeny pomocí příkazu:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Pomocí následujícího příkazu ověřte, zda selhávají operace kontrolního bodu z MSG_ERR_DISKFULL:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Pokud se kontrolní body úspěšně dokončí, zobrazí se výstup podobný následujícímu:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

Pokud selže z důvodu MSG_ERR_DISKFULL, zobrazí se tento výstup:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Určete rychlost změny:

capacity.sh  

Příklad výstupu:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Někdy, pokud se opakuje vysoká míra změn nebo situace "příliš mnoho příliš rychle", lze to zmírnit snížením celkové GSAN nebo uživatelskou kapacitu. S nižším GSAN kapacity, je zde o něco více prostoru pro režii kapacity operačního systému a také vede k menšímu počtu změn kontejnerů úložiště dat. Pokud potřebujete pomoc s tímto scénářem, otevřete servisní požadavek u týmu podpory Dell Technologies Avamar, v opačném případě pokračujte krokem 7.

7. Problémy s vysokou kapacitou operačního systému v jiných oddílech disku mají různé příčiny, ale jejich řešení vyžadují technickou podporu. Otevřete servisní požadavek u týmu podpory Dell Technologies Avamar, v opačném případě pokračujte krokem 7.

Po vyřešení kapacity operačního systému GSAN Je možné zkontrolovat kapacitu nebo jiné kapacity softwaru Avamar. Viz Odstraňování problémů s kapacitou systému Avamar – veškerá kapacita (cesta řešení).