Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Erweiterte benutzerdefinierte Ressourcenwiederherstellungseinstellungen verwenden

Beitragende netapp-mwallis
Änderungen vorschlagen
PDFs

Sie können Wiederherstellungsvorgänge mithilfe erweiterter Einstellungen wie Annotationen, Namespace-Einstellungen und Speicheroptionen an Ihre spezifischen Anforderungen anpassen.

Namespace-Annotationen und -Labels während Wiederherstellungs- und Failover-Operationen

Bei Wiederherstellung und Failover werden die Namespace-Bezeichnungen und -Annotationen des Ziels aktualisiert, um mit denen der Quelle übereinzustimmen: Schlüssel aus der Quelle werden zu den Zielschlüsseln hinzugefügt oder überschrieben, während Schlüssel, die nur im Ziel existieren, unverändert bleiben.

Hinweis In Red Hat OpenShift sind Namespace-Annotationen wichtig, da sie sicherstellen, dass wiederhergestellte Pods die korrekten Sicherheitskontextbeschränkungen und Berechtigungen erhalten, sodass sie auf Volumes zugreifen und ohne Berechtigungsfehler ausgeführt werden können. Weitere Informationen finden Sie unter "OpenShift security context constraints Dokumentation".

Setzen Sie die Kubernetes-Umgebungsvariable

RESTORE_SKIP_NAMESPACE_ANNOTATIONS

Vor der Wiederherstellung oder dem Failover sollte verhindert werden, dass bestimmte Ziel-Namespace-Annotationen überschrieben werden. Zum Beispiel:

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
Hinweis Während der Wiederherstellung oder des Failovers werden alle in restoreSkipNamespaceAnnotations und restoreSkipNamespaceLabels angegebenen Namespace-Annotationen und -Labels von der Wiederherstellungs- oder Failover-Operation ausgeschlossen. Stellen Sie sicher, dass diese Einstellungen während der initialen Helm-Installation konfiguriert sind. Weitere Informationen finden Sie unter "Konfigurieren Sie zusätzliche Trident Protect Helm-Chart-Einstellungen".

Wenn Sie Helm mit dem --create-namespace Flag zur Installation der Quellanwendung verwendet haben, kopiert Trident Protect die Namensbezeichnung in den Ziel-Namespace. Stimmt der Wert der Bezeichnung mit dem Namen des Quell-Namespace überein, wird er durch den Namen des Ziel-Namespace ersetzt; andernfalls bleibt er unverändert.

Beispiel

Das folgende Beispiel zeigt Quell- und Ziel-Namensräume mit unterschiedlichen Bezeichnungen und Annotationen und zeigt den Ziel-Namensraum vor und nach der Operation, um zu veranschaulichen, wie Schlüssel hinzugefügt, zusammengeführt oder überschrieben werden.

Vor dem Wiederherstellungs- oder Failover-Vorgang

Die folgende Tabelle veranschaulicht den Zustand der Beispiel-Quell- und Ziel-Namespaces vor der Wiederherstellungs- oder Failover-Operation:

Namensraum Anmerkungen Etiketten

Namespace ns-1 (Quelle)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • environment=production

  • compliance=hipaa

  • name=ns-1

Namespace ns-2 (Ziel)

  • annotation.one/key: "true"

  • annotation.three/key: "false"

  • role=database

Nach dem Wiederherstellungsvorgang

Die folgende Tabelle veranschaulicht den Zustand des Beispiel-Ziel-Namespace nach der Wiederherstellung oder dem Failover. Einige Schlüssel wurden hinzugefügt, einige wurden überschrieben, und das name Label wurde aktualisiert, um dem Ziel-Namespace zu entsprechen:

Namensraum Anmerkungen Etiketten

Namespace ns-2 (Ziel)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • compliance=hipaa

  • environment=production

  • role=database

Unterstützte Felder

In diesem Abschnitt werden zusätzliche Felder beschrieben, die für Wiederherstellungsvorgänge zur Verfügung stehen.

Speicherklassenzuordnung

Das spec.storageClassMapping Attribut definiert eine Zuordnung von einer Speicherklasse in der Quellanwendung zu einer neuen Speicherklasse im Zielcluster. Sie können dies verwenden, wenn Sie Anwendungen zwischen Clustern mit unterschiedlichen Speicherklassen migrieren oder das Speicher-Backend für BackupRestore-Operationen ändern.

Beispiel:

storageClassMapping:
  - destination: "destinationStorageClass1"
    source: "sourceStorageClass1"
  - destination: "destinationStorageClass2"
    source: "sourceStorageClass2"

Unterstützte Annotationen

Dieser Abschnitt listet die unterstützten Annotationen zur Konfiguration verschiedener Verhaltensweisen im System auf. Wenn eine Annotation nicht explizit vom Benutzer festgelegt wird, verwendet das System den Standardwert.

Anmerkung Typ Beschreibung Standardwert

protect.trident.netapp.io/data-mover-timeout-sec

Zeichenkette

Die maximal zulässige Zeit (in Sekunden), in der der Datenübertragungsvorgang angehalten werden darf.

"300"

protect.trident.netapp.io/kopia-content-cache-size-limit-mb

Zeichenkette

Die maximale Größenbeschränkung (in Megabytes) für den Kopia-Inhaltscache.

"1000"

protect.trident.netapp.io/pvc-bind-timeout-sec

Zeichenkette

Maximale Zeit (in Sekunden), die auf neu erstellte PersistentVolumeClaims (PVCs) gewartet wird, um die Bound Phase zu erreichen, bevor der Vorgang fehlschlägt. Gilt für alle Restore-CR-Typen (BackupRestore, BackupInplaceRestore, SnapshotRestore, SnapshotInplaceRestore). Verwenden Sie einen höheren Wert, wenn Ihr Storage-Backend oder Cluster häufig mehr Zeit benötigt.

"1200" (20 Minuten)