Data Mobility beschreibt die periodische Erstellung eines konsistenten Stands der Produktivdaten an einem zweiten, räumlich entfernten Standort. Es ist daher eine geeignete Variante zur Realisierung eines Katastrophenschutz-Konzepts. Es basiert auf einer Konfiguration aus lokaler und remote Replikation in vorgegebener Konfiguration und ist, abhängig vom Einsatzszenario, eine Alternative zu synchroner und asynchroner remote Replikation.
Data Mobility beschreibt die Hard- und Software-Konfiguration zur redundanten Datenhaltung unter Anwendung gemischter Replikationsfunktionen für die Storage-Systeme ETERNUS DX/AF und Symmetrix/VMAX3.
Data Mobility verwendet Pubsets als Einheiten der Datenhaltung.
Die Steuerung der notwendigen Abläufe kann mit SHC-OSD-Kommandos in Prozeduren automatisiert werden.
Data Mobility umfasst zwei Szenarien:
Die automatische und periodische Erstellung der konsistenten Daten an einem zweiten, räumlich entfernten Standort. Der Konsistenzpunkt wird von der Anwendung definiert.
Schnelle Rekonstruktion der Daten von dem zweiten, räumlich entfernten Standort.
Die Storage-Systeme ETERNUS DX/AF dienen in den folgenden Betrachtungen als Beispiel. Die Szenarien gelten analog für Symmetrix/VMAX3-Systeme.
Ausgangskonfiguration
Die Ausgangskonfiguration ist eine Kombination von lokaler Replikation mit QuickOPC oder EC (siehe auch Abschnitt „Koexistenz von QuickOPC und EC“, „Lokale Replikation mit Clones (ETERNUS DX/AF, Symmetrix/VMAX3)") sowohl im lokalen Storage-System wie auch im remote Storage-System in Verbindung mit remote Replikation mit REC.
Erstellung der konsistenten Daten
Zur Erstellung der konsistenen Daten am zweiten, räumlich entfernten Standort wird zunächst ein Konsistenzpunkt für die Anwendung im lokalen Storage-System definiert und erstellt. An diesem Konsistenzpunkt wird in einem ersten Schritt die lokale Replikation mit QuickOPC/EC aktualisiert/unterbrochen und dadurch der konsistente Datenbestand auf der lokalen Clone-Unit gesichert. Im Anschluss daran kann die Anwendung weiter ablaufen.
Parallel dazu wird nun die lokale Clone-Unit, die gleichzeitig Source-Unit für die remote Replilkation mit REC ist, mit der Target-Unit im remote Storage-System synchronisiert.
Nach Abschluss der Synchronisation wird in einem weiteren das Schritt die Clone-Unit für QuickOPC/EC am remote Storage-System mit diesem Stand aktualisiert und anschliessend für EC auch abgetrennt. Damit ist der erstellte Datenbestand nun auf der Clone-Unit des remote Storage-Systems verfügbar.
Dieser Ablauf kann periodisch wiederholt werden. Dadurch entstehen weitere konsistente Sicherungen des Datenbestands auf Clone-Units des remote Storage-Systems.
Rekonstruktion
Die Rekonstruktion des gesicherten Datenbestandes wird von der Clone-Unit des remote Storage-Systems auf den ursprünglichen Datenträger durchgeführt.
Dafür gibt es unterschiedliche Möglichkeiten:
Rekonstruktion von der Clone-Unit im remote Storage-System direkt auf die Original-Unit im lokalen Storage-System in folgenden Schritten (empfohlene Vorgehensweise):
Auflösen der Clone-Paare im lokalen und im remote Storage-System mit
/STOP-CLONE-SESSIONRemote-Copy-Betrieb unterbrechen mit
/HOLD-REMOTE-COPYTemporäre Replikation mit REC von der Clone-Unit des remote Storage-Systems zur Original-Unit des lokalen Storage-Systems zur Synchronisierung der Datenbestände:
Remote-Copy-Paar erstellen mit
/START-REMOTE-COPY UNIT=<Clone-Unit (remote)>, TARGET-UNIT=<Original-Unit (local)>,WAIT=*UNTIL-SYNCRONIZATION
Bild 24: Data Mobility: Rekonstruktion von Clone-Unit (remote)- Remote-Copy-Betrieb unterbrechen und Pubset umbenennen mit
/HOLD-REMOTE-COPY UNIT=*BY-PUBSET(PUBSET=..., NEW-PUBSET=...)
- Temporären Remote-Copy-Betrieb beendet mit
/STOP-REMOTE-COPY
Erneuter Aufbau der Ausgangskonfiguration für Data Mobility
Vorteil dieses Konzeptes ist die schnelle Wiederherstellung der Originaldaten in einem Synchronisationsprozess mit wenigen Bearbeitungsschritten.
Nachteil dieses Konzeptes ist die Notwendigkeit einer vollständigen Kopie sowohl beim Wiederherstellen der Original-Unit als auch danach beim Wiederaufbau der ursprünglichen Konfiguration für Data Mobility.
Rekonstruktionen sind seltene Prozesse.
Fortsetzung der Anwendung(en) unter Verwendung des remote Storage-Systems als Datenbasis ohne Rekonstruktion (Umkehrung der Replikationsrichtung bei symmetrischen Konfigurationen)
Remote-Copy-Paare beenden mit
/STOP-REMOTE-COPYAnwendung neu starten, remote Storage-System verwenden
Trennen der lokalen und remote Remote-Copy-Paare
Remote-Copy-Paar erstellen mit
/START-REMOTE-COPY UNIT=<Clone-Unit (remote)>, TARGET-UNIT=<Original-Unit (local)>,WAIT=*UNTIL-SYNCRONIZATION
Bild 25: Data Mobility: symmetrische Konfiguration
Vorteil dieses Konzeptes ist die schnelle Wiederherstellung der Konfiguration für die Data Mobility.
Nachteil dieses Konzeptes kann die Verlagerung bzw. der der Neustart der Anwendung(en) sein, unter Verwendung Original-Unit im remote Storage-System als Datenbasis.
Rekonstruktion durch temporäre Umkehr der Replikationsrichtung für alle Spiegelpaare in folgenden Schritten (nur für EC):
Original- und Clone-Eigenschaft der Clone-Paare im lokalen und im remote Storage-System vertauschen mit
/SWAP-CLONE-SESSIONSource- und Target-Eigenschaft des Remote-Copy-Paares vertauschen mit
/SWAP-REMOTE-COPY
Bild 26: Data Mobility: temporäre Umkehr der ReplikationsrichtungRe-Synchronisation für alle EC- und REC-Paare starten, beginnend mit der Clone-Unit auf dem remote Storage-System.
Erneuter Aufbau der Ausgangskonfiguration für Data Mobility
Vorteil dieses Konzeptes ist es, dass sowohl für die Rekonstruktion als auch zur Wiederherstellung der Ausgangskonfiguration für die Data Mobility nur Delta-Kopien notwendig sind. Die Storage-Systeme und die remote Verbindungen werden damit nur gering belastet.
Nachteil dieses Konzeptes ist die höhere Anzahl an Bearbeitungsschritten zur Rekonstruktion der Originaldaten.