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.

Informationen zu ONTAP SnapMirror asynchroner Disaster Recovery

Beitragende netapp-aaron-holt netapp-aherbin netapp-lenida netapp-dbagwell netapp-ahibbard netapp-mwallis
Änderungen vorschlagen

SnapMirror ist eine Technologie zur Notfallwiederherstellung, die für die Ausfallsicherung von primärem Speicher auf sekundären Speicher an einem geografisch entfernten Standort entwickelt wurde. Wie der Name schon sagt, erstellt SnapMirror eine Replik, also einen Spiegel, Ihrer Arbeitsdaten im sekundären Speicher, von dem aus im Katastrophenfall am primären Standort weiterhin Daten bereitgestellt werden können.

Wenn der primäre Standort weiterhin Daten bereitstellen kann, können die benötigten Daten einfach dorthin zurückübertragen werden, und es erfolgt keine Client-Bedienung mehr vom Spiegel. Wie der Failover-Anwendungsfall impliziert, sollten die Controller des sekundären Systems den Controllern des primären Systems gleichwertig oder nahezu gleichwertig sein, um Daten effizient vom gespiegelten Speicher bereitzustellen.

Datensicherungsbeziehungen

Die Daten werden auf Volume-Ebene gespiegelt. Die Beziehung zwischen dem Quell-Volume im Primärspeicher und dem Ziel-Volume im Sekundärspeicher wird als Data Protection Relationship bezeichnet. Die Cluster, in denen sich die Volumes befinden, und die SVMs, die Daten von den Volumes bereitstellen, müssen "gepeert" sein. Eine Peer-Beziehung ermöglicht den sicheren Austausch von Daten zwischen Clustern und SVMs.

Diese Abbildung veranschaulicht SnapMirror Daten­schutz­beziehungen:

SnapMirror Illustration der Datenschutzbeziehungen

Umfang der Datenschutzbeziehungen

Sie können eine Datensicherungsbeziehung direkt zwischen Volumes oder zwischen den SVMs, denen die Volumes gehören, erstellen. In einer SVM-Datensicherungsbeziehung werden die gesamte oder ein Teil der SVM-Konfiguration, von NFS-Exporten und SMB-Freigaben bis zu RBAC, sowie die Daten in den Volumes, die der SVM gehören, repliziert.

SnapMirror kann auch für spezielle Datenschutzanwendungen verwendet werden:

  • Eine Load-Sharing Mirror-Kopie des SVM-Root-Volumes stellt sicher, dass die Daten im Falle eines Node-Ausfalls oder Failover zugänglich bleiben.

  • Eine Datenschutzbeziehung zwischen SnapLock Volumes ermöglicht die Replikation von WORM-Dateien auf Sekundärspeicher.

  • Ab ONTAP 9.13.1 kann SnapMirror asynchron zum Schutz Konsistenzgruppen verwendet werden. Ab ONTAP 9.14.1 kann SnapMirror asynchron genutzt werden, um volume-granulare Snapshots mithilfe der Konsistenzgruppe an das Ziel-Cluster zu replizieren. Weitere Informationen finden sich unter Asynchrone SnapMirror Sicherung konfigurieren.

Wie SnapMirror Datenschutzbeziehungen initialisiert werden

Beim ersten Aufruf von SnapMirror erfolgt ein Basistransfer vom Quell-Volume zum Ziel-Volume. Die SnapMirror Richtlinie für die Beziehung definiert den Inhalt des Basistransfers und alle Aktualisierungen.

Ein Basistransfer gemäß der Standardrichtlinie SnapMirror MirrorAllSnapshots umfasst die folgenden Schritte:

  • Eine Momentaufnahme des Quellvolumes erstellen.

  • Der Snapshot und alle von ihm referenzierten Datenblöcke werden auf das Zielvolume übertragen.

  • Die verbleibenden, weniger aktuellen Snapshots auf dem Quellvolume werden auf das Zielvolume übertragen, damit sie im Falle einer Beschädigung des “aktiven” Spiegels verwendet werden können.

Wie SnapMirror Datenschutzbeziehungen aktualisiert werden

Aktualisierungen erfolgen asynchron gemäß dem von Ihnen konfigurierten Zeitplan. Die Aufbewahrung entspricht der Snapshot-Richtlinie auf der Quelle.

Bei jeder Aktualisierung unter der MirrorAllSnapshots Richtlinie erstellt SnapMirror einen Snapshot des Quell-Volumes und überträgt diesen Snapshot sowie alle Snapshots, die seit der letzten Aktualisierung erstellt wurden. In der folgenden Ausgabe des Befehls für die snapmirror policy show Richtlinie MirrorAllSnapshots ist Folgendes zu beachten:

  • Create Snapshot ist “true”, was bedeutet, dass MirrorAllSnapshots einen Snapshot erstellt, wenn SnapMirror die Beziehung aktualisiert.

  • MirrorAllSnapshots verfügt über die Regeln “sm_created” und “all_source_snapshots”, die darauf hinweisen, dass sowohl der von SnapMirror erstellte Snapshot als auch alle seit der letzten Aktualisierung erstellten Snapshots übertragen werden, wenn SnapMirror die Beziehung aktualisiert.

cluster_dst::> snapmirror policy show -policy MirrorAllSnapshots -instance

                     Vserver: vs0
      SnapMirror Policy Name: MirrorAllSnapshots
      SnapMirror Policy Type: async-mirror
                Policy Owner: cluster-admin
                 Tries Limit: 8
           Transfer Priority: normal
   Ignore accesstime Enabled: false
     Transfer Restartability: always
 Network Compression Enabled: false
             Create Snapshot: true
                     Comment: SnapMirror asynchronous policy for mirroring all snapshots
                              and the latest active file system.
       Total Number of Rules: 2
                  Total Keep: 2
                       Rules: SnapMirror Label     Keep  Preserve Warn Schedule Prefix
                              ----------------     ----  -------- ---- -------- ------
                              sm_created              1  false       0 -        -
                              all_source_snapshots    1  false       0 -        -

MirrorLatest Richtlinie

Die vorkonfigurierte MirrorLatest`Richtlinie funktioniert genau wie `MirrorAllSnapshots, mit der Ausnahme, dass bei der Initialisierung und Aktualisierung nur der von SnapMirror erstellte Snapshot übertragen wird.

                       Rules: SnapMirror Label     Keep  Preserve Warn Schedule Prefix
                              ----------------     ----  -------- ---- -------- ------
                              sm_created              1  false       0 -        -
Verwandte Informationen