Avamar: Suspenderede partitioner, striber og hfscheck-fejl på Avamar

1. Følgende fejl vises muligvis i brugergrænsefladen til Avamar Administrator Server. Meddelelsen kan generere en Dial Home Service Request (SR):

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

2. ADVARE meddelelser relateret til perfbeat tråd rapporteres om datalagringsnoderne 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. Ikonet status.dpn output viser, at en disk har striber suspenderet:
(Dette output produceres kun, når "WARN <1084>" forekommer.)

For eksempel:

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) 

Denne udgang viser, at der er 2374 ophængte striber.

4. Ikonet hfscheck mislykkes, hvis en partition afbrydes, mens hfscheck kører. Et eksempel på en fejl fra /data01/hfscheck/err.log eller /data01/cur/err.log er: 

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ævne mellemrum, hvert femte minut som standard, "tester" gsan I/O delsystem ved at udføre små læsninger fra datapartitionerne.

Den kontrollerer, om læseydelsen er 10 % af den normale ydelse.

I eksemplet nedenfor angiver meddelelsen, at på den bestemte node, der genererede advarselsmeddelelsen, angiver den gennemsnitlige læseydelse over et længere antal forsøg, mens hfscheck kørte er ca. 54,03 MB/sekund. På denne særlige test var den faktiske ydeevne imidlertid 0.57 MB / sekund, hvilket er under "grænsen" på 10% af gennemsnitsværdien eller 5.4029 MB / sekund.

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

Det oprindelige formål med denne test var at give en advarsel om, at der var et problem med I/O delsystem, der får læseydelsen til at være for langsom. 

I dette tilfælde langsommere end 10% af den "gennemsnitlige" disk I/O præstation.

Ikonet perftriallimit Angiver antallet af på hinanden følgende disklæsningstest, der skal være uden for tolerance, før perfbeat Mistanke om, at en disk kan være forringet.

Ikonet perfinterval (standard 300s eller 5 minutter) angiver, hvor længe der skal ventes mellem hver perftriallimit test.

Hvornår perfbeat har mistanke om, at en disk er forringet, fortæller den gsan for at opnå kold tilstand (stop al diskrelateret aktivitet). 

Det venter højst 20 minutter (hardwired) på gsan for at nå denne tilstand, før der opstår timeout og ikke afbrydes disken.

Hvis den kolde tilstand nås, så perfbeat Udfører perfcoldtriallimit (standard 4) Flere læsetest med mellemrum perfcoldinterval (standard: 30) sekunders mellemrum.

Kun hvis alle disse tests viser, at disken stadig er forringet, vil disken blive suspenderet.

Mulige årsager til suspenderede diske:

• Når du forsøger at nå en kold tilstand, venter gsan altid mindst et minut (hardwired). Det venter også på alle ventende gsan-disk I/O relaterede aktiviteter for at fuldføre eller suspendere deres drift. Men når en kold tilstand er nået, udfører operativsystemet muligvis stadig disk I/O, såsom at skylle cachen ud. Denne skylleaktivitet er en mulig forklaring på, hvorfor diske suspenderes unødigt. Med de større mængder hukommelse kan der være meget mere cache-data at skylle.

• En anden mulig forklaring er, at oplysningerne om ydeevnehistorikken ikke nøjagtigt forudsiger, hvad den forventede disklæsningsydelse skal være under forskellige gsan aktiviteter, fordi gsan's Funktionsmåden har ændret sig for hurtigt til, at historikken kan afspejle den (historikken er et gennemsnit af de seneste 10 dages præstationsmålinger).

• En anden mulig forklaring er, at der kan være et problem, såsom ikke at vente på alle gsan skive I/O aktiviteter for at fuldføre eller suspendere deres drift, inden de når en kold tilstand.

Desuden viste forskningen, at under hfscheck "indexsweep" fase (når alle hashes i indeksstriberne læses og derefter udfører massive tilfældige skrivninger til mange Data Referenced Log (DRL) filer) den testede I/O Ydeevnen falder i en betydelig periode.

I Avamar Data Store Gen4, Gen4s og Gen4T er skrivehandlinger blevet prioriteret frem for læsehandlinger og betydningen af at teste læseydeevnen for I/O Delsystemet er meget lavere. Også nogle drev (som Seagate Megalodon drev) anvende nogle forskellige teknikker, der kan forvirre de test, der udføres af perfbeat tråd.

Baggrund:

Der ses typisk tre forskellige advarselsmeddelelser i gsan Logfiler:

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

Advarsel <0968> angiver, at der var en person gsan I/O Test, der var langsom.

Denne meddelelse kan ignoreres sikkert.

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

Advarsel <1051> angiver, at der var nok langsomme læsninger til, at gsan blev overvejet at sætte datapartitionen i suspenderet tilstand, men besluttede ikke at gøre det. Det er det, MSG_ERR_UNNECESSARY indikerer.

Denne meddelelse kan ignoreres sikkert.

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

Advarsel <1084> angiver, at gsan satte datapartitionen i en "suspenderet tilstand".

Denne meddelelse må ikke ignoreres.

Løsning:

Hvis striberne sættes i en suspenderet tilstand, skal du bruge følgende retningslinjer til at undersøge og rette følgende scenarier:

Udfør følgende for at identificere placeringen af den ophængte partition:

1. Log på Avamar Utility-noden som administrator.

2. Opgrader til rodrettigheder.

3. Indlæs rodnøglerne pr. Avamar: Sådan logger du på en Avamar-server og indlæser forskellige nøgler.

4. Kør følgende kommando for at identificere placeringen af den afbrudte partition:

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

5. Gennemgå scenarierne, som de vedrører ovenstående resultater:

• • Så kræves der ingen handling. Striber vender automatisk tilbage online. Det er meget sandsynligt, at hfscheck kørte. 

• • Hvis striber vender tilbage online automatisk, er det meget sandsynligt, at affaldsindsamling eller hfscheck kørte.
  • VIGTIGT: Dette kan være en indikation af et diskproblem eller et underliggende problem.
  • Selvom drevet endnu ikke er mislykket, skal det stadig kontrolleres ved hjælp af nedenstående trin:

1. Find ud af, hvilke fysiske diske der er knyttet til den disk, som Avamar har suspenderet. Problemer med fysisk disk i en virtuel disk suspendering ville være en grundlæggende årsag til en suspendering:

avsysreport pdisk vdisk=x 

Hvor x er nummeret på den virtuelle disk (datapartition), der er blevet afbrudt. Hvis den første datapartition f.eks. viser suspenderede striber, skal du forespørge vdis=0.

2. Kontroller, at der ikke er diskfejl, forudsagte fejl eller andre fejl på det fysiske diskniveau.

3. Bekræft, at der ikke er nogen SCSI-fejl på fysiske diske, der repræsenterer den virtuelle disk på den pågældende node (bestemt i trin 1). 

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

4. Virtuelle diske i skrivebeskyttet tilstand kan forårsage diskstop på grund af lav I/O. Kontroller skrivepolitikken på controlleren:

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

Hvis der registreres problemer i trin 2-4, skal du åbne en SR hos Dell Technologies Avamar Support for yderligere undersøgelse.

Scenarie# 3: Gennemgå standardindstillingen perftriallimit indstillinger:

1. Kontroller, at ikonet perftriallimit er indstillet til 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Hvis ikonet perftriallimit er andet end nul:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"