FlashCopy und IBM i

9. Mai 2015 | Von | Kategorie: Hochverfügbarkeit, Programmierung

In immer mehr Kundenumfeldern wird das Thema Offline-Backup zunehmend schwieriger, weil entsprechende Zeitfenster nicht zur Verfügung stehen. Bei immer größeren Datenmengen ist auch ein traditioneller Restore von einem Band in vielen Fällen nicht mehr wirklich sinnvoll, weil der Zeitbedarf dafür einfach viel zu groß ist – bei größeren Anwendungsänderungen muss aber dennoch sichergestellt werden, dass das Wartungswochenende sowohl für einen intensiven Test der neuen Umgebung ausreicht – aber auch der Zeitbedarf eingeplant wird, der im Notfall benötigt wird, um auf den Stand vor den durchgeführten Änderungen zurückzugehen. Abhilfe kann in diesen Fällen die Verwendung von FlashCopy liefern.

von Sabine Jordan

flashcopy1

FlashCopy erzeugt eine Point-in-Time-Kopie

FlashCopy ist eine Funktion eines IBM Storage Systems. Es ermöglicht die Erstellung einer Zeitpunktkopie eines logischen Volumes. Dabei wird eine sogenannte FlashCopy Relationship zwischen dem Quell-Volume und dem Ziel-Volume erzeugt – die beiden Volumes bilden ein Flash- Copy Paar. Da ein IBM i System im Normalfall nicht auf einem einzigen logischen Volume liegt, ist es notwendig, dass für alle beteiligten Volumes die FlashCopy zum exakt gleichen Zeitpunkt erzeugt wird. Dazu werden sogenannte Consistency Groups verwendet – eine Zusammenfassung von zusammengehörenden Volumes. Wenn eine FlashCopy gestartet wird, so wird im ersten Schritt die entsprechende Relationship gebildet. Die Ziel-Volumes sollen dabei möglichst sofort für die Verwendung zur Verfügung stehen – und nicht erst, wenn eine entsprechend große Datenmenge tatsächlich physisch kopiert wurde. Dazu wird eine Bitmap verwendet, die definiert, auf welchem Volume (Quelle oder Ziel) sich die entsprechenden Daten tatsächlich befinden. Zum Kopierzeitpunkt liegen alle Speicherseiten auf dem Quellvolume. Sobald die Bitmap geschrieben wurde, kann sowohl der Zugriff auf die Quellals auch auf die Zielvolumes freigegeben werden.

Wird zu einem späteren Zeitpunkt eine Speicherseite auf dem Quellvolume geändert, so wird vor dieser Änderung der alte Zustand zuerst in das Zielvolume kopiert und die Bitmap entsprechend geändert.

flashcopy3

Auch Änderungen auf den Zielvolumes werden entsprechend behandelt – liegen die Speicherseiten bisher unverändert auf den Quellvolumes, so werden die gewünschten Änderungen auf das Zielvolume geschrieben und die Bitmap entsprechend verändert.

Dieser Vorgang wird komplett vom Storagesystem gesteuert – IBM i „sieht“ nur die entsprechenden Volumes und führt Schreib- und Leseoperationen ganz normal aus.

Es gibt eine Reihe von unterschiedlichen Möglichkeiten, eine Flash- Copy zu erzeugen. Wird eine „Full Copy“ ausgewählt, so werden zusätzlich zum oben beschriebenen Prozess alle Daten von den Quellvolumes zu den Zielvolumes kopiert, so dass am Ende des tatsächlichen physischen Kopiervorganges zwei eigenständige Kopien der Daten zu Verfügung stehen. Dieses Verfahren kann zum Beispiel verwendet werden, wenn Lasttests gefahren werden sollen, die nicht die Performance der normalen Anwendung beeinflussen sollen und deshalb auf separaten Volumes laufen.

Eine „space efficient“ FlashCopy verzichtet hingegen auf das vollständige Kopieren aller Daten. Lediglich Daten, die im Quell- oder im Zielvolume geändert werden, werden entsprechend kopiert – für alle anderen Daten erfolgt der Zugriff weiterhin über das Quellvolume. Dieses Verfahren spart entsprechend Platz im Storagesystem – und kann zum Beispiel verwendet werden, um aus der FlashCopy Datensicherungen zu fahren. Das Zielvolume kann hier nicht unabhängig vom Quellvolume existieren – es ist nur so lange nutzbar, wie die FlashCopy Relationship existiert.

Einsatzmöglichkeiten von FlashCopy

In immer mehr Kundenumfeldern stellt sich heute das Problem, dass kein Zeitfenster für eine Offline- Datensicherung zur Verfügung steht. Hier kann die Verwendung von FlashCopy eine Alternative bieten. Es wird eine FlashCopy erzeugt (entweder vom Gesamtsystem oder von einem iASP) und diese Kopie aktiviert, um anschließend die Datensicherung von dieser Kopie aus zu starten. Dabei ist zu beachten, dass das Originalsystem nichts von dieser Datensicherung weiß. In den Objektbeschreibungen auf dem Originalsystem finden sich keine Informationen über die erfolgte Sicherung. BRMS bietet entsprechende Verfahren, um sowohl bei einer FlashCopy eines Gesamtsystems als auch eines iASPs die entsprechenden Informationen (was wurde auf welche Bänder gesichert, wie sieht die Recovery- Prozedur aus) an das Originalsystem zu übermitteln.

Wird die FlashCopy, die für eine Datensicherung verwendet werden soll, im laufenden Betrieb gezogen, so ist zu beachten, dass beim Aktivieren der FlashCopy eine Datenbank Recovery läuft. Wenn diese Datensicherung zu einem späteren Zeitpunkt zurückgespeichert wird, so erfordert ein Nachfahren von Journaleinträgen (um auf den aktuellen Datenstand zu kommen) einen nicht unerheblichen manuellen Aufwand. Hintergrund ist hier, dass als Startzeitpunkt für das Nachfahren nicht der Journaleintrag der Datensicherung verwendet werden kann – dieser ist in den Journalempfängern des Originalsystems ja gar nicht vorhanden – und der Zeitpunkt der Datensicherung muss in keinster Weise identisch mit dem Zeitpunkt der FlashCopy sein. Auch der Zeitpunkt der FlashCopy ist kein geeigneter, für alle Dateien gültiger Aufsetzpunkt, weil durch die Datenbankrecovery für einzelne Dateien ein Rollback erfolgt ist und damit im Journalempfänger einzelne Einträge vorhanden sind, die zwar vor dem Erzeugen der FlashCopy in das Journal geschrieben wurden, die aber nicht Bestandteil der gesicherten Daten sind. Hier muss für jede Datei, für die beim Aktivieren der FlashCopy ein Rollback erfolgt ist, manuell der Aufsatzpunkt (Zeitpunkt des letzten Commit für diese Datei) gesucht werden und der APYJRNCHG entsprechend aufgesetzt werden. Ein für alle Dateien identischer Aufsetzpunkt ist nur vorhanden, wenn die FlashCopy auf einem komplett beruhigten System erzeugt wurde – beim Aktivieren der FlashCopy also keinerlei Rollback-Aktivitäten entstehen.

Eine weitere Einsatzmöglichkeit von FlashCopy ist die Funktion eines „Rettungsankers“ bei größeren Softwareänderungen. Dabei wird – möglichst bei ausgeschaltetem System – eine FlashCopy erzeugt, bevor die Softwareänderungen durchgeführt werden. Um sich außerdem gegen den Ausfall des Storagesystems zu schützen, sollte zusätzlich auch immer eine aktuelle Datensicherung zur Verfügung stehen. Stellt man während des Anwendungstests fest, dass die Software-Änderungen nicht erfolgreich waren und auf den Stand vor den erfolgten Änderungen zurückgegangen werden muss, so gibt es dafür zwei unterschiedliche Möglichkeiten. Entweder kann der Zugriff auf das Produktionssystem auf die FlashCopy umgeleitet werden – in diesem Fall kann auf den bereits geänderten Daten noch eine Fehleranalyse erfolgen. Alternativ kann ein FlashCopy Reverse durchgeführt werden. Dabei werden die Daten auf den Quell- Volumes mit den Daten der Ziel- Volumes überschrieben. In beiden Fällen kann der Zugriff auf die Daten innerhalb eines sehr kurzen Zeitfensters zur Verfügung gestellt werden – und so der Zeitaufwand für einen Restore vom Band eingespart werden.

Über die Autorin

Die Autorin Sabine Jordan ist Senior IT Spezialistin bei der IBM Deutschland GmbH und per email erreichbar unter Sabine_ Jordan@de.ibm.com. Sie arbeitet seit 10 Jahren intensiv im Umfeld IBM i und Verfügbarkeit – sowohl in Kundenprojekten als auch bei der Erstellung von Redbooks und als Referentin auf nationalen und internationalen Konferenzen.

Schlagworte: , , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.