Das Data Domain-Betriebssystem unterstützt nach der Kapazitätserweiterung des Data Domain-Dateisystems keine proaktive Neuverteilung von Daten über Storage hinweg

Wie bei vielen Storage-Arrays kann die Kapazität der meisten Modelle von Data Domain Restorer (DDR) erhöht werden, indem externe Speichergehäuse-Einschübe (ES30, DS60) zum System hinzugefügt und dann das Data Domain File System (DDFS) auf diese Gehäuseeinschübe erweitert wird. Wenn dies durchgeführt wird:

• Neue Gehäuseeinschübe sind physisch angeschlossen (verkabelt, eingeschaltet)
• Das Data Domain Operating System (DDOS) scannt den Storage erneut, um das Vorhandensein neuer Gehäuseeinschübe zu ermitteln
• Diese neuen Gehäuseeinschübe werden dann einem Tier von Storage innerhalb des DDR hinzugefügt (dem aktiven Tier oder einer bestimmten Archiveinheit)
• Dieser Tier kann dann online erweitert werden, ohne dass ein Ausfall von DDFS erforderlich ist
• Alle neuen Daten, die auf diesen Storage-Tier geschrieben werden, werden in vorhandene und neue Einschübe geschrieben
• Daten auf vorhandenen Einschüben werden jedoch nicht über neue Gehäuseeinschübe neu ausgeglichen

Zur weiteren Erklärung:

• In DDOS ist die Daten-Storage-Einheit ein 4,5-MB-„Container“
• Bei der Erstellung werden 4,5-MB-Container im Rundlaufverfahren über alle Gehäuseeinschübe in der entsprechenden Tier-Archiveinheit hinweg geschrieben
• Wenn zusätzliche Gehäuseeinschübe zu einer Tier-Archiveinheit hinzugefügt werden, beginnt DDFS mit dem Schreiben neuer 4,5-MB-Container in diese Gehäuse zusätzlich zu den vorhandenen Gehäusen (die neuen Gehäuse werden beim Container-Schreibvorgang im Rundlaufverfahren einbezogen)
• DDOS unternimmt jedoch keinen konkreten Versuch (oder bietet spezifische Funktionen), um vorhandene Container im Tier von vorhandenen zu neuen Einschubgehäusen zu migrieren

Das bedeutet, dass das Hinzufügen von Einschubgehäusen zu einem „Ungleichgewicht“ der Daten im angeschlossenen Storage führen kann. Zum Beispiel:

• Ein DDR verfügt zunächst über ein einzelnes Gehäuse in seinem aktiven Tier, das zu 90 % belegt ist.
• Dem aktiven Tier wird ein zusätzliches Gehäuse hinzugefügt und DDFS wird auf dieses Gehäuse erweitert.
• Schreibvorgänge von neu erstellten 4,5-MB-Containern erfolgen jetzt im Rundlaufverfahren über die vorhandenen und neuen Gehäuse hinweg.
• Dadurch verfügt das vorhandene Gehäuse nicht mehr über genügend freien Speicherplatz, während das neu hinzugefügte Gehäuse nahezu leer ist.

In diesem Szenario ermöglichen viele Storage-Arrays der Administration die Neuverteilung von Daten über angeschlossene Gehäuse hinweg und die proaktive Migration einiger Daten von vorhandenen Gehäusen zu neu hinzugefügten Gehäusen, um sicherzustellen, dass die genutzte Kapazität aller Gehäuse ungefähr gleich ist. Beachten Sie jedoch, dass DDOS diese Funktionalität NICHT bietet und aufgrund des Designs von DDFS nicht erforderlich ist, da die Neuverteilung von Daten auf natürliche Weise im Laufe der Zeit erfolgt.

Die Neuverteilung von Daten erfolgt durch zwei Vorgänge:

• Automatische Speicherbereinigung
• Lokalitätsreparatur

Jeder dieser Vorgänge und wie sie eine automatische Neuverteilung von Daten verursachen, wird im Folgenden ausführlicher erläutert.

Automatische Speicherbereinigung

Die automatische Speicherbereinigung (GC) ist eine geplante Aktivität, die regelmäßig auf einem DDR ausgeführt wird (standardmäßig einmal pro Woche für den aktiven Tier und, sofern die Speicherplatzrückgewinnung aktiviert ist, bei Bedarf für Archiveinheiten). Beim Ausführen geschieht Folgendes:

• Gibt an, welche physischen Daten in der Tier-Archiveinheit „live“ sind (von einer oder mehreren Dateien im Dateisystem oder Objekten wie Snapshots verwendet) oder „dead“ sind (nicht von einem Objekt referenziert, daher für das System überflüssig).
• Bestimmung der 4,5-MB-Container, die den Großteil der Daten mit Status „dead“ innerhalb der Tier-Archiveinheit enthalten.
• Liest diese 4,5-MB-Container und extrahiert alle darin enthaltenen „Live“-Daten. Diese werden dann in neu erstellte 4,5-MB-Container „kopiert“, die über alle Einschübe in der Tier-Archiveinheit hinweg geschrieben werden.
• Löscht die alten 4,5-MB-Container, entfernt die darin enthaltenen „Dead“-Daten und gibt den zugrunde liegenden Speicherplatz auf der Festplatte für die Wiederverwendung frei.

Wenn GC auf einem System mit irgendeiner Form von Datenungleichgewicht ausgeführt wird, wird erwartet, dass die meisten alten Daten (und daher die meisten „Dead“-Daten) auf älteren Einschüben innerhalb der Tier-Archiveinheit gespeichert werden. Daher befinden sich die meisten Container, die gelesen, kopiert und gelöscht werden, auf älteren Einschubgehäusen. Die neu erstellten Container werden jedoch im Rundlaufverfahren zwischen allen Einschüben im Tier geschrieben. Infolgedessen befindet sich der meiste Speicherplatz, der durch GC freigegeben wird, in älteren Einschüben, während auf allen Einschüben Speicherplatz neu verbraucht wird.

Ein einfaches Beispiel:

• Der aktive Tier eines DDR enthält zwei Einschübe – der erste Einschub enthält 10.000 4,5-MB-Container, während der zweite Einschub 100 4,5-MB-Container enthält (für jeden Container auf dem zweiten Einschub befinden sich 100 Container im ersten Einschub).
• GC wird ausgeführt und kopiert Daten aus 5.000 Containern im ersten Einschub
• Live-Daten in diesen 5000 Containern führen dazu, dass 1000 neue 4,5-MB-Container erstellt werden.
• Diese 1.000 neuen 4,5-MB-Container werden in beide Einschübe geschrieben.
• Sobald GC abgeschlossen ist, fasst der erste Container daher 5500 4,5-MB-Container, während der zweite Container 600 Container fasst (für jeden Container auf dem zweiten Einschub befinden sich etwa neun Container auf dem ersten Einschub).
• In einem einzigen Durchlauf von GC wurde das Ungleichgewicht der Container zwischen erstem und zweitem Einschub um den Faktor 10 reduziert - dies wird sich voraussichtlich bei nachfolgenden Durchläufen von GC weiter verringern, was bedeutet, dass die Daten im Laufe der Zeit auf natürliche Weise über die Einschübe hinweg neu ausbalanciert werden.

Lokalitätsreparatur:

Wenn eine Datei auf einen DDR geschrieben wird, finden die folgenden allgemeinen Vorgänge statt:

• Die Datei wird in logische Blöcke (so genannte Segmente) mit einer Größe von 4 bis 12 KB aufgeteilt.
• Jedes Segment wird geprüft, um festzustellen, ob es bereits auf der Festplatte innerhalb des Tiers vorhanden ist, auf das die Datei geschrieben wird.
• Wenn das Segment bereits vorhanden ist, handelt es sich um doppelte Daten und das Segment in der neu geschriebenen Datei wird durch einen Zeiger auf vorhandene Daten auf der Festplatte ersetzt.
• Wenn das Segment nicht vorhanden ist, handelt es sich um eindeutige Daten, die daher in einen neuen 4,5-MB-Container gepackt und auf die Festplatte geschrieben werden.

Alle Dateien haben das Konzept der „Lokalität“, d. h., wie sequenziell die Datensegmente, auf die von dieser Datei verwiesen wird, auf der Festplatte auf dem DDR sind. Es liegt auf der Hand, dass Dateien mit hohen Deduplizierungsraten (die eine große Menge an doppelten Daten enthalten) wahrscheinlich eine schlechtere Lokalität als eine eindeutige Datei haben, da ihre Daten bei der Aufnahme durch Zeiger auf vorhandene Daten ersetzt werden, die über Container/Festplatten innerhalb der entsprechenden Tier-Archiveinheit verstreut sein können.

Für eine gute Leseperformance von Daten auf einem DDR ist eine gute Lokalität der Datei erforderlich (ihre Daten sind auf der Festplatte relativ sequenziell), damit die DDFS-Read-Ahead-Algorithmen optimal funktionieren können. Beachten Sie auch, dass DDFS davon ausgeht, dass die Datei, aus der am wahrscheinlichsten gelesen wird (für die Wiederherstellung oder Replikation), die neueste Kopie eines bestimmten Backups ist. Daher wird für bestimmte Datentypen (z. B. virtuelle synthetische Daten) ein Prozess namens „Lokalitätsreparatur“ durchgeführt, um die Lokalität neu geschriebener Dateidaten zu „optimieren“. Wenn die Lokalitätsreparatur ausgeführt wird:

• Untersuchen Sie die Daten, auf die von der Datei verwiesen wird, und suchen Sie nach Abschnitten, in denen die Daten auf der Festplatte nicht sequenziell sind (schlechte Lokalität wird angezeigt).
• Lesen Sie diese nicht sequenziellen Daten von der Festplatte und schreiben Sie sie sequenziell (als doppelte Daten) erneut in neu erstellte 4,5-MB-Container.

Es wird dann erwartet, dass die alte (nicht sequenzielle) Kopie doppelter Daten bei der nächsten Ausführung von GC als „dead“ identifiziert und aus dem System entfernt wird. Daraus folgt:

• Auf Systemen mit einem Datenungleichgewicht ist davon auszugehen, dass die meisten alten, nicht sequenziellen Daten in alten, vollständiger bestückten Gehäuseeinschüben vorhanden sind.
• Wenn diese Daten sequenziell als duplizierte Daten umgeschrieben werden, werden sie in neuen 4,5-MB-Containern abgelegt, die im Rundlaufverfahren für alle Gehäuse im entsprechenden Tier angewendet werden.
• Infolgedessen befindet sich der Großteil der „Dead“-Daten (alten doppelten Daten), die durch die Lokalitätsreparatur erstellt wurden, in alten, stärker gefüllten Einschüben.
• Wenn GC ausgeführt wird, wird der Großteil der „Dead“-Daten auf alten, vollständiger bestückten Einschüben gefunden und entfernt (wodurch Speicherplatz auf diesen Einschüben freigegeben wird), wie oben beschrieben.

Schlussfolgerung

Infolgedessen kann ein DDR durch die normale Verwendung der Lokalitätsreparatur- und der Bereinigungsfunktion (GC) Daten im Laufe der Zeit transparent über die Einschübe hinweg neu ausbalancieren. Dies geschieht ohne zusätzliche Eingaben von AdministratorInnen und bedeutet, dass keine dedizierte Datenausgleichsfunktion erforderlich ist, wie sie manchmal bei anderen Storage-Arrays zu sehen ist. Um die Geschwindigkeit zu erhöhen, mit der das Rebalancing stattfindet, ist es daher notwendig, entweder:

• die Rate zu erhöhen, mit der Daten auf dem DDR „umgewälzt“ werden.
• die Menge der Daten zu erhöhen, deren Lokalität auf dem DDR repariert wird.

Wenn Sie eine dieser Optionen weiter besprechen möchten, wenden Sie sich an den von Ihnen beauftragten Support-Anbieter und geben Sie die Details dieses Artikels an.