Scandlines COAST Eine hochverfügbare verteilte Architektur

Transkript

1 Donnerstag, 10. November h00, Bruno-Schmitz-Saal Scandlines COAST Eine hochverfügbare verteilte Architektur J. Grade (Scl), M. Penzlin (sd&m), Dr. K. Prott (sd&m) sd&m AG, Scandlines AG, Hamburg Rostock/Warnemünde Schlüsselworte: Hochverfügbarkeit, verteilte Architektur, Replikation, Materialized Views, Datenbank,, Fehlerbehandlung, Schemaänderungen im Betrieb 1. Einleitung Aufbauend auf die Cluster- und Replikations-Technologie von Oracle entwickelte die sd&m AG ( für die Scandlines AG ( das hochverfügbare und verteilte Buchungsund Ticketing-System COAST (Customer Oriented Advanced Service and Transport System). Im geplanten Endausbau, der Ende 2005 abgeschlossen sein wird, läuft COAST in der Zentrale und in neun Häfen im Ostseeraum. Die führende Fährrederei im Ostseeraum unterhält auf einigen Routen einen 24 Stunden Betrieb mit Abfahrten im 30-Minuten-Takt. Die besondere Herausforderung von COAST liegt einerseits in der zentralen Datenhaltung, damit Scandlines in jedem Hafen zu jeder Zeit die aktuellen Stammdaten und die noch verfügbaren Kapazitäten kennt. Anderseits muss auch bei einem WAN-Verbindungsausfall zur Zentrale ein reibungsloser Buchungs- und Checkin- Betrieb in den Häfen sichergestellt werden. In der Designphase von COAST fiel die Entscheidung für die Verwendung der Oracle-DB für die Datenhaltung. Ausschlaggebend waren die sehr hohen Anforderungen an die Verfügbarkeit und Skalierbarkeit gepaart mit der verteilten Datenhaltung. Neben der Replikationstechnologie bildet das Oracle RAC (Real Application Cluster) in jedem der zehn COAST Standorte die Basis für die hohe Ausfallsicherheit der jeweiligen Umgebung. Der Vortrag beziehungsweise dieser Artikel präsentieren den zentralen Baustein dieser hochverfügbaren und verteilten Systemlösung basierend auf "materialized views" der Oracle-Replikationstechnologie. Die kompletten Service- und Stammdaten werden von der Zentrale in alle Häfen repliziert. Dies geschieht teilweise sehr zeitnah in wenigen Sekunden. 2. Das Buchungs- und Ticketing-System COAST COAST ist ein von sd&m entwickeltes Buchungs- und Ticketing-System für Scandlines, dem führenden Fährbetrieb im Ostseeraum. Es unterstützt alle wesentlichen unternehmenskritischen Prozesse bei Scandlines. Mit COAST werden die Stammdaten gepflegt. Das sind beispielsweise die Routen und Abfahren, Preise und Tarife, die Schiffe mit ihren Kapazitäten, die Häfen mit ihren Fahr- und Wartespuren, die Kunden und ihre Konditionen und einiges mehr. Im operativen Geschäft werden mit COAST Services gebucht. Das sind beispielsweise Fährfahrten für Fahrzeuge (PKW, LKW, Bus und Bahn) und Personen. Das können Hin- und Rückfahrten wie auch Fahrten über mehrere aufeinander folgende Routenabschnitte (Legs) sein, zum Beispiel von Puttgarden (Deutschland) nach Rødby (Dänemark) und weiter über Helsingør (Dänemark) nach Helsingborg (Schweden) und zurück. Im Hafen angekommen wird mit COAST eingecheckt und der Service bezahlt. Zum Bezahlen des Services gehört beispielsweise auch das Revenue Sharing (Erlöskontierung). Die Tickets und andere Dokumente werden ebenfalls mit COAST ausgestellt. Zu guter Letzt wird jedem Fahrzeug eine Spur zugewiesen und für jede Abfahrt ein Manifest mit allen Fahrzeugen und Passagieren erstellt. COAST ist ein in Java realisiertes Client-Serversystem, dass verteilt in ca. 10 Häfen und der Zentrale läuft (s. Abbildung 1). Die Intel-basierte COAST-Hardware wird serverseitig unter Microsoft Windows Server 2003 und clientseitig unter Microsoft Windows 2000 betrieben. Eine zentrale Datenhaltung ermöglicht es, in allen Häfen zu jeder Zeit die noch freien Kapazitäten auf den Abfahrten anderer Häfen zu kennen. In Puttgarden kann man damit erfahren, ob in einer zeitlich in Frage kommenden Abfahrt in Helsingør noch Kapazitäten frei sind. Damit die zentrale Datenhaltung bei Ausfall der WAN-Verbindung zur Zentrale nicht zum Ausfall des Systems führt, werden alle für den operativen Betrieb notwendigen Daten in jeden Hafen repliziert.

2 18. Deutsche ORACLE-Anwenderkonferenz Database Abbildung 1: COAST-Architektur Im Normalbetrieb (= WAN-Verbindung zwischen Hafen und Zentrale besteht) wird auf die Daten im Hafen nur lesend zugegriffen und alle schreibenden Operationen erfolgen direkt in der Zentrale. Über die Replikation gelangen alle neuen und geänderten Daten in die Häfen. Nur bei Ausfall der WAN-Verbindung erfolgen auch in den Hafendatenbanken Schreiboperationen. Zusätzlich werden alle Schreiboperationen in einer Queue persistiert und durch die Anwendung nach dem WAN-Ausfall automatisch in der Zentrale nachgezogen. So wurde eine sehr hohe Verfügbarkeit bei gleichzeitig zentraler Datenhaltung ermöglicht. Eine zentrale Technik für COAST ist daher die Replikation, die in diesem Vortrag beziehungsweise Artikel ausführlich beschrieben wird. 3. Die Replikation in COAST Für COAST wurden Writable Materialized Views mit Refreshgruppen ( refresh groups ) eingesetzt. Abschnitt 3.1 erläutert diese Entscheidung. Im zweiten Abschnitt wird auf besondere Anforderungen für COAST eingegangen Writable Materialized Views Um für die Applikation den angemessenen Replikationsmechanismus auszuwählen, müssen bestimmte Kriterien beachtet werden. Einerseits sind dies Kriterien, welche durch die fachlichen und technischen Anforderungen von COAST selbst und andererseits durch die gewählte Datenbanktechnik und die Lastanforderungen bestimmt werden. Im Normalbetrieb führt COAST in der replizierten Hafendatenbank nur lesende und keine schreibenden Operationen aus. In dem Fall, dass keine Datenverbindung zur Zentrale vorhanden ist, wird auch in die Datenbank des Hafens geschrieben. Wenn die Verbindung zur Zentrale wieder steht, werden durch die Replikation die Änderungen des Hafens durch den aktuellen Stand der Zentrale überschrieben: Zentrale gewinnt immer. Die Zentrale ist also Master und Konflikte beim Abgleich der Daten können nicht entstehen. Das Nachziehen der während des WAN-Ausfalls erfolgten Datenänderungen in der Zentrale übernimmt die COAST-Anwendung selbst, sobald die Verbindung wieder hergestellt ist. Oracle s writable materialized views sind genau für ein so beschriebenes Szenario gedacht und wurden deshalb in COAST eingesetzt. Außerdem wurde in COAST Oracles Technik der Refreshgruppen (nicht zu verwechseln mit Replikationsgruppen) eingesetzt. Hiermit werden Änderungen repliziert, die sich über mehrere Tabellen erstrecken. Refreshgruppen sind disjunkte Mengen der zu replizierenden Tabellen, deren Änderungen transaktionssicher repliziert werden. Im Moment der Replikation werden TX-Locks auf die Repliken der Tabellen gelegt. Während der TX-Locks kann in den Häfen nur lesend und nicht schreibend auf die replizierten Tabellen zugegriffen werden. Für COAST ist dies kein Problem. Bei der Konzeption einer anderen Anwendung mit writable materialized views sollte dies aber unbedingt bedacht werden. In COAST wurden die materialized views als fast refreshable angelegt, was bedeutet, dass nur die Änderungen und nicht die kompletten Tabelleninhalte repliziert werden. Anders wären die großen Datenmengen in COAST nicht in ca. 10 Häfen replizierbar. Ferner bieten materialized views die Möglichkeit, diese bezüglich der Basistabellen horizontal und/oder vertikal zu fragmentieren. Dies bedeutet, dass man nicht zwingend die ganze Tabelle replizieren muss, sondern wenn erforderlich nur bestimmte Spalten oder nur bestimmte Zeilen der Mastertabelle.

3 3.2. Besondere COAST-Anforderungen Während die oben beschriebenen Anforderungen durch die writable materialized views out-of-the-box abgedeckt wurden, gibt es in COAST darüber hinaus gehende Anforderungen, welche individuell gelöst werden mussten. Vier der wichtigsten und zugleich kniffligsten Anforderungen stellen wir vor: Optimierung der Replikation: Die ca. 200 zu replizierenden Tabellen wachsen um ca. 30 GByte im Jahr und sind auf 16 Refreshgruppen verteilt. Einerseits müssen die Daten kontinuierlich und zeitnah in die Häfen repliziert werden. Zeitnah bedeutet, daß die Daten teilweise im Sekundenrhythmus im Hafen synchronisiert werden müssen. Andererseits steht dafür nur eine Datenleitung mit einer Kapazität von 1MBit/s zur Verfügung, von der der größere Teil für die Kommunikation der verteilten COAST-Anwendung selbst verwendet wird. Verwendet man die Replikation mit writeable materialized views outoff-the-box, so stellt man fest, daß diese unter den COAST-Anforderungen eine viel zu hohe CPU-, archive.log- und Netzwerk-Last erzeugen. Mit dem im Abschnitt 4 beschriebenen Vorgehen konnte diese Last auf ein für COAST gut verträgliches Niveau verringert werden. Fehlerbehandlung: Bei der Replikation über ein WAN liegt es in der Natur der Sache, daß man die Replikation besonders gegen Störungen der Verbindung robust machen muss. Oracles Replikation wurde deshalb um Fehlerbehandlungs- und Fehlerprotokollierungsmechanismen erweitert (Abschnitt 5). Aufsetzen eines neuen Hafens: Für COAST muss man in der Lage sein einen neuen Hafen in Betrieb zu nehmen, während das System bereits in der Zentrale und mehreren Häfen läuft. Wichtig ist dabei, dass alle Daten vollständig in den neuen Hafen repliziert werden. Über die WAN-Leitung mit 1MBit/s Kapazität ist dies nicht mehr möglich, da das zu replizierende Datenvolumen pro Jahr um ca. 30 GByte wächst. Auch hierfür haben wir eine gute Lösung entwickeln können (Abschnitt 6). Schemaänderungen im Betrieb: Damit die Applikation wartbar ist, müssen auch Schemaänderungen möglich sein. Bei einer replizierten Umgebung im 24x7 Betrieb, muss man folglich ohne große Datenmengen zu transportieren und ohne Transaktionen zu verlieren, Schemaänderungen im laufenden Betrieb durchführen können. Wie dies funktioniert, wird in Abschnitt 7 beschrieben. 4. Optimierung der Replikation Die hohe Last der Replikation lässt sich auf zwei Gründe zurückführen. Zum einen muss bei jeder für manche Refreshgruppen im Sekundentakt angestoßenen Replikation der Hafen feststellen, ob Schreiboperationen in den zugehörigen Tabellen erfolgt sind. Dazu sind für jede Tabelle Remote-Queries auf den Hilfssystemtabellen MLOG$... und RUPD$... notwendig, die in ihrer Menge zu einer hohen CPU und WAN-Last führen. Dies geschieht auch im so genannten Leerlauf, wenn keine Änderungen zu replizieren sind. Zum anderen wird nach jeder Replikation auch im Leerlauf die Zeit der Replikation in Systemtabellen neu gesetzt. Dies ist notwendig, damit die Datenbank erkennen kann, auf welchem Hafen die Änderungen schon angewendet wurden, was aber eine hohe archive.log-last bewirkt. Die Option refresh on commit ist hier nicht gegeben, da diese nicht mit Datenbanklinks in einer verteilten Architektur einsetzbar ist. In unserer Lösung werden die Remote-Queries und das Setzen der Zeit in den Systemtabellen im Leerlauf vermieden. Dafür haben wir in der Zentrale und im Hafen pro Refreshgruppe und Hafen jeweils eine PLSQL-Prozedur entwickelt, die in regelmäßigen Abständen von Datenbankjobs aufgerufen werden. Jeweils eine Prozedur in der Zentrale prüft, ob sich für einen bestimmten Hafen und Refreshgruppe Änderungen in den Mastertabellen ergeben haben. Dieses wird mit Abfragen der lokalen MLOG$- und Systemtabellen festgestellt und das Ergebnis in einer lokalen von uns eingeführten changes -Tabelle in Form eines Flags gespeichert: SchemaName RefreshGroup PortName IsChanged coast Masterdata Puttgarden 1 coast Paymentdetail Puttgarden 0 coast Service Rostock 0 Tabelle 1: Changes-Tabelle Die PLSQL-Prozedur des Hafens prüft nun als erstes ihrerseits durch eine einzelne Remoteabfrage gegen das Flag in der changes -Tabelle, ob Änderungen in der Zentrale aufgelaufen sind. Als zweites wird festgestellt, ob Änderungsvektoren in den lokalen USLOG$-Tabellen vorhanden sind. In COAST ist dies nur der Fall, wenn bei WAN-Ausfall auch lokal schreibend auf die materialized views zugegriffen wird. Ist eines von beiden der Fall, so wird eine Replikation ausgelöst und das Flag in der changes -Tabelle zurückgesetzt. Die WAN-, Archive- und CPU-Last wird durch dieses Vorgehen erheblich reduziert, da die Remote-Prüfung auf zu replizierende Änderungen für eine Refreshgruppe mit vielen Tabellen auf die Abfrage eines einzigen Flags in einer kleinen Tabelle reduziert wurde.

4 18. Deutsche ORACLE-Anwenderkonferenz Sowohl in der Zentral- also auch in der Hafen-Prozedur sind darüber hinaus keine Remote-Queries und keine Joins vorhanden. Um unnötige Joins und Queries zu vermeiden, wurden bestimmte unveränderliche Informationen, zum Beispiel Name der MLOG$- und USLOG$-Tabellen und die Zugehörigkeit zur Refreshgruppe, hart in die PLSQL-Prozedur kodiert. Die PLSQL-Prozeduren werden einmalig beim Aufsetzen eines neuen Hafens generiert. Das spart aufwändige Tipparbeit und schließt gleichzeitig viele Fehlerquellen aus. Database 5. Fehlerbehandlung In der Out-of-the-Box -Lösung wird pro Refreshgruppe ein Job initiiert, der in einem konfigurierbaren Zeitintervall die PLSQL-Prozedur ( dbms_refresh.refresh( ) zum Replizieren der Refreshgruppe anstößt. Läuft dieser Job also die refresh-prozedur auf einen Fehler, so wird dieser Fehler nicht protokolliert. Es wird nur registriert, dass ein Fehler aufgetreten ist und nach 16 Fehlern ohne erfolgreiche Ausführung zwischendurch wird der Job vollständig abgebrochen. Dieses Verhalten haben wir geändert, indem wir den Job um einen Exception-Block ergänzt haben, der alle Fehler abfängt und mit Zeitstempel und Refreshgruppe versehen in einer lokalen Fehlertabelle (s. Tabelle 2) abspeichert. Hierdurch wurde einerseits sichergestellt, dass die Jobs nicht abbrechen und andererseits eine gezielte Fehleranalyse im Fehlerfall ermöglicht. PortName RefreshGroup Message Timestamp Puttgarden Masterdata ora :11:11 Rostock Paymentdetail ora-xyz :00:00 Tabelle 2: Fehlertabelle Ein spezieller Fehler bei Verbindungsstörungen äußerte sich derart, dass der Job einfach hängen blieb ohne einen Fehler anzuzeigen. Erkennbar war dies daran, dass sich die Zeit für die nächste Ausführung des Jobs nicht mehr veränderte und in der Vergangenheit lag. Daher haben wir ergänzend zu den eigentlichen Replikationsjobs noch einen Satz von Überwachungs-Prozeduren entwickelt, die den korrekten Zustand der Jobs und den Platz in den Tablespaces prüfen und gegebenenfalls Einträge in die Fehlertabelle einfügen und Mails an die Betriebsüberwachung verschicken. Zusätzlich gibt es eine weitere Prozedur, die vollautomatisch nach hängengebliebenen Jobs sucht, den Thread ermittelt und diesen Thread per orakill entfernt. Daraufhin läuft der Job wieder, ohne daß manuelle Eingriffe nötig sind. Der zu einem Job gehörende Thread wird wie folgt entfernt: 1.) select /*+ rule */ a.sid, b.what, a.instance from dba_jobs_running a, dba_jobs b where a.job=b.job; Hieraus folgt die Session-ID (SID), in der der JOB ausgeführt wird. 2.) select spid "thread", osuser, s.program,s.sid from v$process p, v$session s where p.addr=s.paddr and s.sid = <a.sid>; Dies ermittelt unter anderem den thread zu einer bestimmten SID. 3.) orakill <instance> <thread> beendet dann den thread. Die Mails an die Betriebsüberwachung werden per utl_smtp -Package direkt von den Überwachungsjobs an eine Betriebsüberwachung gesendet. 6. Aufsetzen eines neuen Hafens Beim einfachen und nahe liegenden Verfahren, einen neuen Hafen aufzusetzen, werden die materialized views im Hafen erzeugt und anschließend alle Daten der zentralen Mastertabelle über die Leitung repliziert. Dies ist bei einem jährlichen zu replizierendem Datenwachstum von ca. 30 GByte über eine 1MBit/s-Leitung nicht möglich. Die Kunst besteht nun darin, beim Aufbau keine Transaktionen zu verlieren und alle Daten vollständig in den Hafen zu transferieren. Das dafür von uns entwickelte Verfahren möchten wir nun Schritt für Schritt beschreiben: Im ersten Schritt werden mit create materialized view log on <tablename>; MLOG$-Tabellen in der Zentrale aufgebaut, damit in diesen Änderungsvektoren gespeichert werden können. Damit ist es dann möglich die materialized views als fast-refreshable anzulegen. Im nächsten Schritt wird die reine Tabellenstruktur des Zentralschemas exportiert und im Hafen importiert. Sollten beim Ex- und Import der Metadaten die MLOG$-Tabellen im Hafen gelandet sein, so können diese jetzt noch mit drop materialized view log on <tablename>; entfernt werden. Nun wird ein Datenbanklink vom Hafen zur Zentrale erzeugt, über den später die eigentliche Replikation laufen wird.

5 Danach können die materialized views mit create materialized view <viewname> on prebuilt table ; gebildet werden. In diesem Schritt entstehen im Hafen die entsprechenden USLOG$-Tabellen die wiederum die Änderungsvektoren des Hafens sammeln. Ab diesem Zeitpunkt wird in der Zentrale erkannt, dass es einen neuen Hafen gibt und Änderungsvektoren der Zentrale werden bis zum nächsten Refresh aufbewahrt. Da erst nun die eigentlichen Tabellendaten der Zentrale exportiert werden, gehen keine Transaktionen der Zentrale verloren. Nun kann der Export per Datenträger in den Hafen transportiert und dort importiert werden. Da dieser Import als normale DML verarbeitet wird, entstehen in den USLOG$-Tabellen die entsprechenden Änderungsvektoren. Diese müssen auf jeden Fall vor dem ersten Refresh geleert werden. Der Refresh würde ansonsten wieder den Import rückgängig machen, da es sich um ein writeable materialized view handelt, bei dem die Änderungen im Hafen überschrieben werden. Sind der Import abgeschlossen und die USLOG$-Tabellen geleert, kann das erste mal die materialized view repliziert werden: dbms_mview.refresh(, f );. Das f steht für fast und bedeutet, dass nur die Änderungen seit dem Anlegen der materialized views repliziert werden. Abschließend werden nur noch die Tabellen beziehungsweise materialized views mit dbms_refresh.add(name=> refreshgroup,list=> <table>, ) in Refreshgruppen eingeteilt. Diese werden von nun ab mit dbms_refresh.refresh( ); synchronisiert. Die wesentliche Idee des Verfahrens besteht also darin, die Hafendatenbank durch einen normalen Exund Import aufzubauen und den Export erst zu starten, wenn durch das Anlegen der materialized views bereits Änderungsvektoren für den Hafen in der Zentrale vorgehalten werden. 7. Schemaänderungen im Betrieb Out-of-the-box kann eine neue zu replizierende Spalte in einer Tabelle nur hinzugefügt werden, indem man die materialized view neu aufbaut und den kompletten Inhalt der Tabelle einmal repliziert. Dies ist bei einer 1MBit/s-Leitung nur bis zu einer gewissen Tabellengröße möglich. Wir haben ein Verfahren entwickelt, bei dem Schemaänderungen im laufenden Betrieb ohne den Transport von großen Datenmengen und ohne den Verlust von Transaktionen möglich sind: Baut man eine materialized view unter namentlicher Benennung der zu replizierenden Spalten auf (also kein select * from ), so ist es möglich nur eine Teilmenge der in der Basistabelle enthaltenen Spalten zum Hafen zu replizieren. So kann in einem ersten Schritt der Mastertabelle in der Zentrale eine Spalte hinzugefügt werden, ohne die Replikation zu beeinträchtigen. Im Hafen hat die materialized view zu diesem Zeitpunkt also eine Spalte weniger. Nun müssen wir in den steuernden PLSQL-Routinen in der Zentrale und im Hafen die Abschnitte für die zu ändernden Tabellen und materialized views auskommentieren. Dies ist notwendig, da mit dem Entfernen der Tabelle aus der Refreshgruppe im nächsten Schritt die Prozeduren nicht mehr compilierbar und damit nicht mehr lauffähig wären. Anschließend können wir die materialized view aus der Refreshgruppe entfernen. Nun müssen wir dafür sorgen, daß keine Transaktionen verloren gehen. Dazu bauen wir in der Zentrale ein Dummy-Mview für die bereits Schema-geänderte Mastertabelle auf. Durch diesen Schritt wird dafür gesorgt, daß alle Änderungen in der Zentrale aufgehoben werden, da die Dummy-Mview nicht refresht wird. Ein letztes Mal wird im Hafen die materialized view refresht. Hierdurch wird noch einmal Zentrale und Hafen synchronisiert und sichergestellt, daß Transaktionen entweder durch das Dummy-Mview aufgehoben werden oder diese schon in den Hafen repliziert wurden. Jetzt kann die materialized view im Hafen entfernt werden. Die Tabelle im Hafen bleibt erhalten, da die materialized view als prebuilt erzeugt wurde. Die Tabelle im Hafen kann anschließend mit einem Alter Table ; der Tabellenstruktur in der Zentrale angepasst werden. Anschließend wird die materialized view mit der neuen Spalte im Hafen neu und wie ursprünglich on prebuilt table erzeugt. Zwischenzeitlich haben sich in der Zentrale Änderungsvektoren angesammelt. Eigentlich wurden diese für die Dummy-Mview aufgehoben, die wir nie refresht haben. Damit diese Änderungsvektoren trotzdem für die materialized view im Hafen wirksam werde, manipulieren wir die Zeiten der Vektoren: update MLOG$_... Set snaptime$$ = to_date('01-jan :00:00 AM'); Anschließend kann die geänderte materialized view im Hafen refresht und der entsprechenden Refreshgruppe hinzugefügt werden. Anschließend werden die kontrollierenden PLSQL-Prozedurn wieder angepasst und die Dummy-Mview entfernt.

6 18. Deutsche ORACLE-Anwenderkonferenz Beim Löschen von Spalten ist entsprechend zu verfahren, wobei darauf zu achten ist, daß erst in allen Häfen die Spalte aus der materialized view entfernt wird und dann erst in der Zentrale die Spalte gelöscht wird. Außerdem muss natürlich sichergestellt sein, dass die Anwendung nicht mehr auf die Spalte zugreift. Database 8. Kontaktadressen Jörg Grade Matthias Penzlin Dr. Karl Prott Scandlines AG sd&m AG sd&m AG Hochhaus am Fährhafen Lübecker Straße 128 Lübecker Straße 128 D Rostock-Warnemünde D Hamburg D Hamburg Telefon: +49(0) (0) (0) Fax: +49(0) (0) (0) Internet: