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.

Volumes mit SnapMirror replizieren

Beitragende netapp-aruldeepa
PDFs

Trident unterstützt Spiegelungsbeziehungen zwischen einem Quellvolume auf einem Cluster und dem Zielvolume auf dem verbundenen Cluster zur Datenreplikation für die Notfallwiederherstellung.   Sie können eine namens Trident Mirror Relationship (TMR) mit einem Namensraum verwenden, um die folgenden Operationen durchzuführen:

  • Spiegelbeziehungen zwischen Volumina (PVCs) erzeugen

  • Spiegelbeziehungen zwischen Volumen entfernen

  • Zerstöre die Spiegelbeziehungen

  • Förderung des sekundären Datenvolumens während Katastrophensituationen (Ausfallereignisse).

  • 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 *: Auf den Quell- und Ziel-Kubernetes-Clustern, die ONTAP als Backend verwenden, muss Trident Version 22.10 oder höher vorhanden sein.

  • Lizenzen: ONTAP SnapMirror -Asynchronlizenzen, die das Data Protection-Bundle verwenden, müssen sowohl auf dem Quell- als auch auf dem Ziel ONTAP -Cluster aktiviert sein. Siehe "SnapMirror -Lizenzübersicht in ONTAP" für weitere Informationen.

    Ab ONTAP 9.10.1 werden alle Lizenzen als NetApp Lizenzdatei (NLF) ausgeliefert. Dabei handelt es sich um eine einzelne Datei, die mehrere Funktionen aktiviert. Siehe"In ONTAP One enthaltene Lizenzen" für weitere Informationen.

    Hinweis Es wird ausschließlich der asynchrone Schutz von SnapMirror unterstützt.
Peering

  • Cluster und SVM: Die ONTAP -Speicher-Backends müssen per Peering verbunden sein. Siehe "Cluster- und SVM-Peering-Übersicht" für weitere Informationen.

    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 Zielcluster verfügbar sein.

Unterstützte Treiber

NetApp Trident unterstützt die Volume-Replikation mit der NetApp SnapMirror -Technologie unter Verwendung von Speicherklassen, 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. Informationen zu ASA r2-Systemen finden Sie unter"Erfahren Sie mehr über ASA R2-Speichersysteme" .

Erstellen Sie ein spiegelndes PVC

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

Schritte

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

    1. Erstellen Sie 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 einer zuvor erstellten 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 der MirrorRelationship aus.

    4. Ermitteln Sie mithilfe der TridentMirrorRelationship CR den internen Namen und die SVM der PVC.

      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 durch:

    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 eine 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 erstellt eine SnapMirror Beziehung mit dem konfigurierten Beziehungsrichtliniennamen (oder dem Standardnamen für ONTAP) und initialisiert diese.

    3. Erstellen Sie eine PVC mit einer zuvor erstellten StorageClass, die als sekundäres Ziel (SnapMirror Ziel) fungieren soll.

      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 fehl, das Volume zu erstellen, wenn die Beziehung nicht existiert. Wenn die Beziehung besteht, sorgt Trident dafür, dass das neue FlexVol volume auf einer SVM platziert wird, die mit der in der MirrorRelationship definierten Remote-SVM verbunden ist.

Volumenreplikationszustände

Eine Trident Mirror Relationship (TMR) ist eine CRD, die ein Ende einer Replikationsbeziehung zwischen PVCs darstellt. Das Ziel-TMR verfügt über einen Zustand, der Trident mitteilt, welcher Zustand gewünscht ist. Das Ziel-TMR hat folgende Zustände:

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

  • Verbessert: Die lokale PVC ist lesbar und beschreibbar und kann eingebunden werden; derzeit besteht keine Spiegelungsbeziehung.

  • Wiederhergestellt: Das lokale PVC ist das Zielvolumen einer Spiegelbeziehung und war auch zuvor Teil dieser Spiegelbeziehung.

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

    • Der wiederhergestellte Zustand schlägt fehl, wenn das Volumen zuvor nicht in Beziehung zur Quelle stand.

Förderung der sekundären PVC-Funktion bei einem ungeplanten Ausfall

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

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

Sekundäre PVC während eines geplanten Ausfalls fördern

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

Schritte

  1. Auf dem primären Kubernetes-Cluster wird ein Snapshot des PVC erstellt und gewartet, bis der Snapshot erstellt ist.

  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 internen Namen des Snapshots.

  4. Bestätigen Sie auf dem sekundären Kubernetes-Cluster, dass der Status (status.state-Feld) der TridentMirrorRelationship auf „promoted“ gesetzt ist.

Nach einem Failover eine Spiegelbeziehung wiederherstellen

Bevor Sie die Spiegelbeziehung wiederherstellen, wählen Sie die Seite aus, die Sie zur neuen primären Seite machen möchten.

Schritte

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

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

Zusätzliche Operationen

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

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

Stellen Sie sicher, dass Sie bereits einen primären PVC-Anschluss und einen sekundären PVC-Anschluss 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 die neue sekundäre (Ziel-)PVC, die Sie einrichten möchten.

Ändern der 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 aus 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 eine PVC (die 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 gespiegelten Beziehung führt dazu, dass der verbleibende TMR in den Status promoted wechselt, bevor Trident den Löschvorgang abschließt. Wenn sich das zum Löschen ausgewählte TMR bereits im Status promoted befindet, besteht keine Spiegelbeziehung und das TMR wird entfernt. Trident wird dann den lokalen PVC auf ReadWrite hochstufen. Durch diese Löschung werden SnapMirror Metadaten für das lokale Volume in ONTAP freigegeben. Wenn dieses Volume in Zukunft in einer Spiegelbeziehung verwendet wird, muss beim Erstellen der neuen Spiegelbeziehung ein neues TMR mit einem etablierten Volume-Replikationsstatus verwendet werden.

Spiegelbeziehungen aktualisieren, wenn ONTAP online ist

Spiegelbeziehungen können jederzeit nach ihrer Einrichtung aktualisiert werden. Sie können die state: promoted oder state: reestablished Felder, um die Beziehungen zu aktualisieren. Beim Hochstufen eines Zielvolumes zu einem regulären ReadWrite-Volume 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 haben muss. Beachten Sie das folgende Beispielformat für 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 Zustand des TridentActionMirrorUpdate CRD wider. Es kann einen Wert von Succeeded, In Progress oder Failed annehmen.