Avamar: Ein Replikationspaar zeigt unterschiedliche Kapazitätsverbrauchsstufen an. So ermitteln Sie die Ursachen.

Zu den Ursachen und möglichen Gründen für die Unterschiede bei den Werten für die Serverauslastung gehören u. a.:

Logische oder physische Unterschiede zwischen den Rastern:

• Unterschiedliche Anzahl von Daten-Nodes auf dem Quell- und Zielraster.
• Die Daten-Nodes jedes Systems weisen unterschiedliche Festplattenkonfigurationen auf.
• Ausgeglichene Verteilung der Stripes über die Daten-Nodes in jedem System (innerhalb von 2 %)
• Die Storage- und Paritätsanforderungen unterscheiden sich je nach Avamar-Version. Wenn sich die Quell- von der Zielsoftwareversion unterscheidet, wird möglicherweise ein Unterschied in der Auslastung angezeigt.
• Die Schreibschutzstufe der Festplatte des Avamar Servers kann sich zwischen den beiden Rastern unterscheiden.   
• Ein Raster kann für RAIN-Parität konfiguriert sein und das andere nicht.

Replikationskonfiguration:

• Auf das Zielsystem replizierte Backups haben möglicherweise eine andere Aufbewahrungs-Policy als die Quelle. Überprüfen Sie die expiredelta-Markierung für weitere Informationen. Oder die replizierten Backups decken möglicherweise nur eine bestimmte Zeitspanne ab. Zum Beispiel die Backups der letzten 4 Wochen von der Quelle.
• Die Replikation kann so konfiguriert sein, dass nur eine Teilmenge der Clients vom Quellsystem auf das Zielsystem repliziert wird. Überprüfen Sie, ob Einschluss- oder Ausschlusseinstellungen verwendet werden.
• Clients und ihre zugehörigen Backups wurden auf dem Quellsystem möglicherweise gelöscht. Durch das Löschen eines Clients oder Backups von der Quelle werden diese Backups nicht vom Zielsystem entfernt. Die Backups verbleiben auf dem Ziel, bis sie gemäß ihren Aufbewahrungseinstellungen ablaufen.
• Aufbewahrungs-Policys können für Backups oder Clients auf dem Quellsystem geändert werden. Die Änderung der Aufbewahrungs-Policys wirkt sich nur auf neue Backups aus. Neue Backups werden auf das Ziel repliziert und entsprechen der aktualisierten Aufbewahrungs-Policy. Backups, die bereits auf dem Ziel vorhanden sind, behalten die Aufbewahrungs-Policy bei, die bei der Replikation auf sie angewendet wurde.

Vorherige Capacity-Managementmaßnahmen:

• Es ist nicht ungewöhnlich, dass KundInnen bemerken, dass eines der Systeme des Avamar-Replikationspaars die Kapazitätsgrenze erreicht, und dann Maßnahmen ergreifen, um die Kapazität zu reduzieren. Denken Sie daran, dass ein Avamar-Replikationspaar aus zwei unabhängig voneinander gemanagten Systemen besteht. Wenn also Maßnahmen auf einem System durchgeführt werden, müssen sie auch auf dem anderen durchgeführt werden. 
• Wenn Backups gelöscht oder Aufbewahrungen auf dem Quellsystem reduziert werden, müssen auf dem Ziel identische Änderungen vorgenommen werden. Die beste Möglichkeit, die Kapazität entsprechend zu verwalten, ist die Verwendung des Skripts modify-snapups. Es kann auf beiden Avamar Servern mit denselben Optionen für Backupänderungen oder -löschungen ausgeführt werden.  

Unterschiedliche Stripe-Struktur (z. B. mehr Paritäts-Stripes auf einem System):

• Da die zwei Avamar-Systeme unabhängig voneinander sind, können sie am Ende unterschiedliche Stripe-Strukturen aufweisen. Systeme mit mehreren Nodes können Unterschiede aufweisen, da sie zum Schutz der Daten Paritäts-Stripes verwenden. Je nach Kapazitätshistorie enthalten zwei Systeme mit mehreren Nodes dieselben Backups, eines kann jedoch eine höhere Anzahl an Paritäts-Stripes aufweisen als das andere.
• Wie bei regulären Stripes verbleibt ein Paritäts-Stripe nach der Erstellung immer auf dem System. Im Gegensatz zu regulären Stripes belegt er jedoch immer eine feste Menge an Speicherplatz auf dem Avamar Server. Dies gilt auch dann, wenn die Safe-Stripes der Paritätsgruppe keine Daten enthalten. Die automatische Speicherbereinigung hat keine Auswirkungen auf dieses Verhalten.
• Ein Replikationszielsystem wird indirekt vor größeren Kapazitätsproblemen einer Replikationsquelle geschützt. Die Situation kann jedoch auf beiden Maschinen auftreten, wenn eine von ihnen aus Kapazitätssicht schlecht verwaltet wird.
• Zugehöriger Artikel: Avamar zeigt eine Auslastung von bis zu ~30 % an, selbst nachdem alle Backups gelöscht und die automatische Speicherbereinigung ausgeführt wurden

Noch in MC_DELETED vorhandene Backups:

• Ein seltenes Szenario, das es zu beachten gilt, ist, wenn ein Client auf der Quelle gelöscht wird, seine Backups aber aufbewahrt werden. Dies kann dazu führen, dass die Quelle eine höhere Auslastung aufweist als das Ziel, auf dem die Backups normal ablaufen würden. Die Verwendung des Skripts dump_root_hashes.rb mit der Option backupcompare hilft bei der Überprüfung auf dieses Szenario.

Daten auf dem Zielsystem aus nicht replizierten Backups:

• Wenn das System *nur in eine Richtung* repliziert, überprüfen Sie auf dem Ziel, dass keine Clients außerhalb von /REPLICATE und MC_SYSTEM vorhanden sind.

Andere Verhaltensweisen:

• Replikationsjobs werden möglicherweise nicht zuverlässig abgeschlossen. Daten, die an das Ziel gesendet werden, können der Quelle um mehrere Tage „hinterherhinken“.
• Beide Systeme enthalten dieselbe Menge an deduplizierten Daten, der Paritäts-Overhead ist jedoch auf beiden unterschiedlich. Dies geschieht unter der folgenden Bedingung: 
  • Ein Avamar-Quellsystem ist fast voll. 
  • Es werden zahlreiche Backups vom Quellsystem gelöscht, um die Kapazitätsstufe zu reduzieren. 
  • Dann erfolgt die Replikation der deduplizierten Daten von der Quelle auf das Ziel. 
  • Die Menge der deduplizierten Daten ist auf beiden Systemen identisch.
  • Das Quellsystem speichert zunächst mehr Paritäts-Overhead als das Ziel.
• Bei der Replikation werden keine physische Stripes von der Quelle auf das Zielraster kopiert. Stattdessen kann das Zielraster selbst bestimmen, wo Daten-Stripes und -blöcke gespeichert werden.
• Manchmal können Avamar-Zielsysteme Daten effizienter speichern als ein Quellraster, auf dem die Daten ursprünglich gesichert wurden.

Verstehen der Replikationsumgebung:

• Notieren Sie sich den vollständigen Hostnamen des Avamar-Quellrasters.
• Untersuchen Sie die Replikationskonfiguration der betroffenen Systeme, um zu verstehen, welche Systeme welche Daten wohin replizieren. 
  • Es kann hilfreich sein, eine schematische Darstellung zu zeichnen, wenn die Umgebung komplizierter ist als die Replikation von einem Avamar Server auf einen anderen.
• Wenn die Quelle mit Data Domain (DD) integriert ist, bringen Sie in Erfahrung, ob sich die Bedenken des/der KundIn auf Backups beziehen, die zwischen DD-Geräten repliziert werden.
• Notieren Sie sich den vollständigen Hostnamen des Avamar-Zielrasters und alle zugehörigen DD-Geräte, die replizierte Backups empfangen.

Überprüfen Sie den Gesamtintegritätszustand und die Situation des Rasters:

• Führen Sie das proaktive Prüfskript auf beiden Rastern aus, rufen Sie eine Kopie von hc_results.txt ab und überprüfen Sie sie, um die Gesamtsituation des Systems zu verstehen. 

Wie schwerwiegend ist der Kapazitätsunterschied?

• Der/die KundIn sollte einen Screenshot bereitstellen, der zeigt, was ihn/sie zu der Annahme führt, dass es einen Unterschied im Kapazitätsverbrauch zwischen Quelle und Ziel gibt.
• Es gibt keinen Grund zur Beunruhigung, wenn der Kapazitätsunterschied weniger als 5 % beträgt.
• Überprüfen Sie die Benutzeroberfläche von Avamar Administrator, um die Kapazitätsstufen des Avamar Servers und (bei Integration mit Data Domain) die Metadatenkapazität zu verstehen.
• Machen Sie sich damit vertraut, wie die Kapazität auf der Benutzeroberfläche angezeigt wird (siehe Avamar-UI-Dashboard in 7.2 und höher zeigt Metadatenauslastung anstelle von Avamar-Auslastung an).
• Führen Sie den folgenden Befehl auf beiden Systemen aus. Der Wert der Serverauslastung gibt einen Gesamtwert der Kapazitätsstufen des Avamar Servers (jedoch nicht Data Domain) an:

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

Server utilization               3.7%

Überprüfen Sie, ob die Hardware auf beiden Rastern identisch ist:

• Es ist nur sinnvoll, Kapazitätsunterschiede bei „gleichen“ Systemen zu vergleichen. 
• Notieren Sie anhand der Ausgabe der proaktiven Überprüfung den Typ der im System vorhandenen Nodes.
• Mit dem folgenden Befehl werden die Gesamtanzahl, die Größe und der Speicherplatzverbrauch der physischen Nodes angezeigt:

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

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

• Die Ausgabe erleichtert die Bestimmung der Anzahl und Größe der Nodes im System. Es sind (23,3 / 3 = ~7,8 TB). 
• Die Anzahl und Größe der Festplattenpartitionen auf jedem Node muss dies bestätigen.

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

• Überprüfen Sie mithilfe dieser Informationen Folgendes:

Überprüfen Sie die Softwareversion und -konfiguration:

• Vergleichen Sie anhand der Ausgabe des status.dpn-Befehls die Version von Avamar, die auf jedem System ausgeführt wird.
• Vergewissern Sie sich bei Systemen mit mehreren Nodes, dass beide mit RAIN-Parität konfiguriert sind, siehe Avamar – So ermitteln Sie, ob ein Server RAIN oder Nicht-RAIN ist.
• Überprüfen und vergleichen Sie die kapazitätsbezogenen Konfigurationsparameter des Avamar Servers auf beiden Systemen. Zum Beispiel:

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"

Überprüfen Sie den Stripe-Ausgleich:

• Überprüfen Sie die Ausgabe von status.dpn und notieren Sie sich die Gesamtzahl der Stripes auf jedem Daten-Node. Die Anzahl der Stripes wird in Klammern angegeben (z. B. onl:xxx). 
• Es sollte weniger als 2 % Unterschied zwischen der Gesamtzahl der Stripes auf jedem Daten-Node bestehen.  

Überprüfen Sie, ob die automatische Speicherbereinigung auf beiden Systemen ordnungsgemäß ausgeführt wurde:

• Wenn die automatische Speicherbereinigung nicht konsistent und effektiv ausgeführt wird, werden abgelaufene Daten nicht entfernt. Das System meldet dann eine höhere Kapazitätsauslastung als erwartet. 
  • Weitere Informationen finden Sie im Lösungspfad-Artikel zur automatischen Speicherbereinigung in den eingeschränkten Hinweisen.  

Stellen Sie sicher, dass die Replikation erfolgreich abgeschlossen wird:

• Stellen Sie sicher, dass alle Replikationsaufgaben von der Quelle zum Ziel erfolgreich abgeschlossen werden. Wenn dies nicht der Fall ist, kann es sein, dass noch Daten von der Quelle zum Ziel repliziert werden müssen.  

Überprüfen Sie die Replikationskonfiguration:

• Überprüfen Sie die Replikationskonfiguration (auf der Benutzeroberfläche, in der CLI oder in Protokollen) auf eine der folgenden Markierungen:  

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

--expiredelta

--retention-types

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

Überprüfen Sie die Aufnahme- und Datenlöschraten beider Systeme:

• Führen Sie proactive_check.pl --capacity auf beiden Systemen aus und vergleichen Sie die Aufnahmeraten des Quell- und Zielsystems.
• Wenn das Ziel ein reines Zielsystem ist und ALLE Backups von der Quelle empfängt, sollte seine Aufnahmerate der Aufnahmerate der Quelle entsprechen.
• Die Spalten „Avamar NEW“ oder „DDR NEW“ zeigen an, wie viele neue Daten zu diesen Systemen hinzugefügt werden.
• Achten Sie auch auf die Spalten „removed“, „mins“ und „pass“, um das Verhalten der automatischen Speicherbereinigung auf beiden Systemen zu verstehen.
• Diese Informationen bieten einen klaren Überblick über die Vorgänge auf beiden Systemen.
• Weitere Informationen zur Interpretation der Ausgabe finden Sie in Avamar: So managen Sie die Kapazität mit dem capacity.sh-Skript  

Rufen Sie eine Liste der auf jedem System vorhandenen Backups ab:

• Das Skript dump_root_hashes.rb ist ein Dienstprogramm, mit dem Sie die Unterschiede bei Backups, die zwischen einer Avamar-Quelle und einem Avamar-Zielsystem gespeichert werden, vergleichen können. Dies gilt auch dann, wenn die Backups auf Data Domain-Storage gehostet werden.   
• Siehe Avamar: Avamar: So verwenden Sie das Skript dump_root_hashes.rb, um eine Liste mit Clients und Backups zu erzeugen für Informationen zum Herunterladen des Dienstprogramms und zu Anwendungsfällen, einschließlich eines Vergleichs der Inhalte von zwei Avamar-Systemen.
  • Führen Sie das Tool aus. Überprüfen Sie die Anzahl der Backups auf allen Clients auf Inkonsistenzen. Achten Sie auf Unterschiede von +/-2.  
• Wie im Abschnitt Ursachen erläutert, führt eine asymmetrische Kapazitätsverwaltung zu Unterschieden zwischen den beiden Systemen. Überprüfen Sie die Ausgabe, um festzustellen, ob dies der Fall sein könnte.
• Außerdem:
  • Überprüfen Sie das Zielsystem auf Daten aus nicht replizierten Backups.
  • Überprüfen Sie die Quelle auf Daten, die nicht auf das Ziel repliziert wurden.  

Prüfen Sie auf abweichende Stripe-Strukturen (z. B. mehr Paritäts-Stripes auf einem System):

• Da beide Avamar-Systeme unabhängig voneinander sind, können sie unterschiedliche Stripe-Strukturen aufweisen. Systeme mit mehreren Nodes können Unterschiede aufweisen, da sie zum Schutz der Daten Paritäts-Stripes verwenden. Je nach Kapazitätshistorie enthalten zwei Systeme mit mehreren Nodes dieselben Backups, eines kann jedoch eine höhere Anzahl an Paritäts-Stripes aufweisen als das andere.  
• Wie bei regulären Stripes verbleibt ein Paritäts-Stripe nach der Erstellung auf dem System. Im Gegensatz zu regulären Stripes belegt er jedoch immer eine feste Menge an Speicherplatz auf dem Avamar Server. Dies gilt auch dann, wenn die Safe-Stripes der Paritätsgruppe keine Daten enthalten. Die automatische Speicherbereinigung hat keine Auswirkungen auf dieses Verhalten.
• Ein Replikationszielsystem wird indirekt vor größeren Kapazitätsproblemen einer Replikationsquelle geschützt. Die Situation kann jedoch auf beiden Maschinen auftreten, wenn eine von ihnen aus Kapazitätssicht schlecht verwaltet wird.
• Zugehöriger Artikel:  Avamar zeigt eine Auslastung von bis zu ~30 % an, selbst nachdem alle Backups gelöscht und die automatische Speicherbereinigung ausgeführt wurden  

Noch in MC_DELETED vorhandene Backups:

• Ein seltenes Szenario, das es zu beachten gilt, ist, wenn ein Client auf der Quelle gelöscht wird, seine Backups aber aufbewahrt werden. Dies führt dazu, dass die Quelle eine höhere Auslastung aufweist als das Ziel, auf dem die Backups normal ablaufen würden. Die Verwendung des Skripts dump_root_hashes.rb mit der Option backupcompare hilft bei der Überprüfung auf dieses Szenario.