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.

Replizieren Sie Applikationen mit NetApp SnapMirror und Trident Protect

Beitragende
PDFs

Mit Trident Protect können Sie die asynchronen Replizierungsfunktionen der NetApp SnapMirror Technologie verwenden, um Daten und Applikationsänderungen von einem Storage-Back-End auf ein anderes zu replizieren, im selben Cluster oder zwischen verschiedenen Clustern.

Namespace-Annotationen und -Labels bei Restore- und Failover-Vorgängen

Während von Restore- und Failover-Vorgängen werden Labels und Annotationen im Ziel-Namespace so angefertigt, dass sie den Labels und Annotationen im Quell-Namespace entsprechen. Beschriftungen oder Anmerkungen aus dem Quell-Namespace, die nicht im Ziel-Namespace vorhanden sind, werden hinzugefügt. Alle bereits vorhandenen Beschriftungen oder Anmerkungen werden überschrieben, um dem Wert aus dem Quell-Namespace zu entsprechen. Beschriftungen oder Anmerkungen, die nur im Ziel-Namespace vorhanden sind, bleiben unverändert.

Hinweis Wenn Sie RedHat OpenShift verwenden, ist es wichtig, die wichtige Rolle von Namespace-Annotationen in OpenShift-Umgebungen zu beachten. Namespace-Anmerkungen stellen sicher, dass wiederhergestellte Pods den durch OpenShift Security Context Constraints (SCCs) definierten Berechtigungen und Sicherheitskonfigurationen entsprechen und ohne Berechtigungsprobleme auf Volumes zugreifen können. Weitere Informationen finden Sie im "Dokumentation zu den Einschränkungen für den Sicherheitskontext von OpenShift".

Sie können verhindern, dass bestimmte Annotationen im Ziel-Namespace überschrieben werden, indem Sie die Kubernetes-Umgebungsvariable vor der Wiederherstellung oder dem Failover einstellen RESTORE_SKIP_NAMESPACE_ANNOTATIONS. Beispiel:

kubectl set env -n trident-protect deploy/trident-protect-controller-manager RESTORE_SKIP_NAMESPACE_ANNOTATIONS=<annotation_key_to_skip_1>,<annotation_key_to_skip_2>

Wenn Sie die Quellanwendung mit Helm mit dem Flag installiert haben, wird der Label-Schlüssel mit --create-namespace einer speziellen Bestrahlung name versehen. Während des Wiederherstellungs- oder Failover-Prozesses kopiert Trident Protect dieses Label in den Ziel-Namespace, aktualisiert jedoch den Wert auf den Ziel-Namespace-Wert, wenn der Wert von Quell-Namespace mit dem Quell-Namespace übereinstimmt. Wenn dieser Wert nicht mit dem Quell-Namespace übereinstimmt, wird er ohne Änderungen in den Ziel-Namespace kopiert.

Beispiel

Im folgenden Beispiel wird ein Quell- und Ziel-Namespace präsentiert, der jeweils unterschiedliche Annotationen und Labels enthält. Sie können den Status des Ziel-Namespace vor und nach dem Vorgang anzeigen und sehen, wie die Annotationen und Labels im Ziel-Namespace kombiniert oder überschrieben werden.

Vor der Wiederherstellung oder dem Failover

Die folgende Tabelle zeigt den Status der Beispiel-Namespaces für Quelle und Ziel vor dem Restore- oder Failover-Vorgang:

Namespace Anmerkungen Etiketten

Namespace ns-1 (Quelle)

  • Annotation.one/key: „Aktualisiertwert“

  • Anmerkung.zwei/Taste: "Wahr"

  • Umgebung = Produktion

  • Compliance=hipaa

  • Name=ns-1

Namespace ns-2 (Ziel)

  • Anmerkung.One/key: „True“

  • Anmerkung.drei/Taste: "False"

  • Rolle=Datenbank

Nach dem Wiederherstellungsvorgang

In der folgenden Tabelle wird der Status des Beispiel-Ziel-Namespace nach der Wiederherstellung oder dem Failover-Vorgang dargestellt. Einige Schlüssel wurden hinzugefügt, einige wurden überschrieben und das Label wurde aktualisiert, name um dem Ziel-Namespace zu entsprechen:

Namespace Anmerkungen Etiketten

Namespace ns-2 (Ziel)

  • Annotation.one/key: „Aktualisiertwert“

  • Anmerkung.zwei/Taste: "Wahr"

  • Anmerkung.drei/Taste: "False"

  • Name=ns-2

  • Compliance=hipaa

  • Umgebung = Produktion

  • Rolle=Datenbank
Hinweis Sie können Trident Protect so konfigurieren, dass Dateisysteme während des Datenschutzes eingefroren und wieder eingefroren werden. "Erfahren Sie mehr über das Konfigurieren des Dateisystemfrierens mit Trident Protect".

Richten Sie eine Replikationsbeziehung ein

Die Einrichtung einer Replikationsbeziehung umfasst Folgendes:

  • Festlegen der Häufigkeit, die Trident schützen soll, um einen App-Snapshot zu erstellen (was die Kubernetes-Ressourcen der Applikation sowie die Volume-Snapshots für die Volumes der Applikation umfasst)

  • Auswahl des Replizierungszeitplans (einschließlich Kubernetes-Ressourcen und persistenter Volume-Daten)

  • Einstellen der Uhrzeit für die Erstellung des Snapshots

Schritte

  1. Erstellen Sie einen AppVault für die Quellanwendung auf dem Quellcluster. Ändern Sie abhängig von Ihrem Storage-Anbieter ein Beispiel in "Benutzerdefinierte Ressourcen von AppVault"entsprechend Ihrer Umgebung:

    Erstellen Sie einen AppVault mit einem CR

    1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-appvault-primary-source.yaml).

    2. Konfigurieren Sie die folgenden Attribute:

      • metadata.name: (required) der Name der benutzerdefinierten AppVault-Ressource. Notieren Sie sich den ausgewählten Namen, da sich andere CR-Dateien, die für eine Replikationsbeziehung benötigt werden, auf diesen Wert beziehen.

      • spec.providerConfig: (required) speichert die Konfiguration, die für den Zugriff auf den AppVault unter Verwendung des angegebenen Providers erforderlich ist. Wählen Sie einen BucketName und alle anderen notwendigen Details für Ihren Anbieter. Notieren Sie sich die ausgewählten Werte, da sich andere CR-Dateien, die für eine Replikationsbeziehung benötigt werden, auf diese Werte beziehen. Beispiele für AppVault CRS mit anderen Anbietern finden Sie unter"Benutzerdefinierte Ressourcen von AppVault".

      • spec.providerCredentials: (required) speichert Verweise auf alle Anmeldeinformationen, die für den Zugriff auf AppVault unter Verwendung des angegebenen Anbieters erforderlich sind.

        • spec.providerCredentials.valueFromSecret: (required) gibt an, dass der Wert der Zugangsdaten von einem Secret stammen soll.

          • Key: (required) der gültige Schlüssel des zu wählenden Geheimnisses.

          • Name: (required) Name des Geheimnisses, das den Wert für dieses Feld enthält. Muss sich im gleichen Namespace befinden.

        • spec.providerCredentials.secretAccessKey: (required) der Zugriffsschlüssel, der für den Zugriff auf den Provider verwendet wird. Der Name sollte mit spec.providerCredentials.valueFromSecret.name übereinstimmen.

      • spec.providerType: (required) legt fest, was das Backup bereitstellt, z. B. NetApp ONTAP S3, generisches S3, Google Cloud oder Microsoft Azure. Mögliche Werte:

        • AWS

        • Azure

        • GCP

        • Generisch-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-appvault-primary-source.yaml haben, wenden Sie den CR an:

      kubectl apply -f trident-protect-appvault-primary-source.yaml -n trident-protect
    Erstellen Sie einen AppVault mithilfe der CLI

    1. Erstellen Sie AppVault und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung:

      tridentctl protect create vault Azure <vault-name> --account <account-name> --bucket <bucket-name> --secret <secret-name>

  2. Erstellen Sie die CR-Quellanwendung:

    Erstellen Sie die Quellanwendung mit einem CR

    1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-app-source.yaml).

    2. Konfigurieren Sie die folgenden Attribute:

      • metadata.name: (required) der Name der benutzerdefinierten Ressource der Anwendung. Notieren Sie sich den ausgewählten Namen, da sich andere CR-Dateien, die für eine Replikationsbeziehung benötigt werden, auf diesen Wert beziehen.

      • spec.includedNamespaces: (required) ein Array von Namespaces und zugehörigen Labels. Verwenden Sie Namespace-Namen und Grenzen Sie optional den Umfang der Namespaces mit Beschriftungen ein, um Ressourcen anzugeben, die in den hier aufgeführten Namespaces vorhanden sind. Der Application Namespace muss Teil dieses Arrays sein.

        Beispiel YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: maria
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: maria
      labelSelector: {}

    3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-app-source.yaml haben, wenden Sie den CR an:

      kubectl apply -f trident-protect-app-source.yaml -n my-app-namespace
    Erstellen Sie die Quellanwendung mithilfe der CLI

    1. Erstellen Sie die Quellanwendung. Beispiel:

      tridentctl protect create app maria --namespaces maria -n my-app-namespace

  3. Optional können Sie einen Snapshot der Quellanwendung erstellen. Dieser Snapshot wird als Basis für die Anwendung auf dem Zielcluster verwendet. Wenn Sie diesen Schritt überspringen, müssen Sie warten, bis der nächste geplante Snapshot ausgeführt wird, damit Sie über einen aktuellen Snapshot verfügen.

    Erstellen Sie einen Schnappschuss mit einem CR-System

    1. Erstellen Sie einen Replikationszeitplan für die Quellanwendung:

      1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-schedule.yaml).

      2. Konfigurieren Sie die folgenden Attribute:

        • metadata.name: (required) der Name der benutzerdefinierten Ressource für den Zeitplan.

        • Spec.AppVaultRef: (required) dieser Wert muss mit dem Feld metadata.name des AppVault für die Quellanwendung übereinstimmen.

        • Spec.ApplicationRef: (required) dieser Wert muss mit dem Feld metadata.name der Quellanwendung CR übereinstimmen.

        • Spec.backupRetention: (required) Dieses Feld ist erforderlich und der Wert muss auf 0 gesetzt werden.

        • Spec.enabled: Muss auf true gesetzt werden.

        • spec.granularity: muss auf eingestellt sein Custom.

        • Spec.recurrenceRule: Definieren Sie ein Startdatum in UTC-Zeit und ein Wiederholungsintervall.

        • Spec.snapshotRetention: Muss auf 2 gesetzt werden.

          Beispiel YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: appmirror-schedule-0e1f88ab-f013-4bce-8ae9-6afed9df59a1
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: maria
  backupRetention: "0"
  enabled: true
  granularity: custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

      1. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-schedule.yaml haben, wenden Sie den CR an:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Erstellen Sie einen Snapshot mit der CLI

    1. Erstellen Sie den Snapshot, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

      tridentctl protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot>

  4. Erstellen Sie eine Quellanwendung AppVault CR auf dem Zielcluster, die mit dem AppVault CR identisch ist, den Sie auf das Quellcluster angewendet haben, und benennen Sie es (z. B. trident-protect-appvault-primary-destination.yaml ).

  5. CR anwenden:

    kubectl apply -f trident-protect-appvault-primary-destination.yaml -n my-app-namespace

  6. Erstellen Sie einen AppVault für die Zielanwendung auf dem Zielcluster. Ändern Sie abhängig von Ihrem Storage-Anbieter ein Beispiel in "Benutzerdefinierte Ressourcen von AppVault"entsprechend Ihrer Umgebung:

    1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-appvault-secondary-destination.yaml).

    2. Konfigurieren Sie die folgenden Attribute:

      • metadata.name: (required) der Name der benutzerdefinierten AppVault-Ressource. Notieren Sie sich den ausgewählten Namen, da sich andere CR-Dateien, die für eine Replikationsbeziehung benötigt werden, auf diesen Wert beziehen.

      • spec.providerConfig: (required) speichert die Konfiguration, die für den Zugriff auf den AppVault unter Verwendung des angegebenen Providers erforderlich ist. Wählen Sie eine bucketName und alle anderen notwendigen Details für Ihren Provider. Notieren Sie sich die ausgewählten Werte, da sich andere CR-Dateien, die für eine Replikationsbeziehung benötigt werden, auf diese Werte beziehen. Beispiele für AppVault CRS mit anderen Anbietern finden Sie unter"Benutzerdefinierte Ressourcen von AppVault".

      • spec.providerCredentials: (required) speichert Verweise auf alle Anmeldeinformationen, die für den Zugriff auf AppVault unter Verwendung des angegebenen Anbieters erforderlich sind.

        • spec.providerCredentials.valueFromSecret: (required) gibt an, dass der Wert der Zugangsdaten von einem Secret stammen soll.

          • Key: (required) der gültige Schlüssel des zu wählenden Geheimnisses.

          • Name: (required) Name des Geheimnisses, das den Wert für dieses Feld enthält. Muss sich im gleichen Namespace befinden.

        • spec.providerCredentials.secretAccessKey: (required) der Zugriffsschlüssel, der für den Zugriff auf den Provider verwendet wird. Der Name sollte mit spec.providerCredentials.valueFromSecret.name übereinstimmen.

      • spec.providerType: (required) legt fest, was das Backup bereitstellt, z. B. NetApp ONTAP S3, generisches S3, Google Cloud oder Microsoft Azure. Mögliche Werte:

        • AWS

        • Azure

        • GCP

        • Generisch-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-appvault-secondary-destination.yaml haben, wenden Sie den CR an:

      kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n my-app-namespace

  7. Erstellen Sie eine AppMirrorRelationship CR-Datei:

    Erstellen Sie eine AppMirrorRelationship mithilfe eines CR

    1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-relationship.yaml).

    2. Konfigurieren Sie die folgenden Attribute:

      • metadata.name: (erforderlich) der Name der benutzerdefinierten AppMirrorRelationship-Ressource.

      • spec.destinationAppVaultRef: (required) dieser Wert muss mit dem Namen des AppVault für die Zielanwendung auf dem Zielcluster übereinstimmen.

      • spec.namespaceMapping: (required) der Ziel- und Quellnamepaces muss mit dem im jeweiligen Anwendungs-CR definierten AnwendungsNamespace übereinstimmen.

      • Spec.sourceAppVaultRef: (required) dieser Wert muss mit dem Namen des AppVault für die Quellanwendung übereinstimmen.

      • Spec.sourceApplicationName: (required) dieser Wert muss mit dem Namen der Quellanwendung übereinstimmen, die Sie in der Quellanwendung CR definiert haben.

      • Spec.storageClassName: (required) Wählen Sie den Namen einer gültigen Storage-Klasse auf dem Cluster. Die Storage-Klasse muss mit der Storage-Klasse peered werden, die auf dem Quell-Cluster verwendet wird, in dem die Quellapplikation implementiert wird.

      • Spec.recurrenceRule: Definieren Sie ein Startdatum in UTC-Zeit und ein Wiederholungsintervall.

        Beispiel YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: amr-16061e80-1b05-4e80-9d26-d326dc1953d8
  namespace: my-app-namespace
spec:
  desiredState: Established
  destinationAppVaultRef: generic-s3-trident-protect-dst-bucket-8fe0b902-f369-4317-93d1-ad7f2edc02b5
  namespaceMapping:
    - destination: my-app-namespace
      source: my-app-namespace
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  sourceAppVaultRef: generic-s3-trident-protect-src-bucket-b643cc50-0429-4ad5-971f-ac4a83621922
  sourceApplicationName: maria
  sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb
  storageClassName: sc-vsim-2

    3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-relationship.yaml haben, wenden Sie den CR an:

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    Erstellen Sie eine AppMirrorRelationship mithilfe der CLI

    1. Erstellen und wenden Sie das AppMirrorRelationship-Objekt an, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

      tridentctl protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault>

  8. (Optional) Status und Status der Replikationsbeziehung prüfen:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Failover zum Ziel-Cluster

Mit Trident Protect können Sie ein Failover replizierter Applikationen auf ein Ziel-Cluster durchführen. Durch dieses Verfahren wird die Replikationsbeziehung angehalten und die App wird auf dem Ziel-Cluster online geschaltet. Trident Protect stoppt die App auf dem Quell-Cluster nicht, wenn sie betriebsbereit war.

Schritte

  1. Öffnen Sie die AppMirrorRelationship CR-Datei (z.B. trident-protect-relationship.yaml ) und ändern Sie den Wert von spec.desiredState in Promoted.

  2. Speichern Sie die CR-Datei.

  3. CR anwenden:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  4. (Optional) Erstellen Sie alle Schutzzeitpläne, die Sie für die Failover-Anwendung benötigen.

  5. (Optional) Status und Status der Replikationsbeziehung prüfen:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Neusynchronisierung einer fehlgeschlagenen Replikationsbeziehung

Durch den Neusynchronisierung wird die Replikationsbeziehung wiederhergestellt. Nach einer Neusynchronisierung wird die ursprüngliche Quellanwendung zur laufenden Anwendung, und alle Änderungen, die an der laufenden Anwendung auf dem Zielcluster vorgenommen werden, werden verworfen.

Der Prozess stoppt die App auf dem Zielcluster, bevor die Replikation wiederhergestellt wird.

Wichtig Alle Daten, die während des Failovers auf die Zielapplikation geschrieben werden, gehen verloren.
Schritte

  1. Erstellen Sie einen Snapshot der Quellanwendung.

  2. Öffnen Sie die AppMirrorRelationship CR-Datei (z. B. trident-protect-relationship.yaml ) und ändern Sie den Wert von spec.desiredState in Established.

  3. Speichern Sie die CR-Datei.

  4. CR anwenden:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  5. Wenn Sie Schutzzeitpläne auf dem Zielcluster erstellt haben, um die Failover-Anwendung zu schützen, entfernen Sie sie. Alle Zeitpläne, die weiterhin zu Fehlern bei Volume-Snapshots führen.

Reverse Resynchronisierung einer Failover-Replizierungsbeziehung

Wenn Sie eine Failover-Replikationsbeziehung umkehren, wird die Zielanwendung zur Quellanwendung, und die Quelle wird zum Ziel. Änderungen, die während des Failovers an der Zielapplikation vorgenommen werden, werden beibehalten.

Schritte

  1. Löschen Sie die AppMirrorRelationship-CR auf dem ursprünglichen Ziel-Cluster. Dadurch wird das Ziel zur Quelle. Wenn auf dem neuen Ziel-Cluster noch Schutzpläne vorhanden sind, entfernen Sie sie.

  2. Richten Sie eine Replikationsbeziehung ein, indem Sie die CR-Dateien anwenden, die Sie ursprünglich zum Einrichten der Beziehung zu den anderen Clustern verwendet haben.

  3. Stellen Sie sicher, dass die AppVault CRS auf jedem Cluster bereit sind.

  4. Richten Sie eine Replikationsbeziehung auf dem anderen Cluster ein, und konfigurieren Sie Werte für die umgekehrte Richtung.

Richtung der Anwendungsreplikation umkehren

Wenn Sie die Replizierungsrichtung umkehren, verschiebt Trident Protect die Applikation auf das Ziel-Storage-Back-End, während die Replikation zurück zum ursprünglichen Quell-Storage-Back-End fortgesetzt wird. Trident Protect stoppt die Quellapplikation und repliziert die Daten zum Ziel, bevor ein Failover zur Zielapplikation erfolgt.

In dieser Situation tauschen Sie Quelle und Ziel aus.

Schritte

  1. Erstellen Sie einen Snapshot zum Herunterfahren:

    Erstellen Sie einen Snapshot zum Herunterfahren mit einem CR

    1. Deaktivieren Sie die Schutzrichtlinienpläne für die Quellanwendung.

    2. Erstellen Sie eine CR-Datei für den ShutdownSnapshot:

      1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie (z. B. trident-protect-shutdownsnapshot.yaml).

      2. Konfigurieren Sie die folgenden Attribute:

        • metadata.name: (required) der Name der benutzerdefinierten Ressource.

        • Spec.AppVaultRef: (required) dieser Wert muss mit dem Feld metadata.name des AppVault für die Quellanwendung übereinstimmen.

        • Spec.ApplicationRef: (required) dieser Wert muss mit dem Feld metadata.name der CR-Datei der Quellanwendung übereinstimmen.

          Beispiel YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: ShutdownSnapshot
metadata:
  name: replication-shutdown-snapshot-afc4c564-e700-4b72-86c3-c08a5dbe844e
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: maria

    3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-shutdownsnapshot.yaml haben, wenden Sie den CR an:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Erstellen Sie einen Snapshot zum Herunterfahren über die CLI

    1. Erstellen Sie den Snapshot zum Herunterfahren, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

      tridentctl protect create shutdownsnapshot <my_shutdown_snapshot> --appvault <my_vault> --app <app_to_snapshot>

  2. Nachdem der Snapshot abgeschlossen ist, rufen Sie den Status des Snapshots ab:

    kubectl get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o yaml

  3. Suchen Sie den Wert von shutdownSnapshot.Status.appArchivePath mit dem folgenden Befehl und notieren Sie den letzten Teil des Dateipfads (auch Basisname genannt; dies ist alles nach dem letzten Schrägstrich):

    k get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}'

  4. Führen Sie mit der folgenden Änderung ein Failover vom Ziel-Cluster zum Quell-Cluster durch:

    Hinweis Fügen Sie in Schritt 2 des Failover-Verfahrens das Feld in die AppMirrorRelationship CR-Datei ein spec.promotedSnapshot, und setzen Sie den Wert auf den Basisnamen, den Sie oben in Schritt 3 aufgezeichnet haben.

  5. Führen Sie die Schritte für die umgekehrte Resynchronisierung in Reverse Resynchronisierung einer Failover-Replizierungsbeziehungaus.

  6. Aktivieren Sie Schutzzeitpläne auf dem neuen Quellcluster.

Ergebnis

Die folgenden Aktionen werden aufgrund der umgekehrten Replikation durchgeführt:

  • Von den Kubernetes-Ressourcen der ursprünglichen Quell-Applikation wird ein Snapshot erstellt.

  • Die PODs der ursprünglichen Quell-App werden mit sanfter Weise gestoppt, indem die Kubernetes-Ressourcen der App gelöscht werden (wodurch PVCs und PVS aktiviert bleiben).

  • Nach dem Herunterfahren der Pods werden Snapshots der Volumes der App erstellt und repliziert.

  • Die SnapMirror Beziehungen sind beschädigt, wodurch die Zieldatenträger für Lese-/Schreibvorgänge bereit sind.

  • Die Kubernetes-Ressourcen der App werden aus dem Snapshot vor dem Herunterfahren wiederhergestellt. Dabei werden die Volume-Daten verwendet, die nach dem Herunterfahren der ursprünglichen Quell-App repliziert wurden.

  • Die Replizierung wird in umgekehrter Richtung wieder hergestellt.

Führen Sie ein Failback von Anwendungen auf das ursprüngliche Quellcluster durch

Mithilfe von Trident Protect können Sie nach einem Failover-Vorgang ein Failback durchführen, indem Sie die folgende Sequenz von Vorgängen verwenden. In diesem Workflow zur Wiederherstellung der ursprünglichen Replikationsrichtung repliziert Trident Protect alle Anwendungsänderungen zurück zur ursprünglichen Quellanwendung, bevor die Replikationsrichtung rückgängig gemacht wird.

Dieser Prozess beginnt mit einer Beziehung, bei der ein Failover zu einem Ziel durchgeführt wurde, und umfasst die folgenden Schritte:

  • Starten Sie mit einem Failover-Status fehlgeschlagen.

  • Umgekehrte Neusynchronisierung der Replikationsbeziehung.

    Achtung Führen Sie keine normale Neusynchronisierung durch, da dadurch während des Failover Daten, die auf das Ziel-Cluster geschrieben werden, verworfen werden.

  • Kehren Sie die Replikationsrichtung um.

Schritte

  1. Führen Sie die Reverse Resynchronisierung einer Failover-Replizierungsbeziehung Schritte aus.

  2. Führen Sie die Richtung der Anwendungsreplikation umkehren Schritte aus.

Löschen einer Replikationsbeziehung

Sie können eine Replikationsbeziehung jederzeit löschen. Wenn Sie die Anwendungsreplikationsbeziehung löschen, führt dies zu zwei separaten Anwendungen ohne Beziehung zwischen ihnen.

Schritte

  1. Löschen Sie die AppMirrorRelationship-CR:

    kubectl delete -f trident-protect-relationship.yaml -n my-app-namespace