Avamar: Awarie zawieszonych partycji, przeplotów i hfscheck w systemie Avamar

1. W interfejsie użytkownika serwera administratora Avamar może pojawić się następujący błąd: Ten komunikat może generować zgłoszenie serwisowe typu Dial Home (SR):

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

2. Komunikaty WARN związane z perfbeat są zgłaszane w węzłach przechowywania danych w /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. Polecenie status.dpn dane wyjściowe pokazują, że dysk ma zawieszone przeploty:
(Te dane wyjściowe są tworzone tylko wtedy, gdy wystąpi "WARN <1084>").

Oto przykład:

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) 

Dane wyjściowe pokazują, że istnieje 2374 zawieszonych pasków.

4. Polecenie hfscheck kończy się niepowodzeniem, jeśli partycja zostanie zawieszona, podczas gdy hfscheck jest uruchomiony. Przykład błędu z /data01/hfscheck/err.log lub /data01/cur/err.log są: 

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

Okresowo, domyślnie co pięć minut, gsan "testuje" I/O podsystemu, wykonując małe odczyty z partycji danych.

Sprawdza ona, czy wydajność odczytu wynosi 10% wydajności normalnej.

W poniższym przykładzie komunikat wskazuje, że w określonym węźle, który wygenerował komunikat ostrzegawczy, średnia wydajność odczytu w większej liczbie prób, podczas gdy hfscheck wynosi około 54,03 MB/s. Jednak w tym konkretnym teście rzeczywista wydajność wyniosła 0,57 MB/s, czyli poniżej "limitu" 10% średniej wartości, czyli 5,4029 MB/s.

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

Pierwotnym celem tego testu było ostrzeżenie, że wystąpił jakiś problem z I/O podsystem, który powoduje zbyt niskie tempo odczytu. 

W tym przypadku wolniej niż 10% "przeciętnego" dysku I/O wydajność.

Polecenie perftriallimit Określa liczbę kolejnych testów odczytu dysku, które muszą wykraczać poza tolerancję perfbeat Istnieje podejrzenie, że dysk może ulec degradacji.

Polecenie perfinterval (domyślnie 300 s lub 5 minut) określa, jak długo należy czekać między kolejnymi perftriallimit test.

When (Kiedy) perfbeat podejrzewa, że dysk uległ degradacji, informuje o tym gsan aby osiągnąć zimny stan (zatrzymaj całą aktywność związaną z dyskiem). 

Czeka co najwyżej 20 minut (podłączony na stałe) na gsan Aby osiągnąć ten stan przed przekroczeniem limitu czasu i nie zawieszać dysku.

Jeśli zostanie osiągnięty stan zimny, perfbeat Wykonuje perfcoldtriallimit (wartość domyślna 4) więcej testów odczytu w odstępach perfcoldinterval (domyślnie: 30) sekund odstępu.

Tylko wtedy, gdy wszystkie te testy wykażą, że dysk nadal uległ degradacji, zostanie on zawieszony.

Możliwe przyczyny zawieszenia dysków:

• Podczas próby osiągnięcia stanu zimnego gsan zawsze czeka co najmniej minutę (podłączony na stałe). Czeka również na wszystkie oczekujące dyski gsan I/O w celu zakończenia lub zawieszenia ich działalności. Jednak po osiągnięciu zimnego stanu system operacyjny może nadal wykonywać dysk I/O, na przykład wypłukiwanie pamięci podręcznej. To opróżnianie jest jednym z możliwych wyjaśnień niepotrzebnego zawieszania dysków. W przypadku większej ilości pamięci może być znacznie więcej danych z pamięci podręcznej do opróżnienia.

• Innym możliwym wyjaśnieniem jest to, że informacje o historii wydajności nie przewidują dokładnie, jaka powinna być oczekiwana wydajność odczytu dysku podczas różnych gsan z uwagi na fakt, że gsan's Zachowanie zmieniło się zbyt szybko, aby można było to odzwierciedlić w historii (historia to średnia z pomiarów wydajności z ostatnich 10 dni).

• Innym możliwym wyjaśnieniem jest to, że może wystąpić problem, taki jak nie czekanie na wszystkie gsan dysk I/O działania mające na celu zakończenie lub zawieszenie ich działania przed osiągnięciem stanu zimnego.

Ponadto badania wykazały, że w okresie hfscheck ”indexsweep" (gdy wszystkie skróty w paskach indeksu są odczytywane, a następnie wykonywane są masowe losowe zapisy w wielu plikach dziennika odniesienia do danych (DRL)) testowany I/O Wydajność spada przez dłuższy czas.

W Avamar Data Store Gen4s, Gen4s i Gen4T operacje zapisu zostały potraktowane priorytetowo w stosunku do operacji odczytu, a znaczenie testowania wydajności odczytu I/O podsystemu jest znacznie niższy. Ponadto niektóre dyski (np. Seagate Megalodon dyski) stosują różne techniki, które mogą mylić testy wykonywane przez perfbeat nitka.

Opis:

Zazwyczaj w gsan Dzienniki:

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

Ostrzeżenie <0968> wskazuje, że była to osoba gsan I/O test, który był powolny.

Ten komunikat można bezpiecznie zignorować.

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

Ostrzeżenie <1051> wskazuje, że było wystarczająco dużo powolnych odczytów, aby gsan Rozważano wprowadzenie partycji danych w stan wstrzymania, ale zdecydowano się tego nie robić. Na to MSG_ERR_UNNECESSARY wskazuje.

Ten komunikat można bezpiecznie zignorować.

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

Ostrzeżenie <1084> wskazuje, że gsan umieścił partycję danych w "stanie zawieszenia".

Tego komunikatu nie można zignorować.

Rozwiązanie:

Jeśli paski są w stanie wstrzymania, skorzystaj z poniższych wskazówek, aby zbadać i skorygować następujące scenariusze:

Wykonaj następujące czynności, aby zidentyfikować położenie zawieszonej partycji:

1. Zaloguj się do węzła Avamar Utility Node jako „admin”.

2. Podnieś poziom uprawnień do uprawnień root.

3. Załaduj klucze główne na Avamar: Logowanie się na serwerze Avamar i ładowanie różnych kluczy.

4. Uruchom następujące polecenie, aby określić lokalizację zawieszonej partycji:

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

5. Przejrzyj scenariusze w odniesieniu do powyższych wyników:

• • Nie jest wymagane dalsze działanie. Paski automatycznie powracają do trybu online. Jest wysoce prawdopodobne, że hfscheck były uruchomione. 

• • Jeśli paski automatycznie powracają do trybu online, istnieje duże prawdopodobieństwo, że wyrzucanie elementów bezużytecznych lub hfscheck były uruchomione.
  • WAŻNE: Może to wskazywać na problem z dyskiem lub inny podstawowy problem.
  • Mimo że dysk jeszcze nie uległ awarii, należy ją sprawdzić, wykonując poniższe czynności:

1. Określ, które dyski fizyczne są powiązane z dyskiem, który został zawieszony przez Avamar. Problemy z zawieszaniem dysku fizycznego w dysku wirtualnym są główną przyczyną zawieszenia:

avsysreport pdisk vdisk=x 

Gdzie x oznacza numer dysku wirtualnego (partycji danych), który został zawieszony. Jeśli na przykład pierwsza partycja danych zawiera zawieszone paski, zapytanie vdis=0.

2. Sprawdź, czy nie ma awarii dysków, przewidywanych i innych błędów na poziomie dysku fizycznego.

3. Upewnij się, że nie ma błędów SCSI na dyskach fizycznych, które reprezentują dysk wirtualny w danym węźle (określone w kroku 1). 

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

4. Dyski wirtualne w trybie zapisu przez mogą powodować wstrzymanie dysku z powodu niskiego I/O. Sprawdź zasady zapisu na kontrolerze:

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

Jeśli w krokach 2–4 zostaną wykryte jakiekolwiek problemy, otwórz zgłoszenie serwisowe Dell Technologies Avamar w celu dokładniejszego zbadania.

Scenariusz # 3: Przejrzyj wartość domyślną perftriallimit Ustawienia:

1. Sprawdź, czy perftriallimit jest ustawiona na 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Jeśli trzeba odzyskać perftriallimit jest czymś innym niż zero:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"