Avamar: Pojemność systemu operacyjnego (OS) (ścieżka rozwiązania)

Rozwiązywanie problemów z pojemnością systemu operacyjnego w systemie Avamar

Ten artykuł o ścieżce rozwiązania ma na celu rozwiązanie problemów z pojemnością systemu operacyjnego w systemie Avamar.


Aby uzyskać wstępne pojęcia i wiedzę na temat pojemności systemu operacyjnego, zapoznaj się z artykułem szkoleniowym Avamar: Pojęcia dotyczące zarządzania pojemnością i szkolenia

Jak podsumowano w artykule szkoleniowym, do kontynuowania pracy w pozostałej części tego artykułu należy wykazać się rozsądną znajomością następujących tematów:

• Podstawowa wiedza na temat punktów kontrolnych (cp), walidacji punktów kontrolnych (hfscheck)i wyrzucanie elementów bezużytecznych (GC) oraz znaczenie każdego z nich
• Różnica między GSAN (tzw. "Pojemność użytkownika" i Pojemność systemu operacyjnego)
• Dane o obciążeniu punktów kontrolnych.
• Jeśli którakolwiek z partycji danych stanowi więcej niż 89% całkowitej fizycznej przestrzeni pojemności systemu operacyjnego, nie można uruchomić odzyskiwania pamięci.
• Im siatka Avamar jest bliższa 100% pojemności użytkownika, tym mniejsza jest dostępna pojemność systemu operacyjnego na potrzeby narzutu punktów kontrolnych.
• Czynniki, które przyczyniają się do narzutu punktów kontrolnych, w tym przetwarzanie asynchroniczne, liczba przechowywanych punktów kontrolnych, HFSCheck i ważność walidacji punktów kontrolnych i tak dalej.
• Jak sprawdzić poziomy pojemności systemu operacyjnego
• Podstawowe działania zmniejszające pojemność systemu operacyjnego

Często najłatwiej jest rozpatrywać pojemność systemu operacyjnego jako rozmiar GSAN danych (a dokładniej miejsca przydzielonego na te dane) oraz narzut generowany przez punkty kontrolne Avamar. Im większa liczba punktów kontrolnych i im wyższy współczynnik zmian, tym większy narzut punktu kontrolnego.

Skutki dużej pojemności systemu operacyjnego mogą obejmować:

• Błąd wyrzucania elementów bezużytecznych: GC kończy się niepowodzeniem z MSG_ERR_DISKFULL jeśli pojemność systemu operacyjnego przekroczy 89%
• Błąd tworzenia kopii zapasowej lub replikacji: Tworzenie kopii zapasowych lub replikacja przychodząca może zakończyć się niepowodzeniem z MSG_ERR_STRIPECREATE, jeśli pojemność systemu operacyjnego wzrośnie powyżej 90%. (Dzieje się tak tylko wtedy, gdy konieczne jest utworzenie nowego paska danych. Jeśli nowy przeplot nie jest potrzebny, kopie zapasowe i replikacja mogą nadal działać pomyślnie).
• Błąd punktu kontrolnego: Punkt kontrolny kończy się niepowodzeniem z MSG_ERR_DISKFULL, jeśli pojemność systemu operacyjnego wzrośnie powyżej 96%

Jak może wskazywać powyższe, pojemność systemu operacyjnego jest często pierwszym typem pojemności Avamar, którą należy rozwiązać, gdy inne pojemności Avamar również są wysokie. Co najmniej nie można uruchomić wyrzucania elementów bezużytecznych, gdy pojemność systemu operacyjnego osiągnie określony poziom, nawet gdy GSAN lub pojemność użytkowników jest również wysoka.

Ogólnie pojemność systemu operacyjnego jest uważana za wysoką, gdy GC ulegnie awarii z MSG_ERR_DISKFULL, jeśli pojemność systemu operacyjnego wzrośnie powyżej 89%. Jeśli pojemność systemu operacyjnego jest mniejsza niż 89%, nie ma to wpływu na żadne zadania konserwacji. 

Pojemność systemu operacyjnego Avamar może wzrosnąć z dowolnej kombinacji następujących powodów:

• Wysoki współczynnik zmian danych kopii zapasowej, dodawanie "za dużo za szybko"
• Wysokie GSAN lub "Pojemność użytkownika", która pozostawia mniej miejsca na pojemność systemu operacyjnego, a czasami może nawet skutkować większą szybkością zmian
• Punkt kontrolny nie został ukończony, co skutkuje stanem "MSG_ERR_DISKFULL" widocznym w danych wyjściowych.
• Walidacja punktu kontrolnego (hfscheck) nie powiodło się lub nie zostało ostatnio uruchomione, przez co najstarsze punkty kontrolne nie mogą zostać wycofane lub usunięte
• Punkty kontrolne nie są wycofywane z innych powodów, w tym z powodu zbyt wysokich ustawień przechowywania punktów kontrolnych

Duża pojemność systemu operacyjnego na innych partycjach dysku może wynikać z różnych przyczyn, w tym z nieprawidłowego rozmieszczenia danych, zbyt dużych plików dziennika itp.

• Aby uzyskać szybkie tło, punkty kontrolne Avamar są migawką tylko do odczytu i łączem do danych na żywo. Ponieważ jest on tworzony za pomocą łączy, punkt kontrolny będzie zużywał zero dodatkowego miejsca na dysku natychmiast po jego utworzeniu. Jeśli nie ma żadnych zmian w aktywnych danych, punkt kontrolny nie używa dodatkowego miejsca.
• Zmienia się to, gdy dane na żywo są modyfikowane, podczas gdy punkt kontrolny pozostaje taki sam. W tym momencie istnieje oryginalna kopia danych w punkcie kontrolnym i zaktualizowana kopia zmodyfikowanych danych. Jest to całkowicie celowe i celowe. Dlatego jest zarezerwowana przestrzeń pojemności systemu operacyjnego.
• Jeśli jednak ilość lub szybkość zmian danych wzrośnie drastycznie i nagle, może to spowodować nietypowy skok rozmiaru pojemności systemu operacyjnego i zostać uznane za "zbyt duże i zbyt szybkie"
• Polecenie capacity.sh pokaże to jako przyczynę podczas porównywania danych wyjściowych z kilku dni.

Jeśli zadania konserwacyjne, w tym odśmiecanie pamięci, kończą się niepowodzeniem z powodu dużej pojemności systemu operacyjnego Avamar, wykonaj następujące czynności:

1. Zbierz wszystkie informacje o pojemności Avamar, aby namalować obraz sytuacji: Avamar: Zbieranie informacji wymaganych do rozwiązywania problemów z pojemnością.

2. Następnie sprawdź, jak duża jest pojemność systemu operacyjnego i jakie działania mogą być wymagane. W artykule dotyczącym zbierania danych można to znaleźć za pomocą następującego polecenia: 

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Sposób działania Avamar polega na tym, że pokazana najwyższa wartość fs-percent-full jest czynnikiem ograniczającym bieżącą pojemność systemu operacyjnego. W zależności od typu i rozmiaru węzła liczba partycji danych przechowujących dane kopii zapasowych i punktów kontrolnych może się różnić. W systemie operacyjnym Linux mogą to być dyski lub partycje, takie jak "/data0*", gdzie "*" może być pojedynczą cyfrą. Liczba partycji danych zależy od typu węzła, generacji sprzętu i rozmiaru (i nie można jej zmienić).

3. Przejrzyj liczbę znalezionych punktów kontrolnych i czas ich weryfikacji z poziomu polecenia:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Sprawdź, czy operacje punktu kontrolnego nie kończą się niepowodzeniem z "MSG_ERR_DISKFULL", uruchamiając następujące polecenie:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Jeśli punkty kontrolne zostały ukończone pomyślnie, widoczne są dane wyjściowe podobne do poniższych:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

W przypadku niepowodzenia z powodu MSG_ERR_DISKFULL wyświetlane są następujące dane wyjściowe:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Określ szybkość zmian:

capacity.sh  

Przykładowe dane wyjściowe:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Czasami, jeśli powtarza się sytuacja z wysokim tempem zmian lub "za dużo za szybko", można to złagodzić, obniżając ogólny GSAN lub pojemność użytkownika. Z niższym GSAN jest nieco więcej miejsca na narzut pojemności systemu operacyjnego, a także powoduje mniej zmian kontenerów do przechowywania danych. Aby uzyskać pomoc dotyczącą tego scenariusza, otwórz zgłoszenie serwisowe w zespole pomocy technicznej Dell Technologies Avamar, a w przeciwnym razie przejdź do kroku 7.

7. Problemy z dużą pojemnością systemu operacyjnego na innych partycjach dysków mają różne przyczyny, ale rozwiązania wymagają pomocy technicznej. Otwórz zgłoszenie serwisowe w zespole pomocy technicznej Dell Technologies Avamar, a w przeciwnym razie przejdź do kroku 7.

Po zajęciu się pojemnością systemu operacyjnego GSAN można sprawdzić pojemność lub inne pojemności systemu Avamar. Zapoznaj się z artykułem Rozwiązywanie problemów, problemy i pytania dotyczące pojemności Avamar — wszystkie pojemności (ścieżka rozwiązania)