Avamar: Angehaltene Partitionen, Stripes und hfscheck-Fehler auf Avamar

1. Der folgende Fehler wird möglicherweise in der Benutzeroberfläche des Avamar Administrator-Servers angezeigt. Die Meldung kann einen Dial-Home-Service-Request (SR) erzeugen:

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

2. WARN-Meldungen im Zusammenhang mit perfbeat Thread auf den Datenspeicher-Nodes im /data01/cur/gsan.logaus:

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. Die Spalte status.dpn Die Ausgabe zeigt, dass die Stripes auf einer Festplatte angehalten sind:
(Diese Ausgabe wird nur erzeugt, wenn "WARN <1084>" auftritt.)

Zum Beispiel:

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) 

Diese Ausgabe zeigt, dass 2374 schwebende Stripes vorhanden sind.

4. Die Spalte hfscheck schlägt fehl, wenn eine Partition angehalten wird, während die hfscheck ausgeführt wird. Ein Beispiel für einen Fehler von /data01/hfscheck/err.log oder /data01/cur/err.log sind: 

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

In regelmäßigen Abständen, standardmäßig alle fünf Minuten, "testet" das GSAN die I/O Subsystem durch Durchführen kleiner Lesevorgänge von den Datenpartitionen.

Es wird überprüft, ob die Leseleistung 10 % der normalen Leistung entspricht.

Im folgenden Beispiel zeigt die Meldung an, dass auf dem bestimmten Node, der die Warnmeldung generiert hat, die durchschnittliche Leseleistung über eine erweiterte Anzahl von Versuchen während hfscheck lief beträgt ca. 54,03 MB/Sekunde. Bei diesem speziellen Test lag die tatsächliche Leistung jedoch bei 0,57 MB/Sekunde und damit unter dem "Limit" von 10 % des Durchschnittswerts oder 5,4029 MB/Sekunde.

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

Der ursprüngliche Zweck dieses Tests bestand darin, eine Warnung bereitzustellen, dass ein Problem mit dem I/O Subsystem, das dazu führt, dass die Leseleistung übermäßig langsam ist. 

In diesem Fall langsamer als 10 % der "durchschnittlichen" Festplatte I/O Leistung.

Die Spalte perftriallimit Gibt die Anzahl der aufeinanderfolgenden Festplattenlesetests an, die außerhalb der Toleranz liegen müssen, bevor perfbeat vermutet, dass ein Laufwerk heruntergestuft ist.

Die Spalte perfinterval (Standardwert 300 oder 5 Minuten) Gibt an, wie lange zwischen den einzelnen Wartezeiten gewartet werden soll perftriallimit Test.

Beim Herunterladen von perfbeat vermutet, dass eine Festplatte heruntergestuft ist, teilt sie dem gsan , um einen inaktiven Status zu erreichen (stoppen Sie alle Festplattenaktivitäten). 

Er wartet höchstens 20 Minuten (fest verdrahtet) auf die gsan , um diesen Status zu erreichen, bevor eine Zeitüberschreitung auftritt und das Laufwerk nicht angehalten wird.

Wenn der kalte Status erreicht ist, dann perfbeat Führt perfcoldtriallimit (Standardwert 4) Mehr Lesetests im Abstand perfcoldinterval (Standardeinstellung 30) Sekundenabstand.

Nur wenn alle diese Tests darauf hindeuten, dass die Festplatte noch immer heruntergestuft ist, wird sie angehalten.

Mögliche Gründe für gesperrte Festplatten:

• Beim Versuch, einen kalten Zustand zu erreichen, wartet das GSAN immer mindestens eine Minute (fest verdrahtet). Außerdem wird auf alle ausstehenden GSAN-Festplatten gewartet. I/O damit zusammenhängenden Tätigkeiten, ihren Betrieb abzuschließen oder auszusetzen. Nach Erreichen eines Cold-Status führt das Betriebssystem jedoch möglicherweise weiterhin Festplatten aus I/O, z. B. das Leeren des Caches. Diese Leerungsaktivität ist eine mögliche Erklärung dafür, warum Festplatten unnötigerweise angehalten werden. Je größer der Arbeitsspeicher ist, desto mehr Cachedaten müssen bereinigt werden.

• Eine weitere mögliche Erklärung ist, dass die Informationen zum Leistungsverlauf nicht genau vorhersagen, wie hoch die erwartete Leseleistung der Festplatte während verschiedener gsan Tätigkeiten, weil die gsan's Das Verhalten hat sich zu schnell geändert, als dass es im Verlauf dargestellt werden könnte (der Verlauf ist der Durchschnitt der Leistungsmessungen der letzten 10 Tage).

• Eine andere mögliche Erklärung ist, dass es ein Problem geben könnte, z. B. wenn nicht auf alle gsan Scheibe I/O -Aktivitäten, um ihren Vorgang abzuschließen oder anzuhalten, bevor sie einen inaktiven Status erreichen.

Darüber hinaus haben Untersuchungen gezeigt, dass während der hfscheck “indexsweepPhase "(wenn alle Hashes in den Index-Stripes gelesen werden und dann massive zufällige Schreibvorgänge in viele DRL-Dateien (Data Referenced Log) durchgeführt werden) I/O Die Leistung fällt über einen längeren Zeitraum ab.

Auf Avamar Data Store Gen4, Gen4s und Gen4T wurden Schreibvorgänge gegenüber Lesevorgängen priorisiert und die Bedeutung des Testens der Leseperformance der I/O Subsystem viel niedriger ist. Außerdem können einige Laufwerke (z. B. Seagate Megalodon Laufwerke) verwenden verschiedene Techniken, die die durchgeführten Tests mit denen des perfbeat Faden.

Hintergrund:

In der Regel gibt es drei verschiedene Warnmeldungen in der gsan baumstämme:

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

Warnung <0968> weist darauf hin, dass eine Person gsan I/O Test, der langsam war.

Diese Meldung kann bedenkenlos ignoriert werden.

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

Warnung <1051> weist darauf hin, dass genügend langsame Lesevorgänge vorhanden waren, dass die gsan Es wurde erwogen, die Datenpartition in den angehaltenen Zustand zu versetzen, entschied sich jedoch dagegen. Darauf deutet MSG_ERR_UNNECESSARY hin.

Diese Meldung kann bedenkenlos ignoriert werden.

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

Warnung <1084> weist darauf hin, dass GSAN die Datenpartition in einen "angehaltenen Status" versetzt hat.

Diese Nachricht darf nicht ignoriert werden.

Lösung:

Wenn die Stripes in einen angehaltenen Zustand versetzt werden, verwenden Sie die folgenden Richtlinien, um die folgenden Szenarien zu untersuchen und zu korrigieren:

Führen Sie die folgenden Schritte aus, um den Speicherort der angehaltenen Partition zu identifizieren:

1. Melden Sie sich beim Avamar Utility Node als AdministratorIn an.

2. Erhöhen Sie das Root-Recht.

3. Laden Sie die Root-Schlüssel pro Avamar: So melden Sie sich bei einem Avamar-Server an und laden verschiedene Schlüssel.

4. Führen Sie den folgenden Befehl aus, um den Speicherort der angehaltenen Partition zu identifizieren:

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

5. Überprüfen Sie die Szenarien in Bezug auf die oben genannten Ergebnisse:

• • sind keine weiteren Maßnahmen erforderlich. Stripes werden automatisch online zurückgegeben. Es ist sehr wahrscheinlich, dass hfscheck liefen. 

• • Wenn Stripes automatisch online zurückgegeben werden, ist es sehr wahrscheinlich, dass die automatische Speicherbereinigung oder hfscheck liefen.
  • WICHTIG: Dies kann ein Hinweis auf ein Festplattenproblem oder ein zugrunde liegendes Problem sein.
  • Obwohl das Laufwerk noch nicht ausgefallen ist, sollte es dennoch mithilfe der folgenden Schritte überprüft werden:

1. Bestimmen Sie, welche physischen Laufwerke der Festplatte zugeordnet sind, die Avamar ausgesetzt hat. Probleme mit physischen Laufwerken innerhalb eines virtuellen Laufwerks, die angehalten werden, wären eine der Hauptursachen für ein Anhalten:

avsysreport pdisk vdisk=x 

Dabei steht x für die Nummer des virtuellen Laufwerks (Datenpartition), das angehalten wurde. Wenn die erste Datenpartition beispielsweise schwebende Stripes aufweist, führen Sie eine Abfrage durch vdis=0.

2. Stellen Sie sicher, dass keine Festplattenausfälle, vorhergesagten Ausfälle oder andere Fehler auf der Ebene des physischen Laufwerks vorliegen.

3. Vergewissern Sie sich, dass keine SCSI-Fehler auf physischen Laufwerken vorhanden sind, die das virtuelle Laufwerk auf dem betreffenden Node darstellen (ermittelt in Schritt 1). 

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

4. Virtuelle Laufwerke im Durchschreibmodus können zu Festplattensperren aufgrund von niedrigen I/O. Überprüfen Sie die Schreibrichtlinie auf dem Controller:

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

Wenn in den Schritten 2 bis 4 Probleme erkannt werden, öffnen Sie zur weiteren Untersuchung eine SR beim Dell Technologies Avamar Support.

Szenario # 3: Überprüfen Sie die Standardeinstellung perftriallimit Einstellungen:

1. Überprüfen Sie, ob der perftriallimit ist auf 0 gesetzt:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Wenn die perftriallimit ist alles andere als Null:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"