Avamar: Deaktiverte partisjoner, striper og hfscheck-feil på Avamar

1. Følgende feil kan vises i brukergrensesnittet for Avamar Administrator Server. Meldingen kan generere en forespørsel om hjemmetjeneste (SR):

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

2. ADVARE meldinger relatert til perfbeat tråden rapporteres om datalagringsnodene 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. Informasjonen i status.dpn Utdataene viser at en disk har deaktiverte striper:
(Disse utdataene produseres bare når "WARN <1084>" forekommer.)

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 utgangen viser at det er 2374 hengende striper.

4. Informasjonen i hfscheck mislykkes hvis en partisjon blir suspendert mens hfscheck kjører. Et eksempel på en feil 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

Hvert femte minutt som standard "tester" gsan med jevne mellomrom I/O delsystem ved å utføre små avlesninger fra datapartisjonene.

Den verifiserer om leseytelsen er 10 % av normal ytelse.

I eksemplet nedenfor angir meldingen at på den bestemte noden som genererte advarselsmeldingen, er gjennomsnittlig leseytelse over et lengre antall forsøk mens hfscheck kjørte er omtrent 54,03 MB/sekund. Men på denne testen var den faktiske ytelsen 0,57 MB / sekund, som er under "grensen" på 10% av gjennomsnittsverdien, eller 5,4029 MB / sekund.

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

Det opprinnelige formålet med denne testen var å gi noen advarsel om at det var noe problem med I/O delsystem som fører til at leseytelsen blir for treg. 

I dette tilfellet, langsommere enn 10% av den "gjennomsnittlige" disken I/O prestasjon.

Informasjonen i perftriallimit Angir antall påfølgende disklesetester som må være utenfor toleranse før perfbeat mistenker at en disk kan bli degradert.

Informasjonen i perfinterval (standard 300-tallet eller 5 minutter) angir hvor lenge det skal vente mellom hver perftriallimit prøve.

Når perfbeat mistenker at en disk er degradert, forteller den gsan for å bli kald (stopp all diskrelatert aktivitet). 

Den venter maksimalt 20 minutter (fastkoblet) på gsan for å oppnå denne tilstanden før du blir tidsavbrutt og ikke deaktiverer disken.

Hvis kald tilstand er nådd, da perfbeat Utfører perfcoldtriallimit (standard 4) Flere lesetester med mellomrom perfcoldinterval (standard med 30 sekunders mellomrom.

Bare hvis alle disse testene indikerer at disken fortsatt er degradert, vil disken bli suspendert.

Mulige årsaker til suspenderte disker:

• Når du prøver å nå en kald tilstand, venter gsan alltid minst ett minutt (hardwired). Den venter også på alle ventende gsan-disker I/O relaterte aktiviteter for å fullføre eller avbryte operasjonen. Når en kald tilstand er nådd, kan det imidlertid hende at operativsystemet fortsatt utfører disken I/O, for eksempel å skylle ut hurtigbufferen. Denne spyleaktiviteten er en mulig forklaring på hvorfor disker blir suspendert unødvendig. Med større mengder minne kan det være mye mer hurtigbufferdata å spyle.

• En annen mulig forklaring er at ytelseshistorikkinformasjonen ikke nøyaktig forutsier hva den forventede diskleseytelsen skal være under ulike gsan aktiviteter fordi gsan's Atferden har endret seg for raskt til at historikken reflekteres (historikken er et gjennomsnitt av ytelsesmålingene som har vært verdt de siste 10 dagene).

• En annen mulig forklaring er at det kan være et problem, for eksempel å ikke vente på alt gsan Disken I/O aktiviteter for å fullføre eller suspendere operasjonen før de når en kald tilstand.

Videre viste forskning at i løpet av hfscheck »indexsweep" fase (når alle hashes i indeksen stripene blir lest og deretter utføre massive tilfeldige skriver til mange Data Referenced Log (DRL) filer) den testede I/O Ytelsen faller av i en betydelig periode.

På Avamar Data Store Gen4, Gen4s og Gen4T har skriveoperasjoner blitt prioritert over leseoperasjoner og betydningen av å teste leseytelsen til I/O delsystemet er mye lavere. Noen stasjoner (som f.eks. Seagate Megalodon stasjoner) bruker noen forskjellige teknikker som kan forvirre testene som utføres av den av perfbeat tråd.

Bakgrunn:

Du ser vanligvis tre forskjellige advarsler i gsan Logger:

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

Advarsel <0968> indikerer at det var en person gsan I/O Test som var treg.

Denne meldingen kan trygt ignoreres.

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

Advarsel <1051> indikerer at det var nok treg lesing at gsan ble vurdert å sette datapartisjonen i suspendert tilstand, men bestemte seg for ikke å gjøre det. Det er det MSG_ERR_UNNECESSARY indikerer.

Denne meldingen kan trygt ignoreres.

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

Advarsel <1084> indikerer at gsan satte datapartisjonen i en "suspendert tilstand".

Denne meldingen må ikke ignoreres.

Løsning:

Hvis stripene er deaktivert, bruker du følgende retningslinjer til å undersøke og rette opp følgende scenarier:

Utfør følgende for å identifisere plasseringen av den suspenderte partisjonen:

1. Logg på Avamar-verktøynoden som administrator.

2. Hev til rotprivilegium.

3. Last inn rotnøklene per Avamar: Slik logger du på en Avamar-server og laster inn ulike nøkler.

4. Kjør følgende kommando for å identifisere plasseringen av den suspenderte partisjonen:

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

5. Gå gjennom scenariene i forbindelse med resultatene ovenfor:

• • Kreves ingen handlinger. Striper kommer automatisk tilbake på nettet. Det er høyst sannsynlig at hfscheck kjørte. 

• • Hvis striper returnerer online automatisk, er det høyst sannsynlig at søppelinnsamling eller hfscheck kjørte.
  • VIKTIG: Dette kan være en indikasjon på et diskproblem eller et underliggende problem.
  • Selv om stasjonen ennå ikke har mislyktes, bør den fortsatt kontrolleres ved å bruke trinnene nedenfor:

1. Finn ut hvilke fysiske disker som er knyttet til disken som Avamar har deaktivert. Problemer med at en fysisk disk i en virtuell disk suspenderer, er en grunnleggende årsak til avbrudd:

avsysreport pdisk vdisk=x 

Der x er nummeret på den virtuelle disken (datapartisjonen) som er deaktivert. Hvis for eksempel den første datapartisjonen viser hengende striper, spør du vdis=0.

2. Kontroller at det ikke er noen diskfeil, forventede feil eller andre feil på det fysiske disknivået.

3. Kontroller at det ikke er noen SCSI-feil på fysiske disker som representerer den virtuelle disken på den aktuelle noden (bestemt i trinn 1). 

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

4. Virtuelle disker i gjennomskrivingsmodus kan forårsake at disken avbrytes på grunn av lav hastighet I/O. Kontroller skrivepolicyen på kontrolleren:

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

Hvis det oppdages problemer i trinn 2–4, må du åpne en SR med Dell Technologies Avamar-kundestøtte for ytterligere undersøkelser.

Scenario # 3: Se gjennom standarden perftriallimit Innstillinger:

1. Kontroller at perftriallimit er satt til 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Hvis perftriallimit er noe annet enn null:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"