Avamar: Verhalten und Theorie der Backupperformance

Der Zweck dieses Artikels besteht darin, die Vorgänge während eines Avamar-Backups zu beschreiben, wobei der Schwerpunkt darauf liegt, dem Leser zu helfen, das Verhalten der Backupperformance zu verstehen.

Dieser Artikel ist eine Ergänzung zu den folgenden Artikeln:

• Avamar: Troubleshooting einer langsamen Backupperformance
• Avamar: Schnelle Ausführung von Tuning-Backups

Was geschieht während eines Avamar-Backups?

Der avtar-Backupprozess :

1) Laden der Datei und der Hash-Cache-Dateien in den Arbeitsspeicher

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Erstellung von VSS-Snapshots (unter Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Durchlaufen aller durch das Datenvolumen definierten Dateien Für alle Dateien im Quelldatenvolumen
verwendet avtar den vollständigen Pfad und kombiniert ihn mit den statähnlichen Metadaten, um einen Hash zur eindeutigen Identifizierung der Datei zu berechnen.

Weitere Informationen finden Sie unter Avamar: Was passiert, wenn avtar eine Datei während der Dateiscanphase liest?

4) Vergleichen Sie berechnete Hashes mit denen in den lokalen Client-Caches.

Avtar sucht den Hash der Datei im Dateicache. Es prüft, ob es neu ist oder ob es seit dem letzten Backup geändert wurde.

Wenn die Dateicachesuche erfolgreich ist, ist die Datei vorhanden und unverändert.

Wenn die Suche fehlschlägt, ist die Datei neu oder wurde geändert. Sie müssen gelesen und verarbeitet werden.

Weitere Informationen finden Sie unter Avamar-Client – Was muss geändert werden, bevor avtar eine Datei als geändert betrachtet?

5) Neue und geänderte Dateien

verarbeiten Für jede neue oder geänderte Datei muss avtar :

• Lesen Sie die gesamte Datei.
• Teilen Sie sie in Stücke unterschiedlicher Größe auf
• Komprimieren der einzelnen Blöcke
• Berechnen Sie einen Hash für jeden Block

6) Überprüfen Sie, ob fehlende Hashes auf dem Avamar Server vorhanden sind.

Avtar sendet Daten für alle fehlenden Hashes über das Netzwerk an den Avamar Server, um zu überprüfen, ob sie bereits vorhanden sind. Diese werden als "ispresent"-Anforderungen bezeichnet.

7) Daten werden auf den Avamar Server (und ggf. Data Domain) geschrieben. 

Weitere Informationen zum Workflow finden Sie im beigefügten Avtarprocess.pdf.


Übersicht über ein Avamar-Backup aus Performance-Perspektive:

Anhand der oben genannten Phasen teilen wir sie in "Phasen" auf, die den größten Einfluss auf die Backupperformance haben:

Phase 0. Erstellen von VSS-Snapshots

Der Volume Shadowcopy Service (VSS) erstellt Snapshots von Volumes, die im Quell-Datenvolumen angegeben sind. Anwendungen können weiterhin auf das Volume schreiben, während das Backup ausgeführt wird.
Avamar sichert den schreibgeschützten "eingefrorenen" Snapshot des Volumes anstelle des beschreibbaren Volumes. Dadurch wird sichergestellt, dass ein konsistenter Datensatz gesichert werden kann.

VSS-Snapshots dauern Sekunden. Wenn auf einem Client VSS-Probleme auftreten, verzögert oder verhindert dies das Fortfahren des Backups.

Phase 1. Phase des Datei-Scans. Der avtar-Prozess statiert alle Dateien im Zieldatenvolumen

Für Clients mit Millionen von Dateien ist diese Phase möglicherweise die zeitaufwändigste.
Datenbankdaten enthalten wenige, aber größere Dateien, sodass die Dateiüberprüfungsphase nur wenig Zeit in Anspruch nimmt. Datenbankclients verbrauchen ihre Zeit in der Regel während Phase #2.

Für einen Client mit rotierenden Festplatten in einer RAID 5-Konfiguration ist die Dateiscanleistung von ~1 Million Dateien pro Stunde typisch. Diese variiert zwischen 300.000 und 3 Millionen pro Stunde. Dies hängt von der Clientumgebung und den Eigenschaften der zu sichernden Daten ab.

Ab Version 7.3 können Linux-Clients, die ein Backup auf Data Domain durchführen, die LFI-Funktion (Fast Incremental) von Linux nutzen. Dadurch wird vermieden, dass bei jeder Ausführung des Backups das gesamte Datenvolumen gescannt wird.

Kritische Ressourcen: Performance der Festplatte, auf der die Backupdaten gespeichert sind.

Phase 2. Avtar liest geänderte Dateien und segmentiert, komprimiert und hasht dann die Daten.

In dieser Phase wird viel berechnet. Jede geänderte oder neue Datei wird von avtar in kleine Blöcke aufgeteilt. Jeder Block wird komprimiert und ein Hash als "Fingerabdruck" berechnet, um den Block zu identifizieren.

Dateien in Datenbankbackups sind oft groß und ändern sich in der Regel täglich. Avtar verbringt die meiste Zeit in dieser Phase. Es empfiehlt sich, offizielle Avamar-Datenbank-Plug-ins zu verwenden, um eine effiziente Verarbeitung der Datenbank sicherzustellen, indem Sie inkrementelle Backupfunktionen, Transaktionsprotokolle usw. nutzen.

Die typische Dateiverarbeitungsleistung liegt bei etwa 100 GB pro Stunde, kann jedoch bis zu 300 GB pro Stunde variieren. Dies ist umgebungsabhängig.

Wichtige Ressourcen: Clientfestplatte und CPU

Bei LAN-Backups, bei denen keine Engpässe beim Senden von Daten an den Avamar Server vorliegen, nehmen die Phasen #1 und #2 die meiste Zeit in Anspruch.

Beachten Sie im folgenden Diagramm, dass die Größe der Fläche in den Balken des Diagramms der Dauer des Backups entspricht. Geänderte Dateien können den Zeitaufwand drastisch erhöhen, insbesondere wenn es sich um große Dateien handelt.

Bei Dateisystem-Datenvolumen können Sie davon ausgehen, dass sich ~0–3 % der Dateien täglich ändern.

Avtar muss jede Datei, die sich ändert, mit dem Befehl 'stat()' ausführen, indem zwei I/O-Operationen durchgeführt werden, eine zur Überprüfung der Dateiattribute und eine andere für die Sicherheitsattribute.

Um die Benchmark-Scanratenperformance von ~1 Million Dateien/Stunde für Dateisystembackups zu erreichen, erfordert avtar etwa zwei Millionen Suchvorgänge pro Stunde oder 600 Suchvorgänge pro Sekunde.

Zum Beispiel: Wenn ein Backup eine Änderungsrate von 3 % aufweist, erfordern 97 von 100 Dateien zwei Festplattensuchvorgänge, um zu ermitteln, ob sie geändert wurden. Die verbleibenden drei, die sich geändert haben, müssen gescannt, in Blöcke unterteilt, komprimiert und gehasht werden.

Dies berücksichtigt nur die Phase des Dateiscans, nicht jedoch die I/O-Ressourcen, die für die Verarbeitung von Dateien erforderlich sind, die geändert wurden.
Je mehr Daten in den geänderten Dateien vorhanden sind, desto mehr Arbeit ist erforderlich, um das Backup abzuschließen.

Phase 3. Überprüfen des Vorhandenseins von Hashes auf dem Avamar -Server

Die Phasen #1 und #2 erzeugen Hashes, die auf Elemente des Backups verweisen. Bei diesen Elementen kann es sich um eindeutige Dateiblöcke, Dateisysteme oder komplette Backups handeln.

Die Hashes werden in die Clientcachedateien geschrieben und mit den auf dem Avamar Server vorhandenen Hashes verglichen, um zu prüfen, ob neue Daten hinzugefügt werden müssen. Dies gilt unabhängig davon, ob ein Avamar Server oder Data Domain der Ziel-Storage ist.

Hash-Vergleiche zwischen Avamar-Client und -Server erfolgen in der Regel schnell. Sie sollten keine Engpässe beim Backup verursachen, wenn beim Avamar Server Folgendes zutrifft:

• Gesund
• Bei normaler Auslastung
• Befindet sich im selben LAN-Segment wie der Client

Da die Hashes nur 20 Byte groß sind, wird diese Phase mehr von der Netzwerklatenz als von der Netzwerkbandbreite beeinflusst. Wenn der Hash auf dem Avamar Server eintrifft, bestimmen die allgemeine Last und die zufällige Suchperformance des Festplattensubsystems der Daten-Nodes, wie schnell der Hash abgerufen und mit dem vom Client gesendeten verglichen wird.

Wichtige Ressourcen: Netzwerkantwortzeit und Performance bei zufälligen Suchvorgängen des Avamar-Daten-Node.

Die Performance bei zufälligen Suchvorgängen einer physischen Avamar-Instanz skaliert mit der Anzahl und Größe der Daten-Nodes. AVE-Systeme bieten eine weniger gute Performance, vergleichbar mit einem Single-Node-System.

Phase 4. Senden des neuen Blocks über das Netzwerk an den Avamar Server oder Data Domain

Wenn ein Client einen neuen, eindeutigen Block (mit einer Größe von bis zu 64 KB) an den Server sendet, hängt die Performance in erster Linie von der Netzwerkbandbreite ab. Dies betrifft vor allem WAN-basierte Clients, die täglich eine große Menge geänderter Daten generieren. Es kann sich auch auf diejenigen auswirken, die über überlastete Netzwerkverbindungen arbeiten. 

Im Folgenden finden Sie schematische Darstellungen des Datenflusses, wobei ein Client Daten an ein Avamar-System und an ein integriertes Avamar-Data Domain-System sendet.






Wichtige Ressourcen: Netzwerkbandbreite zwischen Client und Server

Phase 5. Auf den Avamar Server oder Data Domain

geschriebene DatenBackupdaten müssen auf den Avamar Server oder das Data Domain-System geschrieben werden.

Wichtige Ressourcen: Schreibperformance der Avamar-Serverfestplatte und allgemeines Laden.