Ein halbes Jahr habe ich an einem Datenmigrationsprojekt mitgewirkt. Dieses migrierte 2 Petabyte Daten von acht IBM Enterprise Stroage DS8700 auf vier Storage-Systeme der derzeit aktuellen DS8870-Modellreihe. Die Projektdauer betrug max. 6 Monate und ist ohne teure externe Unterstützung ausgekommen.
F: Warum selber migrieren? Es gibt doch Tools bzw. Dienstleistungen bekannter Hersteller.
A: Die meisten Tools bzw. Dienstleistungen sind leider sehr kostenintensiv, da sie i.d.R. nach Datenvolumen lizenziert bzw. berechnet werden müssen. Bei einem Datenvolumen von 2PiB ein zu großer Kostenblock. Also ist die Migration mit Hausmitteln und einkalkulierten Downtimes die kostenschonendste Variante.
Analyse der Ausgangssituation
Rund 400 LCUs mit mehr als 50.000 Devices
Zu Anfang ist natürlich die Ist-Situation zu begutachten. Hierzu wurden sowohl die 8 DS8700-Systeme als auch das z/OS-IOCP als Datenquelle angezapft und miteinander abgeglichen. Fragen wie welche LCU gehört zu welchen Kunden und wie viele Volumes gehören dazu konnten mit diesen Daten geklärt werden.
Migrationspfad
Für die Migration einer LCU muss zwischen gespiegelten und nicht gespiegelten Volumes unterschieden werden. Denn nur für gespiegelte Volumes, d.h. Volumes mit einer PPRC MetroMirror-Beziehung, kann eine GlobalCopy-Cascade aufgebaut werden. Die Singlesite-Anteile müssen in der Downtime noch synchronisiert werden.
Java-Tools
Objektorientierte Programmiersprache zum einfacheren Handling der Konfigurationsdaten
Java als OOP und Eclipse als Entwicklungsumgebung standen auf unseren Systemen bereits zur Verfügung, damit war die Frage nach einer geeigneten OOP sehr schnell gefunden.
Ich habe mich für eine OOP und gegen eine prozedurale Skriptsprache entschieden, da eine OOP, wie Java, bei der Vielzahl von Sätzen (hier >15.000) an Konfigurationsdaten, die in Beziehung gebracht und Abhängigkeiten beachtet werden mussten, die benötigte Klassen/Methoden von Haus aus mitbringt.
Eine Entwicklungszeit von Rund drei Wochen lies eine Hand voll Migrationstools entstehen, mit denen der gesamte Migrationspfad begleitet werden konnte.
DS8000 CLI
Die IBM Storage Systeme bieten ein Command Line Interface (CLI). Über dieses ist es ein leichtes mittels kleiner Batch-Scripte DS8K-Commands abzusetzen. Das CLI wurde in diesem Projekt sowohl für die Analyse der DS8K als auch für die eigentliche Datenmigration verwendet. Sinniger weise habe ich zu Anfang ein kleines Framework entwickelt, welches als Schnittstelle
Migration
Die Datenmigration startete immer mit den Cascaden, die nach und nach Aufgebaut wurden. Die Umschaltung auf die neuen Systeme erfolgte an insgesamt drei Wochenenden mit je einer Downtime von 4-5 Stunden.
Fazit
Eine gute Vorbereitung und ein strukturiertes Vorgehen sind das A und O um ein solches Projekt zum Ziel zu bringen. Mit fast 4 Wochen Vorsprung vor der Deadline endete meine Mitwirkung an dem Projekt. Die Altsysteme wurden im letzten Schritt zur zertifizierten Datenlöschung, für das ein externer Dienstleister beauftragt wurde, freigegeben.
Unter dem Strich also ein durch und durch gelungenes Projekt.
Auf der März-Tagung des GSE z/OS Guide, war hierzu ein entsprechender Erfahrungsbericht von mir auf der Agenda, der für GSE-Mitglieder auf der GSE-Seite abrufbar ist.
Termine
11. bis 13. März 2015
GUIDE SHARE EUROPE (GSE): Arbeitsgruppe SOSXD – zOS/390 (MVS)
im Wyndham Garden, Lahnstein
Links: GSE Deutschland SOSXD – zOS/390 (MVS)
