Avamar: Selhání pozastavených oddílů, prokládání a nástroje hfscheck v softwaru Avamar

1. V uživatelském rozhraní serveru Avamar Administrator se může zobrazit následující chyba. Tato zpráva může generovat požadavek na službu Dial Home (SR):

Symptom Code: 22632, Desc: A server disk has become suspended.

2. Zprávy WARN související perfbeat vlákna jsou hlášena na uzlech pro ukládání dat v /data01/cur/gsan.log:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. Skript status.dpn výstup ukazuje, že disk má pozastavené pruhy:
(Tento výstup se vytvoří pouze v případě, že dojde k "WARN <1084>".)

Například:

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Tento výstup ukazuje, že existuje 2374 zavěšených pruhů.

4. Skript hfschecK selže, pokud dojde k pozastavení oddílu v době, kdy je hfscheck běží. Příklad chyby z /data01/hfscheck/err.log nebo /data01/cur/err.log ar: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Pravidelně, každých pět minut, ve výchozím nastavení gsan "testuje" I/O prováděním malých čtení z datových oddílů.

Ověří, zda je výkon čtení 10 % ve srovnání s normálním výkonem.

V níže uvedeném příkladu zpráva indikuje, že na konkrétním uzlu, který vygeneroval zprávu s upozorněním, je průměrný výkon čtení za delší počet pokusů hfscheck , což je přibližně 54.03 MB/s. V tomto konkrétním testu však byl skutečný výkon 0,57 MB/s, což je pod "limitem" 10 % průměrné hodnoty, tedy 5,4029 MB/s.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

Původním účelem tohoto testu bylo poskytnout varování, že došlo k nějakému problému s I/O subsystému, který způsobuje příliš pomalý výkon čtení. 

V tomto případě je pomalejší než 10 % "průměrného" disku I/O představení.

Skript perftriallimit Určuje počet po sobě jdoucích testů čtení disku, které musí být mimo toleranci před perfbeat má podezření, že disk může být degradován.

Skript perfinterval (výchozí 300 s nebo 5 minut) určuje, jak dlouho se má čekat mezi jednotlivými perftriallimit test.

Kdy perfbeat podezření na degradaci disku, sdělí gsan dosažení studeného stavu (zastavení veškeré aktivity související s diskem). 

Čeká maximálně 20 minut (napevno) na gsan , abyste tohoto stavu dosáhli před vypršením časového limitu a nepozastavením disku.

Pokud je dosaženo studeného stavu, pak perfbeat provádí perfcoldtriallimit (výchozí: 4) více testů čtení s rozestupy perfcoldinterval (ve výchozím nastavení 30) s odstupem 30 sekund.

Disk bude pozastaven pouze v případě, že všechny tyto testy naznačují, že je disk stále v režimu degradace.

Možné důvody pozastavení disků:

• Při pokusu o dosažení chladného stavu gsan vždy čeká alespoň jednu minutu (napevno). Čeká také na všechny čekající disky gsan I/O souvisejících činností, aby dokončily nebo pozastavily jejich provoz. Po dosažení chladného stavu však operační systém může stále pracovat na disku I/O, jako je vyprázdnění mezipaměti. Toto vyprázdnění je jedním z možných vysvětlení, proč jsou disky zbytečně pozastaveny. S větším množstvím paměti může být k vyprázdnění mnohem více dat mezipaměti.

• Dalším možným vysvětlením je, že informace o historii výkonu přesně nepředpovídají, jaký by měl být očekávaný výkon čtení z disku během různých gsan činnosti, protože gsan's Chování se změnilo příliš rychle na to, aby se historie projevila (historie je průměrem měření výkonu za posledních 10 dní).

• Dalším možným vysvětlením je, že by mohl nastat problém, například nečekat na všechny gsan disk I/O činnosti k dokončení nebo pozastavení jejich provozu před dosažením studeného stavu.

Výzkum dále ukázal, že během hfscheck “.indexsweep" (když se čtou všechny hashe v prokládání indexu a poté se provádějí masivní náhodné zápisy do mnoha souborů Data Referenced Log (DRL)) testovaný I/O Výkon po značnou dobu klesá.

V datovém úložišti Avamar Data Store Gen4, Gen4s a Gen4T mají operace zápisu přednost před operacemi čtení a význam testování výkonu čtení I/O subsystém je mnohem nižší. Také některé jednotky (například Seagate Megalodon pohony) používat některé různé techniky, které mohou zmást prováděné zkoušky perfbeat vlákno.

Pozadí:

V okně se obvykle zobrazují tři různé varovné zprávy. gsan polena:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

Varování <0968> znamená, že došlo k gsan I/O test, který byl pomalý.

Tuto zprávu můžete bezpečně ignorovat.

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

Upozornění <1051> znamená, že došlo k dostatečně pomalému čtení, aby gsan Společnost zvažovala uvedení datového oddílu do pozastaveného stavu, ale rozhodla se to neučinit. To je to, co MSG_ERR_UNNECESSARY naznačuje.

Tuto zprávu můžete bezpečně ignorovat.

WARN: <1084> changing disk 0 on node 0.3 to suspended state

Upozornění <1084> označuje, že gsan uvedl datový oddíl do "pozastaveného stavu".

Tuto zprávu nesmíte ignorovat.

Řešení:

Pokud jsou pruhy v pozastaveném stavu, pomocí následujících pokynů prozkoumejte a opravte následující scénáře:

Umístění pozastaveného oddílu zjistíte následovně:

1. Přihlaste se k uzlu nástroje Avamar jako uživatel „admin“.

2. Zvýšení oprávnění na uživatele root.

3. Načtěte kořenové klíče na Avamar: Jak se přihlásit k serveru Avamar a načíst různé klíče

4. Spuštěním následujícího příkazu určete umístění pozastaveného oddílu:

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Projděte si scénáře související s výše uvedenými výsledky:

• • Není vyžadována žádná akce. Pruhy se automaticky vrátí online. Je vysoce pravděpodobné, že hfscheck běželi. 

• • Pokud se prokládání automaticky vrátí do režimu online, je vysoce pravděpodobné, že uvolňování paměti nebo hfscheck běželi.
  • DŮLEŽITÉ: Může se jednat o známku problému s diskem nebo o nějaký základní problém.
  • Přestože jednotka ještě neselhala, měla by být stále zkontrolována pomocí níže uvedených kroků:

1. Určete, které fyzické disky jsou přidruženy k disku, který software Avamar pozastavil. Hlavní příčinou pozastavení mohou být problémy s uspáním fyzického disku v rámci virtuálního disku:

avsysreport pdisk vdisk=x 

Kde x je číslo virtuálního disku (datového oddílu), který byl pozastaven. Pokud se například v prvním oddílu dat zobrazují pozastavené pruhy, dotaz vdis=0.

2. Ověřte, zda na úrovni fyzického disku nedochází k selhání disku, předpokládaným selháním nebo jiným chybám.

3. Ověřte, zda se na fyzických discích nevyskytují žádné chyby SCSI, které představují daný virtuální disk v daném uzlu (určeno v kroku 1). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. Virtuální disky v režimu Write Through mohou způsobit uspání disku z důvodu nízkého stavu I/O. Zkontrolujte zásady zápisu na řadiči:

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

Pokud v krocích 2–4 zjistíte nějaké problémy, otevřete servisní požadavek u podpory Dell Technologies Avamar pro další šetření.

Scénář # 3: Kontrola výchozího nastavení perftriallimit nastavení:

1. Ujistěte se, že složka perftriallimit nastavena na hodnotu 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. V případě, že se perftriallimit je cokoli jiného než nula:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"