Wenn die Clone-Unit eine vollständige Kopie der Original-Unit ist, stehen die vollständigen Daten auf der Clone-Unit einer Anwendung zur Verfügung. Während eine Anwendung mit den Daten auf der Original-Unit arbeitet, kann eine andere Anwendung die kopierten Daten auf der Clone-Unit benutzen. Wenn mehr als zwei Anwendungen Zugriff auf die Daten haben sollen, können mehrere Clone-Sessions eingerichtet werden, so dass jede Anwendung mit eigenen Daten arbeitet.
Im BS2000-Umfeld geht es hauptsächlich darum, die Daten eines Pubsets zu verarbeiten oder zu sichern. In diesem Abschnitt wird deshalb stets davon ausgegangen, dass vollständige Pubsets bearbeitet und homogen gespiegelt/kopiert werden. Eine Kopie der Daten eines Pubsets entsteht auf den Clone-Units, die den Original-Units des Pubsets zugeordnet sind. Vereinfachend werden die Clone-Units eines Pubsets ein Clone-Pubset genannt.
Ein Clone-Pubset aus abgetrennten Clone-Units sollte grundsätzlich umbenannt werden.
Verarbeitung der Daten durch mehrere Anwendungen
Bei dieser Nutzung wird davon ausgegangen, dass eine Anwendung die Daten des Pubsets auf den Original-Units verarbeitet. In der Regel wird dies die Hauptanwendung mit den längsten Zugriffszeiten und dem größten Änderungsvolumen sein. Für jede weitere Anwendung, die auf die Daten zugreifen soll, wird eine eigene Clone Session eingerichtet. Bevor eine Anwendung auf die Daten zugreift, findet eine Synchronisation zwischen Original- und Clone-Units statt.
Beispiel für QuickOPC
Pubset A umfasst drei Units. Neben der Hauptanwendung („Main“) greifen sporadisch zwei weitere Anwendungen („Save“ und „Report“) auf die Daten des Pubsets A zu. Es werden zwei Clone-Sessions gestartet.
Im Normalbetrieb greift nur die Hauptanwendung „Main“ auf die Daten zu. Wenn nun die Anwendung „Save“ auf die Daten zugreifen will, wird die Clone-Session gestartet. Die Clone-Units werden automatisch aktiviert. Der Pubset wird umbenannt (zuvor sollte ein Konsistenzpunkt erstellt werden, siehe "Clone-Paare aktivieren"):
/START-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(2000,2001,2002)
Die Anwendung „Save“ kann nun unmittelbar auf die Daten des Clone-Pubsets B zugreifen. Dabei handelt es sich um die Original-Daten zum Zeitpunkt der Aktivierung. Nach Abschluss des Zugriffs bleibt die Clone-Session unverändert.
Wenn die Anwendung „Save“ wieder auf die aktualisierten Daten zugreifen soll, wird das Kommando /RESTART-CLONE-SESSION eingegeben:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=B)
Der Ablauf für die Anwendung „Report“ ist analog, nur dass hier der Clone-Pubset-Name C ist:
/START-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(1000,1001,1002)
Zur Aktualisierung der Daten auf den Clone-Units:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=C)
Die Anwendungen „Main“, „Save“ und „Report“ greifen relativ unabhängig voneinander auf die Daten zu. Unterbrechungen entstehen nur dann, wenn vor einem Kommando /RESTART-CLONE-SESSION ein Konsistenzpunkt erstellt wird.
Beispiel für EC und TimeFinder/Clone
Pubset A umfasst drei Units. Neben der Hauptanwendung („Main“) greifen sporadisch zwei weitere Anwendungen („Save“ und „Report“) auf die Daten des Pubsets A zu. Es werden zwei Clone-Sessions gestartet:
/START-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=(2000,2001,2002)
/START-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=(1000,1001,1002)
Im Normalbetrieb greift nur die Hauptanwendung „Main“ auf die Daten zu. Wenn nun die Anwendung „Save“ auf die Daten zugreifen will, werden die Clone-Units einer Session aktiviert. Dabei wird der Pubset umbenannt (zuvor sollte ein Konsistenzpunkt erstellt werden, siehe "Clone-Paare aktivieren"):
/ACTIVATE-CLONE UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(2000,2001,2002)
Die Anwendung „Save“ kann nun unmittelbar auf die Daten des Clone-Pubsets B zugreifen. Dabei handelt es sich um die Original-Daten zum Zeitpunkt der Aktivierung. Nach Abschluss des Zugriffs wird die Clone-Session erneut gestartet, damit die Daten zwischen Original- und Clone-Units wieder synchronisiert werden:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=B)
Wenn die Anwendung „Save“ wieder auf die aktualisierten Daten zugreifen soll, wird das Kommando /ACTIVATE-CLONE erneut eingegeben.
Der Ablauf für die Anwendung „Report“ ist analog, nur dass hier der Clone-Pubset-Name C ist:
/ACTIVATE-CLONE UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(1000,1001,1002)
Nach Beendigung der Anwendung:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=C)
Die Anwendungen „Main“, „Save“ und „Report“ greifen relativ unabhängig voneinander auf die Daten zu. Unterbrechungen entstehen nur dann, wenn vor einem Kommando /ACTIVATE-CLONE ein Konsistenzpunkt erstellt wird.
Clone-Units mit QuickOPC, EC und TimeFinder/Clone
QuickOPC, EC und TimeFinder/Clone können in gleicher Weise genutzt werden, wenn die Clone-Unit eine vollständige Kopie der Original-Unit ist.
QuickOPC und EC bieten auf ETERNUS DX/AF die gleichen Nutzungsszenarien wie TimeFinder/Clone auf Symmetrix/VMAX3.
Auf ETERNUS DX/AF und für neue Anwendungen wird der Einsatz der flexibleren und strategischen Funktion QuickOPC empfohlen. Sie ist auch die Voraussetzung für den Einsatz der Funktion „Continuous Copy“ für Storage Cluster.
Die Funktionalität von EC kann auf ETERNUS DX/AF mit kleinen Einschränkungen auf QuickOPC abgebildet werden.
Bei Wechsel des Storage-Systems lässt sich die Funktion von TimeFinder/Clone auf QuickOPC bzw. EC abbilden.
Die folgende Tabelle gibt eine Übersicht über die äquivalenten Kommandos:
Kommandos für EC bzw. TimeFinder/Clone | Kommandos für QuickOPC |
|
|
| nicht erforderlich |
|
|
| nicht verfügbar |
|
|
|
|