Software Defined Mainframe: Eine inkrementelle Mainframe-Migration mittels Re-Hosting

Viele Mainframe-Nutzer suchen nach Wegen, ihre Bestandsapplikationen auf moderne Plattformen zu überführen. Dabei handelt es sich um Applikationen, die zumeist fester Bestandteil unternehmenskritischer Geschäftsprozesse sind. Allerdings ist deren Ablösung eine große Herausforderung. Denn eine Applikation neu zu schreiben oder eine Standardapplikation zu verwenden – soweit eine solche überhaupt verfügbar ist – sind sehr komplexe und aufwändige Projekte. Eine inkrementelle Migration mittels eines Software Defined Mainframe (SDM) bietet hier eine willkommene Alternative. Der folgende Beitrag erläutert anhand eines konkreten Anwendungsfalles, wie eine derartige Re-hosting-Strategie funktioniert.

von Mike Cairns, Senior Client Solutions Engineer bei LzLabs

Dabei ist zu beachten, dass Unternehmen, beispielsweise aus dem Finanzsektor, den Einsatz des Großrechners nach wie vor für bestimmte Aufgaben schätzen, nur haben diese einen hohen Preis. Zudem wird es zusehends schwieriger, den Betrieb sicherzustellen und Innovation voranzutreiben. Dennoch will man bei einer Migration möglichst geringe Risiken in Kauf nehmen. In diesem Szenario kommen insbesondere die Stärken des Software Defined Mainframe (SDM) zum Tragen, hier der von LzLabs (LzSDM). Dieses System ist speziell für einen inkrementellen und risikoarmen Migrationsprozess konzipiert.

Ausgangspunkt der in diesem Szenario geschilderten Migration war eine klassische Mainframe-Konfiguration im Bankenumfeld mit einem Transaktionsmonitor und einem auf einer relationalen Datenbank basierten Anwendungssatz. Das System erhielt im Zuge der ersten Welle der IT-Modernisierung in den vergangenen zwanzig Jahren eine Web-Oberfläche über dem Legacy-System. Die Umgebung setzte sich somit aus unterschiedlichen Komponenten in verschiedenen Ebenen zusammen. Dazu gehörten ein Application Server, ein Enterprise Service Bus (ESB), Gateway zum Transaktionsmonitor und ein Remote-Zugriff auf die relationalen Daten. Sie alle bieten jeweils Zugangspunkte zu einer Vielzahl anderer Systeme, die mit den zugrunde liegenden Anwendungen interagieren müssen. Nach der Analyse ergibt sich eine Umgebung, die mit der in untenstehendem Schaubild vergleichbar ist:

Aufgrund der Binärkompatibilität des SDM zur Mainframe-Umgebung ist die Einbindung der Applikation in eine solche SDM-Umgebung gut realisierbar. Diese vielschichtige Architektur eignet sich ideal für den Einsatz des SDM, um in einem ersten Schritt die Transaktionen auszulagern.”

Hierbei ist der Transaktionsmonitor zu einer effektiven Service Architektur geworden, die vom Benutzer und von den Client-Systemen der Kunden genutzt werden kann. Einige dieser Dienste sind allerdings für das Unternehmen bedeutender als andere. Der Kunde ist entsprechend in der Lage, selbst zu bestimmen, welche Dienste auf die SDM-Domäne ausgelagert werden und welche in der bestehenden Umgebung verbleiben sollen – dies ist schrittweise, nachprüfbar und kontrolliert umsetzbar.

Die Daten bleiben, wo sie sind

Testen ist ein entscheidender Faktor bei einer Mainframe-Migration. Auch hier bietet der SDM einen großen Vorteil gegenüber herkömmlichen Migrationsmethoden. In den bisher umgesetzten Migrationsprojekten konnte eine Reduktion des Testaufwands um rund zwei Drittel beobachtet werden. Der Vorteil des SDM bei diesem Prozess liegt insbesondere in der Binärkompatibilität, welche eine umfangreiche Konsistenz im Verhalten der Kunden-Applikationen erlaubt. Dies reduziert die Anzahl der benötigten Tests.

Darüber hinaus bleiben die Datenformate und Schnittstellen weitestgehend unberührt, so dass Tests und deren Ergebnisvergleich stärker automatisiert werden können. All diese Aspekte des SDM sorgen für eine höchstmögliche Kompatibilität zur vorherigen Mainframe-Umgebung. Folglich werden dadurch die Risiken einer Applikationsmigration weg vom Legacy-Mainframe enorm reduziert.

Die Migration auf eine Nicht-Mainframe-Umgebung oder der Einsatz von Standardapplikationen sind aufwändige Aufgaben, welche ein tiefes Applikations-Knowhow zwingend erfordern, um überhaupt erst einmal zu definieren, was das richtige Ergebnis ist. Ein einfacher Vorher-Nachher-Vergleich der Ausführungsergebnisse ist praktisch nicht möglich. Der Rückgriff auf den SDM hilft jedoch, diese große Herausforderung zu meistern. Dies wird erreicht, indem der direkte Vergleich zwischen den bisherigen Ausführungsergebnissen und denen des SDM aufgrund der oben beschriebenen unveränderten Datenkodierungen wesentlich vereinfacht wird – die Ergebnisse bleiben die gleichen. Hierzu werden Ausgangswerte der Datenbank-Snapshots und die Vorher-Nachher-Ergebnisse der Transaktionsausführung sowohl vom Legacy-Mainframe als auch vom SDM für einen automatisierten Abgleich erfasst.

Daher ist es auch möglich, die Anzahl der Tester zu reduzieren, um zu validieren, ob die kritische Geschäftslogik in der neuen Umgebung korrekt implementiert wurde. Dies stellt somit lediglich einen Teilbereich der Migration dar, bei dem diese Vergleiche im Verlauf des Migrationsprojekts wiederholt als ganz normaler Prozess durchgeführt werden. In diesem konkreten Fall war es sogar möglich, während der Migration die Applikationen vollumfänglich weiter zu entwickeln, was bei herkömmlichen Methoden undenkbar gewesen wäre.

Zuerst die lesenden Services

Für eine partielle Migration ausgewählter Dienste werden zuerst die hierfür passenden Dienste ausgewählt, vorzugsweise wählt man initial solche, die lesend auf die Daten zugreifen. Andere wiederum aktualisieren Daten innerhalb der Datenbank, was automatisierte Vergleiche erschwert. Natürlich können auch schreibende Dienste verschoben werden, welche komplexe Tabellen-Joins und andere potenziell langandauernde Abfragen durchführen und Daten aktualisieren bzw. einfügen. Nur führt die Datenveränderung zu Komplikationen bei der Automatisierung von Vergleichen der Vorher-Nachher-Ergebnisse. Daher geht es zunächst am einfachsten, wenn nur lesende Dienste bewegt werden und erst später auch die schreibenden.

Die Verarbeitung wird sodann an einen SDM ausgelagert, der mit den ausführbaren Lademodulen und den relevanten Transaktionsmonitor-Regionen konfiguriert ist, die an eine LzOnline-Instanz übertragen werden. LzOnline ist dabei eine einheitliche Umgebung für das Re-Hosting von Anwendungen, welche bestehende Transaktionsmonitore auf dem Mainframe nutzen. Sie ermöglicht das Re-Hosting, ohne dass der Quellcode geändert oder neu kompiliert werden müsste.

Nach der Verschiebung der Transaktionen könnte in einem weiteren Schritt ein Ansatz gewählt werden, bei dem die erforderlichen Daten zwischen der alten Bestandsdatenbank- und der LzRelational-Datenbankinstanz – also einer Datenbankimplementierung, die auf den Standard-PostgreSQL-Funktionen und -Schnittstellen aufbaut – gespiegelt worden wären. Sinnvoll ist dabei die Verwendung eines Datenpropagations- oder Replikations-Tools.

Jede Umgebung würde ihre eigene lokale Kopie dieser Referenzdaten enthalten, und die Kopie auf der Bestandsumgebung würde zunächst als Single Point of Truth betrachtet – regelmäßig repliziert auf die anderen Kopien.”

In dem hier beschriebenen Szenario wurden die Daten allerdings vorerst auf dem Mainframe belassen und zunächst remote von der bzw. den SDM-Instanz(en) darauf zugegriffen.

Foreign Data Wrapper

Ohne dass der Code der Applikation geändert werden muss, werden die gleichen binären Lademodule ausgeführt, die gleichzeitig auf dem Mainframe verwendet werden. Hierzu wurde eine Implementierung für SQL Management of External Data (MED) zwischen Postgres und DB2, auch bekannt als „Foreign Data Wrapper“ (FDW), entwickelt.

Die FDW-Implementierung bietet Postgres die Möglichkeit, für eine lokal katalogisierte Tabelle auf eine Legacy-Datenbank zuzugreifen, so dass die Datenintegrität erhalten bleibt, während die auf dem Mainframe verbleibenden Dienste ebenfalls weiterhin auf dieselben Daten zugreifen. Werden die Daten vorerst auf der Legacy-Datenbank belassen und gleichzeitig die Transaktionslast auf LzOnline übertragen, schafft dies aufseiten der Verantwortlichen das nötige Vertrauen, um auch komplexe Anwendungen inkrementell auf eine moderne Plattform zu überführen und gleichzeitig die nahtlose Zusammenarbeit mit dem Mainframe aufrechtzuerhalten.

Nach und nach wird so eine Reihe von Diensten aufgebaut, die auf einen lastverteilten Satz von SDM-Instanzen skaliert werden. Sie alle verarbeiten Teile der Gesamt-Workload. Im Rahmen des Migrationsprozesses folgen in einem nächsten Schritt sodann Transaktionen und Dienste, die die Daten aktualisieren.

Fazit

Wenngleich in diesem Szenario nur ein Teilbereich der gesamten Applikationslandschaft betrachtet wurde, so werden dennoch die Vorteile dieser Vorgehensweise deutlich.

Die schrittweise Migration gibt den Mainframe-Verantwortlichen genug Sicherheit und bietet gleichzeitig perspektivisch ungekannte Möglichkeiten. Der Ansatz führt dazu, dass die Datenintegrität gewahrt bleibt, die Applikationsentwicklung nicht unterbrochen wird und sich die mit der Migration einhergehenden Risiken auf ein Minimum beschränken lassen.”

Die Aussicht, langfristig auf den Mainframe verzichten zu können, ohne den Code von Anwendungen neu schreiben zu müssen und zudem von den Vorteilen der Cloud profitieren zu können, war lange Zeit undenkbar. Was vielen Mainframe-Veteranen wie eine Utopie erscheint, wird nun durch den Einsatz eines SDM möglich.Mike Cairns, LzLabs