Storage-Cluster und relevante SVMs müssen aktiviert werden.

Der ONTAP Mediator muss auf beiden Storage-Clustern verfügbar und konfiguriert sein.

In der ONTAP-Dokumentation "Übersicht über die aktive SnapMirror-Synchronisierung in ONTAP" wird das Konzept der Konsistenzgruppen mit SnapMirror Active Sync wie folgt beschrieben:

Eine Konsistenzgruppe ist eine Sammlung von FlexVol Volumes, die eine Konsistenzgarantie für den Applikations-Workload bietet, der für Business Continuity geschützt werden muss.

Der Zweck einer Konsistenzgruppe besteht darin, gleichzeitige Snapshot Images mehrerer Volumes zu erstellen. Auf diese Weise wird sichergestellt, dass absturzkonsistente Kopien einer Sammlung von Volumes zu einem Zeitpunkt erstellt werden. Eine Konsistenzgruppe stellt sicher, dass alle Volumes eines Datensatzes stillgelegt und dann zu genau dem gleichen Zeitpunkt eingerastet werden. So erhalten Sie einen datenkonsistenten Restore-Zeitpunkt über Volumes hinweg, der den Datensatz unterstützt. Eine Konsistenzgruppe behält dabei die abhängige Konsistenz der Schreibreihenfolge bei. Wenn Sie Applikationen für Business Continuity schützen möchten, muss die Volume-Gruppe, die dieser Applikation entspricht, einer Konsistenzgruppe hinzugefügt werden, damit eine Datensicherungsbeziehung zwischen einer Quell- und einer Zielkonsistenzgruppe hergestellt wird. Die Quell- und Zielkonsistenz muss die gleiche Anzahl und den gleichen Typ von Volumes enthalten.

Für die Replizierung von HANA-Systemen muss die Konsistenzgruppe alle Volumes enthalten, die vom einzelnen HANA-System verwendet werden (Daten, Protokoll und Shared). Volumes, die Teil einer Konsistenzgruppe sein sollten, müssen auf derselben SVM gespeichert werden. Betriebssystem-Images können auf einem separaten Volume mit einer eigenen Konsistenzgruppe gespeichert werden. Die Abbildung unten zeigt ein Konfigurationsbeispiel mit zwei HANA-Systemen.

In unserem Lab-Setup haben wir eine Initiatorgruppe erstellt, die beide Storage-SVMs für die aktive synchrone Replizierung mit SnapMirror verwendet. In der später beschriebenen Konfiguration für aktive SnapMirror-Synchronisierung wird festgelegt, dass die Initiatorgruppe Teil der Replizierung ist.

Mithilfe der Annäherungseinstellungen wurde festgelegt, welcher ESX Host sich in der Nähe des Storage-Clusters befindet. In unserem Fall liegt die A700 in der Nähe von ESX-1 und die A800 ist nah an ESX-2.

Der Datastore, in dem die OS-Images des HANA-Systems, SnapCenter und das vSphere Plug-in gespeichert werden, wird in der gleichen Weise repliziert wie bei den HANA-Datenbankdatenspeichern beschrieben.

Das aktive Synchronisierungsverhalten von SnapMirror ist symmetrisch, mit einer wichtigen Ausnahme: Konfiguration des primären Standorts.

SnapMirror Active Sync betrachtet einen Standort als „Quelle“ und den anderen als „Ziel“. Dies impliziert eine One-Way-Replikationsbeziehung, aber dies gilt nicht für das IO-Verhalten. Die Replizierung ist bidirektional und symmetrisch, und die I/O-Reaktionszeiten sind auf beiden Seiten der Spiegelung identisch.

Wenn die Replikationsverbindung verloren geht, stellen die LUN-Pfade auf der Quellkopie weiterhin Daten bereit, während die LUN-Pfade auf der Zielkopie erst dann nicht mehr verfügbar sind, wenn die Replikation wiederhergestellt ist und SnapMirror wieder in den synchronen Zustand wechselt. Die Pfade setzen dann das Bereitstellen von Daten fort.

Der Effekt der Festlegung eines Clusters als Quelle steuert einfach, welches Cluster als Lese-/Schreib-Speichersystem überlebt, wenn die Replikationsverbindung verloren geht.

Der primäre Standort wird von SnapCenter erkannt und zur Durchführung von Backup-, Wiederherstellungs- und Klonvorgängen verwendet.