Systemumstellung eines Gepäckdaten- Management-Systems unter HP OpenVMS von Oracle8i OPS auf Oracle9i RAC

Transkript

1 Systemumstellung eines Gepäckdaten- Management-Systems unter HP OpenVMS von Oracle8i OPS auf Oracle9i RAC Georg Konopik Kundenberater Datenbanken HP Consulting & Integration Niederlassung München Fraport AG Eigentümer und Betreiber des Flughafens Frankfurt Kennzahlen HP Deutschland Jahr 2000! ca. 50 Millionen Passagiere! ca Flugbewegungen Daten und Fakten zum neuen Unternehmen! ca. 1.6 Millionen Tonnen Fracht Langjähriger HP Kunde 1 2 1

2 Anwendung + Gepäckdaten-Management- System (BODB) Aufgaben! Steuerung und Überwachung Flug- und Gepäckabfertigung! Verwaltung von verdächtigem und nicht abgeholtem Gepäck! Research System! Disposition Ankunftsbandvergabe! Weiterleitung von Informationen Softwareumgebung! OpenVMS! Oracle! MQ-Series! MetaObject! Java RTE! Visual Basic-, Java- und C- Anwendungen 4 Überblick Anwendung Airline-Host 1 INFO/FIDS BRS... SITA- Gateway SITA Airline-Host 2... Fraport-LAN Airline-Host n Schnittstelle Schnittstelle... Schnittstelle BOIT Daten BODB Schnittstelle... Schnittstelle Schnittstelle Schnittstelle Fraport-LAN TR OB TB... XY... -Arbeitsstation -Arbeitsstation Fraport AG 5 2

3 BODB Anwendung! Alle Daten aus externen Quellen werden durch MQ-Series entgegengenommen und in Queues abgelegt! Schnittstellenprozesse lesen Nachrichten aus Queues! enthalten Informationen über Gepäckstücke, Container, Flugdaten, Förderanlagen etc.! Überwachungsprozess! überwacht alle Anwender-, MQ- Series- und Oracle Prozesse! Disponenten! ca. 20 Online Benutzer! Schnittstellen zu! zentrales Fluginformationssystem! Gepäcksystemverbund! Baggage Reconciliation System! Ankunftsbandanlagen 6 Altsystem Anwendung OpenVMS Cluster redundante Hardware zwei AlphaServer 1200 Rechner mit je MHz CPUs HSZ70 RAID Kontroller OpenVMS Gepäckdaten 7.2 Management System (BODB) Oracle Datenbank Oracle8i (8.1.7) OPS Aktiv-Aktiv Konfiguration Datenbank auf Dateisystem Gründe für Migration HW hatte Leistungsgrenze erreicht keine weitere Steigerung der Last möglich Ausfall einer Maschine konnte von zweiter nicht vollständig aufgefangen werden Oracle8i OPS lief nicht stabil 7 3

4 Auswahlkriterien Neusystem! Ausfallsicherheit! Cluster! keinen SPOF! Performance! ein Rechner muss komplette Last abdecken können! Umschaltzeit < 3 Minuten! Erweiterbarkeit und Skalierbarkeit! CPU, Hauptspeicher und Storage! Einfacher Migrationspfad! Möglichst kein Programmieraufwand! Rückfallmöglichkeit! Investitionssicherheit Marktpositionen HP Deutschland 8 Neusystem Aufgrund der sehr guten Erfahrungen mit Stabilität, Ausfallsicherheit und Systemmanagement wurde ein OpenVMS Cluster gewählt! zwei AlphaServer ES45 Rechner! je eine CPU mit 1GHz! alle HW Komponenten redundant ausgelegt! SAN Storage! OpenVMS 7.3 Oracle Datenbank! Oracle9i Release 1! Real Application Cluster RAC 9 4

5 Migrationsweg HW + SW Installation des Neusystems Oracle9i Installation und Aufbau der Datenbank Portierung der Anwendungssoftware Funktionale Tests Leistungstests Migration der Datenbank Inbetriebnahme 10 Migration HW & SW Installation Bei und durch HP Partner COS Concat mit Unterstützung von HP Anpassungen für die Fraport Systemumgebung Oracle9i Datenbank Installation und Aufbau Vorbereitung der Leistungstests Anpassungen der Systemparameter Neue Oracle Eigenschaften Oracle und HP Standard Software Installation Setup Fraport Anwendungssoftware Installation der Entwicklungsund Laufzeitumgebung Funktionaler Test aller Softwarekomponenten Fraport 11 5

6 Leistungstests Allgemeine Bemerkungen! Vergleich von Oracle8i OPS zu Oracle9i RAC ist aufgrund der unterschiedlichen HW nicht möglich! Ziel war die Ermittlung der Leistungsfähigkeit der neuen HW/SW Umgebung Leistung des Altsystems! Ermittlung der CPU Auslastung für einen Tag X Vorbereitung für Lasttests auf Neusystem! Backup der Datenbank am Tag X! Protokollierung aller externen Nachrichten, Anzahl und Typ der Datenbankabfragen Leistung des Neusystems! Einspielen Datenbankbackup vor jedem Test! Zeitlich gesteuertes Schreiben der Nachrichten in die Queues! Ausführen der Datenbankabfragen durch Batchjobs! Messung der CPU Belastung Erwartetes Ergebnis aufgrund der SPECint Vergleichswerte Testergebnisse! Ratio Alt zu Neusystem 1:1,67 Gemessene CPU Auslastung Altsystem! 51% von zwei CPUs Gemessene CPU Auslastung Neusystem! 20% von einer CPU Dies entspricht einen Ratio von 2,5 Gründe! Last am Neusystem war etwas geringer als auf Altsystem! Schnellerer I/O Subsystem! Neue Oracle Software! Neue Oracle Eigenschaften wurden verwendet 13 6

7 Inbetriebnahme und Produktion Inbetriebnahme! Nur Übernahme der Daten war notwendig! Export/Import! Zeitdauer des Umstiegs! 8 Stunden davon 6 für Datenübernahme (15 GB)! während Wartungsfenster Rückfallmöglichkeit! Altsystem stand zur Verfügung! Nur Aktualisierung der Daten notwendig Produktionsstart! August `02! verlief Problemlos Produktion! CPU Auslastung der beiden Maschinen beträgt ca. 35%! konnte durch Einsatz von materialized views für häufig benutzte Abfragen um ca.15% reduziert werden Oracle9i RAC Konfiguration und Failover der Anwendung Aktiv-Aktiv Konfiguration! Lese- und Schreibtransaktionen auf beiden Instanzen! Verteilung der Prozesse mit modifizierenden Zugriffen nach Aufgabengebiet Failover Clients! Visual Basic/OLE-DB Anwendungen über TAF Failover=select, type=basic! MQ-Series Server: automatisch durch Produkt abgedeckt! MQ-Series Client: Anwendungen führen reconnect im Programm durch Failover Serverprozesse! Cluster Funktionalität von MQ-Series! startet Interfaceprozesse auf verbleibender Maschine! setzt virtuelle IP-Adresse für Clients! führt Fallback durch! 14 7

8 Probleme Oracle9i RAC Installation Intelligent Agent lief nicht auf beiden Maschinen Registrierung des Listener auf der 2ten Netzwerkkarte war problematisch Probleme auf Clients ORA-600 Fehler auf JDBC Clients behoben durch aktuellen JDBC Treiber Probleme auf Server Starten der 2ten Instanz funktioniert manchmal nicht Anwendungsprozesse bleiben manchmal beim disconnect bestehen Sonstiges Keine Unterstützung von WORKAREA_SIZE_POLICY=AUTO unter OpenVMS 16 Erfahrungen SW-Migration Problemlos Keine Änderung der Sourcen notwendig Neu Linken und Binden wegen neuer Oracle Client Library Performance Sehr gutes Antwortzeitverhalten Abarbeiten der Queues nach Problemen wesentlich schneller Oracle Einfache Portierung Stabilität bisher kein Absturz Keine Probleme mit RAC Akzeptanz Benutzer Sehr hoch Antwortzeitverhalten und Stabilität 17 8

9 Fazit! Erfolgreiche Migration ohne größere Probleme! Leistungsanforderungen wurden erfüllt! Sorgfältige Planung und Tests sind wichtig! Beratungsleistungen durch HP Consulting & Integration waren wichtig! Erste Oracle9i RAC Produktionsumgebung auf OpenVMS in Europa! Aufgrund der guten Erfahrungen ist Fraport Referenzkunde für Oracle und HP! HP verfügt über die meisten Oracle9i RAC Installationen weltweit und somit über entsprechende Erfahrungen 18 9