Troubleshooting eines schlechten Deduplizierungs- und Komprimierungsverhältnisses von Dateien auf Data Domain Restorers (DDRs)

Data Domain Restorers (DDRs) sind darauf ausgelegt, große Mengen an logischen (vorkomprimierten) Daten unter Verwendung von minimalem physischem (postkomprimiertem) Festplattenspeicher zu speichern. Dies wird erreicht durch:

• Deduplizierung aufgenommener Daten zum Entfernen doppelter Datenblöcke, die bereits auf der Festplatte auf dem DDR gespeichert sind, sodass nur eindeutige Daten übrig bleiben
• Komprimierung eindeutiger Daten, bevor diese Daten physisch auf die Festplatte geschrieben werden.

Das allgemeine Komprimierungsverhältnis von Daten, die ein DDR aufnehmen kann, variiert aufgrund verschiedener Faktoren, wie z. B.:

• Anwendungsbeispiel
• Aufgenommene Datentypen
• Konfiguration der Backupanwendung

Bei optimaler Konfiguration erzielen DDRs in der Regel ein 10- bis 20-faches Gesamtkomprimierungsverhältnis (und können manchmal höhere Kennzahlen anzeigen). Umgekehrt kann jedoch in einigen Umgebungen das allgemeine Komprimierungsverhältnis niedriger sein als dies, was zu Folgendem führen kann:

• Der DDR kann seine nutzbare Kapazität schnell ausschöpfen.
• Auswirkungen auf Backup-, Wiederherstellungs- oder Replikationsperformance
• Ein Fehler des DDR, um die Kundenerwartungen zu erfüllen

In diesem Artikel soll Folgendes besprochen werden:

• Eine kurze Übersicht über die Deduplizierung und Komprimierung von Daten auf einem DDR
• Bestimmen des allgemeinen Komprimierungsverhältnisses für das System und einzelne Dateien
• Faktoren, die zu einer Verschlechterung des allgemeinen Komprimierungsverhältnisses führen können

Wie nimmt ein Data Domain Restorer neue Daten auf?

• Die Backupanwendung sendet Daten (d. h. Dateien) an den DDR.
• Der DDR teilt diese Dateien in Blöcke mit einer Größe von 4 bis 12 KB auf – jeder Block wird als "Segment" betrachtet.
• Der DDR erzeugt je nach den im Segment enthaltenen Daten einen eindeutigen "Fingerabdruck" (ähnlich einer Prüfsumme) für jedes Segment.
• Die Fingerabdrücke der neu eingetroffenen Segmente werden in Festplattenindizes auf dem DDR abgehakt, um festzustellen, ob der DDR bereits ein Segment mit demselben Fingerabdruck enthält.
• Wenn der DDR bereits ein Segment mit demselben Fingerabdruck enthält, ist das entsprechende Segment in den neu eingetroffenen Daten ein Duplikat und kann gelöscht werden (d. h. dedupliziert).
• Sobald alle doppelten Segmente aus den neu eingetroffenen Daten entfernt wurden, bleiben nur eindeutige oder neue Segmente erhalten.
• Diese eindeutigen oder neuen Segmente werden in 128 KB "Komprimierungsbereiche" gruppiert und dann komprimiert (standardmäßig mit dem lz-Algorithmus ).
• Komprimierte Komprimierungsregionen werden in 4,5-Mb-Speichereinheiten komprimiert, die als "Container" bezeichnet werden und dann auf die Festplatte geschrieben werden.

Wie verfolgt der DDR, welche Segmente eine bestimmte Datei bilden?

Neben der Deduplizierung/Komprimierung neu eingetroffener Daten erstellt der DDR auch eine "Segmentstruktur" für jede aufgenommene Datei. Dies ist im Wesentlichen eine Liste der Segment-"Fingerabdrücke", aus denen diese Datei besteht. Wenn der DDR die Datei später wieder lesen muss, wird Folgendes ausgeführt:

• Bestimmen Sie den Speicherort der Dateisegmentstruktur.
• Lesen Sie die Segmentstruktur, um eine Liste aller Segmentfingerabdrücke zu erhalten, die den Bereich der zu lesenden Datei bilden.
• Verwenden Sie in Festplattenindizes, um den physischen Speicherort (d. h. Container) der Daten auf der Festplatte zu bestimmen.
• Lesen Sie die physischen Segmentdaten aus den zugrunde liegenden Containern auf der Festplatte.
• Verwenden Sie physische Segmentdaten, um die Datei zu rekonstruieren.

Dateisegmentstrukturen werden auch in 4,5-Mb-Containern auf der Festplatte gespeichert und stellen den Großteil der einzelnen Dateien "Metadaten" dar (weiter unten in diesem Artikel erläutert).

Wie kann das allgemeine Komprimierungsverhältnis auf einem DDR ermittelt werden?

Die Gesamtauslastung eines DDR (und Komprimierungsverhältnis) kann mit dem Befehl "filesys show space" angezeigt werden. Beispiel:

Aktiver Tier:
Ressourcengröße GiB Verwendet GiB Nutzung GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/Data: pre-comp - 115367.8 - -
/data: post-comp 6794 0,2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % –


---------------- -------- -------- --------- ---- -------------- In diesem Fall sehen wir Folgendes:

• Vorkomprimierte oder logische Daten, die auf DDR gespeichert sind: 115367,8 Gb
• Postkomprimierte oder physischer Speicherplatz, der auf DDR verwendet wird: 6242,4 GB
• Das Gesamtkomprimierungsverhältnis beträgt 115367,8 / 6242,4 = 18,48 x

Die Ausgabe des Befehls "filesys show compression" bestätigt die gespeicherten Daten, den verwendeten Speicherplatz und das Komprimierungsverhältnis. Zum Beispiel:

                   Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:*   115367.8 6242.4 – 18,5 x (94,6) <– HINWEIS
geschrieben:                                                                          
  Letzte 7 Tage 42214,7 1863,2 11,0 x 2,1 x 22,7 x (95,6)
  Die letzten 24 Stunden 4924,8 274,0 8,8 x 2,0 x 18,0 x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Overall-Auslastungszahlen auf dem DDR werden wie folgt berechnet:

• Insgesamt vorkomprimierte Daten: Die Summe der vorkomprimierten (logischen) Größe aller Dateien, die vom DDR aufbewahrt werden.
• Gesamtanzahl der postkomprimierten Daten: Die Anzahl der verwendeten Container auf der Festplatte multipliziert mit 4,5 Mb (die Größe eines einzigen Containers).
• Postkomprimierte Gesamtgröße: Die Anzahl der maximalen "Container", die erstellt werden, wenn der verfügbare Speicherplatz auf dem System angegeben wird.

Statistiken zur maximal verwendeten Container sind in Autosupports verfügbar. Beispiel:

Container-Set 73fcwolledea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <== Containergröße in Byte
...
    attrs.max_containers = 1546057 <== Maximal mögliche Container
attrs.free_containers = 125562 <== Derzeit freie Container
attrs.used_containers = 1420495 <== Derzeit in Verwendung von Containern
...

Sehen Sie sich Folgendes an:
 
Wie können Deduplizierungs- und Komprimierungsverhältnisse für eine einzelne Datei, ein Einzelnes Verzeichnis oder eine Verzeichnisstruktur ermittelt werden?

Wenn eine Datei aufgenommen wird, erfasst der DDR Statistiken über die Datei, einschließlich:

• Vorkomprimierte (logische) Byte
• Größe der eindeutigen Segmente nach deduplizierung
• Größe der eindeutigen Segmente nach Deduplizierung und Komprimierung
• Größe der Metadaten der Datei (d. h. Segmentstruktur usw.)

Es ist möglich, einige dieser Statistiken mit dem Befehl "filesys show compression [path]" zu speichern, z. B. um Statistiken für eine einzelne Datei zu melden:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  Byte/storage_used: 2.9
Ursprüngliche Byte:        3.242.460.364
Global komprimiert:        1.113.584.070
lokal komprimiert:        1.130.871.915
Metadaten:            4.772.672

So melden Sie Statistiken für eine gesamte Verzeichnisstruktur:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  Byte/storage_used: 1.4
Ursprüngliche Byte:        7.554.284.280
global komprimiert:        5.425.407.986
lokal komprimiert:        5.510.685.100
Metadaten:           23.263.692

Beachten Sie jedoch, dass es bei der Verwendung dieser Statistiken einige Einschränkungen gibt:

• Die Statistiken werden zum Zeitpunkt der Datei- oder Datenaufnahme erzeugt und danach nicht aktualisiert. Aufgrund der Funktionsweise eines DDR kann die Aufnahme neuer Dateien oder das Löschen von Dateien, die auf dieselben Daten verweisen usw. ändern, wie eine Datei im Laufe der Zeit dedupliziert wird, was dazu führt, dass diese Statistiken veraltet werden.
• Darüber hinaus können bestimmte Anwendungsfälle auf dem DDR (z. B. fastcopy einer Datei und anschließendes Löschen der ursprünglichen Datei) dazu führen, dass diese Statistiken irreführend oder falsch werden.

Daher sollten diese Zahlen nur als Schätzungen betrachtet werden.

Die vorkomprimierten Bytes entsprechen nicht unbedingt der vorkomprimierten/logischen Größe der Datei. Stattdessen handelt es sich um die Gesamtzahl der Byte, die in ihrer Lebensdauer in eine Datei geschrieben wurden. Daher werden in bestimmten Umgebungen vorhandene Dateien häufig überschrieben (z. B. solche, die funktionen der virtuellen Bandbibliothek verwenden), diese Abbildung kann größer sein als die logische Größe der entsprechenden Dateien.

Kann die Aufnahme von Daten mit "schlechter Qualität" zu einer Verschlechterung des allgemeinen Komprimierungsverhältnisses führen?

Ja – Damit ein DDR ein gutes Komprimierungsverhältnis der aufgenommenen Daten erreichen kann, muss er diese Daten deduplizieren und komprimieren können. Es gibt verschiedene Arten von Daten, die dies verhindern können, wie unten beschrieben:

Vorkomprimierte/vorverschlüsselte Daten:

Dies sind Datentypen, die entweder auf dem Clientsystem oder durch die Backupanwendung komprimiert oder verschlüsselt werden. Dies kann auch anwendungsspezifische Dateien umfassen, die per Design komprimiert oder verschlüsselt werden (z. B. Mediendateien) und Datenbankdateien, die entweder komprimiert oder verschlüsselt sind oder binäre Objekte wie Mediendateien einbetten.

Aufgrund der Art und Weise, wie der Komprimierungs- oder Verschlüsselungsalgorithmus eine relativ kleine Änderung an den zugrunde liegenden Daten einer Datei verwendet, führt dies dazu, dass Änderungen in der gesamten Datei "ankniffen". Ein Client kann beispielsweise eine 100 Mb verschlüsselte Datei enthalten, in der 10 KB geändert werden. Normalerweise wäre die resultierende Datei vor und nach der Änderung identisch, abgesehen vom 10-KB-Abschnitt, der sich geändert hat. Wenn die Verschlüsselung verwendet wird, obwohl sich vor und nach der Änderung nur 10 KB unverschlüsselter Daten geändert haben, führt der Verschlüsselungsalgorithmus dazu, dass sich der gesamte Inhalt der Datei ändert.

Wenn solche Daten regelmäßig geändert und regelmäßig an einen DDR gesendet werden, führt dieser "Welleneffekt" dazu, dass jede Generation der Datei anders als frühere Generationen derselben Datei aussieht. Daher enthält jede Generation einen eindeutigen Satz von Segmenten (und Segmentfingerabdrücke), sodass ein schlechtes Deduplizierungsverhältnis angezeigt wird.

Beachten Sie auch, dass anstelle von vorkomprimierten Dateien der lz-Algorithmus wahrscheinlich nicht in der Lage sein wird, konstituierende Segmentdaten weiter zu komprimieren, sodass Daten nicht komprimiert werden können, bevor sie auf die Festplatte geschrieben werden.

Als allgemeine Richtlinie führt die Vorkomprimierung/Vorabverschlüsselung zu Folgendem:

• Vorverschlüsselte Daten: Schlechtes Deduplizierungsverhältnis, aber akzeptables Komprimierungsverhältnis
• Vorkomprimierte Daten: Schlechtes Deduplizierungsverhältnis und schlechtes Komprimierungsverhältnis

Wenn dieselben (unveränderten) vorkomprimierten/vorverschlüsselten Daten mehrmals von einem DDR aufgenommen werden, verbessert sich das Deduplizierungsverhältnis der Daten, da trotz der Verwendung von Komprimierungs- oder Verschlüsselungsalgorithmen bei jedem Backup eine ähnliche Gruppe von Segmenten (und Segmentfingerabdrücke) angezeigt wird.

Wenn möglich, sollten an einen DDR gesendete Daten nicht verschlüsselt oder komprimiert werden. Dies kann die Deaktivierung der Verschlüsselung oder Komprimierung auf dem Endclient oder innerhalb der entsprechenden Backupanwendung erfordern.

Wenden Sie sich an den entsprechenden Supportanbieter, um Unterstützung bei der Überprüfung, Änderung der Verschlüsselungs- oder Komprimierungseinstellungen innerhalb eines bestimmten Backups, einer Clientanwendung oder eines Betriebssystems zu erhalten.

Mediendateien:

Bestimmte Dateitypen enthalten standardmäßig vorkomprimierte oder vorverschlüsselte Daten. Zum Beispiel:

• PDF-Dateien
• Bestimmte Audiodateien (mp3, wma, ogg usw.)
• Videodateien (avi, mkv usw.)
• Bilddateien (png, bmp, jpeg usw.)
• Anwendungsspezifische Dateien (Microsoft Office, Open Office, Libre Office usw.)

Die Daten in den Dateien werden durch den Codec der Datei komprimiert oder verschlüsselt und führen daher zu den gleichen Problemen, wenn sie auf einem DDR aufgenommen werden, wie oben beschrieben für vorkomprimierte oder vorverschlüsselte Daten.

Dateien mit hoher "Eindeutigkeit":

Das Erreichen eines guten Deduplizierungsverhältnisses hängt davon ab, ob der DDR mehrmals dieselbe Gruppe von Segmenten (und Segment-Fingerabdrücken) sieht. Bestimmte Datentypen enthalten jedoch nur eindeutige Transaktionsdaten, die designweise "eindeutige" Daten enthalten.

Wenn diese Dateien an einen DDR gesendet werden, enthält jede Generation des Backups einen eindeutigen Satz von Segmenten oder Segmentfingerabdrucken und erkennt daher ein herabgesetztes Deduplizierungsverhältnis.

Beispiele für solche Dateien sind:

• Datenbanktransaktionsprotokolle (z. B. Oracle-Archivprotokolle).
• Microsoft Exchange-Transaktionsprotokolle

Das erste Backup eines "neuen" Clients auf einem DDR kann ebenfalls dieses Problem verursachen (da die Daten zuvor vom DDR nicht gesehen wurden, sind die entsprechenden Segmente oder Segmentfingerabdrücke im Backup eindeutig). Wenn jedoch zukünftige Generationen desselben Backups an den DDR gesendet werden, verbessert sich das Deduplizierungsverhältnis von Backups, da weniger Segmente in jedem neuen Backup eindeutig sind. Aus diesem Grund wird erwartet, dass das gesamte Deduplizierungs- oder Komprimierungsverhältnis auf einem neu installierten DDR, der hauptsächlich neue Backups empfängt, heruntergestuft wird, sich aber im Laufe der Zeit verbessert.

Kleine Dateien:

Kleine Dateien verursachen verschiedene Probleme beim Schreiben auf einen DDR. Dazu gehören:

• Metadatenaufblähung: Der DDR enthält im Vergleich zu physischen Daten eine höhere Menge an Dateimetadaten als erwartet.
• Schlechte Containerauslastung – designmäßig (aufgrund des Data Domain Stream Informed Segment Layout oder der SISL-Architektur – über den Umfang dieses Dokuments hinaus) enthält ein 4,5-Mb-Container auf der Festplatte nur Daten aus einer einzigen Datei. Das Backup einer einzelnen 10-KB-Datei führt beispielsweise dazu, dass mindestens ein vollständiger 4,5-Mb-Container für diese Datei geschrieben wird. Dies kann bedeuten, dass der DDR für solche Dateien deutlich mehr postkomprimierten (physischen) Speicherplatz verwendet als die entsprechende Menge der vorkomprimierten (logischen) daten, die gesichert werden, was wiederum ein negatives Gesamtkomprimierungsverhältnis verursacht.
• Schlechtes Deduplizierungsverhältnis: Dateien, die kleiner als 4 KB sind (die minimale unterstützte Segmentgröße auf einem DDR), bestehen aus einem einzigen Segment, das auf 4 KB gepolstert ist. Solche Segmente werden nicht dedupliziert, sondern direkt auf die Festplatte geschrieben. Dies kann dazu führen, dass der DDR mehrere Kopien desselben Segments (als doppelte Segmente) hält.
• Schlechte Backup-, Wiederherstellungs- oder Bereinigungsperformance – Es gibt große Overheads während des Backups, der Wiederherstellung oder der Bereinigung, wenn von einer Datei zur nächsten verschoben wird (da der Kontext der verwendeten Metadaten gewechselt werden muss).

Sehen Sie sich Folgendes an:

• Die Auswirkungen auf die Bereinigungsleistung bei verwendung kleiner Dateien wurden durch die Einführung der physischen Bereinigung oder automatischen Speicherbereinigung in DDOS 5.5 und höher bis zu einem gewissen Grad verringert.
• Die Bereinigung versucht, die schlechte Containerauslastung rückgängig zu machen, indem Daten aus Containern mit geringer Auslastung während der Kopierphase in eng gepackte Container aggregiert werden.
• Bereinigung versucht, übermäßige doppelte Segmente während der Kopierphase zu entfernen.

Trotz der obigen Schritte sollte die Verwendung einer großen Anzahl kleiner Dateien oder Workloads, die hauptsächlich aus kleinen Dateien bestehen, vermieden werden. Es ist besser, vor dem Backup eine große Anzahl kleiner Dateien in einem einzigen dekomprimierten/unverschlüsselten Archiv zu kombinieren, als die kleinen Dateien in ihrem nativen Zustand an den DDR zu senden. Es ist beispielsweise viel besser, eine einzelne 10-Gbit-Datei zu sichern, die 1048576 einzelnen 10-KB-Dateien enthält, als alle 1048576-Dateien einzeln.

Übermäßiges Multiplexing durch Backupanwendungen:

Backupanwendungen können so konfiguriert werden, dass Multiplexing von Daten über Streams hinweg durchgeführt wird, die an das Backupgerät gesendet werden, d. h. Daten aus Eingabestreams (d. h. verschiedene Clients) werden in einem einzigen Stream an das Backupgerät gesendet. Diese Funktion ist in erster Linie beim Schreiben auf physische Bandgeräte wie folgt zu verwenden:

• Ein physisches Bandgerät kann nur einen einzelnen eingehenden Schreibstream unterstützen.
• Die Backupanwendung muss einen ausreichenden Durchsatz auf dem Bandgerät aufrechterhalten, um zu verhindern, dass Band gestartet, gestoppt oder zurückspulet (auch als "Shoe-Shining" bezeichnet). Dies ist einfacher, wenn der Stream, der zum Bandgerät geht, Daten enthält, die von mehr als einem Client gelesen werden.

Im Falle eines DDR führt dies jedoch dazu, dass eine einzelne Datei auf dem DDR Daten von mehreren Clients enthält, die in beliebiger Reihenfolge oder Blockgröße verschachtelt sind. Dies kann zu einer herabgesetzten Deduplizierungsrate führen, da der DDR möglicherweise nicht in der Lage ist, doppelte Segmente aus jeder Generation eines bestimmten Clients-Backups genau zu erkennen. Im Allgemeinen gilt: Je kleiner die Multiplexing-Granularität ist, desto schlechter sind die Auswirkungen auf das Deduplizierungsverhältnis.

Darüber hinaus kann die Wiederherstellungsleistung schlecht sein, da der DDR viele Dateien oder Container lesen muss, wenn die meisten Daten in den Dateien oder Containern überflüssig sind, da sie sich auf backups anderer Clients beziehen.

Backupanwendungen dürfen beim Schreiben auf einen DDR kein Multiplexing verwenden, da DDRs eine höhere eingehende Streamanzahl als physische Bandgeräte unterstützen, da jeder Stream mit einer variablen Geschwindigkeit schreiben kann. Daher sollte Multiplexing durch Backupanwendungen deaktiviert werden. Wenn die Backupperformance nach dem Deaktivieren von Multiplexing beeinträchtigt wird, gehen Sie wie folgt vor:

• Bei Backupanwendungen mit CIFS, NFS oder OST (DDBoost) sollte die Anzahl der Schreibstreams erhöht werden (sodass mehr Dateien parallel auf dem DDR geschrieben werden können).
• Umgebungen, die VTL verwenden, sollten dem DDR zusätzliche Laufwerke hinzufügen, da jedes Laufwerk die Unterstützung eines zusätzlichen parallelen Schreibstreams ermöglicht.

Wenn Unterstützung bei der Deaktivierung von Multiplexing erforderlich ist oder Sie die empfohlene Multiplexing-Konfiguration für eine bestimmte Backupanwendung besprechen möchten, wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter.

Backupanwendungen, die übermäßige Bandmarkierungen einfügen:

Einige Backupanwendungen können wiederholte Datenstrukturen in einen Backupstream einfügen, der als "Marker" bezeichnet wird. Markierungen stellen keine physischen Daten innerhalb des Backups dar, sondern werden stattdessen von der Backupanwendung als Indexierungs- oder Positionssystem verwendet.

Unter bestimmten Umständen kann die Einbeziehung von Markern in einen Backupstream das Deduplizierungsverhältnis beeinträchtigen, z. B.:

• In der ersten Generation eines Backups gab es 12 KB Daten, die zusammenhängend waren. Dies wurde vom DDR als ein einziges Segment erkannt.
• In der zweiten Generation des Backups werden jedoch dieselben 12 KB an Daten durch die Einbeziehung einer Backupmarkierung aufgeteilt, die durch 6 KB Daten, Backupmarkierung und 6 KB Daten dargestellt werden kann.
• Daher stimmen die Segmente, die während der zweiten Generation des Backups erstellt werden, nicht mit denen überein, die während der ersten Generation des Backups erzeugt wurden. Daher werden sie nicht ordnungsgemäß dedupliziert.

Je enger die Markierungen entfernt sind, desto schlechter sind die Auswirkungen auf das Deduplizierungsverhältnis (z. B. verursacht das Einfügen von Markern einer Backupanwendung alle 32 KB mehr Probleme als das Einfügen von Markern in einer Backupanwendung alle 1 Mb).

Um dieses Problem zu vermeiden, verwendet der DDR eine Marker Recognition-Technologie, die Folgendes ermöglicht:

• Backupmarkierungen, die während der Aufnahme des Backups transparent aus dem Backupstream entfernt werden.
• Backupmarkierungen, die während der Wiederherstellung des Backups wieder in den Backupstream eingefügt werden

Dies trägt dazu bei, die Fragmentierung von Daten oder Segmenten durch Backupmarkierungen zu verhindern, und verbessert das Deduplizierungsverhältnis der entsprechenden Backups.

Um diese Technologie voll auszuschöpfen, ist es jedoch wichtig, dass der DDR die Markierungen, die in Backupstreams eingefügt werden, korrekt erkennen kann. Der DDR sucht nach Markierungen, abhängig von der Einstellung der Option "marker type", z. B.:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Markierungstyp automatisch
...


-------------------------------- --------Usualerweise sollte dies auf "auto" eingestellt werden, da dies es dem DDR ermöglicht, automatisch den gängigsten Markierungstypen zu entsprechen. Wenn das System Daten von nur einer Backupanwendung erfasst, die Markierungen einfügt, kann die Angabe eines bestimmten Markierungstyps einen Performancevorteil haben, d. h.:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Beachten Sie Folgendes:

• Jeder Vorteil der Performance durch die Auswahl eines bestimmten Markierungstyps ist wahrscheinlich minimal.
• Die Auswahl eines falschen Markierungstyps kann zu einer erheblichen zusätzlichen Verschlechterung der Backup- oder Wiederherstellungsperformance und des Deduplizierungsverhältnisses führen.

Daher empfiehlt Data Domain in der Regel, den Markierungstyp auf "auto" festzulegen. Wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter, um weitere Ratschläge zur Änderung des Markierungstyps zu erhalten.

Für Systeme, die Daten aus Anwendungen aufnehmen, die Backupmarkierungen verwenden, aber nicht durch automatisierte Marker-Handling-Technologie (z. B. Produkte von BridgeHead-Software) erkannt werden, wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter, der dann mit dem Data Domain-Support zusammenarbeiten kann, um die erforderlichen Einstellungen auf dem DDR zu bestimmen, um den nicht standardmäßigen Marker zu erkennen.

Hinweise darauf, dass daten mit schlechter Qualität von einem DDR empfangen werden:

In der folgenden Tabelle sind die erwarteten Deduplizierungs- und Komprimierungsverhältnisse für die verschiedenen oben aufgeführten Datentypen aufgeführt. Diese Liste ist nicht erschöpfend und es kann offensichtlich einige Abweichungen bei den genauen Zahlen geben, die aufgrund von Workloads oder Daten, die vom DDR aufgenommen werden, auf einem bestimmten System zu sehen sind:
 

Globale Komprimierung	Lokale Komprimierung	Wahrscheinliche Ursache
Niedrig (x 1 bis 4)	Niedrig (x 1 bis 1,5)	Vorkomprimierte oder verschlüsselte Daten
Niedrig (x 1 bis 2)	Hoch (>x 2)	Eindeutige, aber komprimierbare Daten, z. B. Datenbankarchivprotokolle
Niedrig (x 2 bis 5)	Hoch (>x 1,5)	Markierungen, die nicht erkannt werden, oder eine hohe Datenänderungsrate oder Stream-Multiplexing.
Hoch (>10x)	Niedrig (<x 1,5)	Backups derselben komprimierten oder verschlüsselten Daten. Das ist ungewöhnlich.

Gibt es bestimmte Faktoren auf einem DDR, die sich auf das gesamte Deduplizierungsverhältnis auswirken können?

Ja – Es gibt mehrere Faktoren, die dazu führen können, dass alte/Superflous-Daten auf der Festplatte auf einem DDR aufbewahrt werden, was zu einer Zunahme des postkomprimierten (physischen) Speicherplatzes und einem Rückgang des komprimierten Gesamtverhältnisses führt. Solche Faktoren werden unten besprochen.

Ein Fehler beim regelmäßigen Ausführen der Dateisystembereinigung:

Die Dateisystembereinigung ist die einzige Möglichkeit, alte/Superflous-Daten auf der Festplatte physisch zu entfernen, die nicht mehr von Dateien auf dem DDR referenziert werden. Infolgedessen löscht ein Benutzer möglicherweise mehrere Dateien aus dem System (was zu einem Rückgang der vorkomprimierten Auslastung führt), führt aber nicht bereinigt aus (sodass die postkomprimierte/physische Auslastung hoch bleibt). Dies würde zu einem Rückgang des allgemeinen Komprimierungsverhältnisses führen.

Data Domain empfiehlt, die Bereinigung wie folgt in regelmäßigen Abständen auszuführen:

• Normaler DDR: Einmal pro Woche
• DDR mit erweiterter Aufbewahrung: Einmal alle zwei Wochen

Die Bereinigung sollte nicht mehr als einmal pro Woche ausgeführt werden, da dies zu Problemen mit der Fragmentierung von Daten auf der Festplatte führen kann, die sich als schlechte Wiederherstellungs-/Replikationsleistung manifestieren.

Übermäßige alte Snapshots auf dem System:

DDRs können MTree-Snapshots erstellen, die den Inhalt eines MTree zu dem Zeitpunkt darstellen, zu dem der Snapshot erstellt wurde. Beachten Sie jedoch, dass das Verlassen alter Snapshots auf einem System zu einer Zunahme der postkomprimierten/physischen Auslastung führen kann, was zu einem Rückgang des gesamten Komprimierungsverhältnisses führt. Zum Beispiel:

• Ein MTree enthält viele Dateien (daher ist die vorkomprimierte Auslastung hoch).
• Ein Snapshot des MTree wird erstellt.
• Viele Dateien werden gelöscht (was dazu führt, dass die vorkomprimierte Auslastung abfällt).
• Dateisystembereinigung wird ausgeführt. Beachten Sie jedoch, dass nur minimaler Festplattenspeicherplatz freigegeben wird, da eine Kopie der gelöschten Dateien im MTree-Snapshot verbleibt, was bedeutet, dass daten, die von diesen Dateien referenziert werden, nicht von der Festplatte entfernt werden können.
• Infolgedessen bleibt die postkomprimierte/physische Auslastung hoch.

Data Domain empfiehlt, bei Verwendung von MTree-Snapshots (z. B. für die Recovery nach versehentlichem Löschen von Daten) mit automatisierten Snapshot-Zeitplänen zu verwalten, sodass Snapshots in regelmäßigen Abständen mit einem definierten Ablaufzeitraum erstellt werden (die Zeitdauer, bevor der Snapshot automatisch entfernt wird). Darüber hinaus sollte der Ablaufzeitraum so kurz wie möglich sein (dies kann jedoch offensichtlich vom Anwendungsbeispiel der Snapshots oder dem Schutzlevel abhängen, das diese Snapshots bereitstellen). Dadurch wird verhindert, dass alte Snapshots mit einem langen Ablaufzeitraum erstellt werden.

Weitere Informationen zum Arbeiten mit Snapshots und Snapshot-Zeitplänen finden Sie im folgenden Artikel: Data Domain – Managen von Snapshot-Zeitplänen

Übermäßige Replikationsverzögerung:

Die native Data Domain-Replikation verwendet entweder ein Replikationsprotokoll oder MTree-Snapshots (je nach Replikationstyp), um nachzuverfolgen, welche Dateien oder Daten eine Replikation auf einen Remote-DDR ausstehen. Replikationsverzögerung ist das Konzept, dass das Replikat änderungen am Quell-DDR hinterherhinkt. Dies kann auf verschiedene Faktoren zurückzuführen sein, darunter:

• Deaktivierte Replikationskontexte
• Unzureichende Netzwerkbandbreite zwischen DDRs
• Häufige Netzwerktrennung.

Große Replikationsverzögerungen können dazu führen, dass das Replikationsprotokoll weiterhin Verweise auf Dateien enthält, die auf dem Quell-DDR oder alten oder veralteten MTree-Snapshots auf Quell- und Ziel-DDRs gelöscht wurden. Wie oben beschrieben, können die von diesen Snapshots (oder dem Replikationsprotokoll) referenzierten Daten nicht physisch von der Festplatte auf dem DDR entfernt werden, selbst wenn entsprechende Dateien aus dem System gelöscht wurden. Dies kann dazu führen, dass die postkomprimierte oder physische Auslastung des DDR steigt, was dann zu einer Verschlechterung des Deduplizierungsverhältnisses führt.

Wenn DDRs unter hoher Auslastung leiden und dies vermutlich auf Replikationsverzögerungen zurückzuführen ist, wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter, um weitere Unterstützung zu erhalten.

Gibt es Konfigurationsänderungen oder bestimmte Faktoren auf einem DDR, die das Komprimierungsverhältnis insgesamt erhöhen können?

Ja– Das Entfernen oder Beheben der zuvor in diesem Dokument besprochenen Probleme sollte es einem DDR ermöglichen, ein verbessertes Komprimierungsverhältnis im Laufe der Zeit anzuzeigen. Es gibt auch verschiedene Faktoren oder Arbeitslasten auf einem DDR, die zu einer Steigerung der Deduplizierungsrate führen können. Dazu gehören in der Regel:

• Reduzierung des Festplattenspeicherplatzes, der von Dateien auf dem DDR verwendet wird (z. B. Erhöhung der Aggressivität des komprimierungsalgorithmus, der vom DDR verwendet wird)
• Plötzliches Erhöhen der Menge der vorkomprimierten (logischen) Daten auf dem DDR ohne eine entsprechende Steigerung der postkomprimierten/physischen Auslastung

Änderung des Komprimierungsalgorithmus:

Standardmäßig komprimieren DDRs Daten, die mit dem lz-Algorithmus auf die Festplatte geschrieben werden. Wie bereits erwähnt, wird lz verwendet, da es relativ geringe Overheads in Bezug auf die CPU aufweist, die für die Komprimierung oder Dekomprimierung erforderlich sind, aber eine angemessene Effektivität bei der Reduzierung der Datengröße zeigt.

Es ist möglich, die Aggressivität des Komprimierungsalgorithmus zu erhöhen, um weitere Einsparungen bei der postkomprimierten oder Festplattenauslastung zu erzielen (und damit das Komprimierungsverhältnis insgesamt zu verbessern). Unterstützte Komprimierungsalgorithmen in der Reihenfolge der Effektivität (von niedrig bis hoch) lauten wie folgt:

• Lz
• gzfast
• Gz

Ein allgemeiner Vergleich der einzelnen Algorithmen lautet wie folgt:

• lz im Vergleich zu gzfast bietet ~15 % bessere Komprimierung und verbraucht 2-mal mehr CPU.
• lz im Vergleich zu gz bietet ~30 % bessere Komprimierung und verbraucht 5-mal mehr CPU.
• gzfast im Vergleich zu gz bietet ca. 10 bis 15 % bessere Komprimierung.

Es ist auch möglich, die Komprimierung vollständig zu deaktivieren (geben Sie einen Algorithmus von none an), dies wird jedoch nicht für die Verwendung auf Kundensystemen unterstützt und ist nur für interne Tests vorgesehen.

Gemäß der obigen Tabelle gilt: Je aggressiver der Komprimierungsalgorithmus ist, desto mehr CPU ist während der Komprimierung oder Dekomprimierung von Daten erforderlich. Aus diesem Grund sollten Änderungen an einem aggressiveren Algorithmus nur auf Systemen vorgenommen werden, die bei normaler Workload leicht geladen sind. Das Ändern des Algorithmus auf stark ausgelasteten Systemen kann zu einer extremen Verschlechterung der Backup- oder Wiederherstellungsleistung und möglichen Dateisystem-Paniken oder Neustarts führen (was zu einem Ausfall des DDR führt).

Weitere Informationen zum Ändern des Komprimierungstyps finden Sie im folgenden Artikel: Auswirkungen der Konvertierung in GZ-Komprimierung

auf das Data Domain-System und die BereinigungsleistungAufgrund der potenziellen Auswirkungen einer Änderung des Komprimierungsalgorithmus wird empfohlen, dass Kunden, die dies tun möchten, sich an ihren vertraglich vereinbarten Supportanbieter wenden, um die Änderung weiter zu besprechen, bevor sie fortfahren.

Verwendung von file system fastcopy:

DDRs ermöglichen die Verwendung des Befehls "file system fastcopy", um schnell eine Datei (oder Verzeichnisstruktur) zu kopieren. Diese Funktion erstellt eine Datei durch Klonen der Metadaten einer vorhandenen Datei (oder Einer Gruppe von Dateien), sodass die neuen Dateien zwar nicht physisch mit der ursprünglichen Datei verbunden sind, aber genau dieselben Daten auf der Festplatte wie die ursprüngliche Datei referenzieren. Das bedeutet, dass die neue Datei unabhängig von der Größe der ursprünglichen Datei wenig Speicherplatz auf der Festplatte belegt (da sie perfekt mit vorhandenen Daten dedupliziert wird).

Das Ergebnis dieses Verhaltens ist, dass bei Verwendung von File System Fastcopy die vorkomprimierte (logische) Größe der Daten auf dem DDR schnell zunimmt, die postkomprimierte/physische Auslastung des DDR jedoch statisch bleibt.

Der folgende DDR verfügt beispielsweise über eine Auslastung wie folgt (was das Komprimierungsverhältnis von ~1,8x angibt):

Aktiver Tier:
Ressourcengröße GiB Verwendete GiB GiB Nutzung% Bereinigungsfähige GiB*
---------------- -------- -------- --------- ---- --------------
/Daten: pre-comp - 12.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------

It enthält eine große Datei (/data/col1/backup/testfile):

!!! DDVE60_JF Ihre Daten in Gefahr !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 Jul 29 04:20 /data/col1/backup/testfile

Die Datei wird mehrmals schnell kopiert:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data/. col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Dies führt dazu, dass die vorkomprimierte Auslastung für geringe Änderungen an der postkomprimierten Auslastung zunimmt:

aktiver Tier:
Ressourcengröße GiB Verwendete GiB GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/Data: pre-comp - 21.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45,6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------

Als Ergebnis zeigt der DDR jetzt ein Komprimierungsverhältnis von ca. 3,1x an.

Wie oben erwähnt, zeigen die Komprimierungsstatistiken der Kopien, dass sie perfekt dedupliziert werden:

sysadmin@DDVE60_JF# filesys zeigen Komprimierung /data/col1/backup/testfile_copy1
Gesamtdateien: 1;  Byte/storage_used: 21331976.1
Ursprüngliche Byte:        3.242.460.364
Global komprimiert:                    0
Lokal komprimiert:                    0
Metadaten:                  152

Die Fastcopy-Funktion kann nicht verwendet werden, um das Komprimierungsverhältnis insgesamt zu verbessern, indem die physische Auslastung des DDR reduziert wird. Dies kann jedoch die Ursache für ein hohes allgemeines Komprimierungsverhältnis sein (insbesondere in Umgebungen, in denen fastcopy wie Avamar 6.x umfassend verwendet wird).