von Peter M. Horbach

Bidirektionale Replikation – Eine Analyse

Die B.O.S. Software Service und Vertrieb GmbH und ihre tcVISION Lösung sind seit über einer Dekade ein fester Bestandteil im Bereich von Datenreplikation, -synchronisation, -transformation und -austausch.

Es gibt keinen Hersteller in diesem Bereich, der die technische Vielfalt der Betriebssysteme, Datenbanken und Cloud-Umgebungen so konsequent abdeckt wie die B.O.S. Software. Es sei in diesem Zusammenhang noch einmal auf die unterstützten Systeme hingewiesen.

„Datensynchronisation in Echtzeit“ lautet die Headline unserer Webseite und wir haben bereits in einem früheren Blog den Unterschied zwischen „Echtzeit-Realtime und Near Realtime“ durchleuchtet und die Unterschiede erklärt.

Unser heutiges Thema ist die bidirektionale Replikation, also eine Replikation mit gleichberechtigten Partnern (Plattformen/Datenbanken) mit dem Ziel, jede Änderung auf einer Plattform festzustellen und auf die andere Plattform zu replizieren, ohne dass diese Änderung wieder zur auslösenden Plattform zurückgeschickt wird.

Diese Art einer Replikation wird auch „Master-Master“ Replikation genannt. In der Regel werden Replikationen von einer produktiven Datenbank (z.B. Db2, IMS, DL/I, VSAM, Adabas) in eine andere Umgebung durchgeführt (RDBMS unter Windows/Unix/Linux bzw. Linux on z, bzw. ein Cloud-System) wobei die Replikation selbst nur in eine Richtung geht. Diese sog. „Master-Slave“ Replikation dient dazu, die Daten der bestimmenden, produktiven Datenbank auf einer parallelen Umgebung zu synchronisieren. Dort soll die Möglichkeit gegeben sein, mit aktuellen Daten für Analysezwecke, Reporting, Business Intelligence, Data Warehousing etc. zu arbeiten.

Im Falle einer Anwendungsmodernisierung oder sogar einer Anwendungsverlagerung vom Mainframe auf eine Open-System-Plattform bekommt die bidirektionale Replikation eine große Bedeutung, insbesondere wenn beide Plattformen eine strategische Bedeutung haben.

Es gibt spezielle Ausprägungen der bidirektionalen Replikation. Diese liegen immer dann vor, wenn Mainframe Datenbanken beteiligt sind, deren Daten und Records über sogenannte interne Indizes und Schlüssel referenziert werden. Wir werden auf diese spezielle Verarbeitungsart später im Blog zurückkommen.

Wenden wir uns der „normalen“ bidirektionalen Replikation zu und gehen von dem folgenden Beispiel aus:

Die Replikation wird zwischen einer Mainframe Datenquelle (Db2, IMS, DL/I, VSAM, CA DATACOM/DB) und einer relationalen Datenbank unter Windows/Unix/Linux oder Linux on z durchgeführt (z.B. ORACLE, MS SQL Server, Db2 LUW, PostgreSQL etc.). Beide Plattformen sind gleichberechtigt, d.h. Benutzer arbeiten mit dem jeweiligen System und führen Änderungen durch. Diese Änderungen müssen erkannt und in Echtzeit auf die andere Plattform repliziert werden. Diese Art der Verarbeitung setzt in der Regel auch gewisse organisatorische Maßnahmen voraus (z.B. unterschiedliche Schlüssel- und Nummernkreise für die jeweilige Plattform). Dies ist aber keine Notwendigkeit für eine funktionierende bidirektionale Replikation.

Ein Anwender des Mainframe Systems macht eine Änderung für einen bestimmten Record. Diese Änderung wird in Echtzeit „gecaptured“, an das Zielsystem übergeben und dort eingepflegt. Diese Änderung auf dem Zielsystem wiederum würde - ohne spezielle Vorkehrungen - ebenfalls „gecaptured“ und wieder an das Ursprungssystem zurückrepliziert. Diese Verarbeitung würde zu zirkulierenden Änderungen führen.

Um dies zu verhindern, müssen Vorkehrungen getroffen werden, die Änderung zu identifizieren und nicht an das Ursprungssystem zurück zu senden. Diese Vorkehrungen sind in der tcVISION Lösung vorhanden und werden als „BackUpdateCheck“ im tcVISION Repository bei der Verbindung zwischen Quelle und Ziel definiert. In Abhängigkeit der Quelle werden Indikatoren festgelegt, um die Änderung bei der Rückreplikation identifizieren zu können. Dies können unterschiedliche Indikatoren sein: User Name, Online Transaktions-ID, Jobnamen, PSB Namen u.v.m. Die Definition des BackUpdateChecks ist sehr einfach durchzuführen, wie das folgende Beispiel zeigt:

Die tcVISION Repository-Definition zeigt eine Replikation zwischen einer VSAM-Datei, die über CICS geändert wird, und einer PostgreSQL Tabelle. Ein Doppelklick auf die Verbindungslinie zwischen der Eingabe- und Ausgabe-Tabelle zeigt die Eigenschaften der Replikationsverbindung an:

Als Replikationstyp wurde „BackUpdateCheck“ ausgewählt und als Identifikation wird CICS Id, CICS Transaction und CICS userid angeboten.

Wird bei einer Änderung der VSAM Datei festgestellt, dass die Änderung durch den CICS userid von tcVISION oder durch die tcVISION CICS Transaktion verursacht wurde, wird die Änderung nicht weiterrepliziert, da die Änderung in diesem Beispiel von PostgreSQL ausgelöst wurde.

Änderungen, die aufgrund eines BackUpdateChecks unterbunden wurden, werden natürlich in einem speziellen Log festgehalten und sind für Revisionszwecke jederzeit verfügbar.

Wie bereits vorher erwähnt, gibt es auch spezielle BackUpdateChecks, die im Verbund mit bestimmten Mainframe Datenbanken wichtig sein können.

Mainframe Datenbanksysteme wie ADABAS von der Software AG bzw. IDMS/DB von der Computer Associates (BROADCOM) verwenden interne Schlüssel zur Identifikation eines Records. Dies sind z.B. die ISN (Internal Sequence Number) im Falle von ADABAS bzw. DBKEY im IDMS. Wird in einem Replikationsszenario ein Record auf dem Replikat hinzugefügt, bleibt die ISN Nummer bzw. DBKEY unberührt. Nachdem der INSERT auf dem Mainframe durchgeführt wurde (z.B. via tcVISION), wird die Änderung wiederum durch tcVISION gecaptured. Da jedoch durch den INSERT auf dem Mainframe eine neue ISN bzw. DBKEY für den Record kreiert worden ist, muss diese über eine UPDATE Anweisung an das Zielsystem übermittelt werden.

Die Implementierung dieses Verfahrens geschieht über das tcVISION Repository unter Verwendung des Typs "BackUpdateCheck für Inserts". Diese Art der Verarbeitung wird auch LOOPBACK-Verfahren genannt.

Zusammenfassung:

Bidirektionale Replikationen sind im Rahmen einer Anwendungsmodernisierung oder Anwendungsmigration auf eine neue Plattform wichtige Bestandteile der Unternehmensinitiativen. Insbesondere dann, wenn ein Mainframe die zentrale Rolle in diesem Szenario spielt.

Unsere tcVISION Lösung zeichnet sich dadurch aus, dass eine bidirektionale Replikation ohne Probleme zu implementieren ist und dass traditionelle Mainframe Ressourcen als Ausgabeziele genutzt werden können, ohne dass zusätzliche Softwarekomponenten erforderlich sind.

Seit der Markteinführung von tcVISION haben viele Kunden ihre Migrationsszenarien mit Hilfe der bidirektionalen Replikation von tcVISION erfolgreich durchgeführt. Jede dieser Szenarien hatte eigene Schwerpunkte und Eigenschaften, die letztendlich gelöst wurden und ihren Weg in die tcVISION Lösung gefunden haben.

Peter M. Horbach ist mit über 40 Jahren IT Erfahrung seit vielen Jahren in den Bereichen Datensynchronisation und Replikation tätig. Für BOS Software pflegt er Kontakte zu den internationalen Partnern und schreibt den Blog.

zurück zur Übersicht