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.

Konvertieren einer vorhandenen SnapMirror Beziehung zu einer aktiven SnapMirror Synchronisierungsbeziehung

Beitragende
PDFs

Wenn Sie SnapMirror-Schutz konfiguriert haben, können Sie die Beziehung zu SnapMirror Active Sync konvertieren. Ab ONTAP 9.15.1 können Sie die Beziehung in symmetrischen aktiv/aktiv-Schutz konvertieren.

Konvertieren einer vorhandenen SnapMirror-Beziehung in eine asymmetrische SnapMirror Active Sync Beziehung

Wenn Sie über eine bestehende synchrone SnapMirror Beziehung zwischen einem Quell- und Ziel-Cluster verfügen, können Sie diese in eine asymmetrische SnapMirror Active Sync Beziehung konvertieren. Auf diese Weise können Sie die gespiegelten Volumes einer Konsistenzgruppe zuordnen, um für einen Workload mit mehreren Volumes einen RPO von null zu gewährleisten. Darüber hinaus können Sie vorhandene SnapMirror Snapshots beibehalten, wenn Sie zu einem bestimmten Zeitpunkt vor dem Herstellen der SnapMirror Active Sync Beziehung zurücksetzen müssen.

Über diese Aufgabe

  • Sie müssen ein Cluster- und SVM-Administrator auf den primären und sekundären Clustern sein.

  • Sie können keine RPO von null auf ein RTO von null konvertieren, indem Sie die SnapMirror Richtlinie ändern.

  • Sie müssen sicherstellen, dass die Zuordnung der LUNs aufgehoben wird, bevor Sie die ausgeben snapmirror create Befehl.

    Wenn vorhandene LUNs auf dem sekundären Volume zugeordnet sind, und der AutomatedFailover Policy wird konfiguriert, der snapmirror create Befehl löst einen Fehler aus.

Bevor Sie beginnen

  • Zwischen dem primären und dem sekundären Cluster muss eine synchrone SnapMirror Beziehung zum RPO von null bestehen.

  • Die Zuordnung aller LUNs auf dem Ziel-Volume muss aufgehoben werden, bevor die SnapMirror Beziehung zum RTO von null erstellt werden kann.

  • SnapMirror Active Sync unterstützt nur SAN-Protokolle (nicht NFS/CIFS). Stellen Sie sicher, dass für den NAS-Zugriff keine Komponente der Konsistenzgruppe bereitgestellt ist.

Schritte

  1. Führen Sie aus dem sekundären Cluster ein SnapMirror Update der bestehenden Beziehung durch:

    SiteB::>snapmirror update -destination-path vs1_dst:vol1

  2. Überprüfen Sie, ob das SnapMirror Update erfolgreich abgeschlossen wurde:

    SiteB::>snapmirror show

  3. Halten Sie jede der synchronen Beziehungen mit einem RPO von null an:

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol1

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol2

  4. Sie löschen jede der synchronen Beziehungen ohne RPO:

    SiteB::>snapmirror delete -destination-path vs1_dst:vol1

    SiteB::>snapmirror delete -destination-path vs1_dst:vol2

  5. Geben Sie die SnapMirror Quellbeziehung frei, behalten Sie die gemeinsamen Snapshot Kopien jedoch bei:

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2

  6. Synchrone Beziehung zwischen SnapMirror und Recovery von null auf dem NetApp RTO:

    SiteB::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailover

  7. Neusynchronisierung der Konsistenzgruppe:

    SiteB::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst

  8. Wiederherstellen aller Pfade zu den LUNs durch erneute Überprüfung der Host-LUN-I/O-Pfade

Konvertieren einer vorhandenen SnapMirror Beziehung in symmetrische aktiv/aktiv-Lösung

Ab ONTAP 9.15.1 können Sie eine vorhandene SnapMirror Beziehung in eine symmetrische aktiv/aktiv-Beziehung mit SnapMirror Active Sync konvertieren.

Bevor Sie beginnen

  • Sie müssen ONTAP 9.15.1 oder höher ausführen.

  • Zwischen dem primären und dem sekundären Cluster muss eine synchrone SnapMirror Beziehung zum RPO von null bestehen.

  • Die Zuordnung aller LUNs auf dem Ziel-Volume muss aufgehoben werden, bevor die SnapMirror Beziehung zum RTO von null erstellt werden kann.

  • SnapMirror Active Sync unterstützt nur SAN-Protokolle (nicht NFS/CIFS). Stellen Sie sicher, dass für den NAS-Zugriff keine Komponente der Konsistenzgruppe bereitgestellt ist.

Schritte

  1. Führen Sie aus dem sekundären Cluster ein SnapMirror Update der bestehenden Beziehung durch:

    SiteB::>snapmirror update -destination-path vs1_dst:vol1

  2. Überprüfen Sie, ob das SnapMirror Update erfolgreich abgeschlossen wurde:

    SiteB::>snapmirror show

  3. Halten Sie jede der synchronen Beziehungen mit einem RPO von null an:

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol1

    SiteB::>snapmirror quiesce -destination-path vs1_dst:vol2

  4. Sie löschen jede der synchronen Beziehungen ohne RPO:

    SiteB::>snapmirror delete -destination-path vs1_dst:vol1

    SiteB::>snapmirror delete -destination-path vs1_dst:vol2

  5. Geben Sie die SnapMirror Quellbeziehung frei, behalten Sie die gemeinsamen Snapshot Kopien jedoch bei:

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1

    SiteA::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2

  6. Erstellen einer synchronen SnapMirror-Beziehung mit einem RTO von null mit der AutomatiteFailoverDuplex-Richtlinie:

    SiteB::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailoverDuplex

  7. Wenn die vorhandenen Hosts lokal das primäre Cluster sind, fügen Sie den Host zum sekundären Cluster hinzu, und stellen Sie die Verbindung mit dem entsprechenden Zugriff auf jedes Cluster her.

  8. Löschen Sie am sekundären Standort die LUN-Zuordnungen der Initiatorgruppen, die Remote-Hosts zugeordnet sind.

    Hinweis Stellen Sie sicher, dass die Initiatorgruppe keine Zuordnungen für nicht replizierte LUNs enthält.

    SiteB::> lun mapping delete -vserver svm_name -igroup igroup -path <>

  9. Ändern Sie am primären Standort die Initiatorkonfiguration für vorhandene Hosts, um den proximalen Pfad für Initiatoren auf dem lokalen Cluster festzulegen.

    SiteA::> igroup initiator add-proximal-vserver -vserver svm_name -initiator host -proximal-vserver server

  10. Fügen Sie eine neue Initiatorgruppe und einen neuen Initiator für die neuen Hosts hinzu und legen Sie die Host-Nähe für die Host-Affinität zu ihrem lokalen Standort fest. Ennable-igroup-Replikation zur Replikation der Konfiguration und Invertierung der Hostlokalität auf dem Remote-Cluster.


    SiteA::> igroup modify -vserver vsA -igroup ig1 -replication-peer vsB
    SiteA::> igroup initiator add-proximal-vserver -vserver vsA -initiator host2 -proximal-vserver vsB

  11. Ermitteln Sie die Pfade auf den Hosts und überprüfen Sie, ob die Hosts über einen aktiv/optimierten Pfad zur Storage-LUN vom bevorzugten Cluster verfügen

  12. Implementieren Sie die Applikation und verteilen Sie die VM-Workloads über Cluster hinweg.

  13. Neusynchronisierung der Konsistenzgruppe:

    SiteB::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst

  14. Wiederherstellen aller Pfade zu den LUNs durch erneute Überprüfung der Host-LUN-I/O-Pfade