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 Wiederherstellungseinstellungen für Kubernetes in NetApp Backup and Recovery

Beitragende netapp-mwallis
Änderungen vorschlagen
PDFs

Annotationen, Namespace-Einstellungen und Speicheroptionen ermöglichen die Anpassung von Kubernetes-Wiederherstellungsvorgängen an Ihre Umgebung.

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

Dieser Abschnitt beschreibt zusätzliche Felder für Wiederherstellungsvorgänge.

Speicherklassenzuordnung

Das spec.storageClassMapping Attribut ordnet eine Speicherklasse in der Quellanwendung einer neuen Speicherklasse im Zielcluster zu. Dieses Feld wird verwendet, wenn Anwendungen zwischen Clustern mit unterschiedlichen Speicherklassen migriert werden oder wenn das Speicher-Backend für BackupRestore Operationen geändert wird.

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 keine Annotation explizit festgelegt wird, verwendet das System den Standardwert.

Anmerkung Typ Beschreibung Standardwert

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

Zeichenkette

Die maximale Zeit in Sekunden, die ein Datenmover-Vorgang angehalten bleiben kann.

"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). Ein höherer Wert ist sinnvoll, wenn das Storage-Backend oder der Cluster häufig mehr Zeit benötigt.

"1200" (20 Minuten)