Avamar: Upphängda partitioner, stripes och hfscheck-fel på Avamar

1. Följande fel kan visas i användargränssnittet för Avamar Administrator-servern. Meddelandet kan generera en Dial Home Service Request (SR):

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

2. VARNA meddelanden relaterade till perfbeat tråden rapporteras på datalagringsnoderna i /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. Informationen status.dpn utdata visar att en disk har pausade stripes:
(Dessa utdata skapas bara när "WARN <1084>" inträffar.)

Exempel:

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) 

Dessa utdata visar att det finns 2374 upphängda ränder.

4. Informationen hfscheck misslyckas om en partition blir pausad medan hfscheck körs. Ett exempel på ett fel från /data01/hfscheck/err.log eller /data01/cur/err.log är: 

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

Med jämna mellanrum, var femte minut som standard, "testar" gsan I/O genom att utföra små läsningar från datapartitionerna.

Den kontrollerar om läsprestandan är 10 % av normal prestanda.

I exemplet nedan anger meddelandet att den genomsnittliga läsprestandan, på den specifika nod som genererade varningsmeddelandet, under ett utökat antal utvärderingsversioner hfscheck var igång är ungefär 54,03 MB/sekund. Men på just det här testet var den faktiska prestandan 0,57 MB/sekund, vilket är under "gränsen" på 10 % av medelvärdet, eller 5,4029 MB/sekund.

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

Det ursprungliga syftet med detta test var att ge en varning om att det fanns något problem med I/O vilket gör att läsprestandan blir överdrivet långsam. 

I det här fallet långsammare än 10 % av den "genomsnittliga" disken I/O föreställning.

Informationen perftriallimit Anger antalet på varandra följande diskläsningstest som måste vara utanför toleransen innan perfbeat Misstänker att en disk kan vara skadad.

Informationen perfinterval (standard 300 eller 5 minuter) anger hur lång tid det ska ta mellan varje perftriallimit test.

När perfbeat misstänker att en disk är degraderad, talar den om för gsan för att nå ett kallt tillstånd (stoppa all diskrelaterad aktivitet). 

Den väntar högst 20 minuter (trådbunden) på gsan för att nå det här läget innan tidsgränsen överskrids och disken inte pausas.

Om det kalla tillståndet uppnås, då perfbeat Utför perfcoldtriallimit (standard 4) fler lästa tester med avstånd perfcoldinterval (standard 30) sekunders mellanrum.

Endast om alla dessa tester visar att disken fortfarande är nedgraderad kommer disken att pausas.

Möjliga orsaker till pausade diskar:

• När du försöker nå ett kallt tillstånd väntar gsan alltid minst en minut (trådbunden). Den väntar också på alla väntande gsan-diskar I/O verksamhet för att slutföra eller tillfälligt avbryta sin verksamhet. När ett kallt tillstånd har uppnåtts kan det hända att operativsystemet fortfarande kör disk I/O, till exempel att tömma cacheminnet. Den här tömningsaktiviteten är en möjlig förklaring till varför diskar pausas i onödan. Med större mängder minne kan det finnas mycket mer cachedata att tömma.

• En annan möjlig förklaring är att informationen om prestandahistorik inte exakt förutsäger vad den förväntade diskläsningsprestandan bör vara under olika gsan verksamhet, eftersom gsan's Beteendet har ändrats för snabbt för att historiken ska återspegla det (historiken är ett genomsnitt av de senaste 10 dagarnas prestandamätningar).

• En annan möjlig förklaring är att det kan finnas ett problem, till exempel att inte vänta på alla gsan skiva I/O aktiviteter för att slutföra eller avbryta driften innan de når kallt tillstånd.

Dessutom visade forskning att under hfscheck ”indexsweep"-fasen (när alla hashvärden i indexremsorna läses och sedan utför massiva slumpmässiga skrivningar till många DRL-filer (Data Referenced Log) ska den testade I/O prestanda sjunker under en betydande tidsperiod.

På Avamar Data Store Gen4, Gen4s och Gen4T har skrivåtgärder prioriterats framför läsåtgärder och vikten av att testa läsprestandan för I/O delsystemet är mycket lägre. Vissa enheter (t.ex. Seagate Megalodon enheter) använda några olika tekniker som kan förvirra de tester som utförs av perfbeat tråd.

Bakgrund:

Det finns vanligtvis tre olika varningsmeddelanden i gsan Loggar:

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

Varning <0968> indikerar att det fanns en individ gsan I/O test som var långsamt.

Det här meddelandet kan ignoreras på ett säkert sätt.

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

Varning <1051> indikerar att det fanns tillräckligt med långsamma läsningar för att gsan övervägdes att försätta datapartitionen i pausat tillstånd, men bestämde sig för att inte göra det. Det är vad MSG_ERR_UNNECESSARY indikerar.

Det här meddelandet kan ignoreras på ett säkert sätt.

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

Varning <1084> anger att gsan försätter datapartitionen i ett "pausat tillstånd".

Detta meddelande får inte ignoreras.

Lösning:

Om ränderna försätts i pausat tillstånd använder du följande riktlinjer för att undersöka och korrigera följande scenarier:

Utför följande för att identifiera platsen för den upphängda partitionen:

1. Logga in på Avamar-verktygsnoden som administratör.

2. Höj till rotprivilegium.

3. Läs in rotnycklarna per Avamar: Logga in på en Avamar-server och läs in olika nycklar.

4. Kör följande kommando för att identifiera platsen för den pausade partitionen:

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

5. Granska scenarierna när det gäller resultaten ovan:

• • Inga åtgärder krävs. Stripes returneras automatiskt till nätet. Det är mycket troligt att hfscheck var igång. 

• • Om stripes automatiskt returneras online är det mycket troligt att skräpinsamling eller hfscheck var igång.
  • VIKTIGT! Detta kan vara en indikation på ett diskproblem eller något underliggande problem.
  • Även om drivenheten ännu inte har slutat att fungera, bör den ändå kontrolleras med hjälp av stegen nedan:

1. Ta reda på vilka fysiska diskar som är associerade med den disk som Avamar har pausat. Problem med fysiska diskar i en virtuell diskpausning skulle vara en rotorsak till ett uppehåll:

avsysreport pdisk vdisk=x 

Där x är numret på den virtuella disken (datapartitionen) som har pausats. Om den första datapartitionen till exempel visar upphängda stripes frågar du vdis=0.

2. Kontrollera att det inte finns några diskfel, förutsagda fel eller andra fel på den fysiska disknivån.

3. Kontrollera att det inte finns några SCSI-fel på fysiska diskar som representerar den virtuella disken på noden i fråga (fastställs i steg 1). 

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

4. Virtuella diskar i genomskrivningsläge kan orsaka att disken pausas på grund av låg I/O. Kontrollera skrivpolicyn på styrenheten:

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

Om några problem upptäcks i steg 2–4 öppnar du en tjänstebegäran med Dell Technologies Avamar-support för vidare undersökning.

Scenario # 3: Granska standardinställningen perftriallimit Inställningar:

1. Kontrollera att perftriallimit är inställt på 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Om den perftriallimit är något annat än noll:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"