Data Domain: Einführung in die langfristige Aufbewahrung/Cloud-Tier-Bereinigung/automatische Speicherbereinigung auf Data Domain Restorers (DDRs)

Summary: Dieser Artikel dient als Einführung in die Bereinigung/automatische Speicherbereinigung von Cloud-Tiers, die auf Data Domain Restorers (DDRs) mit Cloud-/langfristiger Aufbewahrung (LTR) konfiguriert sind. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

Das Data Domain Operating System (DDOS) 6.0 führt eine neue Funktion ein, die als Cloud-Aufbewahrung oder langfristige Aufbewahrung (Long-Term Retention, LTR) bezeichnet wird. Mit dieser Funktion kann bestimmten Modellen des Data Domain Restorer (DDR) mit einer zugehörigen CLOUD_CAPACITY-Lizenz ein zweiter von einem Cloud-Anbieter bereitgestellter objektbasierter Storage-Tier hinzugefügt werden.

Auf Systemen, die LTR verwenden, werden Dateien, die vom DDR aufgenommen werden, zunächst in den aktiven Tier (lokal angeschlossener Storage) geschrieben. Dann werden Datenverschiebungs-Policies/Altersschwellenwerte pro MTree konfiguriert, damit bestimmte Dateien, die eine langfristige Aufbewahrung erfordern, später durch den Datenverschiebungsprozess (eine regelmäßig geplante Aufgabe) vom aktiven in den Cloud-Tier migriert werden.

Dateien im Cloud-Tier können wie gewohnt gelöscht werden, der zugehörige Speicherplatz im Cloud/Objekt-Storage wird jedoch nicht sofort zur Verwendung freigegeben. Um überflüssige Daten aus der Cloud zu entfernen, muss der Cloud-Tier bereinigt werden.

Struktur des Cloud-Tier:

Der Cloud-Tier ist in „Cloud-Einheiten“ unterteilt. Hinweis:
  • Der Cloud-Tier kann bis zu zwei Cloud-Einheiten enthalten.
  • Jede Cloud-Einheit kann so groß sein wie die maximal unterstützte Größe des aktiven Tier für das jeweilige DDR-Modell.
  • Jede Cloud-Einheit kann von einem anderen Objekt-Storage-Anbieter bereitgestellt werden.
Beispiel:

# cloud unit list
Name                      Profile        Status
-----------------------   ------------   ------
B-unit                    LTR-ECS-Ben    Active <=== ECS provider
cloud-unit-virtustream1   virtustream1   Active <=== Virtustream provider
-----------------------   ------------   ------


Grundlegende Konzepte der Cloud-Bereinigung:
  • Die Cloud-Bereinigung wird bei jeder Ausführung nur für eine einzige Cloud-Einheit durchgeführt. Um zu ermitteln, welche Cloud-Einheit bereinigt wird, finden Sie in den DDFS-Protokollen (/ddr/var/log/debug/ddfs.info) die folgende Meldung – in diesem Fall wird die Cloud-Einheit cloud-unit-virtustream1 bereinigt:
08/12 13:25:07.551 (tid 0x7f22991eb880): gc: Physical Cleaning will run on partition: cloud-unit-virtustream1, select_flags:  none, usr: SCHEDULED CLOUD-GC, asm: Ja

Leider sind diese Informationen für laufende Bereinigungen von Cloud-Einheiten derzeit nicht über die Data Domain-Befehlszeilen-Shell (DDSH) verfügbar.
  • Wenn auf einem System mehrere Cloud-Einheiten konfiguriert sind, führt die Cloud-Bereinigung die Bereinigung dieser Einheiten im Rundlaufverfahren durch, wobei bei jeder Ausführung der Cloud-Bereinigung versucht wird, eine einzelne Einheit zu bereinigen.
  • Die Cloud-Bereinigung kann manuell oder automatisch über einen Zeitplan gestartet werden. Zum manuellen Starten wird der folgende Befehl verwendet:
# cloud clean start [Name der Cloud-Einheit]
  • Die Bereinigung des aktiven Tier und die Cloud-Bereinigung können nicht parallel ausgeführt werden (da beide dieselben Speicherstrukturen in DDFS verwenden).
  • Wenn die Bereinigung des aktiven Tier ausgeführt (entweder manuell oder über den Zeitplan gestartet) und versucht wird, die Cloud-Bereinigung zu starten, tritt ein Fehler auf:
# cloud clean start cloudunit2
Failed to start: activer tier cleaning is currently running. Use 'filesys clean watch' to monitor its progress.
  • Wenn die Cloud-Bereinigung automatisch gestartet wurde (d. h. über den Zeitplan) und die Bereinigung des aktiven Tier gestartet wird, wird die Bereinigung der Cloud-Einheit abgebrochen, damit die Bereinigung des aktiven Tier ausgeführt werden kann. Dies wird in den DDFS-Protokollen durch Folgendes angezeigt:
08/12 13:25:24.532 (tid 0x7f2277e9d210): gc_asm_start: Abort scheduled cloud-GC
  • Wenn die Cloud-Bereinigung manuell gestartet wurde und versucht wird, die Bereinigung des aktiven Tier zu starten, kann die Bereinigung des aktiven Tier nicht gestartet werden und die Cloud-Bereinigung wird bis zum Abschluss ausgeführt:
# filesys clean start
**** Cleaning cannot start since Cloud tier cleaning is in progress. Use 'cloud clean watch' to monitor progress.
  • Bei einer Cloud-Einheit muss eine Datenveränderung von mindestens 1 % aufgetreten sein (d. h. >= 1 % der derzeit in der Cloud-Einheit befindlichen Daten müssen als überflüssig und daher entfernbar angesehen werden), damit die Cloud-Bereinigung gestartet werden kann. Ist dies nicht der Fall, wird Folgendes in der Befehlszeile angezeigt, wenn die Cloud-Bereinigung manuell gestartet wird:
# cloud clean start cloudunit2
**** Failed to start: cloud unit "cloudunit2" does not have sufficient cleanable data.

Darüber hinaus wird in den DDFS-Protokollen Folgendes angezeigt, wenn die Cloud-Bereinigung manuell oder über den Zeitplan gestartet wird:
 
07/26 15:38:58.496 (tid 0x7f7a450fd340): gc: cp: cloudunit2 has 0% churn, minimum churn needed to run gc: 1%
07/26 15:38:58.496 (tid 0x7f7a450fd340): gc: cp: cloudunit2 does not have sufficient churn for GC to run
  • Wenn ein System zwei Cloud-Einheiten enthält und die geplante Bereinigung der ersten Einheit aus irgendeinem Grund fehlschlägt (z. B. unzureichende Datenänderung), wird automatisch versucht, die Bereinigung der zweiten Einheit zu starten (d. h. es ist nicht erforderlich, auf die nächste geplante Ausführung der Cloud-Bereinigung zu warten, damit die zweite Einheit bereinigt wird).
  • Die Cloud-Bereinigung kann gedrosselt werden (ähnlich wie die Bereinigung des aktiven Tier), um zu entscheiden, welche Aktion durchgeführt werden soll, wenn das System einer erheblichen anderen Workload (z. B. Aufnahme/Wiederherstellung/Replikation) ausgesetzt ist.
Wie bei der Bereinigung des aktiven Tier wird die Drosselung als Prozentsatz zwischen 0 und 100 angegeben:

0 %: Die Cloud-Bereinigung gibt schnell Ressourcen für die andere Workload frei, was zu einer langsameren Ausführung der Bereinigung führen kann, aber nur minimale Auswirkungen auf die Gesamtsystemperformance hat.
100 %: Die Cloud-Bereinigung gibt keine Ressourcen für die andere Workload frei und wird daher so schnell wie möglich ausgeführt, was jedoch erhebliche Auswirkungen auf die Gesamtsystemperformance haben kann.

Die Drosselung der Cloud-Bereinigung ist auf einen Standardwert von 50 % festgelegt.

# cloud clean throttle show
Cloud tier cleaning throttle is set to 50 percent


Um die Drosselung zu ändern, kann der folgende Befehl verwendet werden – Beachten Sie, dass der neue Drosselungswert sofort wirksam wird und DDFS oder die Cloud-Bereinigung nach Änderung der Drosselung nicht neu gestartet werden muss:

# cloud clean throttle set 75
Cloud tier cleaning throttle set to 75 percent

Planen der Cloud-Bereinigung:

In DDOS 6.0 und höher hat sich die Art und Weise, wie die Bereinigung des aktiven Tier geplant wird, nicht geändert. Die Bereinigung des aktiven Tier wird standardmäßig einmal pro Woche um 06.00 Uhr am Dienstag ausgeführt:

# filesys clean show schedule
Filesystem cleaning is scheduled to run "Tue" at "0600".


Die Cloud-Bereinigung ist standardmäßig so geplant, dass sie nach jedem 4. Aufruf der geplanten Bereinigung des aktiven Tier ausgeführt wird. Um den Zeitplan für die Cloud-Bereinigung anzuzeigen, sollte der folgende Befehl verwendet werden:

# cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.


Infolgedessen wird auf einem System mit Standardkonfiguration die Cloud-Bereinigung alle 4 Wochen gestartet. Wenn das System über zwei Cloud-Einheiten verfügt, wird jede Einheit einmal alle 8 Wochen bereinigt.

Um die Häufigkeit der Cloud-Bereinigung zu ändern, kann der folgende Befehl verwendet werden:

# cloud clean frequency set 2
Cloud tier cleaning frequency is set to run after every 2 active tier cleaning cycles.


Um die Cloud-Bereinigung auf den Standardzeitplan nach jeweils 4 Bereinigungen des aktiven Tier zurückzusetzen, kann der folgende Befehl verwendet werden:

# cloud clean frequency reset
Cloud tier cleaning frequency is reset to default (every 4 active tier cleaning cycles).


Beachten Sie, dass der Zeitplan für die Cloud-Bereinigung keine manuell gestarteten Bereinigungszyklen des aktiven Tier berücksichtigt. Daher würde die Cloud-Tier-Bereinigung auf dem oben genannten System nur einmal alle 4 Wochen gestartet werden, selbst wenn die Bereinigung des aktiven Tier jeden Tag manuell ausgeführt würde.

Es ist auch möglich, die geplante Cloud-Bereinigung mit dem folgenden Befehl vollständig zu deaktivieren:

# cloud clean frequency set never
Cloud tier cleaning frequency is set to "never".


In diesem Fall wird die Cloud-Bereinigung nur ausgeführt, wenn sie manuell gestartet wird.

Um eine derzeit ausgeführte Cloud-Bereinigung zu beenden, kann der folgende Befehl verwendet werden:

# cloud clean stop

Um zu ermitteln, wann die Cloud-Bereinigung zuletzt ausgeführt wurde, kann der folgende Befehl verwendet werden:

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.


Algorithmus für die Cloud-Bereinigung:

Bei der Cloud-Bereinigung wird derselbe Bereinigungsalgorithmus verwendet, der auch für den aktiven Tier konfiguriert ist. In DDOS 6.0 (und höher) ist dies standardmäßig auf PPGC (Perfect Physical Garbage Collection) festgelegt. Dies kann jedoch über die Systemparameter auf PGC (Physical Garbage Collection) geändert werden.

Beachten Sie, dass PGC nicht deaktiviert werden sollte, da die Verwendung des herkömmlichen/vollständigen Bereinigungsalgorithmus zur Bereinigung einer Cloud-Einheit zu einem DDFS-Fehler/Neustart führen kann.

Der für die Cloud-Bereinigung verwendete Algorithmus wird in den DDFS-Protokollen angezeigt, wenn die Bereinigung gestartet wird:

06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern:: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Traditional GC


Beachten Sie, dass es in der obigen Ausgabe nicht möglich ist, zwischen PPGC oder PGC zu unterscheiden. Der verwendete spezifische Algorithmus ist aus der Anzahl der Phasen ersichtlich, die von der Bereinigung ausgeführt werden. Im Allgemeinen gilt:

Herkömmliche/vollständige Speicherbereinigung: 10 Phasen
PGC: 12 Phasen
PPGC: 6 Phasen

Weitere Informationen zum Ändern des Bereinigungsalgorithmus, der auf einem System verwendet wird, erhalten Sie von Ihrem vertraglich gebundenen Supportanbieter.

Unterschiede bei den Kopierphasen während der Bereinigung des aktiven Tier und der Bereinigung des Cloud-Tier:

Die Kopierphase der Bereinigung ist die Phase, in der überflüssige Daten auf einem DDR physisch entfernt werden/Speicherplatz zurückgewonnen wird. Beachten Sie, dass es Unterschiede bei der Funktionsweise der Kopierphase während der Bereinigung des aktiven Tier und der Bereinigung des Cloud-Tier gibt:

Aktiver Tier:
  • Daten, die auf den aktiven Tier eines DDR geschrieben werden, befinden sich in 4,5-MB-Containern.
  • Standardmäßig wird ein Container von der Bereinigung nur dann für das „Kopieren“ berücksichtigt, wenn er <= 92 % „Live“-Daten (d.h. aktiv verwendete Daten) enthält.
  • Die Live-Daten werden aus dem Container extrahiert und in einen neuen Container (zusammen mit Live-Daten aus anderen kopierten Containern) am Ende des Dateisystems geschrieben.
  • Die Indizes auf den Festplatten werden aktualisiert, um den neuen Container, der die Live-Daten enthält, widerzuspiegeln.
  • Der ursprüngliche Container (der sowohl aktive als auch tote Daten enthält) wird dann gelöscht und der zugrundeliegende Speicherplatz zur Verwendung verfügbar gemacht.

Cloud-Tier:
  • Daten, die in den Cloud-Tier eines DDR geschrieben werden, sind anders strukturiert: Anstatt in 4,5-MB-Containern platziert zu werden, werden einzelne Datenblöcke (64-kB-Komprimierungsregionen) in die Cloud-Einheit geschrieben (HINWEIS: Ab DDOS 6.1.2.0 und höher sind Objekte, die in der Cloud-Einheit gespeichert sind, größer, siehe Data Domain: Große Objektgröße für Cloud-Tier für weitere Informationen).
  • Anstatt Live-Daten aus einer vorhandenen Komprimierungsregion zu extrahieren und weiterzukopieren, berücksichtigt die Cloud-Bereinigung zum Löschen nur Komprimierungsregionen, die ausschließlich tote Daten enthalten.
Wenn also eine Komprimierungsregion eine einzelne sehr kleine Datenmenge enthält, die noch live ist (von einer Datei genutzt wird), wird sie nicht gelöscht und die toten Daten innerhalb der Komprimierungsregion werden nicht von der Festplatte entfernt (d. h. es wird kein von der Komprimierungsregion verwendeter Speicherplatz zurückgewonnen).

Komprimierungsregionen, die zum Löschen markiert sind, werden von der Cloud-Bereinigung asynchron verarbeitet. Infolgedessen kann der freie Speicherplatz in einer Cloud-Einheit auch nach Abschluss der Cloud-Bereinigung weiter zunehmen.

Dieser Unterschied ist auf die inhärenten Kosten zurückzuführen, die mit dem Lesen/Schreiben großer Datenmengen in Cloud-Storage verbunden sind, bedeutet jedoch auch, dass eine Cloud-Einheit künstlich voll werden kann (da sie eine große Anzahl an Komprimierungsregionen enthält, von denen jede eine sehr kleine Menge an Live-Daten enthält, die ihre Löschung verhindern).

Wenn diese Situation eintritt, können Systemparameter festgelegt werden, um eine „Defragmentierungsbereinigung“ der Cloud-Einheit zu erzwingen. Dadurch werden Live-Daten aus vorhandenen Komprimierungsregionen weiterkopiert, um die Live-Daten in so wenigen Komprimierungsregionen wie möglich zu konsolidieren, damit Speicherplatz freigegeben werden kann.

Weitere Informationen zum Ausführen einer „Defragmentierungsbereinigung“ erhalten Sie von Ihrem vertraglich gebundenen Supportanbieter.

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000019165
Article Type: How To
Last Modified: 25 Jul 2025
Version:  3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.