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.

Grundlagen der asynchronen Disaster Recovery von SnapMirror

Beitragende
PDFs

SnapMirror ist eine Disaster Recovery-Technologie für den Failover von primärem Storage zu sekundärem Storage an einem geografisch verteilten Standort. Wie der Name schon andeutet, erstellt SnapMirror ein Replikat, oder Mirror Ihrer Arbeitsdaten im Sekundärspeicher, von dem Sie im K-Fall am primären Standort weiter Daten bereitstellen können.

Wenn der primäre Standort weiterhin Daten versorgen kann, können Sie einfach alle benötigten Daten zurück darauf übertragen und nicht Clients vom Spiegel bedienen. Wie der Anwendungsfall für Failover impliziert, sollten die Controller auf dem sekundären System äquivalent oder fast vergleichbar mit den Controllern auf dem Primärsystem sein, um Daten effizient aus dem gespiegelten Storage bereitzustellen.

Datensicherungsbeziehungen

Daten werden auf Volume-Ebene gespiegelt. Die Beziehung zwischen dem Quell-Volume im primären Storage und dem Ziel-Volume im sekundären Storage wird als „Data Protection Relationship“ bezeichnet. die Cluster, in denen sich die Volumes befinden, und die SVMs, die Daten aus den Volumes bereitstellen, müssen peering durchgeführt werden. Eine Peer-Beziehung ermöglicht den Austausch von Clustern und SVMs Sicher aus Daten.

"Cluster- und SVM-Peering"

In der folgenden Abbildung werden SnapMirror Datensicherungsbeziehungen dargestellt.

Abbildung zu SnapMirror Datensicherungsbeziehungen

Umfang Datensicherungsbeziehungen

Sie können eine Datensicherungsbeziehung direkt zwischen Volumes oder zwischen den SVMs, die Eigentümer der Volumes sind, erstellen. In einer Datensicherungsbeziehung mit SVM, die vollständig oder teilweise von der SVM-Konfiguration, von NFS-Exporten und SMB-Freigaben bis hin zur rollenbasierten Zugriffssteuerung, repliziert wird, sowie die Daten in den Volumes, die die SVM besitzt.

SnapMirror kann auch für besondere Datensicherungsapplikationen eingesetzt werden:

  • Eine Load-Sharing-Mirror Kopie des SVM Root-Volume stellt sicher, dass im Falle eines Node-Ausfalls oder eines Failover auf die Daten zugegriffen werden kann.

  • Eine Datensicherungsbeziehung zwischen SnapLock Volumes ermöglicht es Ihnen, WORM-Dateien in den Sekundärspeicher zu replizieren.

    "Archivierung und Compliance mit SnapLock Technologie"

  • Ab ONTAP 9.13.1 können Sie SnapMirror asynchron zum Schutz verwendenKonsistenzgruppen. Ab ONTAP 9.14.1 können Sie SnapMirror asynchron verwenden, um mithilfe der Konsistenzgruppenbeziehung Snapshots mit Volume-Granularität auf das Ziel-Cluster zu replizieren. Weitere Informationen finden Sie unter Konfigurieren Sie die asynchrone Sicherung von SnapMirror.

So werden die SnapMirror Datensicherungsbeziehungen initialisiert

Beim ersten Aufruf von SnapMirror führt es einen Baseline-Transfer vom Quell-Volume zum Ziel-Volume durch. Die Richtlinie SnapMirror für die Beziehung definiert den Inhalt der Baseline und alle Updates.

Ein Basistransfer gemäß der standardmäßigen SnapMirror-Richtlinie MirrorAllSnapshots umfasst die folgenden Schritte:

  • Erstellen einer Snapshot Kopie des Quell-Volume

  • Übertragen Sie die Snapshot Kopie und alle Datenblöcke, auf die sie auf das Ziel-Volume verweist.

  • Übertragen Sie die verbleibenden, weniger aktuellen Snapshot Kopien auf dem Quell-Volume auf das Ziel-Volume, falls die „aktive“-Spiegelung beschädigt ist.

Aktualisierung von SnapMirror Datensicherungsbeziehungen

Updates werden asynchron und folgen dem von Ihnen konfigurierten Zeitplan. Die Aufbewahrung spiegelt die Snapshot-Richtlinie auf der Quelle.

Bei jeder Aktualisierung im Rahmen der MirrorAllSnapshots Richtlinie erstellt SnapMirror eine Snapshot Kopie des Quell-Volume und überträgt diese Snapshot Kopie sowie alle seit der letzten Aktualisierung erstellten Snapshot Kopien. snapmirror policy show `MirrorAllSnapshots`Beachten Sie in der folgenden Ausgabe des Befehls für die Richtlinie Folgendes:

  • Create Snapshot Ist „true“. Dies gibt an MirrorAllSnapshots, dass beim Aktualisieren der Beziehung durch SnapMirror eine Snapshot Kopie erstellt wird.

  • MirrorAllSnapshots Verfügt über die Regeln „sm_created“ und „all_source_Snapshots“, die angeben, dass sowohl die von SnapMirror erstellte Snapshot Kopie als auch alle seit der letzten Aktualisierung erstellten Snapshot Kopien ü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 so wie MirrorAllSnapshots, außer dass nur die von SnapMirror erstellte Snapshot Kopie bei der Initialisierung und dem Update übertragen wird.

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