Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Volumes replizieren mit SnapMirror

Änderungen vorschlagen
PDFs

Trident unterstützt Spiegelungsbeziehungen zwischen einem Quellvolume in einem Cluster und dem Zielvolume im verbundenen Cluster zur Datenreplikation für die Notfallwiederherstellung.  Sie können eine namensbasierte Custom Resource Definition (CRD), genannt Trident Mirror Relationship (TMR), verwenden, um die folgenden Operationen durchzuführen:

  • Spiegelbeziehungen zwischen Volumes (PVCs) erstellen

  • Spiegelbeziehungen zwischen Volumes entfernen

  • Spiegelbeziehungen aufheben

  • Das sekundäre Volume während Katastrophenbedingungen (Failover) promoten

  • Führen Sie einen verlustfreien Übergang von Anwendungen von Cluster zu Cluster durch (während geplanter Failover oder Migrationen)

Replikationsvoraussetzungen

Stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind, bevor Sie beginnen:

ONTAP Cluster

  • Trident: Trident Version 22.10 oder höher muss auf beiden Quell- und Ziel-Kubernetes-Clustern vorhanden sein, die ONTAP als Backend nutzen.

  • Lizenzen: ONTAP SnapMirror asynchrone Lizenzen mit dem Data Protection Bundle müssen sowohl auf dem Quell- als auch auf dem Ziel-ONTAP-Cluster aktiviert sein. Weitere Informationen finden Sie unter "SnapMirror Lizenzierungsübersicht in ONTAP".

    Ab ONTAP 9.10.1 werden alle Lizenzen als NetApp Lizenzdatei (NLF) bereitgestellt, bei der es sich um eine einzelne Datei handelt, die mehrere Funktionen aktiviert. Weitere Informationen finden Sie unter "In ONTAP One enthaltene Lizenzen".

    Hinweis Es wird ausschließlich SnapMirror asynchroner Schutz unterstützt.
Peering

  • Cluster und SVM: Die ONTAP-Speicher-Backends müssen per Peering verbunden sein. Weitere Informationen finden Sie unter "Cluster- und SVM-Peering-Übersicht".

    Wichtig Stellen Sie sicher, dass die in der Replikationsbeziehung zwischen zwei ONTAP Clustern verwendeten SVM-Namen eindeutig sind.

  • Trident und SVM: Die verbundenen Remote-SVMs müssen für Trident auf dem Ziel-Cluster verfügbar sein.

Unterstützte Treiber

NetApp Trident unterstützt die Volume-Replikation mit NetApp SnapMirror-Technologie unter Verwendung von Storage-Klassen, die von den folgenden Treibern unterstützt werden: ontap-nas: NFS ontap-san: iSCSI ontap-san: FC ontap-san: NVMe/TCP (erfordert mindestens ONTAP Version 9.15.1)

Hinweis Die Volume-Replikation mit SnapMirror wird für ASA r2-Systeme nicht unterstützt. Weitere Informationen zu ASA r2-Systemen finden Sie unter "Erfahren Sie mehr über ASA r2-Speichersysteme".

Erstellen Sie ein gespiegeltes PVC

Folgen Sie diesen Schritten und verwenden Sie die CRD-Beispiele, um eine Spiegelbeziehung zwischen primären und sekundären Volumes zu erstellen.

Schritte

  1. Führen Sie die folgenden Schritte auf dem primären Kubernetes-Cluster aus:

    1. Erstelle ein StorageClass Objekt mit dem trident.netapp.io/replication: true Parameter.

      Beispiel
      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-nas
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "nfs"
  trident.netapp.io/replication: "true"

    2. Erstellen Sie eine PVC mit zuvor erstellter StorageClass.

      Beispiel
      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: csi-nas
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-nas

    3. Erstellen Sie eine MirrorRelationship CR mit lokalen Informationen.

      Beispiel
      kind: TridentMirrorRelationship
apiVersion: trident.netapp.io/v1
metadata:
  name: csi-nas
spec:
  state: promoted
  volumeMappings:
  - localPVCName: csi-nas

      Trident ruft die internen Informationen für das Volume und den aktuellen Datenschutzstatus (DP) des Volumes ab und füllt dann das Statusfeld des MirrorRelationship.

    4. Rufen Sie das TridentMirrorRelationship CR ab, um den internen Namen und die SVM des PVC zu erhalten.

      kubectl get tmr csi-nas
      kind: TridentMirrorRelationship
apiVersion: trident.netapp.io/v1
metadata:
  name: csi-nas
  generation: 1
spec:
  state: promoted
  volumeMappings:
  - localPVCName: csi-nas
status:
  conditions:
  - state: promoted
    localVolumeHandle: "datavserver:trident_pvc_3bedd23c_46a8_4384_b12b_3c38b313c1e1"
    localPVCName: csi-nas
    observedGeneration: 1

  2. Führen Sie die folgenden Schritte auf dem sekundären Kubernetes-Cluster aus:

    1. Erstellen Sie eine StorageClass mit dem Parameter trident.netapp.io/replication: true.

      Beispiel
      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-nas
provisioner: csi.trident.netapp.io
parameters:
  trident.netapp.io/replication: true

    2. Erstellen Sie ein MirrorRelationship CR mit Ziel- und Quellinformationen.

      Beispiel
      kind: TridentMirrorRelationship
apiVersion: trident.netapp.io/v1
metadata:
  name: csi-nas
spec:
  state: established
  volumeMappings:
  - localPVCName: csi-nas
    remoteVolumeHandle: "datavserver:trident_pvc_3bedd23c_46a8_4384_b12b_3c38b313c1e1"

      Trident wird eine SnapMirror Beziehung mit dem konfigurierten Beziehungsrichtliniennamen (oder dem Standardnamen für ONTAP) erstellen und initialisieren.

    3. Erstellen Sie eine PVC mit zuvor erstellter StorageClass, um als sekundäres (SnapMirror Ziel) zu fungieren.

      Beispiel
      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: csi-nas
  annotations:
    trident.netapp.io/mirrorRelationship: csi-nas
spec:
  accessModes:
  - ReadWriteMany
resources:
  requests:
    storage: 1Gi
storageClassName: csi-nas

      Trident prüft, ob die TridentMirrorRelationship CRD vorhanden ist, und schlägt die Erstellung des Volumes fehl, falls die Beziehung nicht existiert. Wenn die Beziehung besteht, stellt Trident sicher, dass das neue FlexVol volume auf einer SVM platziert wird, die mit der Remote-SVM, die in der MirrorRelationship definiert ist, verbunden ist.

Volumenreplikationszustände

Eine Trident Mirror Relationship (TMR) ist eine CRD, die ein Ende einer Replikationsbeziehung zwischen PVCs darstellt. Die Ziel-TMR hat einen Zustand, der Trident den gewünschten Zustand mitteilt. Die Ziel-TMR hat die folgenden Zustände:

  • Festgestellt: Das lokale PVC ist das Zielvolume einer SnapMirror Beziehung, und dies ist eine neue Beziehung.

  • Promoted: Die lokale PVC ist ReadWrite und mountbar, es besteht derzeit keine Spiegelbeziehung.

  • Wiederhergestellt: Das lokale PVC ist das Zielvolume einer SnapMirror Beziehung und war auch zuvor in dieser SnapMirror Beziehung.

    • Der wiederhergestellte Zustand muss verwendet werden, wenn das Zielvolume jemals in einer Beziehung mit dem Quellvolume stand, da er den Inhalt des Zielvolumes überschreibt.

    • Der wiederhergestellte Zustand schlägt fehl, wenn das Volume zuvor nicht in einer Beziehung mit der Quelle stand.

Sekundäres PVC während eines ungeplanten Failovers promoten

Führen Sie den folgenden Schritt auf dem sekundären Kubernetes-Cluster durch:

  • Aktualisiere das Feld spec.state von TridentMirrorRelationship auf promoted.

Sekundäre PVC während eines geplanten Failovers promoten

Führen Sie während eines geplanten Failovers (Migration) die folgenden Schritte aus, um den sekundären PVC zu promoten:

Schritte

  1. Erstellen Sie im primären Kubernetes-Cluster einen Snapshot des PVC und warten Sie, bis der Snapshot erstellt wurde.

  2. Erstellen Sie auf dem primären Kubernetes-Cluster die SnapshotInfo CR, um interne Details zu erhalten.

    Beispiel
    kind: SnapshotInfo
apiVersion: trident.netapp.io/v1
metadata:
  name: csi-nas
spec:
  snapshot-name: csi-nas-snapshot

  3. Aktualisieren Sie auf dem sekundären Kubernetes-Cluster das Feld spec.state der TridentMirrorRelationship CR auf promoted und spec.promotedSnapshotHandle auf den internalName des Snapshots.

  4. Bestätigen Sie auf dem sekundären Kubernetes-Cluster den Status (status.state-Feld) von TridentMirrorRelationship auf promoted.

Eine Spiegelbeziehung nach einem Failover wiederherstellen

Bevor Sie die Spiegelbeziehung wiederherstellen, wählen Sie die Seite aus, die Sie als neue primäre Seite festlegen möchten.

Schritte

  1. Stellen Sie auf dem sekundären Kubernetes-Cluster sicher, dass die Werte für das Feld spec.remoteVolumeHandle auf der TridentMirrorRelationship aktualisiert werden.

  2. Aktualisieren Sie auf dem sekundären Kubernetes-Cluster das Feld spec.mirror von TridentMirrorRelationship auf reestablished.

Zusätzliche Operationen

Trident unterstützt die folgenden Operationen auf den primären und sekundären Volumes:

Primäres PVC auf ein neues sekundäres PVC replizieren

Stellen Sie sicher, dass Sie bereits ein primäres PVC und ein sekundäres PVC haben.

Schritte

  1. Löschen Sie die PersistentVolumeClaim und TridentMirrorRelationship CRDs aus dem eingerichteten sekundären (Ziel-)Cluster.

  2. Löschen Sie die TridentMirrorRelationship CRD aus dem primären (Quell-)Cluster.

  3. Erstellen Sie eine neue TridentMirrorRelationship CRD auf dem primären (Quell-)Cluster für das neue sekundäre (Ziel-)PVC, das Sie einrichten möchten.

Ändern Sie die Größe eines gespiegelten, primären oder sekundären PVC

Die PVC-Größe kann wie gewohnt angepasst werden, ONTAP erweitert automatisch alle Ziel-Flevxols, wenn die Datenmenge die aktuelle Größe überschreitet.

Replikation von einem PVC entfernen

Um die Replikation zu entfernen, führen Sie eine der folgenden Operationen auf dem aktuellen sekundären Volume durch:

  • Löschen Sie die MirrorRelationship auf dem sekundären PVC. Dadurch wird die Replikationsbeziehung unterbrochen.

  • Oder aktualisieren Sie das Feld spec.state auf promoted.

Löschen Sie ein PVC (das zuvor gespiegelt wurde)

Trident prüft, ob PVCs repliziert sind, und gibt die Replikationsbeziehung frei, bevor versucht wird, das Volume zu löschen.

Löschen eines TMR

Das Löschen eines TMR auf einer Seite einer Spiegelungsbeziehung führt dazu, dass der verbleibende TMR in den Status promoted wechselt, bevor Trident den Löschvorgang abschließt. Befindet sich der zum Löschen ausgewählte TMR bereits im Status promoted, besteht keine Spiegelungsbeziehung mehr, der TMR wird entfernt und Trident stuft den lokalen PVC auf ReadWrite hoch. Durch diese Löschung werden SnapMirror-Metadaten für das lokale Volume in ONTAP freigegeben. Wird dieses Volume zukünftig in einer Spiegelungsbeziehung verwendet, muss beim Erstellen der neuen Spiegelungsbeziehung ein neuer TMR mit einem established Volume-Replikationsstatus verwendet werden.

Spiegelbeziehungen aktualisieren, wenn ONTAP online ist

Spiegelungsbeziehungen können jederzeit nach ihrer Einrichtung aktualisiert werden. Sie können die Felder state: promoted oder state: reestablished verwenden, um die Beziehungen zu aktualisieren. Wenn Sie ein Zielvolume zu einem regulären ReadWrite-Volume hochstufen, können Sie mit promotedSnapshotHandle einen bestimmten Snapshot angeben, auf den das aktuelle Volume wiederhergestellt werden soll.

Spiegelbeziehungen aktualisieren, wenn ONTAP offline ist

Sie können eine CRD verwenden, um ein SnapMirror-Update durchzuführen, ohne dass Trident eine direkte Verbindung zum ONTAP-Cluster benötigt. Beachten Sie das folgende Beispielformat von TridentActionMirrorUpdate:

Beispiel
apiVersion: trident.netapp.io/v1
kind: TridentActionMirrorUpdate
metadata:
  name: update-mirror-b
spec:
  snapshotHandle: "pvc-1234/snapshot-1234"
  tridentMirrorRelationshipName: mirror-b

status.state spiegelt den Status der TridentActionMirrorUpdate CRD wider. Es kann den Wert Succeeded, In Progress oder Failed annehmen.