Ścieżka rozwiązania pojemności GSAN lub użytkownika Avamar

Aby zapoznać się z początkowymi pojęciami i interpretacją pojemności systemu operacyjnego (OS), zobacz Avamar: ogólne szkolenie w zakresie pojemności — ścieżka rozwiązania

Często najłatwiej jest postrzegać pojemność GSAN jako przestrzeń i wykorzystanie przeznaczone na kopie zapasowe klientów.

• Podstawowa wiedza na temat deduplikacji
• Podstawowa wiedza na temat punktu kontrolnego, walidacji punktu kontrolnego (hfscheck) i Garbage Collection oraz znaczenia każdego z tych pojęć.
• Różnica między pojemnością GSAN (lub Użytkownika) a pojemnością systemu operacyjnego
• Zmień szybkość
• Stan stabilny

• Niepowodzenie tworzenia kopii zapasowej lub replikacji po zmianie stanu dostępu do sieci na „tryb administratora”

  • Zadanie tworzenia kopii zapasowej klienta może zakończyć się niepowodzeniem z komunikatem podobnym do następującego:  ”avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Automatyczne wyłączanie harmonogramu tworzenia kopii zapasowych (do momentu potwierdzenia i wyczyszczenia przez kogoś)

• 80% — ostrzeżenie o pojemności
• 95% — osiągnięto limit sprawdzania poprawności działania (czasami może to spowodować wyłączenie harmonogramu tworzenia kopii zapasowych, przynajmniej do momentu ręcznego potwierdzenia)
• 100% — osiągnięto limit serwera tylko-do-odczytu (siatka przechodzi w tryb administracyjny)

1. Ze względu na deduplikację Avamar musi zapisywać i przechowywać tylko drobne zmiany i różnice między zadaniami tworzenia kopii zapasowych każdego klienta. W miarę uruchamiania nowych kopii zapasowych (lub replikacji przychodzącej) może dodać nowe dane i zwiększyć pojemność lub wartość wykorzystania Avamar. 
2. Po upływie określonego czasu kopie zapasowe wygasną na podstawie skonfigurowanego czasu przechowywania i wygaśnięcia i nie można ich znaleźć w siatce Avamar dostępnej do przywrócenia. 
3. Po uruchomieniu zadania konserwacji Avamar o nazwie Garbage Collection (GC) znajduje wszystkie unikatowe porcje danych, które nie są już potrzebne z powodu wygasłych kopii zapasowych. GC sprawdza, czy żadne inne bieżące kopie zapasowe nie współdzielą tych samych danych (z powodu deduplikacji), a następnie usuwa lub zwalnia te fragmenty danych, które nie są już potrzebne, aby zmniejszyć pojemność lub wykorzystanie serwera Avamar.

Gdy ilość codziennie dodawanych danych przychodzących jest mniej więcej taka sama jak ilość danych usuwanych dziennie, nazywa się to „stanem stabilnym”. Jest to cel każdej zainstalowanej siatki Avamar.

Przed skonfigurowaniem nowej siatki Avamar wykonywane są ogólne obliczenia rozmiaru przed instalacją w celu określenia pojemności wymaganej do przechowywania danych kopii zapasowej. Obliczenia te opierają się na wymaganiach klientów dotyczących przechowywania danych i ilości danych, które mają zostać zarchiwizowane. Obliczane jest również, ile z tych danych można średnio zdeduplikować i tak dalej.

1. Narzędzie Garbage Collection nie działa prawidłowo
2. Garbage Collection ma niską wydajność lub nie działa wystarczająco długo
3. Szacunki dotyczące deduplikacji przed instalacją sieci Avamar nie były wystarczająco dokładne
4. Na tym serwerze Avamar tworzona jest kopia zapasowa danych innych niż obliczone przed instalacją sieci Avamar.
5. Inne powody

Sprawdź, czy każdy z poniższych kroków rozwiązywania problemów dotyczy środowiska:

Krok 1. Gromadzenie danych:

Upewnij się, że nie ma innych problemów niezwiązanych z przepustowością sieci Avamar. Jeśli są, mogą wymagać uwagi PRZED przystąpieniem do rozwiązywania problemów.

Obejmuje to błędy sprzętowe, problemy z integralnością danych (w tym węzły w trybie offline), paski w trybie offline, niepowodzenia sprawdzania poprawności punktów kontrolnych lub niepowodzenia zadań konserwacji. Jeśli wystąpi którykolwiek z tych problemów, należy przerwać analizę pojemności i zająć się najpierw pozostałymi kwestiami. Po rozwiązaniu innych problemów można ponownie sprawdzić pojemność.

Należy uruchomić kontrolę poprawności działania (Avamar: jak uruchomić skrypt kontroli stanu proactive_check.pl na serwerze Avamar, ale polecenie status.dpn może zapewnić szybki przegląd i weryfikację większości tych problemów. Zobacz Avamar: jak zrozumieć dane wyjściowe wygenerowane przez polecenie status.dpn

Dodatkowe informacje można znaleźć w poniższym artykule: Avamar: jak prawidłowo zastosować metodę „Hierarchia rozwiązywania problemów Avamar”.

Jeśli wymagana jest pomoc w celu rozwiązania problemów niezwiązanych z pojemnością, utwórz zgłoszenie serwisowe w zespole pomocy technicznej Dell Technologies Avamar.

Krok 2. Gromadzenie informacji o pojemności: 

Zapoznaj się z poniższymi informacjami, aby uzyskać wszystkie wymagane informacje wymagane do rozwiązywania problemów z pojemnością Avamar: Avamar: zbieranie informacji w celu rozwiązywania problemów z pojemnością

W wersji minimalnej polecenie status.dpn lub wartości w interfejsie administracyjnym Avamar pokazują pojemność GSAN .

Krok 3. Sprawdź, czy pojemność systemu operacyjnego jest pełna:

Poniższe polecenie pomaga wyświetlić bieżącą wartość pojemności systemu operacyjnego dla każdej partycji dysku. Jeśli którakolwiek z wartości osiągnęła lub przekroczyła 85%, jak w danych wyjściowych drugiej próbki, jest to uznawane za wysoką pojemność systemu operacyjnego:

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

Przykładowe dane wyjściowe:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Tylko wtedy, gdy pojemność systemu operacyjnego będzie mniejsza niż 85%, rozwiązywanie problemów z Pojemnością GSAN będzie kontynuowane. 

Krok 4. Problemy niezwiązane z pojemnością, które czasami mogą być błędnie rozumiane jako problemy z pojemnością:

Istnieje możliwość, że tworzenie kopii zapasowych klienta nie powiedzie się nie z powodu błędu pojemności, ale z powodu błędu „Quota”. Czasami może on być błędnie rozumiany jako błąd pojemności.

Sytuację tę można potwierdzić przy użyciu polecenia status.dpn lub innych zebranych danych wyjściowych pokazujących mniejszą pojemność.

Możliwe jest również, że tworzenie kopii zapasowych klienta nie powiodło się lub nie zostało uruchomione z powodu innych przyczyn związanych z Pojemnością Non-GSAN . Zebrane informacje powinny to potwierdzić; można to również zobaczyć w interfejsie administracyjnym Avamar.

• Avamar: ścieżka rozwiązywania problemów związanych z pojemnością metadanych
• Data Domain: ścieżka rozwiązywania problemów związanych z wysoką pojemnością wynikającą z integracji z Avamar

Jeśli Pojemność GSAN jest wysoka, podobnie jak inne pojemności, rozwiązywanie problemów można wykonywać w dowolnej kolejności (z wyjątkiem pojemności systemu operacyjnego, która zawsze musi być pierwsza).

Krok 5. Równowaga pasków i równowaga dysków systemowych:

„Paski” w Avamar to pliki kontenera, w których przechowywane są dane kopii zapasowych w węzłach danych (z wyjątkiem siatki Avamar z jednym węzłem).

Oczekuje się, że paski są „zrównoważone” lub równomiernie rozłożone na różnych dyskach i węzłach w siatce, jednak czasami mogą stać się niezrównoważone.

Zgodnie z projektem w Avamar największy węzeł lub partycja dysku jest czynnikiem ograniczającym, jeśli chodzi o pojemność Avamar.

Jest to zamierzone, więc żaden z dysków lub węzłów nie tworzy więcej pasków, niż jest w stanie obsłużyć (lub jest to dozwolone), dlatego zrównoważone paski są ważne dla pojemności.

Na przykład podczas dodawania dodatkowych węzłów danych w celu rozszerzenia sieci Avamar należy uruchomić równoważenie, aby równomiernie rozłożyć paski na nowe węzły w celu zmniejszenia ogólnego procentu pojemności Avamar.

Innym typem równowagi wymagającym zrozumienia jest równowaga dysków systemowych. Ogranicza się to tylko do partycji danych w tym samym węźle, a nie partycji w wielu węzłach. 

Jeśli w tym samym węźle danych jedna partycja jest znacznie większa lub mniejsza niż inna partycja TEGO SAMEGO węzła, może zostać przekroczony limit określany jako „freespaceunbalance”. Chociaż zwykle dotyczy to systemu operacyjnego, a nie pojemności GSAN , może zostać zgłoszone jako problem związany z pojemnością GSAN .

Krok 6. Sprawdź, czy proces Garbage Collection kończy się prawidłowo: 

Uruchom poniższe polecenie, aby uzyskać informacje na temat odśmiecania pamięci:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

W idealnym przypadku dane wyjściowe będą pokazywać, że proces GC został ukończony w ciągu ostatnich 30 dni:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

Komunikaty o błędach GC mogą obejmować między innymi:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Jeśli narzędzie GC uległo awarii, najpierw rozwiąż ten problem, korzystając z poniższego artykułu: Avamar: rozwiązywanie problemów z błędami Garbage Collection (GC) (ścieżka rozwiązania)
(Jeśli jakiekolwiek problemy zostały już rozwiązane, przejdź do następnego kroku).

Krok 7. Czy GC działa wystarczająco długo?

A. Uruchom poniższe polecenie, aby sprawdzić maksymalny dozwolony czas GC:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Przykładowe dane wyjściowe:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Zwróć uwagę na wartość maxtime , która w tym przykładzie wynosi 14400 (sekund).
(Wartość 0 oznacza brak limitu)

b. Uruchom poniższe polecenie, aby określić, jak długo trwa GC i ile „przebiegów” zostało ukończonych:
(Przebiegi dotyczą warstw przechowywanych danych kopii zapasowej. Można porównać pojemność GSAN do warstw cebuli. Warstwy zewnętrzne należy obrać lub usunąć, aby uzyskać dostęp do warstw wewnętrznych. Każdy przebieg to warstwa przechowywanych danych GSAN ).

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Przykładowe dane wyjściowe:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Zwróć uwagę na liczbę przebiegów i na elapsed-time (sek).

c. Zakładając, że wartość maxtime jest różna od zera, oblicz 2/3 maxtimei porównaj z czasem, który upłynął.
(W powyższym przykładzie 2/3 z 14400 to 9600, a wszystkie dane wyjściowe dotyczące czasu, który upłynął, są znacznie poniżej tej liczby).

Różne problemy mogą powodować powolne działanie GC lub brak skanowania wszystkiego. Może to obejmować brak wystarczającej ilości czasu na uruchomienie przez znaczną ilość czasu lub liczbę dni w przeszłości, nieprawidłową konfigurację, błędy i inne.

W przypadku obaw dotyczących maxtimelub liczby przebiegów, utwórz zgłoszenie serwisowe w zespole pomocy technicznej Dell Technologies Avamar, aby dokładniej zbadać sprawę.

Krok 8. Jeśli podejrzewano, że proces GC nie usunął oczekiwanych danych lub wystarczającej ich ilości:

Jeśli potwierdzono, że GC działa wystarczająco długo, możliwe, że dane nie są zbierane z powodów, na które Garbage Collection nie ma wpływu. To jest lista udokumentowanych powodów, które ogólnie powinny zostać sprawdzone:

a. Sprawdź, czy kopie zapasowe są skonfigurowane tak, aby w końcu wygasły lub regularnie wygasały. Jeśli kopie zapasowe nie wygasają często, narzędzie GC nie będzie miało zbyt wiele pracy do wykonania.

B. Skorzystaj z tego artykułu, aby znaleźć klienty o najwyższym współczynniku zmian: Avamar: zarządzanie pojemnością za pomocą skryptu capacity.sh. (Przejrzyj zarówno „% OF TOTAL”, jak i „CHGRATE”).

c. Sprawdź, czy nie pominięto skrótów dla Avamar: narzędzie Garbage Collection Avamar zgłasza „pominięte skróty”, których nie można wyczyścić. Jeśli występują one rzadko, jest to normalne i można to pominąć.

d. Istnieje flaga lub opcja, która wymusza na serwerze Avamar przechowywanie ostatniej i najnowszej kopii zapasowej z każdego klienta. Jest używana ze względów bezpieczeństwa, aby klient nie doprowadził do przypadkowego wygaśnięcia wszystkich kopii zapasowych. Może to jednak powodować inne problemy, jeśli chodzi o czyszczenie danych i odśmiecanie pamięci. Zespół pomocy technicznej Dell Technologies Avamar może sprawdzić, czy ta opcja jest włączona.

E. Jeśli kopie zapasowe zostały niedawno przełączone z GSAN na zaplecze DD lub doszło do przypadkowej kopii zapasowej GSAN , ale pojemność GSAN nie zmniejsza się, utwórz zgłoszenie serwisowe w zespole pomocy technicznej Dell Technologies Avamar, aby dokładniej zbadać sprawę.

Krok 9. Siatka Avamar jest niewymiarowa w stosunku do ilości bieżących lub oczekiwanych danych, które mają zostać dodane:

Gdy wszystkie inne rozwiązania i możliwe przyczyny wysokiego zużycia pojemności zostały już przeanalizowane i nie jest to problem konfiguracyjny ani kwestia przypadkowych danych:

Oznacza to, że dane mogą wymagać usunięcia lub zbadania opcji, takich jak migracja niektórych klientów do innych siatek Avamar, dodanie nowych węzłów danych itd.

Krok 10. W razie potrzeby potwierdź wszystkie zdarzenia dotyczące pojemności i wznów harmonogram tworzenia kopii zapasowych:

a. Po rozwiązaniu problemów z pojemnością potwierdź wszystkie zdarzenia związane z pojemnością w interfejsie administratora Avamar.

b. Wznów harmonogram tworzenia kopii zapasowych:

dpnctl start sched

W razie innych pytań dotyczących pojemności, szkoleń, rozwiązywania problemów i innych informacji związanych z Avamar, patrz: Avamar: rozwiązywanie problemów z pojemnością, problemy i pytania — wszystkie pojemności (ścieżka rozwiązania)

• Ta czynność sama w sobie może „zamaskować” i ukryć prawdziwe problemy, przez co po kilku dniach lub tygodniach pojawią się one ponownie, a wykonana ręcznie operacja okaże się stratą czasu.
• Ponadto ręczne uruchomienie GC może nie działać tak wydajnie, ponieważ odbywa się poza zaplanowanym harmonogramem.
  • Czasami może to pogłębić inne problemy. Aby uzyskać więcej informacji, patrz: Avamar: informacje o korzystaniu z ręcznego uruchamiania Garbage Collection

• Ta zmiana lub akcja zazwyczaj nie jest wykonywana i nie powinna być uważana za domyślną. Inżynier Avamar L2 lub ekspert merytoryczny (SME) musi zatwierdzić tę zmianę.
• Niestety, takie działania mogą często powodować trwałe uszkodzenie siatki Avamar na różne sposoby, które można rozwiązać tylko poprzez dodanie dodatkowych węzłów pamięci masowej lub ponowne wdrożenie.

Należy pamiętać, że żadna z powyższych czynności nie jest wykonywana, ponieważ zespół pomocy technicznej chce pomóc w rozwiązaniu problemów z pojemnością w najbardziej korzystny sposób.