Erfahrungsbericht Eine Architektur für ausfallsichere Systeme in standortübergreifenden Multiserver-Umgebungen

Transkript

1 Erfahrungsbericht Eine Architektur für ausfallsichere Systeme in standortübergreifenden Multiserver-Umgebungen Hamburg, 30. März 2007 Andree de Boer 1.0

2 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Das System in der Praxis

3 Fakten zum System Integriertes Buchungs- und Ticketingsystem für eine Fährgesellschaft (insgesamt wurden 8 verschiedene Systeme ersetzt) Das zentrales fachliche Objekt des Systems ist der Service Ein Service kann u. a. folgendes beinhalten: Fährprodukte mit Route (bestehend aus einem oder mehreren sog. Legs) zusätzliche Produkte (Kaffee-Gutschein, Dinner, etc.) Kabinenprodukte (auf Fähren / Routen mit Kabinen) externe Produkte (Freizeitparks, Hotels, Brückenmaut, etc.) Aufschläge (Überlänge, -breite, -gewicht; Treibstoffzuschlag, etc.) Ein Service kann im Voraus gebucht oder direkt beim Einchecken angelegt werden (ShowGo). 16 Häfen + 1 Zentrale Alle Services (egal mit welchen Abfahrts- und Ankunftshäfen) sind in allen Häfen bekannt 3 sd&m,

4 Das System unterstützt alle wesentlichen operativen Prozesse Stammdaten pflegen Service buchen Service einchecken Customer Oriented Advanced Service- and Transport System Service bezahlen Ticket ausstellen Spur zuweisen sd&m,

5 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Das System in der Praxis

6 Technische Herausforderungen des Systems 1 2 Performance CheckIn-Zeit < 20 s 4000 Services/h Zentrale Datenhaltung Kapazitätsmgmt Überbuchungen vermeiden Verfügbarkeit Komplexität Autarke Häfen Produkt- und 24x7x365-Betrieb Tarifstruktur rechenintensive 3 Operationen 4 6 sd&m,

7 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Das System in der Praxis

8 Die operativen Anforderungen führten zu einer verteilten Lösung: Zentrale und Häfen identisch, hochverfügbar CSS CSS Masterdata Maintenance CSS CSS externe Systeme Hafen C 1 MBit/s Zentrale DB- Cluster Hafen B 1 MBit/s DB- Cluster Hafen A Häfen autark bei WAN-Ausfall zustandslose Appl.-Server DB-Cluster CSS für Lastverteilung und Failover DB-Replikation 8 sd&m,

9 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Das System in der Praxis

10 Architektur Client Kommunikation Anwendungskern Persistenz Hafen Kommunikation Anwendungskern Persistenz Zentrale 10 sd&m,

11 Überblick T-Architektur: Kommunikation und Delegation Client (in der Zentrale) Dynam. Proxy Sender Client (im Hafen) Dynam. Proxy Sender Client A-Software 0-Software T-Software R-Software Empfänger Dispatcher Anwendungskern Sender Persistenz Replizierte Datenbank Hafenserver in Zentrale ungenutzt Empfänger Dispatcher Sender Anwendungskern Persistenz Master Datenbank Zentralserver 11 sd&m,

12 Delegationsstrategien Strategie Normalbetrieb Bei WAN Ausfall Beispiel READ_LOCAL_ONLY Lokal lesen Lokal lesen Hafenspezifische Daten WRITE_LOCAL_ONLY Lokal schreiben Lokal schreiben Hafenspezifische Daten READ_CENTRAL_ONLY Zentral lesen Fehler Nicht replizierte Daten (Reports) WRITE_CENTRAL_ONLY Zentral schreiben Fehler Stammdatenpflege READ_CENTRAL_ELSE_LOCAL Zentral lesen Lokal lesen Bewegungsdaten (z.b. Services) WRITE_CENTRAL_ELSE_LOCAL Zentral schreiben 1) Lokal schreiben Bewegungsdaten (z.b. Services) 2) Asynchron zentral schreiben (sobald Zentrale wieder verfügbar) 12 sd&m,

13 Replikation Zentrale Häfen RG0: Nicht repliziert RG1: 5-10 Min. Refreshgruppe 0 Refreshgruppe 1 RG2: 1-2 Min. RG3: Sek. Refreshgruppe 0 Refreshgruppe 1 Refreshgruppe 2 Refreshgruppe 3 RG4: 5-10 Sek. Refreshgruppe 2 Refreshgruppe 3 RG5: 1-2 Sek. Refreshgruppe 4 Refreshgruppe 5 Refreshgruppe 4 Refreshgruppe 5 13 sd&m,

14 Szenario Ausfallbetrieb Client Kommunikation Anwendungskern Persistenz Hafen Übergang zum Normalbetrieb Normalbetrieb Kommunikation Anwendungskern Persistenz Ausfallbetrieb Zentrale 14 sd&m,

15 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Updates Das System in der Praxis

16 Ausrollen neuer Releases Hafen Zentrale AP1 AP2 AP1 AP2 DB- Cluster DB- Cluster Alte Version Neue Version 16 sd&m,

17 Agendafolie Überblick Anforderungen Verfügbarkeit Zentrale Datenhaltung Software Updates Das Das System System in der in der Praxis Praxis

18 Das System in der Praxis Das System läuft seit 2 Jahren stabil! Statistik aus einem Tag in der Hauptsaison ,1 Millionen Geschäftsvorfälle am Tag Durchschnittliche Ausführungszeit pro Geschäftsvorfall 389 ms (inkl. Batches, Reporting) 235 Geschäftsvorfälle wurden nach einem Ausfallbetrieb nachgezogen Probleme Java-Architektur: Speicherverbrauch pro Thread nicht ermittelbar Externe Schnittstellen: Hohes unkontrollierbares Datenaufkommen auf der operativen Serverinstanz Reporting: Temporäre Lösung führt zu Problemen, da auf operativen Daten gearbeitet wird. Was hat bei Problemanalysen und beim Betrieb geholfen? Historisierung, Logging, Managementkonsole, Überwachungsmechanismus, 18 sd&m,

19 "Menschen machen Projekte" sd&m AG software design & management Lübecker Str Hamburg Tel