Vorab-Vergleich gibt Aufschluss
Der Rückgriff auf den SDM hilft jedoch, diese große Herausforderung zu meistern. Dies wird dadurch möglich, dass der direkte Vergleich zwischen den bisherigen Ergebnissen der Ausführungen auf dem Mainframe mit den entsprechenden Ergebnissen des SDMs aufgrund der erwähnten unveränderten Datenkodierungen wesentlich vereinfacht wird – die Ergebnisse bleiben die gleichen. Zu diesem Zweck werden Ursprungswerte der Datenbank-Snapshots und die Vorher-Nachher-Ergebnisse der Transaktionsausführung sowohl vom Legacy-Mainframe als auch in der neuen Umgebung von einem automatisierten Abgleich erfasst.

Auf diese Weise ist es daher auch möglich, die Anzahl der Tester zu reduzieren, um zu validieren, ob die oft unternehmenskritische Geschäftslogik auf dem SDM korrekt implementiert wurde. Dies stellt zwar lediglich einen Teilbereich der Migration dar, aber einen ganz entscheidenden. Denn die korrekte Implementierung der Geschäftslogik muss sicherstellen, dass die kritischen Geschäftsprozesse auf der neuen Plattform die gleichen Ergebnisse liefern, wie das beim alten Großrechner der Fall ist.

Entsprechend verfügt der SDM über eine höchstmögliche Kompatibilität zur vorherigen Mainframe-Umgebung und reduziert damit die Risiken, die in der Regel mit einer Applikationsmigration verbunden sind.

Am Anfang stehen die lesenden Services
Generell ist zu empfehlen, dass bei einer schrittweisen oder nur teilweisen Migration in der ersten Stufe diejenigen Services ausgewählt werden, die ausschließlich lesend auf die Daten zugreifen. Der Hintergrund ist ausschließlich die Minimierung des Risikos, technische Gründe spielen an dieser Stelle keine Rolle. So kommen technisch gesehen selbstverständlich auch schreibende Dienste in Frage, doch lassen diese sich deutlich schwieriger automatisch vergleichen. Entsprechend sollten sie erst zu einem späteren Zeitpunkt migriert werden.

Bei dieser empfohlenen Vorgehensweise wird die Verarbeitung an einen SDM ausgelagert. Dieser ist mit den ausführbaren Lademodulen und den relevanten Transaktionsmonitor-Regionen konfiguriert, die an eine LzOnline-Instanz übertragen werden. Bei LzOnline handelt es sich um eine einheitliche Umgebung für das Re-Hosting von Applikationen, die existierende Transaktionsmonitore auf dem Großrechner nutzen. Diese Instanz ermöglicht das Re-Hosting, ohne Neukompilierung oder Änderung des Quellcodes.

In einem nächsten Schritt kann dann die Migration der erforderlichen Daten erfolgen. Diese werden von der alten Bestandsdatenbank auf die LzRelational-Datenbankinstanz gespiegelt. Diese Datenbankimplementierung baut auf den Standard-PostgreSQL-Funktionen und -Schnittstellen auf. Hierbei ist die Verwendung eines Datenpropagations- oder Replikations-Tools zu empfehlen. Auf diese Weise enthält jede Umgebung ihre eigene lokale Kopie der Referenzdaten. Die Kopie der Bestandsumgebung wird dabei als Single Point of Truth betrachtet und regelmäßig auf die anderen Kopien repliziert.

Identischer Code auf SDM und Mainframe
Ohne Code-Änderungen in der Anwendung werden auf dem SDM die gleichen binären Lademodule ausgeführt, die gleichzeitig auf dem Mainframe zum Einsatz kommen. Hierfür kommt der Foreign Data Wrapper (FDW) als eine Komponente des LzSDM zum Einsatz. Dabei handelt es sich um eine Implementierung für SQL Management of External Data (MED) zwischen Postgres und DB2.

Der FDW eröffnet Postgres die Möglichkeit, für eine lokal katalogisierte Tabelle auf eine Legacy-Datenbank zuzugreifen. Dies stellt die Datenintegrität sicher, während die auf dem Mainframe verbleibenden Dienste ebenfalls weiterhin auf dieselben Daten Zugriff haben. Schrittweise wird so eine Reihe von Services aufgebaut, die auf einen lastverteilten Satz von SDM-Instanzen skaliert werden. Sie alle verarbeiten Teile des gesamten Workloads. Dann folgen im Rahmen der schrittweisen Migration die Transaktionen und Dienste, die die Daten aktualisieren.

Im konkreten Projekt beim Finanzinstitut wurden die Daten vorerst auf der Legacy-Datenbank belassen und gleichzeitig die Transaktionslast auf LzOnline übertragen. Da dies einwandfrei funktioniert hat, erhielten die Verantwortlichen das nötige Vertrauen in den Migrationsprozess und den SDM, um auch komplexe Anwendungen inkrementell auf die moderne Plattform zu überführen und parallel die nahtlose Zusammenarbeit mit dem Großrechner beizubehalten.

Fazit
Die beschriebene schrittweise Migration stellt sicher, dass im Prozess weg vom Mainframe die Datenintegrität gewahrt bleibt und die Applikationsentwicklung nicht unterbrochen wird. So lassen sich die mit der Migration einhergehenden Risiken minimieren. Die Möglichkeit, langfristig auf Großrechner verzichten zu können, ohne den Source-Code der Applikationen neu schreiben zu müssen und gleichzeitig die Vorteile der Cloud zu nutzen, erschien bis vor kurzem illusorisch. Doch der SDM kann genau diese Herausforderung bewältigen. Zudem ermöglicht es das schrittweise Vorgehen, sehr schnell Ergebnisse vorzuweisen – in einer Zeit hohen Drucks auf Kosten und Ressourcen ein nicht zu verachtender Aspekt.


ln/Mike Cairns, Senior Client Solutions Engineer bei LzLabs