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

01/28/2025 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 Volume-granulare Snapshots auf den 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 Sie einen Snapshot des Quell-Volumes.
Übertragen Sie den Snapshot und alle Datenblöcke, die er auf das Ziel-Volume verweist.
Übertragen Sie die verbleibenden, weniger aktuellen Snapshots auf dem Quellvolume auf das Zielvolume für den Fall, dass der „Active“-Spiegel 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 einen Snapshot des Quell-Volumes und überträgt diesen Snapshot sowie alle Snapshots, die seit der letzten Aktualisierung erstellt wurden. snapmirror policy show `MirrorAllSnapshots`Beachten Sie in der folgenden Ausgabe des Befehls für die Richtlinie Folgendes:

Create Snapshot Ist „true“ und zeigt an, dass MirrorAllSnapshots ein Snapshot erstellt wird, 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 Snapshots, die seit der letzten Aktualisierung erstellt wurden, ü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 der von SnapMirror erstellte Snapshot bei der Initialisierung und Aktualisierung übertragen wird.

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