Migration und Betrieb unter SLES9/Steeleye Cluster auf XFS und NetApp

Transkript

1 Migration und Betrieb unter SLES9/Steeleye Cluster auf XFS und NetApp Rainer Freis science + computing ag IT-Dienstleistungen und Software für anspruchsvolle Rechnernetze Tübingen München Berlin Düsseldorf

2 science + computing auf einen Blick Gründungsjahr 1989 Umsatz 07/08 26 Mio Mitarbeiter 270 Standorte Tübingen München Berlin Düsseldorf Partner Japan: Daikin Industries Italien: NICE srl USA: Exa Corporation Kanada: Platform Computing Seite 2

3 Anspruchsvolle Rechnernetze effizient nutzen s+c Kernkompetenzen Seite 3

4 Referenzen Automobilindustrie Mikroelektronik Luft- und Raumfahrt Lifescience Öffentlicher Dienst IT-Dienstleister Seite 4

5 Alte Architektur Seite 5

6 Gründe für die Migration Server zu alt Hohe Wartungskosten Performance genügt mittlerweile nicht mehr den Ansprüchen Wechsel der strategischen Plattform Wechsel von SUN Solaris zu SuSE Linux Enterprise Server Umstieg auf neue Oracle-Versionen Oracle mittlerweile ohne Support Verstärkt Anfrage nach Oracle 10g aus Applikationsbetrieb heraus Konsolidierung der Datenbankinstanzen Seite 6

7 Projektumfang Planung Aufgaben: Konzepterstellung für den Aufbau der künftigen Oracle-Umgebung detaillierte Planung der neuen Oracle-Umgebung Erstellen eines Backup-Konzeptes Erstellen eines Audit-Konzeptes und Auswahl der sinnvollen Optionen drop create von sys und system Erstellen von Vorgaben zur Parametrisierung der Datenbank Seite 7

8 Projektumfang Migration Aufgaben: Unterstützung bei der Migrationsplanung Unterstützung der Applikationsverantwortlichen bei der Migration, vor allem beim Testen Durchführen der Datenmigration auf die neue Plattform Davon getrennt: Der eigentliche Betrieb (inklusive Installation) der Oracle DB erfolgt durch einen externen Dienstleister Seite 8

9 Neue Architektur Seite 9

10 Migrationsschritte Test Aufbau der Testmaschine Installation und Konfiguration der Testinstanzen Applikationsweise Migration der alten Testumgebung auf die neue Testmaschine Applikationstests und Durchführung der notwendigen Anpassungen Seite 10

11 Migrationsschritte Prod Aufbau des produktiven Clusters und Durchführung der Clustertests Installation und Konfiguration der Produktivinstanzen und ausführliche Tests bzgl. Data Guard und Backup Applikationsweise Migration der Produktivumgebung Seite 11

12 Cluster ohne RMAN Seite 12

13 Probleme in der Testumgebung 1 OUI benötigte andere Java-Version als in SLES9 SP3 vorhanden Patch für OUI Oracle 9.2 unter Itanium nötig Probleme mit Export / Import unter Oracle 9i Export mehrerer User aus mit Oracle Client funktioniert Anschließender Import in funktioniert nicht Export / Import funktioniert nur, wenn beides mit DBA-Rechten ausgeführt wurde Seite 13

14 Probleme in der Testumgebung 2 Rechte der Standard-Rollen in Oracle 9i und 10g unterschiedlich (connect) Undokumentierte direkte Zugriffe von Datenbankusern auf andere Schemata Unklare Applikationsverantwortung wegen Personalwechsel Seite 14

15 Probleme in der Produktivumgebung 1 Probleme mit Clustersoftware und Anbindung der Festplattenressourcen (Software nur 32bit und wegen Itanium2 in Emulationsmodus) XFS (ArchiveLogs) mehrfach vollgelaufen, Filesystem hängt und Reboot notwendig Probleme mit pre allocation bei mehr als 90% Füllstand In SLES10 behoben Wegen Oracle 9i Backport auf SLES9 notwendig Seite 15

16 Probleme in der Produktivumgebung 2 RAID Speed Limit maximiert für schnelle Wiederherstellung nach Plattenfehlern führt zu Performanceproblemen mit Data Guard max open files (fs.file-max) von nicht ausreichend wegen Anzahl der Instanzen OS-Pakete für async I/O mussten nachinstalliert werden (inkl. Oracle Patches) Seite 16

17 Probleme in der Produktivumgebung 3 Performanceeinbußen Tivoli Monitoring wegen Itanium2-Bug sehr hohe CPU-Last durch Tivoli Monitoring Agents RMAN zu langsam für ArchiveLogs Definition der Thresholds für das Monitoring sowohl Instanzen mit statischen als auch solche mit sehr dynamischen Daten Seite 17

18 Probleme in der Produktivumgebung 4 Testinstanzen keine exakte Kopie der Produktivinstanzen Konfigurationsunterschiede Unterschiede in Datenmenge und zusammensetzung undokumentierte Database Links und Private Synonyms Bei Umstieg auf UTF-8 z.t. Probleme mit Feldlängen bei Längenbeschränkung auf Byte-Basis Probleme mit Sonderzeichen Seite 18

19 Resümee 1 Kein Big Bang, sondern applikationsweise Migration Kein Zeitdruck, dadurch ausführliche Tests möglich Gleichzeitiger Wechsel von Betriebssystem und Datenbankversion möglich Wahl einer exotischen Konfiguration vertretbar Applikationsverantwortliche wurden gezwungen, dokumentierte Testpläne zu erstellen auch für künftige Patches / Upgrades Seite 19

20 Resümee 2 Einige Applikationen fielen weg Verwenden eines IP-Aliases pro Instanz, daher Clusterswitch instanzweise möglich allerdings: erhöhter Aufwand für Monitoring pro Instanz eigener Tivoli Agent Auditing: anfallende Datenmenge unklar Seite 20

21 Ausblick Statistiken für künftige Tuningmaßnahmen müssen erstellt werden Hardware wird erweitert (verdoppelt) Weitere Instanzen werden auf die Datenbankserver umgezogen Angedacht: Einführung von Oracle 11g ab Ende 2009 Seite 21

22 Vielen Dank für Ihre Aufmerksamkeit. Vortrag von: science + computing ag Telefon: info@science-computing.de