Avamar: Para replikująca pokazuje różne poziomy wykorzystania pojemności. Jak zbadać przyczyny.

Możliwe przyczyny różnic pomiędzy wartościami „server utilization”:

Różnice logiczne lub fizyczne między siatkami:

• Różna liczba węzłów danych w siatce źródłowej i docelowej.
• Węzły danych każdej siatki mają różne konfiguracje dysków.
• Odpowiednio zrównoważony rozkład przeplotów w węzłach danych w każdym systemie (z dokładnością do 2%)
• Wymagania dotyczące pamięci masowej i parzystości mogą być różne w zależności od wersji Avamar. Różnicę w użytkowaniu można zaobserwować, jeśli wersje oprogramowania źródłowego i docelowego różnią się od siebie.
• Poziom tylko-do-odczytu dysku serwera Avamar Server może się różnić w obu siatkach.   
• Jedna siatka może być skonfigurowana pod kątem parzystości RAIN, a druga nie.

Konfiguracja replikacji:

• Kopie zapasowe replikowane do systemu docelowego mogą mieć inne zasady przechowywania niż źródło. Przejrzyj flagę expiredelta, aby uzyskać więcej informacji. Alternatywnie replikowane kopie zapasowe mogą obejmować tylko określony przedział czasu. Na przykład kopie zapasowe ze źródła z ostatnich 4 tygodni.
• Replikację można skonfigurować tak, aby replikowała tylko podzbiór klientów z systemu źródłowego do systemu docelowego. Sprawdź, czy używane są ustawienia „dołączania”, czy „wykluczania”.
• Klienty i skojarzone z nimi kopie zapasowe mogły zostać usunięte z systemu źródłowego. Usunięcie klienta lub kopii zapasowych w źródle nie powoduje usunięcia tych samych kopii zapasowych z systemu docelowego. Kopie zapasowe pozostają w miejscu docelowym aż do wygaśnięcia zgodnie z ich ustawieniami przechowywania.
• Zasady przechowywania można zmienić dla kopii zapasowych lub klientów w systemie źródłowym. Zmiana zasad przechowywania dotyczy tylko nowych kopii zapasowych. Nowe kopie zapasowe są replikowane do obiektu docelowego i są zgodne ze zaktualizowanymi zasadami przechowywania. Kopie zapasowe już istniejące w obiekcie docelowym zachowują zasady przechowywania, które zostały do nich zastosowane podczas replikacji.

Wcześniejsze działania związane z zarządzaniem pojemnością:

• Nierzadko zdarza się, że klienci zauważają, że jeden z systemów z pary replikacji Avamar zbliża się do limitu pojemności, a następnie podejmują działania w celu zmniejszenia pojemności. Pamiętaj — para replikacji Avamar składa się z dwóch niezależnie zarządzanych systemów. Jeśli działania są wykonywane w jednym systemie, muszą być również wykonywane w drugim. 
• W przypadku usunięcia kopii zapasowych lub ograniczenia retencji w systemie źródłowym należy wprowadzić identyczne zmiany w systemie docelowym. Najlepszym sposobem zarządzania pojemnością w ten sposób jest użycie skryptu modify-snapups. Można to uruchomić na obu serwerach Avamar z tymi samymi opcjami modyfikacji lub usuwania kopii zapasowej.  

Różna struktura przeplotu (np. większa liczba przeplotów parzystości w jednym systemie):

• Będąc niezależnymi, dwa systemy Avamar mogą mieć różne struktury przeplotów. Systemy wielowęzłowe mogą wykazywać różnice ze względu na użycie przeplotów parzystości w celu ochrony danych. W zależności od historii pojemności dwa systemy wielowęzłowe zawierają te same kopie zapasowe, ale jeden z nich może mieć większą liczbę przeplotów parzystości niż drugi.
• Podobnie jak w przypadku zwykłych przeplotów, raz utworzony przeplot parzystości zawsze pozostaje w systemie. W przeciwieństwie do zwykłych przeplotów zawsze zajmuje stałą ilość miejsca na serwerze Avamar. Dzieje się tak nawet wtedy, gdy ich bezpieczne przeploty grup parzystości nie zawierają żadnych danych. Odśmiecanie pamięci nie ma wpływu na to zachowanie.
• System docelowy replikacji jest pośrednio chroniony przed poważnymi problemami z pojemnością w źródle replikacji. Taka sytuacja może jednak wystąpić na obu maszynach, jeśli jedna z nich jest źle zarządzana z punktu widzenia pojemności.
• Powiązane artykuły: System Avamar pokazuje użycie na poziomie do 30% nawet po usunięciu wszystkich kopii zapasowych i śmieci

Kopie zapasowe nadal w MC_DELETED:

• Jednym z rzadkich scenariuszy, o których należy pamiętać, jest sytuacja, w której klient jest usuwany w źródle, ale jego kopie zapasowe są zachowywane. Może to spowodować, że źródło będzie miało większe wykorzystanie niż miejsce docelowe, w którym kopie zapasowe powinny wygasnąć w sposób naturalny. Użycie skryptu dump_root_hashes.rb z opcją backupcompare pomaga sprawdzić ten scenariusz.

Dane w systemie docelowym z niereplikowanych kopii zapasowych:

• Jeśli system replikuje tylko w jednym kierunku*, sprawdź w systemie docelowym, czy poza /REPLICATE i MC_SYSTEM nie ma klientów.

Inne zachowania:

• Zadania replikacji mogą nie być wykonywane w sposób niezawodny. Dane wysyłane do miejsca docelowego mogą być opóźnione w stosunku do źródła o wiele dni.
• Oba systemy zawierają taką samą ilość deduplikowanych danych, ale narzut parzystości w każdym z nich jest inny. Dzieje się tak w niżej przedstawionej sytuacji. 
  • System źródłowy Avamar jest prawie pełny. 
  • Wiele kopii zapasowych jest usuwanych z systemu źródłowego w celu zmniejszenia jego pojemności. 
  • Następnie dochodzi do replikacji deduplikowanych danych ze źródła do miejsca docelowego. 
  • Ilość deduplikowanych danych jest taka sama w obu systemach.
  • System źródłowy początkowo przechowuje więcej narzutu parzystości niż system docelowy.
• Replikacja nie kopiuje fizycznych przeplotów z siatki źródłowej do docelowej. Zamiast tego siatka docelowa może sama określić, gdzie są przechowywane pasma i fragmenty danych.
• Czasami docelowe systemy Avamar mogą przechowywać dane wydajniej niż siatka źródłowa, w której pierwotnie utworzono kopię zapasową danych.

Opis środowiska replikacji:

• Zanotuj pełną nazwę hosta źródłowej siatki Avamar.
• Sprawdź konfigurację replikacji systemów, których dotyczy problem, aby dowiedzieć się, które systemy replikują jakie dane i gdzie. 
  • Jeśli środowisko jest bardziej skomplikowane niż replikacja z jednego serwera Avamar na drugi, pomocne może być narysowanie schematu.
• Jeśli źródło integruje się z Data Domain (DD), dowiedz się, czy zastrzeżenia klienta dotyczą kopii zapasowych replikowanych między urządzeniami DD.
• Zanotuj pełną nazwę hosta docelowej siatki Avamar i wszystkich powiązanych urządzeń DD, które otrzymują replikowane kopie zapasowe.

Sprawdź ogólną kondycję i stan siatki:

• Uruchom proaktywny skrypt kontrolny na obu siatkach, uzyskaj kopię hc_results.txt i przejrzyj, aby zrozumieć ogólną sytuację z systemem. 

Jak poważny wpływ ma różnica pojemności?

• Klient powinien przedstawić zrzut ekranu pokazujący to, na co patrzy, co prowadzi go do przekonania, że istnieje różnica w zużyciu pojemności między źródłem a obiektem docelowym.
• Nie rozważylibyśmy tutaj, że różnica pojemności mniejsza niż 5% może być powodem alarmu.
• Sprawdź interfejs użytkownika administratora Avamar, aby zrozumieć poziomy pojemności serwera Avamar i (jeśli domena danych Data Domain jest zintegrowana) pojemności metadanych.
• Należy pamiętać o tym, jak działa wyświetlanie pojemności interfejsu użytkownika (omówiono to w artykule Pulpit interfejsu użytkownika Avamar w wersji 7.2 i nowszych pokazuje wykorzystanie metadanych zamiast wykorzystania Avamar).
• Uruchom następujące polecenie w obu systemach. Wartość wykorzystania serwera to ogólna wartość poziomów pojemności serwera Avamar Server (ale nie Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Sprawdź, czy sprzęt jest taki sam w obu siatkach:

• Porównywanie różnic w pojemności ma sens tylko w przypadku systemów podobnych. 
• Korzystając z wyników kontroli proaktywnej, zanotuj typ węzłów obecnych w systemie.
• Poniższe polecenie przedstawia ogólną liczbę, rozmiar i wykorzystanie miejsca w węzłach fizycznych:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Te dane wyjściowe ułatwiają określenie liczby i rozmiaru węzłów w systemie. Wynoszą one (23,3 / 3 = ~7,8 TB). 
• Liczba i rozmiar partycji dysku twardego w każdym węźle musi to potwierdzać.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Korzystając z tych informacji, sprawdź następujące kwestie:

Sprawdź wersję i konfigurację oprogramowania:

• Korzystając z danych wyjściowych polecenia status.dpn, porównaj wersję aplikacji Avamar działającą w każdym systemie.
• W przypadku systemów wielowęzłowych upewnij się, że oba są skonfigurowane z parzystością RAIN na każdy system Avamar — Ustalanie, czy serwer ma parzystość RAIN, czy inną
• Sprawdź i porównaj parametry konfiguracji serwerów Avamar Server związane z pojemnością obu systemów. Na przykład:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Sprawdź równoważenie przeplotu:

• Sprawdź dane wyjściowe polecenia status.dpn i zanotuj łączną liczbę przeplotów w każdym węźle danych. Liczba przeplotów jest podana w nawiasach kwadratowych (na przykład onl:xxx). 
• Różnica między całkowitą liczbą przeplotów w każdym węźle danych powinna być mniejsza niż 2%.  

Sprawdź, czy usuwanie śmieci działa prawidłowo w obu systemach:

• Jeśli usuwanie śmieci nie działa konsekwentnie i skutecznie, nie usunie wygasłych danych. System zgłasza większe wykorzystanie pojemności niż oczekiwano. 
  • Więcej informacji można znaleźć w artykule Ścieżka rozwiązania GC w uwagach zastrzeżonych.  

Upewnij się, że replikacja przebiega pomyślnie:

• Upewnij się, że wszystkie zadania replikacji z systemu źródłowego do docelowego zostały pomyślnie ukończone. Jeśli tak się nie stało, możliwe, że nadal istnieją dane do zreplikowania ze źródła do miejsca docelowego.  

Sprawdź konfigurację replikacji:

• Sprawdź konfigurację replikacji (w interfejsie użytkownika, interfejsie wiersza poleceń lub dziennikach) pod kątem dowolnej z następujących flag:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Sprawdź szybkości przyswajania i usuwania danych przez oba systemy:

• Uruchom polecenie proactive_check.pl --capacity w obu systemach i porównaj prędkości przyswajania w systemie źródłowym i docelowym.
• Jeśli system docelowy jest jedynym systemem docelowym i odbiera WSZYSTKIE kopie zapasowe ze źródła, jego prędkości przyswajania powinna być ściśle zgodna z szybkością przyswajania w systemie źródłowym.
• Kolumny Avamar NEW lub DDR NEW pokazują, ile nowych danych zostało dodanych do tych systemów.
• Zwróć również szczególną uwagę na kolumny „removed”, „mins” i „pass”, aby zrozumieć zachowanie usuwania śmieci w obu systemach.
• Informacje te dają jasny obraz tego, co dzieje się w obu systemach.
• Aby uzyskać więcej informacji na temat interpretowania danych wyjściowych, zobacz Avamar: Zarządzanie pojemnością za pomocą skryptu capacity.sh  

Wykonaj zrzut listy kopii zapasowych istniejących w każdym systemie:

• Skrypt dump_root_hashes.rb to narzędzie, które pomaga porównać różnice w przechowywanych kopiach zapasowych między systemem źródłowym i docelowym Avamar. Dzieje się tak nawet wtedy, gdy kopie zapasowe są hostowane w pamięci masowej Data Domain.   
• Zobacz Avamar: Avamar: Generowanie listy klientów i kopii zapasowych za pomocą skryptu dump_root_hashes.rb w celu uzyskania informacji na temat pobierania narzędzia i jego zastosowań, w tym do porównywania zawartości dwóch systemów Avamar.
  • Uruchom narzędzie. Sprawdź niespójności w liczbie kopii zapasowych na wszystkich klientach. Zwróć uwagę na różnice +/-2).  
• Jak omówiono w sekcji Przyczyny, asymetryczne zarządzanie pojemnością powoduje różnice między tymi dwoma systemami. Przejrzyj dane wyjściowe, aby określić, czy taki scenariusz może być realizowany.
• Ponadto:
  • Sprawdź w systemie docelowym dane z niereplikowanych kopii zapasowych.
  • Sprawdź źródło danych, które nie zostały zreplikowane do obiektu docelowego.  

Sprawdź struktury przeplotu pod kątem różnic (na przykład więcej przeplotów parzystości w jednym systemie):

• Oba systemy Avamar, chociaż są niezależne, mogą mieć różne struktury przeplotów. Systemy wielowęzłowe mogą wykazywać różnice ze względu na użycie przeplotów parzystości w celu ochrony danych. W zależności od historii pojemności dwa systemy wielowęzłowe zawierają te same kopie zapasowe, ale jeden z nich może mieć większą liczbę przeplotów parzystości niż drugi.  
• Podobnie jak w przypadku zwykłych przeplotów raz utworzony przeplot parzystości pozostaje w systemie. W przeciwieństwie do zwykłych przeplotów zawsze zajmuje stałą ilość miejsca w systemie Avamar, nawet jeśli bezpieczne przeploty grup parzystości nie zawierają żadnych danych. Odśmiecanie pamięci nie ma wpływu na to zachowanie.
• System docelowy replikacji jest pośrednio chroniony przed poważnymi problemami z pojemnością w źródle replikacji. Taka sytuacja może jednak wystąpić na obu maszynach, jeśli jedna z nich jest źle zarządzana z punktu widzenia pojemności.
• Powiązane artykuły:  System Avamar pokazuje użycie na poziomie do 30% nawet po usunięciu wszystkich kopii zapasowych i śmieci  

Kopie zapasowe nadal w MC_DELETED:

• Jednym z rzadkich scenariuszy, o których należy pamiętać, jest sytuacja, w której klient został usunięty w źródle, ale jego kopie zapasowe zostały zachowane. Powoduje to większe wykorzystanie źródła niż miejsce docelowe, w którym kopie zapasowe powinny wygasnąć w sposób naturalny. Użycie skryptu dump_root_hashes.rb z opcją backupcompare powinno pomóc sprawdzić ten scenariusz.