Data Domain Restorer und Long-Term Retention (langfristige Aufbewahrung) in der Cloud: Häufig gestellte Fragen (FAQs)

Dieser Artikel befasst sich mit den am häufigsten gestellten Fragen zur Konfiguration und Verwendung von Data Domain Restorers (DDRs) und Long-Term Retention (LTR) oder zur Cloud-Funktion.
 

Was ist LTR?

• Ab Data Domain Operating System (DDOS) 6.0 wurde eine neue Funktion namens LTR eingeführt.
• Mit der LTR können bestimmte DDR-Modelle eine Teilmenge von Dateien oder Daten von einer Reihe unterstützter Public- oder Private-Cloud-Anbieter zu einem Objekt- oder Cloud-Storage, einem sogenannten Cloud-Tier, migrieren.
• Um Dateien oder Daten physisch in den Objektspeicher zu migrieren, wird ein Datenverschiebungsprozess auf dem DDR ausgeführt.
• Um redundante Daten physisch aus dem Cloud-Tier zu entfernen, wird ein Cloud-Tier-Bereinigungsprozess auf dem DDR ausgeführt.
• LTR ist eine lizenzierte Funktion und erfordert eine CLOUDTIER_CAPACITY license.
• Für die langfristige Aufbewahrung ist ein Teil des lokalen Storage für Cloud-Tier-Metadaten erforderlich.

Für welche DDR-Systeme ist LTR verfügbar?
Dies hängt von der installierten DDOS-Version und dem Systemmodelltyp ab. Die meisten Modelle haben bestimmte Hardwareanforderungen, die im Voraus erfüllt werden müssen, damit LTR konfiguriert werden kann. Weitere Informationen zu den Anforderungen finden Sie im Hardwareinstallationshandbuch für die spezifischen Modelle sowie im DDOS-Administrationshandbuch.

Welche Lizenz ist für LTR erforderlich?

• Da LTR als neue Funktion von DDOS 6.x und höher betrachtet wird, ist eine elektronische Lizenz erforderlich. 
• Der erforderliche Typ der E-Lizenz heißt CLOUDTIER_CAPACITY license. Ein Beispiel für eine CLOUDTIER_CAPACITY license lautet wie folgt:

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Wie funktionieren die verschiedenen Tiers?

• Normale DDRs (ohne LTR-Lizenz) verfügen über einen einzigen Tier, der als aktiver Tier bezeichnet wird.
• Der aktive Tier ist der herkömmliche Speicher-Tier auf allen standardmäßigen DDRs.
• LTR-Systeme verfügen über einen zweiten Speicher-Tier, der als Cloud-Tier bezeichnet wird.

Die maximale Größe der einzelnen Tiers wird durch die unterstützten Grenzwerte für die jeweilige Hardwarekonfiguration und DDOS-Version bestimmt. Weitere Informationen finden Sie im DDOS-Administrationshandbuch und im Hardwarehandbuch für das jeweilige Modell.

Ein Beispiel für eine LTR-Konfiguration mit zwei Tiers, einer aktiven und einer Cloud-basierten LTR-Konfiguration ist unten dargestellt:   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

Wie ist ein Cloud-Tier aufgebaut?

• Ein Cloud-Tier besteht aus:   
  • Lokal aufbewahrten Metadaten, die bei Verwendung eines physischen DDR auf einem Gehäuse oder einer LUN oder einem Gerät gespeichert sind, wenn DDVE verwendet wird.
  • Objektspeicheranbieter
• Beide oben genannten Elemente werden in einer Cloudeinheit kombiniert.
• Wenn mehrere Cloudeinheiten konfiguriert sind, können sie die lokal gespeicherten Metadaten gemeinsam nutzen.
• Pro System können maximal zwei Cloudeinheiten konfiguriert werden. Jede Cloudeinheit kann von einem anderen Objektspeicheranbieter bereitgestellt werden.
• Jede Cloudeinheit kann so groß sein wie die maximal unterstützte Größe des aktiven Tier für das jeweilige DDR-Modell. Weitere Informationen finden Sie im DDOS-Administrationshandbuch.

Was geschieht während eines typischen Backup-Lebenszyklus, wenn LTR konfiguriert ist?

• Alle Daten werden zunächst in den aktiven Tier geschrieben, wo sie altern.
• Kurzlebige Daten, die ihre Aufbewahrungsfrist erreichen, werden wie auf einem normalen DDR gelöscht bzw. laufen ab.
• Eine Teilmenge der Daten, die eine langfristige Aufbewahrung erfordern, wird jedoch zum Cloud-Tier migriert.
• Das Dateisystem verwaltet einen einzigen Namespace über alle Tiers hinweg. Wenn also eine Datei in die Cloud migriert wird, ändert sich der Namespace nicht und ist daher für NutzerInnen oder die Backupanwendung einigermaßen transparent.
• Wenn eine Datei, die bereits in den Cloud-Tier migriert wurde, ihre Aufbewahrungsfrist erreicht, läuft sie wie jede andere Datei ab bzw. wird gelöscht.
• Der Speicherplatz, den eine Datei im Cloud-Tier verwendet hat, wird nicht sofort zurückgewonnen, stattdessen muss eine Cloud-Tier-Bereinigung ausgeführt werden.

Wie werden Daten zwischen Tiers dedupliziert?

• Jede Cloudeinheit ist ein eigenständiges Volume, sprich: eine eigenständige Deduplizierungseinheit.
• Daher können Daten, die in die jeweilige Cloudeinheit geschrieben werden, nur anhand von Daten in derselben Cloudeinheit dedupliziert werden.

Was ist die Platzierungszeit (auch als ptime bezeichnet)?

• Dateien und Verzeichnissen sind verschiedene Zeitstempel zugeordnet.
• Beispielsweise hat eine Datei oder ein Verzeichnis eine Erstellungszeit, eine Zeit des letzten Zugriffs und eine Änderungszeit.
• DDOS hat dies erweitert, um auch eine Platzierungszeit einzubeziehen. Die Platzierungszeit entspricht dem Datum und der Uhrzeit, zu der die Datei vom aktiven Tier zum Cloud-Tier migriert wurde.
• Je nach DDOS-Version ist die Platzierungszeit ersichtlich, wenn untersucht wird, auf welchem Tier sich eine Datei befindet. Wenn die Datei in den Cloud-Tier migriert wurde, wird die Platzierungszeit angezeigt, z. B.:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• ptime ist das letzte Feld in der obigen Ausgabe, obwohl keine Feldüberschrift angezeigt wird.

Wie werden Daten vom aktiven Tier in den Cloud-Tier verschoben?

• Ein Prozess namens Datenverschiebung ist für die Prüfung von Dateien in einem MTree verantwortlich, die sich im aktiven Tier befinden.
• Die Datenverschiebung beginnt mit der Erstellung eines Snapshots aller MTrees, die für die Datenverschiebung konfiguriert sind.
• Jede Datei hat eine Änderungszeit, die speichert, wann in eine Datei das letzte Mal geschrieben wurde.
• Wenn eine Datei zuvor in den Cloud-Tier migriert wurde, wird ein zusätzliches Zeitfeld namens Platzierungszeit festgelegt. Die Platzierungszeit speichert das Datum und die Uhrzeit, zu der die Datei in den Cloud-Tier migriert wurde. Wenn die Platzierungszeit eingestellt ist, wird diese anstelle der Änderungszeit verwendet. Dadurch soll vermieden werden, dass eine Datei kontinuierlich zurück in den Cloud-Tier migriert wird, wenn eine Datei abgerufen wird (da das Abrufen einer Datei ihre Änderungszeit nicht ändert).
• Die oben erstellten Snapshots werden durch Datenverschiebung durchlaufen.
• Wenn die zu untersuchende Datei einen definierten Schwellenwert erreicht hat, der durch die Datenverschiebungs-Policy für den betreffenden MTree festgelegt ist, wird die Datei untersucht, um festzustellen, welche Daten in dieser Datei vom aktiven Tier in den Cloud-Tier migriert werden müssen. Pro MTree wird eine Datenverschiebungs-Policy festgelegt.
• Die eindeutigen Segmente für die ausgewählte Datei werden in den Cloud-Tier geschrieben oder kopiert. 
• Sobald die eindeutigen Segmente kopiert wurden, wird die Datei durch erneutes Lesen überprüft, um sicherzustellen, dass die Migration erfolgreich war.
• Sobald die Datei überprüft wurde, werden die Metadaten aktualisiert, um widerzuspiegeln, dass sich die Datei jetzt auf dem Cloud-Tier befindet.
• Die Datenverschiebung kann mit einer bestimmten Häufigkeit geplant oder manuell initiiert werden.

Welche Phasen gibt es, wenn die Datenverschiebung gestartet wird, und welche Aktionen werden in jeder Phase durchgeführt?

• Es gibt drei Phasen im Zusammenhang mit der Datenverschiebung: die Kopierphase, die Überprüfungsphase und die Installationsphase.
• Die Kopierphase ist dafür verantwortlich, Segmente zu identifizieren, die in die Cloud kopiert werden müssen, und diese Segmente dann in die Cloud zu migrieren.
• Sobald die Kopierphase beginnt, handelt es sich um einen Cloud- oder Objektspeicher. Dieser wird verwendet, da in der Kopierphase die vom aktiven Tier identifizierten Segmente in den Cloud-Tier kopiert werden.
• Die Überprüfungsphase ist dafür verantwortlich, sicherzustellen, dass die Segmente einer Datei erfolgreich in die Cloud migriert wurden.
• Die Installationsphase ist für die Aktualisierung der Metadaten der migrierten Datei verantwortlich, um zu zeigen, dass sie sich jetzt in der Cloud oder im Objektspeicher befindet.
• Jede Datei muss alle drei Phasen durchlaufen, damit die Datenverschiebung für diese Datei als erfolgreich angesehen wird. Daher verbleibt eine Datei bis zum Abschluss der Installationsphase im aktiven Tier.

Welche Datenverschiebungs-Policies sind verfügbar?

• Datenverschiebungs-Policies können eine der folgenden sein:   
  • Altersschwellenwert: Wenn die Platzierungs- oder Änderungszeit einer Datei älter als der festgelegte Altersbereich ist, wird sie für die Migration zum Cloud-Tier ausgewählt.
  • Altersgruppe: Wenn die Platzierungs- oder Änderungszeit einer Datei in den festgelegten Altersbereich fällt, wird sie für die Migration zum Cloud-Tier ausgewählt.
  • Anwendungsdefiniert: Die Backupanwendung gibt an, ob eine Datei für die Migration in den Cloud-Tier ausgewählt werden soll.
• Policies schließen sich gegenseitig aus, d. h., für einen MTree kann jeweils nur eine Policy festgelegt sein.

Wie kann eine Datenverschiebungs-Policy für einen MTree festgelegt werden?

• Der folgende Befehl kann verwendet werden. Zum Beispiel:   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

Welche Datenverschiebungs-Policies sind bereits konfiguriert?

• Mit dem folgenden Befehl wird eine Liste der MTrees bereitgestellt, denen Datenverschiebungs-Policies zugewiesen sind. Zum Beispiel:   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

Wie funktioniert eine von Apps verwaltete Datenverschiebungs-Policy?

• Die Datenverschiebungs-Policy für den betreffenden MTree ist auf „app-managed“ eingestellt. Dies erfolgt entweder manuell oder die Backupanwendung führt dies über die Data Domain REST API-Schnittstelle durch.
• Die Backupanwendung muss LTR-fähig sein.
• Die Backupanwendung muss DD Boost verwenden und die Version von DD Boost muss LTR-fähig und kompatibel sein.
• Mithilfe der DD Boost-Bibliothek/API legt die Backupanwendung die Platzierungszeit für die Datei, die in den Cloud-Tier migriert werden muss, auf einen speziellen Wert fest, der angibt, dass die Datei bei der nächsten Datenverschiebung in die Cloud migriert werden soll.
• Wenn eine Datenverschiebung auf dem Data Domain-System ausgeführt wird, wird die Platzierungszeit geprüft. Wenn sie, wie oben erwähnt, auf den speziellen Wert eingestellt ist, wird die Datei in die Cloud migriert.

Wie kann die Datenverschiebung manuell gestartet werden?

• Der folgende Befehl kann z. B. verwendet werden:   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

Wie kann die Datenverschiebung überwacht werden?

• Mit dem folgenden Befehl kann der Status der Datenverschiebung überprüft werden. Zum Beispiel:   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Wenn eine Datenverschiebung ausgeführt wird, kann z. B. der folgende Befehl verwendet werden:   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

Wie kann die Datenverschiebung gestoppt werden?

• Der folgende Befehl kann verwendet werden. Zum Beispiel:   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

Wenn mehr als eine Cloudeinheit vorhanden ist, kann dann eine Datenverschiebung zu beiden Cloudeinheiten parallel ausgeführt werden?

• Nein. Im Wesentlichen können Daten bei Datenverschiebungen jeweils nur in eine Cloudeinheit migriert werden.

Wie ist die LTR konfiguriert?

• Dies ist eine allgemeine Übersicht, siehe detaillierter Prozess im DDOS-Administrationshandbuch.
• Hinzufügen der entsprechenden CLOUDTIER_CAPACITY license.
• Legen Sie die Systempassphrase fest, wenn sie noch nicht festgelegt ist.
• Aktivieren Sie die Cloud-Funktion.
• Fügen Sie den Metadatenspeicher für den Cloud-Tier hinzu.
• Konfigurieren Sie ein Cloudprofil oder ein Profil für den entsprechenden Cloud- oder Objektspeicheranbieter.
• Fügen Sie eine Cloudeinheit hinzu.
• Konfigurieren Sie eine Datenverschiebungs-Policy für den MTree oder die MTrees, für die Daten in der Cloud gespeichert werden müssen.
• Starten Sie die Datenverschiebung manuell oder warten Sie, bis eine automatische oder geplante Datenverschiebung gestartet wird.

Kann eine Cloudeinheit gelöscht werden? Wenn ja, wie?

• Achtung: Dadurch werden alle Daten auf der Cloudeinheit gelöscht und sind nicht mehr wiederherstellbar. Gehen Sie daher vorsichtig vor.
• Im Abschnitt Wie ermitteln NutzerInnen, auf welchem Tier sich eine Datei befindet in diesem Wissensdatenbankdokument erfahren Sie, welche Dateien sich auf der Cloudeinheit befinden, die gelöscht werden soll.
• Diese Dateien sollten entweder gelöscht werden, wenn sie nicht mehr benötigt werden, oder in den aktiven Tier abgerufen werden, wenn sie aufbewahrt werden müssen.
• Wenn Dateien aufbewahrt werden müssen, stellen Sie sicher, dass alle Dateien abgerufen werden, bevor Sie fortfahren.
• Es sollten keine Dateien auf der zu löschenden Cloudeinheit verbleiben.
• Setzen Sie alle Datenverschiebungs-Policies für den MTree oder die MTrees zurück, die diese Cloudeinheit verwenden.
• Deaktivieren Sie das Dateisystem.
• Löschen Sie die Cloudeinheit. Dadurch wird die Cloudeinheit standardmäßig mit dem Status DELETE_PENDING markiert.
• Aktivieren Sie das Dateisystem.
• Sobald das Dateisystem gestartet wurde, beginnt es asynchron mit dem Löschen aller Objekte in der Cloud oder dem Objektspeicheranbieter, die von dieser Cloudeinheit verwendet wurden. Nachdem alle Objekte gelöscht wurden, werden auch die Buckets, die diese Cloudeinheit verwendet hat, gelöscht. Wenn viele Objekte vorhanden sind, kann die Cloudeinheit über einen längeren Zeitraum im Status DELETE_PENDING bleiben.
• Nachdem alle Objekte und Buckets erfolgreich entfernt wurden, verschwindet die Cloudeinheit aus der Liste der Cloudeinheiten.

Was passiert, wenn eine Cloudeinheit nicht gelöscht werden kann, weil der Objektspeicher nicht mehr verfügbar ist oder ein Verbindungsproblem vorliegt?

• Wenden Sie sich für weitere Unterstützung an den Support von Dell.

Können LTR und Extended Retention (ER) auf demselben System konfiguriert werden?

• Nein. ER und LTR schließen sich gegenseitig aus.

Wie werden Daten aus dem Cloud-Tier freigegeben oder bereinigt?

• Dies funktioniert auf ähnliche Weise wie Dateien, die sich auf dem aktiven Tier befinden
• Sobald eine Datei ihre Aufbewahrungsfrist erreicht hat, wird sie aus dem Dateisystem-Namespace gelöscht.
• Die Cloud-Tier-Bereinigung ist für die Ausführung geplant. Standardmäßig wird die Cloud-Tier-Bereinigung nach jeweils vier aktiven Tier-Bereinigungssitzungen ausgeführt.
• Damit die Cloud-Tier-Bereinigung ausgeführt werden kann, muss die zu reinigende Cloudeinheit mindestens 1 % an überflüssigen oder bereinigungsfähigen Daten enthalten, um gestartet werden zu können. Dies liegt daran, dass jeglicher Cloud-Netzwerkverkehr kostenpflichtig sein kann, sodass der DDR versucht, den Netzwerkdatenverkehr nach Möglichkeit zu begrenzen.
• Cloud Tier wird mit einer Standardbereinigungsdrosselung von 50 % ausgeführt.
• Sowohl der Cloud-Tier-Bereinigungszeitplan als auch die Reinigungsdrosselung können geändert werden.
• Die Bereinigung des aktiven Tier und des Cloud-Tier kann nicht parallel ausgeführt werden.
• Wenn eine automatische oder geplante Cloud-Tier-Bereinigung ausgeführt wird, wird sie durch die Bereinigung des aktiven Tier vorweggenommen.
• Wenn eine manuelle Cloud-Tier-Bereinigung initiiert wird, kann die aktive Tier-Bereinigung erst gestartet werden, wenn die Cloud-Tier-Bereinigung abgeschlossen ist.
• Wenn ein Cloud-Tier über zwei Cloudeinheiten verfügt, wird nur eine Cloudeinheit pro geplanter oder automatischer Cloud-Tier-Bereinigung bereinigt. Die Cloudeinheiten werden im Hinblick auf die Cloud-Tier-Bereinigung im Rundlaufverfahren betrieben. Wenn zwei Cloudeinheiten vorhanden sind, ist es erforderlich, die zu bereinigende Cloudeinheit anzugeben, wenn sie über die Befehlszeile ausgeführt wird (cloud clean start <unit-name>)
• Wenn eine Cloud-Tier-Bereinigung auf einer Cloudeinheit nicht gestartet werden kann, z. B. weil die aktuelle Cloudeinheit nicht über genügend bereinigungsfähige Daten verfügt, um sie als lohnenswert zu betrachten, versucht das System automatisch, die nächste Cloudeinheit zu bereinigen.
• Weitere Informationen zur Cloud-Tier-Bereinigung finden Sie im folgenden Artikel Data Domain: Einführung in die langfristige Aufbewahrung, Cloud-Tier-Bereinigung, automatische Speicherbereinigung auf Data Domain Restorers (DDRs)

Wie wird eine manuelle Cloud-Tier-Bereinigung gestartet?

• Der folgende Befehl kann verwendet werden. Zum Beispiel:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

Wie kann eine Cloud-Tier-Bereinigung überwacht werden?

• Mit dem folgenden Befehl kann überprüft werden, ob die Cloud-Bereinigung ausgeführt wird. Zum Beispiel:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• Wenn eine Cloud-Bereinigung ausgeführt wird, kann dies mit dem folgenden Befehl überwacht werden:

cloud clean watch

Kann die aktive Tier-Bereinigung gleichzeitig mit der Cloud-Tier-Bereinigung ausgeführt werden?

• Nein. Sowohl die Bereinigung des aktiven Tier als auch die Bereinigung des Cloud-Tier verwenden dieselben gemeinsamen internen freigegebenen Datenstrukturen, die exklusiven Zugriff erfordern.

Wie kann ein Cloud-Tier-Bereinigungszeitplan angezeigt oder geändert werden?

• Mit dem folgenden Befehl kann der aktuelle Cloud-Bereinigungszeitplan angezeigt werden. Zum Beispiel:   

cloud clean frequency show

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

• Der folgende Befehl wird verwendet, um einen Zeitplan zu ändern. Zum Beispiel:  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

Wie kann die Drosselung der Cloud-Tier-Bereinigung geändert oder angezeigt werden?

• Standardmäßig ist die Drosselung der Cloud-Tier-Bereinigung auf 50 % eingestellt. Mit dem folgenden Befehl kann die Drosselung auf den Standardprozentsatz zurückgesetzt werden.

cloud clean throttle reset

• Mit dem folgenden Befehl kann die aktuelle Drosselung der Cloud-Bereinigung angezeigt werden. Zum Beispiel:   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• Mit dem folgenden Befehl kann die Reinigungsdrosselung geändert werden. Zum Beispiel:   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

Was steuert die Drosselung der Cloud-Tier-Bereinigung?

• Die Cloud-Tier-Bereinigungsdrosselung funktioniert ähnlich wie die Bereinigungsdrosselung für den aktiven Tier, da die Drosselung die I/O- und CPU-Ressourcen einschränkt, die die Cloud-Tier-Bereinigung verwenden kann.
• Die Netzwerkübertragung wird nicht gedrosselt.

Warum werden bei der Cloud-Tier-Bereinigung nicht so viele Objekte wie erwartet freigegeben/gelöscht?

• Die Reinigung wird immer als Schätzung betrachtet. In den folgenden KB-Artikeln werden Aspekte zu diesem Thema beschrieben, da sie gleichermaßen für Daten gelten, die sich auf dem Cloud-Tier befinden:  

• Darüber hinaus gibt es weitere spezifische Details zur Implementierung des Cloud-Tiers.
• Es wurden verschiedene Methoden implementiert, um die Menge des Netzwerkverkehrs zu einem Cloud- oder Objektspeicheranbieter zu begrenzen, da dies mit Kosten verbunden sein kann.
• Wie bereits erwähnt, ist eine Datenänderung von mindestens 1 % erforderlich, damit eine Bereinigung ausgeführt werden kann.
• Wenn das Dateisystem durchlaufen wird, um nach Dateien zu suchen, die der Datenverschiebungs-Policy entsprechen, werden nur lokale Kopien der Metadaten berücksichtigt.
• Alle Segmente im Cloud- oder Objektspeicher, die nur Nutzerdaten enthalten, werden für die asynchrone Löschung markiert.
• Alle Segmente, die mindestens ein Live-Segment enthalten, werden übersprungen, da DDOS aufgrund des beteiligten Netzwerkverkehrs keine kleinen Datenmengen kombinieren möchte.

Wie ermitteln NutzerInnen, auf welchem Tier sich eine Datei befindet?

• Verwenden Sie den folgenden Befehl als Beispiel für die von diesem Befehl erzeugte Ausgabe:  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

Kann eine Datei direkt nach der Migration zum Cloud-Tier gelesen oder aufgerufen werden?

• Dies hängt von der Version von DDOS ab, die zusammen mit dem Cloud-Anbieter verwendet wird:   

• Die direkte Wiederherstellung von Dateien ist möglich, ohne dass Sie eine Datei zuerst abrufen müssen. Dies wird als direkte Wiederherstellungsfunktion bezeichnet und ist auf ECS als Cloud- oder Objektanbieter beschränkt.
• Weitere Informationen zur direkten Wiederherstellung über Avamar finden Sie im Whitepaper Avamar Granular or File Level Restore from Data Domain Cloud Tier.
• Für die Avamar GLR/FLR-Funktion (Direct Restore) ist eine Mindestkombination aus Avamar 18.1 oder DDOS 6.1 mit ECS als Cloud-Anbieter erforderlich. 

• Eine Datei muss zuerst abgerufen werden. Das heißt, die Daten wurden vom Cloud-Tier zurück zum aktiven Tier migriert.
• Die Datei muss mithilfe des Befehls „data-movement call“ vom Cloud-Tier in den aktiven Tier abgerufen werden, um Lesevorgänge aus einer Datei oder Änderungen an einer Datei, die sich auf dem Cloud-Tier befindet, zu ermöglichen.
• Jeder Versuch, eine Datei zu lesen oder zu ändern, die sich auf dem Cloud-Tier befindet, führt dazu, dass ein I/O-Fehler an denjenigen zurückgegeben wird, der versucht, die Datei zu lesen, bei der es sich um die Backupanwendung handelt, wenn die Datei nicht zuerst abgerufen wird.
• Einige Cloud-fähige Backupanwendungen können Dateiabrufe initiieren, andernfalls müssen Dateien manuell abgerufen werden.
• Seit DDOS 7.7+:
  • Mit der direkten Wiederherstellung können nicht integrierte Anwendungen Dateien direkt aus dem Cloud-Tier lesen, ohne den aktiven Tier zu durchlaufen.
  • Zu den wichtigsten Überlegungen bei der Entscheidung für die direkte Wiederherstellung gehören:
  • Die direkte Wiederherstellung erfordert keine integrierte Anwendung und ist für nicht integrierte Anwendungen transparent.
  • Das Lesen aus dem Cloud-Tier erfordert kein vorheriges Kopieren in den aktiven Tier.
  • Histogramme und Statistiken sind für die Nachverfolgung direkter Lesevorgänge aus dem Cloud-Tier verfügbar.
  • Die direkte Wiederherstellung wird nur für AWS- und ECS-Cloud-Anbieter unterstützt.
  • Bei Anwendungen kommt es zu Cloud-Tier-Latenz.
  • Das Lesen direkt aus dem Cloud-Tier ist nicht bandbreitenoptimiert.

Wie viele Dateien können parallel abgerufen werden?

• DDOS 6.0 unterstützt vier Dateien, die parallel in die Warteschlange gestellt und abgerufen werden können.
• DDOS 6.1 unterstützt 1.000 Dateien, die in die Warteschlange eingereiht werden, und 4 Dateien in der Abrufwarteschlange, die parallel abgerufen werden können.

Gemäß Data Domain Admin Guide 7.9:

• Systeme mit 256 GB Arbeitsspeicher oder mehr können bis zu 16 Dateien gleichzeitig abrufen.
• Systeme mit weniger als 256 GB Arbeitsspeicher können bis zu acht Dateien gleichzeitig abrufen.
• DDVE-Instanzen können bis zu 4 Dateien gleichzeitig abrufen.

Wie kann eine Datei abgerufen werden?

• Eine Datei kann mit dem folgenden Befehl abgerufen werden. Zum Beispiel:   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

Wie können alle Dateien in einem MTree abgerufen werden?

• Je nach DDOS-Version können alle Dateien in der Cloud mit einem einzigen Befehl wie dem folgenden abgerufen werden:   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Weitere Informationen finden Sie im „Dell DDOS-Befehlsrefenzhandbuch“ für Ihre DDOS-Version

Wie kann eine Abrufaktion überwacht werden?

• Eine Abrufaktion kann mithilfe des folgenden Befehls überwacht werden oder wenn eine bestimmte Datei erforderlich ist. Zum Beispiel:   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

Führt das Umbenennen einer Datei dazu, dass die Datei aus dem Cloud-Tier in den aktiven Tier abgerufen wird?

• Nein. Wenn eine Datei umbenannt wird, verbleibt sie auf ihrem aktuellen Tier.

Welche Cloud-Anbieter werden unterstützt?

•  Je nach verwendeter DDOS-Version unterstützt DDOS die folgenden Cloud-Anbieter:   
• Amazon Web Services (AWS).
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Weitere Informationen finden Sie im DDOS-Administrationshandbuch.

Wird Verschlüsselung auf dem Cloud-Tier unterstützt und muss sie lizenziert werden?

• Ja, Verschlüsselung wird auf dem Cloud-Tier unterstützt. Im Gegensatz zur aktiven Tier-Verschlüsselung ist hierfür keine zusätzliche Lizenz erforderlich.
• Dies kann konfiguriert werden, wenn die Cloud-Funktion danach aktiviert oder geändert wird. 
• Zum Zeitpunkt der Erstellung dieses Artikels wird nur der integrierte Key Manager für die Cloud-Tier-Verschlüsselung unterstützt und nur ein Verschlüsselungsalgorithmus kann für die systemweite LTR verwendet werden.

Welche Buckets werden im Objektspeicher des Cloud-Anbieters erstellt?

• DDOS erstellt drei Buckets
• Die Buckets enden mit der folgenden Zeichenfolge:

'-d0'

'-c0' 

'-m0'

• Der Bucket, der mit der Zeichenfolge „-d0“ endet, wird für Datensegmente verwendet.
• Der Bucket, der mit der Zeichenfolge „-c0“ endet, wird für Konfigurationsdaten verwendet.
• Der Bucket, der mit der Zeichenfolge „-m0“ endet, wird für Metadaten verwendet.
• Vor DDOS 6.1 werden zwar drei Buckets erstellt, aber nur der Bucket mit der Endung „-d0“ wird verwendet. Es werden jedoch alle drei Buckets benötigt. Stellen Sie daher sicher, dass sie nicht entfernt werden.

Ist es möglich, vorhandene Bucket-Namen zu verwenden, die zuvor erstellt wurden?

• Nein, das ist nicht möglich.

Gibt es zusätzlich zu den Hardwareanforderungen weitere obligatorische Anforderungen, die vor der Konfiguration der langfristigen Aufbewahrung erforderlich sind?

• Ja
• Wenn ECS verwendet wird, ist ein Lastenausgleichsmodul eine zwingende Anforderung. Ohne Lastenausgleichsmodul kommuniziert Data Domain mit ECS auf einem einzigen Node und trennt die Verbindung, sobald mehrere Anfragen gestellt werden.
• Ein 1-Gbit-Netzwerk zwischen dem DDR und dem Cloud-Anbieter

Sind Zertifikate erforderlich und wenn ja, welche Zertifikate sollten verwendet werden?

• Dies hängt vom verwendeten Objekt oder Cloud-Anbieter sowie von der Konfiguration ab.
• Für AWS, Virtustream oder Azure ist ein Zertifikat erforderlich. Weitere Informationen finden Sie im DDOS-Administrationshandbuch.
• Wenn ECS mit einem HTTP-Endpunkt konfiguriert ist, ist kein Zertifikat erforderlich.
• Wenn ECS mit einem HTTPS-Endpunkt konfiguriert ist, ist ein Zertifikat erforderlich. Da ein Lastenausgleichsmodul obligatorisch ist, stammt das erforderliche Zertifikat aus dem System des Lastenausgleichsmoduls und nicht aus dem ECS-System. Weitere Informationen erhalten Sie von Ihrem Lastenausgleichsmodulanbieter.
• Beim Importieren des Zertifikats muss dieses im PEM-Format vorliegen. Einige Anbieter stellen das Zertifikat nicht im PEM-Format bereit, sodass es vor dem Import konvertiert werden muss.

Welche Replikationstopologien werden unterstützt?

• Erfassungsreplikation wird nicht unterstützt.
• Die Verzeichnisreplikation wird unterstützt, kann jedoch nur vom MTree „/data/col1/backup“ verwendet werden, aber dieser MTree unterstützt keine Datenverschiebung.
• Die MTree-Replikation wird vollständig unterstützt.
• Die MFR- oder VSR-Replikation wird vollständig unterstützt.

Was ist bei der Konfiguration/Initialisierung/erneuten Initialisierung der Replikation auf einem System zu beachten, auf dem bereits die langfristige Aufbewahrung konfiguriert ist?

• Das Quellsystem erstellt einen Snapshot des MTree (dieser Snapshot umfasst Details zu Dateien auf aktiven und Cloud-Tiers).
• Das Quellsystem repliziert den Snapshot auf den aktiven Tier des Zielsystems.
• Erst wenn der Snapshot vollständig repliziert wurde, wird er auf dem Zielsystem verfügbar gemacht (zu diesem Zeitpunkt werden Dateien im Namespace des Zielsystems verfügbar).
• Erst nachdem Dateien verfügbar gemacht wurden, kann die Datenverschiebung auf dem Ziel ausgeführt werden (vorausgesetzt, es ist für die langfristige Aufbewahrung konfiguriert).
• Wenn der aktive Tier des Ziels nicht groß genug ist, um einen vollständigen Snapshot von der Quelle zu speichern, wird der Snapshot nie verfügbar gemacht und die Replikation kann die Initialisierung nicht abschließen.

Was ist bei der Konfiguration der MFR- oder VSR-Replikation auf einem System zu beachten, für das LTR bereits konfiguriert ist?

• Wenn Daten, die bereits auf den Cloud-Tier auf einem Quell-DDR migriert wurden, repliziert werden müssen, werden sie automatisch vom Cloud-Anbieter auf den aktiven Tier abgerufen, bevor sie über das Netzwerk gesendet werden können.
• Das Abrufen von Dateien aus dem Cloud-Tier in den aktiven Tier kann Kosten oder Verzögerungen verursachen.

Warum spiegelt die Ausgabe des Data Domain-Befehls „file system show space“ nicht die tatsächliche Größe des Cloud- oder Objektspeichers wider?

• Aufgrund der inhärenten Funktionsweise von Cloud- oder Objektspeicher hat ein Data Domain-System keine Möglichkeit, die physische Größe eines Cloudgeräts abzufragen, da diese als scheinbar unendlich angesehen werden könnte.
• DDOS musste jedoch eine Möglichkeit entwickeln, aktuelle Nutzungs-/Deduplizierungsstatistiken aus DDOS-Perspektive anzuzeigen.
• Daher wird einer von zwei Ansätzen verwendet:

1. Die Größe des Cloud-Tier wird ermittelt durch die CLOUDTIER_CAPACITY license
2. Die Größe des Cloud-Tier wird als Vielfaches der Größen der aktiven Tier-Einheiten für diesen Modelltyp angezeigt, je nachdem, wie viele Cloudeinheiten konfiguriert sind. Weitere Informationen zu den Größen des aktiven Tier finden Sie im Hardwareinstallationshandbuch für das entsprechende Modell.

Wie kann das Dateisystem gestartet werden, wenn keine Cloudeinheit verfügbar ist?

• Stellen Sie sicher, dass das Dateisystem deaktiviert ist.
• Deaktivieren Sie die Cloudeinheit, die nicht verfügbar ist, mit dem folgenden Befehl:

cloud unit disable <cloud unit name>

• Aktivieren Sie das Dateisystem.

Wenn eine Cloudeinheit deaktiviert ist, wie kann sie aktiviert werden?

• Stellen Sie sicher, dass das Dateisystem deaktiviert ist.
• Aktivieren Sie die Cloudeinheit mit dem folgenden Befehl:

cloud unit enable <cloud unit name>

• Aktivieren Sie das Dateisystem.

Warum sind noch Dateien im Dateisystem vorhanden, die sich auf einer Cloudeinheit befinden, die gelöscht wurde?

•  Wenn Dateien nicht aus einem MTree entfernt wurden, bevor eine Cloudeinheit gelöscht wurde, befinden sich die Dateien weiterhin im Dateisystem-Namespace.
• Daher zeigt der Dateispeicherortbericht an, dass die Dateien Teil einer gelöschten Cloudeinheit sind. Zum Beispiel:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• Die Dateien können weiterhin im Dateisystem-Namespace angezeigt werden, indem auf eine CIFS-/NFS-Share für diesen MTree zugegriffen wird.
• Die Dateien sind jedoch nicht lesbar, da die Cloudeinheit, in der sie sich befanden, gelöscht wurde.
• Daher besteht die einzige Möglichkeit darin, diese Dateien zu löschen, da die Daten, auf die sie verwiesen haben, nicht mehr vorhanden sind.

Ist es möglich, den Protokollendpunkt oder die Ports für einen ECS- oder S3 Flexible-Cloud-Anbieter zu ändern, nachdem eine Cloudeinheit erstellt wurde?

• Dies kann beispielsweise erforderlich sein, wenn Sie von http zu https oder umgekehrt zu einem neuen Lastenausgleichsmodul migrieren.
• Zum Zeitpunkt der Erstellung dieses Artikels gibt es für Data Domain-AdministratorInnen keine Möglichkeit, diese Änderung durchzuführen. Diese Funktion wird für eine zukünftige DDOS-Version in Betracht gezogen.
• Dies kann jedoch vom Support oder der Technikabteilung durchgeführt werden.
• Das Dateisystem muss deaktiviert sein, um diese Änderung durchführen zu können.
• Wenn dies erforderlich ist, wird die gesamte Konfiguration außerhalb des Data Domain-Systems zuerst durchgeführt, denn sobald dies geändert wird, erwartet das Dateisystem bei der Aktivierung, dass es über das aktualisierte Protokoll oder den aktualisierten Port kommunizieren und die Buckets oder Objekte wie zuvor lesen kann.