Avamar: Opgeschorte partities, stripes en HFSCHECK-fouten op Avamar

1. De volgende fout wordt mogelijk weergegeven in de gebruikersinterface van de Avamar Administrator Server. Het bericht kan een Dial Home Service Request (SR) genereren:

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

2. WAARSCHUW berichten met betrekking tot perfbeat datastorageknooppunten worden gerapporteerd op de datastorageknooppunten in de /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. De status.dpn output geeft aan dat een schijf strepen heeft onderbroken:
(Deze output wordt alleen geproduceerd wanneer "WARN <1084>" voorkomt.)

Bijvoorbeeld:

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) 

Deze output laat zien dat er 2374 hangende strepen zijn.

4. De hfscheck mislukt als een partitie wordt onderbroken terwijl het hfscheck wordt uitgevoerd. Een voorbeeld van een fout van /data01/hfscheck/err.log of /data01/cur/err.log zijn: 

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

Periodiek, standaard elke vijf minuten, "test" de gsan de I/O subsysteem door kleine leesbewerkingen uit te voeren vanaf de datapartities.

Hiermee wordt gecontroleerd of de leesprestaties 10% zijn van die van de normale prestaties.

In het onderstaande voorbeeld geeft het bericht aan dat, op het specifieke knooppunt dat het waarschuwingsbericht heeft gegenereerd, de gemiddelde leesprestaties over een uitgebreid aantal proeven terwijl hfscheck is ongeveer 54,03 MB/seconde. Bij deze specifieke test waren de werkelijke prestaties echter 0,57 MB/seconde, wat onder de "limiet" van 10% van de gemiddelde waarde ligt, of 5,4029 MB/seconde.

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

Het oorspronkelijke doel van deze test was om een waarschuwing te geven dat er een probleem was met de I/O subsysteem dat ervoor zorgt dat de leesprestaties te traag zijn. 

In dit geval langzamer dan 10% van de "gemiddelde" schijf I/O voorstelling.

De perftriallimit Specificeert het aantal opeenvolgende schijfleestests dat buiten de tolerantie moet vallen perfbeat Vermoedt dat een schijf mogelijk is verslechterd.

De perfinterval (standaard 300 s of 5 minuten) geeft aan hoe lang er moet worden gewacht tussen elke perftriallimit test.

Wanneer perfbeat vermoedt dat een schijf is gedegradeerd, vertelt het de gsan om een koude status te bereiken (stop alle schijfgerelateerde activiteit). 

Het wacht maximaal 20 minuten (bedraad) op de gsan om deze toestand te bereiken voordat er een time-out optreedt en de schijf niet wordt onderbroken.

Als de koude toestand is bereikt, dan perfbeat Voert perfcoldtriallimit (standaard 4) meer leestests verspreid over tussenruimte perfcoldinterval (standaard 30) seconden uit elkaar.

Alleen als al deze tests aangeven dat de schijf nog steeds verslechterd is, wordt de schijf onderbroken.

Mogelijke redenen voor zwevende schijven:

• Wanneer u probeert een koude toestand te bereiken, wacht de gsan altijd minstens een minuut (bedraad). Er wordt ook gewacht op alle gsan-schijven die in behandeling zijn I/O gerelateerde activiteiten om hun werking te voltooien of op te schorten. Echter, nadat een koude status is bereikt, kan het besturingssysteem nog steeds presteren schijf I/O, zoals het leegmaken van de cache. Deze spoelactiviteit is een mogelijke verklaring waarom schijven onnodig worden onderbroken. Met de grotere hoeveelheden geheugen kunnen er veel meer cachegegevens worden geleegd.

• Een andere mogelijke verklaring is dat de informatie over de prestatiegeschiedenis niet nauwkeurig voorspelt wat de verwachte leesprestaties van de schijf zouden moeten zijn tijdens verschillende gsan activiteiten omdat de gsan's Het gedrag is te snel veranderd om in de geschiedenis weer te geven (de geschiedenis is een gemiddelde van de prestatiemetingen van de laatste 10 dagen).

• Een andere mogelijke verklaring is dat er een probleem kan zijn, zoals niet op alles wachten gsan schijf I/O activiteiten om hun werking te voltooien of op te schorten voordat ze een koude toestand bereiken.

Verder is uit onderzoek gebleken dat tijdens de hfscheck "indexsweep" fase (wanneer alle hashes in de index stripes worden gelezen en vervolgens massale willekeurige schrijfbewerkingen uitvoeren naar veel Data Referenced Log (DRL)-bestanden) wordt de geteste I/O De prestaties nemen gedurende een aanzienlijke periode af.

In Avamar Data Store Gen4, Gen4s en Gen4T hebben schrijfbewerkingen prioriteit gekregen op leesbewerkingen en het belang van het testen van de leesprestaties van de I/O subsysteem is veel lager. Sommige schijven (zoals Seagate Megalodon schijven) een aantal verschillende technieken gebruiken die de tests die worden uitgevoerd kunnen verwarren met die van de perfbeat draad.

Achtergrond:

Er zijn doorgaans drie verschillende waarschuwingsberichten in de gsan Logs:

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

Waarschuwing <0968> geeft aan dat er een persoon was gsan I/O test die traag was.

Dit bericht kan veilig worden genegeerd.

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

Waarschuwing <1051> geeft aan dat er voldoende trage lezingen waren dat de gsan Er werd overwogen om de gegevenspartitie in de opgeschorte status te zetten, maar besloot dit niet te doen. Dat is wat MSG_ERR_UNNECESSARY aangeeft.

Dit bericht kan veilig worden genegeerd.

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

Waarschuwing <1084> geeft aan dat de gsan de datapartitie in een "opgeschorte status" heeft gezet.

Deze boodschap mag niet worden genegeerd.

Oplossing:

Als de strepen in een hangende status worden gezet, gebruikt u de volgende richtlijnen om de volgende scenario's te onderzoeken en te corrigeren:

Voer het volgende uit om de locatie van de zwevende partitie te identificeren:

1. Meld u aan bij het Avamar hulpprogrammaknooppunt als beheerder.

2. Verheffen tot rootprivilege.

3. Laad de basissleutels per Avamar: Aanmelden bij een Avamar Server en verschillende sleutels laden.

4. Voer de volgende opdracht uit om de locatie van de opgeschorte partitie te identificeren:

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

5. Bekijk de scenario's met betrekking tot de bovenstaande resultaten:

• • is verdere actie niet nodig. Stripes keren automatisch online terug. Het is zeer waarschijnlijk dat hfscheck aan het rennen waren. 

• • Als stripes automatisch online terugkeren, is de kans groot dat garbage collection of hfscheck aan het rennen waren.
  • BELANGRIJK: Dit kan een indicatie zijn van een schijfprobleem of een onderliggend probleem.
  • Hoewel de schijf nog niet defect is, moet deze toch worden gecontroleerd met behulp van de onderstaande stappen:

1. Bepaal welke fysieke schijven zijn gekoppeld aan de schijf die door Avamar is onderbroken. Problemen met een fysieke schijf in een virtuele schijf die wordt onderbroken, zijn een hoofdoorzaak voor een onderbreking:

avsysreport pdisk vdisk=x 

Waarbij x het nummer is van de virtuele schijf (datapartitie) die is onderbroken. Als de eerste gegevenspartitie bijvoorbeeld zwevende strepen weergeeft, query's vdis=0.

2. Controleer of er geen schijffouten, voorspelde storingen of andere fouten zijn op het niveau van de fysieke schijf.

3. Controleer of er geen SCSI-fouten zijn op fysieke schijven die de virtuele schijf op het betreffende knooppunt vertegenwoordigen (bepaald in stap 1). 

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

4. Virtuele schijven in de doorschrijfmodus kunnen schijfonderbrekingen veroorzaken als gevolg van een laag I/O. Controleer het schrijfbeleid op de controller:

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

Als er problemen worden gedetecteerd in stap 2-4, opent u een SR met Dell Technologies Avamar Support voor verder onderzoek.

Scenario # 3: Controleer de standaardwaarden perftriallimit Instellingen:

1. Controleer of het perftriallimit is ingesteld op 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Als de perftriallimit is iets anders dan nul:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"