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

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 jest to najłatwiejsze do rozważenia GSAN Pojemność jako miejsce i wykorzystanie kopii zapasowych klienta.

• Podstawowa wiedza na temat deduplikacji
• Podstawowa wiedza na temat punktu kontrolnego, walidacji punktu kontrolnego (hfscheck) i odśmiecanie pamięci oraz znaczenie każdego z nich.
• Różnica między GSAN (lub Użytkownik) Pojemność i pojemność 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 kontroli 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 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. Szacuje również, ile z tych danych można średnio zdeduplikować i tak dalej.

1. Odśmiecanie pamięci nie działa spójnie
2. Wydajność odzyskiwania pamięci jest niska 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. Kopia zapasowa danych innych niż obliczone przed instalacją sieci Avamar jest tworzona na tym serwerze Avamar.
5. Inne powody

Sprawdź, czy wszystkie poniższe kroki rozwiązywania problemów dotyczą środowiska:

Krok 1. Gromadzenie danych:

Upewnij się, że nie ma innych problemów niezwiązanych z przepustowością sieci Avamar. Jeśli tak, 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 którykolwiek z tych problemów stanowi problem, należy przerwać rozwiązywanie problemów z pojemnością i rozwiązać inne problemy. Po rozwiązaniu innych problemów można ponownie sprawdzić pojemność.

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

Dodatkowe informacje można znaleźć w następującym artykule: Avamar: Prawidłowe stosowanie podejścia "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ą

Co najmniej, status.dpn lub wartości w interfejsie administracyjnym Avamar pokazują GSAN pojemność.

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 wyniki:

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 jest mniejsza niż 85%, GSAN Kontynuację rozwiązywania problemów z pojemnością. 

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

Istnieje możliwość, że tworzenie kopii zapasowych klienta nie powiedzie się nie z powodu "pojemności", ale z powodu "limitu przydziału". Czasami mogą one być błędnie rozumiane jako pojemność.

Sytuację tę może potwierdzić status.dpn lub inne zebrane dane wyjściowe pokazujące mniejszą pojemność.

Możliwe jest również, że tworzenie kopii zapasowych klienta nie powiodło się lub nie zostało uruchomione z powodu innych Non-GSAN Ze względu na pojemność. Zebrane informacje powinny to potwierdzić lub są widoczne w interfejsie administracyjnym Avamar.

• Avamar: Ścieżka rozwiązania pojemności metadanych
• Data Domain: Duża pojemność ze ścieżki rozwiązania integracji Avamar

Jeśli trzeba odzyskać GSAN Pojemność jest wysoka, podobnie jak te 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. Saldo przeplotu i równowaga dysków systemu operacyjnego:

"Przeploty" 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 przeplotów, niż są w stanie obsłużyć (lub jest to dozwolone), dlatego zrównoważone przeploty 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ć przeploty na nowe węzły w celu zmniejszenia ogólnego procentu pojemności Avamar.

Innym typem równowagi wymagającym zrozumienia jest równowaga dysku systemu operacyjnego. 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, limit może zostać przekroczony o nazwie "freespaceunbalance”. Chociaż zwykle dotyczy to systemu operacyjnego, a nie GSAN Pojemność, można ją podać jako GSAN Problem z pojemnością.

Krok 6. Sprawdź, czy wyrzucanie elementów bezużytecznych kończy się: 

Uruchom następujące polecenie, aby uzyskać informacje na temat wyrzucania elementów bezużytecznych:

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

W idealnym przypadku dane wyjściowe będą pokazywać, że GC zostało ukończone 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 GC uległo awarii, najpierw rozwiąż ten problem, korzystając z następującego artykułu jako odwołania: Avamar: Rozwiązywanie problemów z błędami wyrzucania elementów bezużytecznych (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 następujące 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 maxtime wartość, która w tym przykładzie wynosi 14400 (sekundy).
(Wartość 0 oznacza nieograniczoną)

b. Uruchom następujące polecenie, aby określić, jak długo trwa GC i ile "przebiegów" zostało ukończonych:
(Przebiegi dotyczą warstw przechowywanych danych kopii zapasowej. Pomyśl o GSAN Pojemność jak warstwy cebuli. Warstwy zewnętrzne należy odkleić lub usunąć, zanim warstwy wewnętrzne będą widoczne. Każdy przebieg jest warstwą GSAN przechowywane dane.)

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ę przejść i elapsed-time (sekundy).

c) Zakładając, że maxtime jest różny od zera, oblicz 2/3 maxtimei porównaj go 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 dni w przeszłości, nieprawidłową konfigurację, błędy i inne.

W przypadku obaw dotyczących maxtimelub liczbę 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 GC nie usunął wystarczającej ilości lub oczekiwanych danych:

Jeśli potwierdzono, że GC działa wystarczająco długo, możliwe, że dane nie są zbierane z powodów poza kontrolą wyrzucania elementów bezużytecznych. To jest lista udokumentowanych powodów, które ogólnie powinny być sprawdzone:

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

b. Skorzystaj z tego artykułu, aby znaleźć klientów z najwyższym współczynnikiem zmian: Avamar: Jak zarządzać pojemnością za pomocą skryptu capacity.sh. (Przejrzyj oba "% OF TOTAL" oraz "CHGRATE".)

c. Sprawdź, czy nie pominięto skrótów dla Avamar: Odzyskiwanie pamięci 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 to używane ze względów bezpieczeństwa, aby klient nie miał każdej kopii zapasowej przypadkowo wygasłej. 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 do zaplecza DD lub wystąpił przypadkowy GSAN kopia zapasowa, ale GSAN Pojemność 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:

Po sprawdzeniu wszystkich innych rozwiązań i możliwych przyczyn pod kątem dużej pojemności i nie jest to problem z konfiguracją lub przypadkowymi danymi:

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 przypadku innych pytań dotyczących pojemności, szkoleń, rozwiązywania problemów i innych informacji związanych z Avamar zobacz: 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, sprawiając, że pojawią się one ponownie kilka dni lub tygodni później, powodując, że ta ręczna praca jest marnowanym czasem.
• Ponadto ręczne GC może nie działać tak wydajnie, ponieważ kończy się harmonogram.
  • Czasami może to pogorszyć inne problemy. Aby uzyskać więcej informacji, patrz: Avamar: Informacje o korzystaniu z ręcznego wyrzucania elementów bezużytecznych

• Ta zmiana lub akcja zazwyczaj nie jest wykonywana i nie powinna być rozpatrywana domyślnie. Inżynier Avamar L2 lub ekspert merytoryczny (SME) musi zatwierdzić tę zmianę.
• Niestety, takie działania mogą często spowodować 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.