Data Domain: Übersicht über die Phasen des Data Domain File System (DDFS) Clean/Garbage Collection (GC)

Das Data Domain-Dateisystem (DDFS) unterscheidet sich von vielen gängigen Dateisystem Implementierungen, wenn eine Datei aus dem Dateisystem-Speicherplatz gelöscht wird, der von dieser Datei verwendet wird, nicht sofort für die Wiederverwendung verfügbar ist. Der Grund dafür ist, dass der Data Domain Restorer (DDR) nicht sofort weiß, ob Daten, auf die von der gelöschten Datei verwiesen wurde, auch von anderen Dateien dedupliziert werden und es daher sicher ist, diese Daten zu entfernen.

"Cleaning" (manchmal auch als "Garbage Collection/GC" bezeichnet) ist der Prozess, bei dem ein DDR:

• Bestimmt, welche Daten auf der Festplatte überflüssig sind (d. h., es wird nicht mehr von Objekten wie Dateien oder Snapshots referenziert)
• Entfernt die überflüssigen Daten physisch, sodass zugrunde liegender Speicherplatz für die Wiederverwendung verfügbar ist (d. h. die Aufnahme neuer Daten)

Clean/GC wird in regelmäßigen Abständen ausgeführt (Standardmäßig wird es jeden Dienstag um 6:00 Uhr gestartet) und kann Folgendes sein:

• Lang läuft
• Rechnerisch teuer

Beachten Sie jedoch, dass es keine andere Möglichkeit gibt, als durch Ausführen von Clean/GC, in dem Daten entfernt werden können/Speicherplatz auf einem Data Domain-Restorer physisch freigegeben wird (d. h. es gibt keine Verknüpfungen, um diesen Prozess zu beschleunigen).

In diesem Artikel werden Clean/GC ausführlicher erläutert:

• Die Phasen, die normalerweise bereinigt werden,
• Die verschiedenen Clean-Algorithmen, die in verschiedenen Versionen von DDoS verwendet werden

Keine

Jedes Mal, wenn Clean/GC ausgeführt wird, hat es zwei Hauptzwecke: zuerst muss es überflüssige Daten auf dem DDR finden – eine kurze Übersicht über die Vorgehensweise:

• Clean/GC listet die Inhalte des DDFS-Dateisystems auf und sucht nach Objekten wie Dateien, Snapshots und Replikationsprotokollen, die derzeit auf dem System vorhanden sind.
• Anschließend werden alle physischen Daten auf der Festplatte festgelegt, die von diesen Objekten aktiv referenziert werden.
• Daten, die aktiv referenziert werden, werden als "Live" bezeichnet und können nicht aus der DDR entfernt werden. andernfalls werden die Objekte, auf die diese Daten verweisen, beschädigt (Sie könnten nicht mehr gelesen werden, da die zugrundeliegenden Daten, auf die Sie abhingen, nicht mehr auf der Festplatte vorhanden sind).
• Daten, die von keinem Objekt aktiv referenziert werden, gelten als ' Dead ' und sind überflüssig – diese Daten können sicher aus dem System entfernt werden.
• Alle Daten auf einem DDR werden in Objekten mit einer Größe von 4,5 MB gepackt, die als Container bezeichnet werden.
• Durch die Enumeration Clean/GC kann bestimmen, welche 4,5 MB-Container Tote Daten enthalten, und die Menge der Toten Daten in jedem
• Standardmäßig wird Clean/GC 4,5 MB Container mit > 8% Toten Daten für die Verarbeitung auswählen.

Zweitens müssen Tote Daten auf dem DDR entfernt werden – eine kurze Erläuterung der Vorgehensweise:

• Für die Verarbeitung ausgewählte Container werden erneut geprüft, um zu bestätigen, dass Sie eine gute Menge toter Daten enthalten.
• Live-Daten werden aus diesen Containern extrahiert und auf neue 4,5 MB-Container am Ende des Dateisystems geschrieben.
• Sobald dies abgeschlossen ist, werden die ausgewählten Container (einschließlich der darin enthaltenen Toten Daten) von der Festplatte gelöscht, um Speicherplatz freizugeben.

Der Bereinigungsprozess wird in eine Anzahl von "Phasen" aufgeteilt, wobei die Gesamtanzahl der Phasen von folgendem abhängt:

• Die Version von DDoS, die auf dem DDR verwendet wird (daher der Clean-Algorithmus, der standardmäßig von dieser Version von DDoS verwendet wird)
• Konfiguration/Inhalte des Systems

Im Allgemeinen findet jedoch der Prozess der Suche nach ' Dead '-Daten und der Auswahl der entsprechenden Container in einer Reihe von Phasen statt, während die Entfernung von Toten Daten in einer einzigen Phase stattfindet, die als "Copy" bezeichnet wird. Zum Beispiel würden bestimmte Versionen von DDoS wie folgt Clean-Phasen ausführen:

1. Vor der Aufzählung – Aufzählen der Inhalte des DDFS-Dateisystems
2. Pre-Merge: führen Sie eine DDFS-Index Zusammenführung durch, um sicherzustellen, dass die neueste Kopie der Indexinformationen auf die Festplatte geleert wird.
3. PreFilter: bestimmen Sie, ob im DDFS-Dateisystem doppelte Daten vorhanden sind, und wenn dies der Fall ist.
4. Vor der Auswahl: bestimmen Sie, welche 4,5 MB-Container von der Reinigung verarbeitet werden sollen.
5. Copy: physisches Extrahieren von Livedaten aus ausgewählten Containern, Schreiben dieser in neue Container und Löschen ausgewählter Container
6. Summary: zusammenfassende Vektoren neu erstellen (die als Optimierung bei der Aufnahme neuer Daten verwendet werden)

Im obigen Beispiel werden die Phasen 1-4 verwendet, um zu bestimmen, wo die "Toten" Daten auf dem DDR vorhanden sind (bezeichnet als "Aufzählungs Phasen" im Rest dieses Dokuments), während Phase 5 (Kopie) verwendet wird, um diese Daten physisch zu entfernen.

Beachten Sie, dass auf dem System kein Speicherplatz freigegeben wird, bis Clean/GC die Kopierphase erreicht. Infolgedessen kann es zu einer erheblichen Verzögerung zwischen dem Starten von Clean und dem freien Speicherplatz kommen (weil der Aufzählungs Prozess erst nach Abschluss des Vorgangs ausgeführt werden muss). Aus diesem Grund sollten Systeme nicht in der Lage sein, 100% voll zu belegen, bevor Clean/GC gestartet wird.

Aufzählungs Phasen sind im Hinblick auf die CPU-Nutzung tendenziell teuer (d. h., Sie sind in der Regel CPU-gebunden). die Kopierphase ist in puncto CPU und i/o teuer (d. h., Sie sind in der Regel CPU und i/o-gebunden). Zusammenfassend kann jedoch Folgendes sagen:

• Die Gesamtlänge der Aufzählungs Phasen hängt von der Menge der Daten auf dem DDR ab, die gezählt werden müssen.
• Die Gesamtlänge der kopiephase hängt von der Menge der Toten Daten auf dem DDR, die entfernt werden muss, und der "fragmentierten" Daten auf der Festplatte (weiter unten erörtert)

Die Anzahl/Funktionalität der Aufzählungs Phasen hängt von der Version von DDoS ab, die auf einem DDR verwendet wird.

DDoS 5,4 (und früher) – vollständiger Clean-Algorithmus: Führt 6 oder 10 Phasen aus (siehe Abbildung oben):

• Der Inhalt des DDFS-Dateisystems wird Top-Down-Liste (d. h. Datei zentriert) aufgelistet.
• DDFS erkennt alle Dateien, die auf dem DDR vorhanden sind, scannt dann jede Datei nacheinander, um zu bestimmen, welche Daten von dieser Datei referenziert werden.
• Dies ermöglicht es Clean/GC, zu bestimmen, welche Daten auf der Festplatte "Live" sind.

DDoS 5,5 (und höher) – Physical Clean Algorithm (PGC): Läuft 7 oder 12 Phasen:

• Der Inhalt der DDFS wird Bottom up (d. h., es werden keine einzelnen Dateien mehr gescannt) aufgelistet.
• DDFS erkennt Dateisystem-Metadaten, die auf physische Daten auf der Festplatte verweisen, und überprüft diese Metadaten, um zu bestimmen, welche Daten referenziert werden.
• Dies ermöglicht es Clean/GC, zu bestimmen, welche Daten auf der Festplatte "Live" sind.
• Dies wird durch das Hinzufügen einer "Analyse"-Phase erreicht (daher die Zunahme der Phasenanzahl über den vollständigen Clean-Algorithmus).
• In den meisten Fällen wird die Gesamtdauer der physischen Reinigung jedoch voraussichtlich kürzer sein als die vollständige Bereinigung für das gleiche System (trotz der bestehend aus mehreren einzelnen Phasen)

DDoS 6,0 (und höher) – Perfect Physical Clean Algorithm (PPGC):

• Dies ist lediglich eine Optimierung des physischen Clean-Algorithmus und wird weiter unten beschrieben.

Beachten Sie, dass DDoS von dem vollständigen Clean-Algorithmus auf den physischen Clean-Algorithmus umgeschaltet wurde, um die Skalierbarkeit/Leistung des Aufzählungs Prozesses zu verbessern. aufgrund der Top-Down-Beschaffenheit des vollständigen Clean-Algorithmus konnte es auf DDRs mit den folgenden Optionen nicht skaliert werden:

• Eine große Anzahl kleiner Dateien (als Kontextschalter bei der Umstellung von der Aufzählung einer Datei zur nächsten war teuer/langsam)
• Hohes Deduplizierungs-Verhältnis (wenn mehrere Dateien dieselben physischen Daten referenzierten, sodass die gleichen Daten mehrfach aufgelistet wurden)

DDRs wechselt beim Upgrade von DDoS 5,4 (oder früher) auf 5,5 (oder höher) automatisch von vollständigen zu physischen Clean-Algorithmen. Die einzige Ausnahme hiervon sind Systeme, die mit Extended Retention konfiguriert sind, wobei der Inhalt des DDFS-Dateisystems auf "Spanning-Dateien" geprüft werden muss, bevor die physische Bereinigung aktiviert werden kann. eine Diskussion über diesen Prozess geht über den Rahmen dieses Dokuments hinaus.

Diese Überprüfung wird jedoch automatisch nach dem Upgrade durchgeführt und die Physical Clean wird nach Abschluss dieser Prüfung ohne manuelle Maßnahme aktiviert Bei einem Upgrade von DDoS 5. x auf 6,0 (oder höher) wechseln DDRs von Physical zu Perfect Physical Clean Algorithms automatisch. Beachten Sie jedoch, dass für den perfekten Physical Clean-Algorithmus Indizes im Format "Index 2,0" vorliegen müssen, bevor Sie verwendet werden können. Hinweis:

• Das Format "Index 2,0" wurde mit DDoS 5,5 eingeführt (sodass alle Dateisysteme, die auf 5,5 oder höher erstellt werden, bereits Index 2,0 verwenden)
• Das Dateisystem, das auf 5,4 oder früher erstellt wurde, hat anfänglich Indizes im Index 1,0-Format. Nach dem Upgrade auf DDoS 5,5 (oder höher) werden die Indizes in den Index 2,0 Format konvertiert-die Konvertierung erfolgt jedes Mal, wenn Clean ausgeführt wird. allerdings werden nur 1% der Indizes während jeder Bereinigung konvertiert, sodass es bis zu 2 Jahre dauern kann (vorausgesetzt, dass Clean Weekly ausgeführt wird), um Indizes vollständig in das 2,0-Format zu konvertieren.

DDRs, die zunächst DDoS 5,4 (oder früher) ausführen, aber anschließend auf DDoS 5,5 (oder höher) aktualisiert wurden, können gezwungen werden, Indizes durch eine einmalige ' Index Wiederherstellung ' in das Index 2,0-Format zu konvertieren. Beachten Sie jedoch, dass eine Index-Neuerstellung eine Zeitspanne der Ausfallzeit erfordert, während Indizes physisch neu erstellt werden – dieser Vorgang dauert in der Regel 2-8 Stunden, abhängig von der Größe/Menge der Daten auf dem DDR. Wenden Sie sich an ihren vertraglich festgelegten Supportanbieter, um eine Index Wiederherstellung zu besprechen.

Wie bereits erwähnt, kann für Clean (ungeachtet des verwendeten Clean/GC-Algorithmus) eine Variable Anzahl von Phasen benötigt werden, z. b. der vollständige Clean-Algorithmus kann 6 oder 10 Phasen beanspruchen. Der Grund dafür ist, dass:

• Wenn DDFS gestartet wird, reserviert es eine festgelegte Menge an Arbeitsspeicher, die von Clean/GC verwendet werden soll.
• In diesem Speicher Clean/GC erstellt Datenstrukturen, um die Ergebnisse der Aufzählung zu beschreiben (d. h., wo Live vs Dead Data auf dem Laufwerk vorhanden ist).
• Wenn ein DDR eine relativ geringe Datenmenge enthält, kann der gesamte Inhalt des DDFS-Dateisystems in diesem Speicherbereich beschrieben werden.
• Auf vielen Systemen ist dies jedoch nicht möglich und dieser Bereich des Speichers würde erschöpft werden, bevor der gesamte Inhalt des DDFS-Dateisystems gezählt wurde.
• Dies führt dazu, dass diese Systeme "Sampling" durchführen, was die Anzahl der erforderlichen sauberen Phasen erhöht.

Wenn die Sampling-Funktion Clean/GC verwendet wird:

• Durchführen einer Sampling-Übergabe der Aufzählung im gesamten Dateisystem – beachten Sie, dass diese Aufzählung nicht ' Complete ' ist (d. h. es werden nicht alle Informationen zu jedem Teil des Dateisystems aufgezeichnet, sondern stattdessen Informationen für jeden Teil des Dateisystems angenähert)
• Verwenden Sie diese Sampling-Informationen, um zu bestimmen, welcher Teil des DDFS-Dateisystems am meisten davon profitieren würde, wenn Clean/GC ausgeführt wird (d. h. welcher Teil des Dateisystems würde die besten Erträge in Bezug auf den freien Speicherplatz liefern, wenn er bereinigt wurde)
• Führen Sie eine zweite Rundung der vollständigen Aufzählung für den ausgewählten Teil des Dateisystems durch, dessen Inhalte jetzt vollständig im Speicher beschrieben werden können, der für GC reserviert ist.

Die Sampling-Funktion wird bei Bedarf automatisch während des Clean/GC aktiviert, was jedoch Folgendes zur Folge hat:

• Eine Erhöhung der Anzahl der Phasen, die von Clean/GC durchgeführt werden müssen
• Eine entsprechende Zunahme der Gesamtdauer von Clean/GC

Vor DDoS 6,0 führen die meisten DDRs Sampling während des Clean/GC durch (es sei denn, Sie verfügen über einen relativ kleinen Datensatz). Der perfekte Physical Clean-Algorithmus umfasst jedoch verschiedene Optimierungen, um die Menge des Arbeitsspeichers zu reduzieren, die für Clean/GC beim Aufzählen von Daten im Dateisystem erforderlich ist. Das bedeutet, dass viele Systeme, die eine Sampling während des Clean/GC auf DDoS 5. x durchführen, keine Sampling auf DDoS 6,0 mehr benötigen. Dadurch wird die Anzahl der Phasen verringert, die von Clean durchgeführt werden. Dies führt zu einer entsprechenden Senkung der Gesamtbetriebszeit (d. h. einer Verbesserung der sauberen Performance).

Es stehen keine Informationen zur Verfügung, um direkt festzustellen, ob ein System vom physischen Clean-Algorithmus auf den perfekten physikalischen Clean-Algorithmus umgeschaltet wurde, außer:

• Wenn das System auf dem DDoS 5,5-5,7 eine physische Bereinigung durchgeführt hat, hat es während der Reinigung 12 Phasen ausgeführt.
• Nach dem Upgrade des Systems auf DDoS 6,0 (oder höher) werden während der Reinigung nur 7 Phasen durchgeführt.

Wenn ein System, auf dem DDoS 6,0 ausgeführt wird, noch eine Sampling durchführen muss, wird dieses automatisch während des Clean-Vorgangs aktiviert und wird während der Bereinigung auf 12 Phasen umgeschaltet.

Unabhängig vom bereinigten Algorithmus funktioniert die kopiephase (wobei Tote Daten physisch aus dem System entfernt werden) in ähnlicher Weise in allen Versionen. Die Performance der Copy-Phase hängt in der Regel von:

• Die Menge der "Toten" Daten, die entfernt werden müssen
• Die "Fragmentierung" dieser Toten Daten (z. b. die Verbreitung über die Festplatte)

Wie oben beschrieben, funktioniert die Kopie, indem 4,5 MB Container ausgewählt werden, die Tote Daten enthalten, alle Livedaten aus diesen Containern extrahiert und die Livedaten in neue Container geschrieben werden. Anschließend werden die ursprünglich ausgewählten Container gelöscht. In den folgenden Beispielen wird beschrieben, warum die Fragmentierung toter Daten wichtig ist:

Beispiel 1:

• 10 Container sind für die Kopie ausgewählt (45 MB Gesamtdaten)
• Alle, wenn diese Container keine Live-Daten enthalten (d. h., dass die Daten, die Sie speichern, vollständig nicht referenziert/inaktiv sind)
• Als Ergebnis Kopie müssen diese Container einfach als gelöscht gekennzeichnet werden, um 45 MB physischen Speicherplatz auf der Festplatte freizugeben.

Beispiel 2:

• 100-Container sind für die Kopie ausgewählt (450mb gelangte Gesamtdaten)
• Jeder dieser Container enthält 90% Live-Daten/10% Tote Daten
• Um diese Container zu verarbeiten, muss die Kopie:

Es ist klar, dass eine deutlich höhere Menge an I/O und CPU für die Durchführung der in Beispiel 2 beschriebenen Kopie erforderlich ist, verglichen mit dem in Beispiel 1. Daher wird es deutlich länger dauern, 45 MB physischen Speicherplatz in der Festplatte in diesem Beispiel freizugeben.

Benutzer haben in der Regel keine Kontrolle über die "Fragmentierung" toter Daten auf einer Festplatte auf einem DDR. Dies hängt sehr stark vom Anwendungsfall/Typ der Daten ab, die auf das System geschrieben werden. Beachten Sie jedoch, dass Clean/GC Statistiken aufrecht erhält, die bei der Bestimmung der "Fragmentierung" toter Daten, die während der Kopierphase aufgetreten sind, hilfreich sind (was es einem Benutzer ermöglicht, zu bestimmen, ob diese Fragmentierung eine potenziell lange andauernde Kopie-Phase erklären kann). Solche Statistiken aus der aktuellen Phase des Clean/GC werden in Auto Supports erfasst. Die folgende Abbildung zeigt z. b. eine kopiephase, in der die Toten Daten ziemlich zusammenhängend waren (d. h. die Mehrheit der für die Kopie ausgewählten Container, die größtenteils Tote Daten waren):

Prozentsatz der Live Daten in kopiert:              3,6% 4,3%

Im folgenden wird eine kopiephase gezeigt, in der die Toten Daten fragmentiert sind (d. h., die Mehrheit der für die Kopie ausgewählten Container enthält größtenteils Livedaten):

Prozentsatz der Live Daten in kopiert:             70,9% 71,5%

Wie oben beschrieben, muss Clean/GC im zweiten Szenario vergleichsweise viel mehr Arbeit leisten, um auf dem DDR physisch freien Speicherplatz zu schaffen, wodurch der Durchsatz der Kopierphase reduziert wird.

Der Kopier Phasen Durchsatz kann auch durch folgende Auswirkungen beeinflusst werden:

• Die Verwendung von Encryption: Daten müssen möglicherweise während der Kopie entschlüsselt/wieder verschlüsselt werden, was die Menge der erforderlichen CPU deutlich erhöht.
• Nutzung der Optimierung bei niedriger Bandbreite: Container benötigen möglicherweise ' Sketch '-Informationen, die während der Kopie erzeugt werden müssen, was auch zu einer erheblichen Erhöhung der erforderlichen CPU-Größe führt.

Hinweis: Wenn die Optimierung und/oder Verschlüsselung für eine geringe Bandbreite vor kurzem aktiviert wurde, müssen alle vorhandenen Container (unabhängig davon, ob Sie für die Kopie ausgewählt sind oder nicht) möglicherweise verschlüsselt werden und/oder Sie müssen während der nachfolgenden Bereinigung Skizzier Informationen erstellen.

Weitere Hinweise zur Überprüfung/Änderung von Clean Schedule and Throttle finden Sie im folgenden KB-Artikel: https://support.EMC.com/kb/306100

beachten Sie jedoch Folgendes:

• Unter normalen Umständen sollte Clean so geplant werden, dass Sie höchstens einmal pro Woche ausgeführt wird – wenn die Reinigung öfter durchgeführt wird, kann dies dazu führen, dass Daten auf der Festplatte zu stark fragmentiert werden (d. h
• Clean Throttle hat keinen Einfluss auf die Gesamtmenge der CPU-und I/O-Bandbreite, die von Clean verbraucht wird. stattdessen wird gesteuert, wie sensibel Clean auf andere Workloads im System reagiert. Zum Beispiel:

• Standardmäßig ist Clean Throttle auf 50 festgelegt-es liegt in der Verantwortung des Benutzers, die Cleaning-Funktion mit unterschiedlichen Drosselungseinstellungen zu testen, während der DDR normale Arbeitslasten erfährt, um eine drosselungseinstellung zu bestimmen, die Folgendes erlaubt:

• Beachten Sie, dass ein Cleaning mit langer Laufzeit nicht unbedingt ein Problem ist, solange:

• Das System, das die Extended Retention-Funktion verwendet, muss so konfiguriert werden, dass:

• Vollständige Informationen zum neuesten Bereinigungsvorgang finden Sie unter Auto Supports und Details: