Pilotierung SAP auf ORACLE RAC Stadtwerke München

Transkript

1 Pilotierung SAP auf ORACLE RAC Stadtwerke München 1

2 Unternehmen Stadtwerke München 2

3 Die Stadtwerke München... Das Unternehmen stehen für eine zuverlässige, sichere Versorgung mit Strom, Wasser, Erdgas und Fernwärme stehen für Multi Utility und Komplettservices aus einer Hand versorgen rund 1,6 Mio. Kunden mit Energie und Wasser bieten attraktive und wettbewerbsfähige Produkte und Dienstleistungen 3

4 Die Stadtwerke München... Das Unternehmen bieten ihren Kunden eines der besten Trinkwasser in ganz Europa stehen für das modernste Bäderangebot Bayerns: 17 Hallen- und Freibäder verfügen über das am besten ausgebaute Nahverkehrsnetz Europas 4

5 Die Stadtwerke München... sind bundesweit die Nummer 1 unter den kommunalen Unternehmen sind der Umwelt verpflichtet und wahren ökologische Grundsätze Das Unternehmen tragen dazu bei, dass München zu den führenden Wirtschaftsstandorten Europas zählt 5

6 SWM Gruppe und verbundene Unternehmen Stadtwerke München GmbH 100 % SWM Versorgungs GmbH Bayerngas GmbH 45 % 100 % SWM Infrastruktur GmbH citiworks AG 50 % 100 % SWM Services GmbH Erdgas Südbayern GmbH 50 % 100 % MVG - Münchner Verkehrsgesellschaft mbh Gasversorgung Haar GmbH 50 % 100 % SWM Consulting und Service GmbH aquakomm GmbH & Co. KG 30 % 49,99 % M net Telekommunikations GmbH Kommunale Energie Allianz Bayern GmbH 18,52 % 6

7 SWM in Zahlen SWM als Wirtschaftsfaktor Anzahl Mitarbeiter: rund Umsatz: Stromleitungsnetz: Erdgasnetz: Wassernetz: Fernwärmenetz: 2,949 Milliarden Euro ca km mit Netztrafostationen ca km ca km ca. 590 km 589 km MVG-Netz 79 Linien und 886 Fahrzeuge ca. 450 Millionen Fahrgäste pro Jahr, d. h. mehr als eine Million Fahrgäste nutzen täglich U-Bahn, Bus und Tram 7

8 SAP Systemumgebung vor RAC 8

9 Ausgangssituation OS Windows 2000 Microsoft Cluster Zusätzliche Software BMC / Patrol EDM NT-Client Backint für SAP SAP Release 4.6C AddOn IS-U/CCS 4.64 PlugIn - PI 2002_2_46C Public- Transport - Release 1.2 9

10 SAP-R/3 Produktivsystem vor RAC DV2 BR Connectrix Connectrix 3 Applikationsserver Standby 3 Applikationsserver Sicherungsserver SRDF Symmetrix DMX 3000 Symmetrix DMX 3000 EDM 10

11 DB - Kennzahlen bei SWM Entwicklung Qualitätssicherung SWI Oracle ca. 200 GB SWK Oracle ca GB Schulung Produktion SWT Oracle ca GB SWP Oracle ca GB Monatl. Wachstum ca. 50 GB 11

12 Motivation Keine Skalierbarkeit bei Windows 2000 möglich Performance Probleme Serverkonsolidierung (DB-Host und eigene Applikationsserver) Speichererweiterung nicht mehr möglich Ausfall eines Nodes betrifft alle User Ausfallzeit beim Failover der Clustergruppen Storageerweiterung sehr aufwendig Laufwerksbuchstaben Größe Metadevices Probleme mit Signaturen der Clusterplatten 12

13 Warum Oracle RAC? Skalierbarkeit Höhere Verfügbarkeit / Ausfallsicherheit Performance Steigerung (Aktive-Aktive Nodes) Serverkonsolidierung / Kosten (DB-Host mit Applikationsserver) Memory (SGA verteilt sich auf 3 Nodes) Ausfall eines Nodes betrifft max. 33% der User Know How an RAC-Systemen mit OCFS vorhanden Positive Erfahrungen durch Betrieb von zwei produktiven RAC- Systemen 13

14 Pilotierung Start April

15 Partner Oracle SAP DELL EMC² SWM 15

16 Hardware-Konfiguration Hardware 5 DELL PowerEdge Server mit 4 x 2790 GHz / 8 GB Memory - 2 Server mit 4 x 2790 GHz / 4 GB Memory OS Windows 2003 Microsoft Cluster 2003 Zusätzliche Software BMC / Patrol Legato NetWorker Backint für SAP Redundantes Netzwerk 1 Gbit Public Privat OIC MS - Heartbeat Redundante Anbindung zu EMC² 16

17 Logische Sicht 17

18 Oracle & SAP Installation Mai 2004 OCFS Oracle Cluster RDBMS Oracle SAP Release 4.6C Zentralinstanz im MS-Cluster auf den 3 RAC- Nodes SAP-Appl. - Server 18

19 Dateisystem OCFS Datenfiles, werden über logische Links angesprochen Oracle-Home Online-Log s Offline-Log s Trace-Verzeichnisse NTFS SAP-Zentralinstanz (MS-Cluster-Gruppe) Transportverzeichnis SAPMNT / SAPLOC RAW Device srvcfg 19

20 Datenübernahme für Tests Abzug der produktiven Daten mit EMC² BCV (Split / Mirror Technik) Paralleler RoboCopy von NTFS nach OCFS Dauer ca. 15 Std. über Privat- und Public- LAN 1 Gbit Wiederaufsetzen des Kopiervorgangs möglich 20

21 Test Hardwareausfall Netzwerkkomponenten Physikalische Leitungen von Public oder Privat Physikalische Leitungen von OIC oder MS-Heartbeat Ausfall oder Teilausfall der Switches Ausfall der Teaming Software Intel ProSet EMC² - Komponenten Physikalische Leitungen zu EMC² Physikalische QLogic - Karten Ausfall von EMC² Software PowerPath Ausfall von Netzteilen Ausfall kompletter Server 21

22 Test Softwareausfall RAC - Instancen Shutdown immediate Shutdown abort Kill Kill Clustermanager an jeder RAC - Node SAP - Application Failover - Switch der Zentralinstanz Reconnect - Shutdown immediate - Shutdown abort - Kill Kill Clustermanager an jeder RAC - Node 22

23 Erste Testergebnisse Juni 2004 Performanceprobleme auf allen RAC-Nodes RAC-Nodes laufen instabil RAC-Nodes waren nach kurzer Zeit nicht mehr administrierbar Instanzabbrüche an allen RAC-Nodes 23

24 Taskforce ab Juli 2004 Wöchentliche Telefon - Konferenz aller beteiligter Partner Einbeziehung der Fa. Microsoft Massnahmen Mehrmalige Datenübernahme Oracle und SAP System wiederholt aufgebaut Neuinstallation - Server - Netz- und Clusterkomponenten - Oracle und SAP Update von Treibern und Firmware OCFS bei Problemanalyse als Verursacher identifiziert! 24

25 OCFS Bug s bei SWM Index-Korruption in den OCFS - Directories Startup der Instanzen ORA-0600 bis zu einer Std. OCFS-Dateisystem voll Dateien können nicht gelöscht werden Dateien werden angezeigt, sind aber physikalisch nicht vorhanden Probleme in der Freiplatzverwaltung von OCFS Dismount- und Mount-Probleme Keine Reaktionen an den anderen RAC-Nodes Performance-Probleme beim I/O-Stack Handhabung der Maschinen usw. 25

26 Aktivitäten der Fa. Oracle Fehleranalyse von Oktober 2004 bis Januar 2005 Remote von Februar bis April 2005 vor Ort, Intensive Lasttests am RAC-System Ausgiebige Tests von Bugfixes Seit April 2005 Finalversion OCFS

27 Finale Test s Hardware Software Systemverbund Datenübernahme Standby System Backup und Restore Szenario 27

28 Migrationsbegin mit Aufbau SAP-Auskunftsystem Migrations-Zeitplan Freitag Samstag ab 20 : 30 Uhr Stop SAP- und Datenbank ca. 21:00 Uhr BCV-Sicherung ca. 23:00 Uhr RoboCopy NTFS nach OCFS ab 14:00 Uhr Migration Single DB zu RAC ca. 17:00 Uhr Migration SAP-System ca. 20:00 Uhr Interne Tests Sonntag ab 09:00 Uhr Abnahmetests durch Abteilungen ca. 14:00 Uhr Zoning an EMC² Box ca. 15:00 Uhr Aufbau StandBy-System Migrationsende Sonntag ca. 18:00 Uhr 28

29 DV2 / 1 SAP-R/3 Produktivsystem mit RAC 3 Oracle RAC Server MS/Cluster SAP-CI 2 Applikationsserver BR Connectrix StandBy Server 2 Applikationsserver Connectrix 1 Applikationsserver Sicherungsserver Symmetrix DMX 3000 SRDF Symmetrix DMX 3000 EDM 29

30 Erfahrung mit RAC ab Juni 2005 Skalierbarkeit Hochverfügbarkeit / Ausfallsicherheit Performance Steigerung (Aktive-Aktive 3 Nodes) Serverkonsolidierung / Kosten (DB-Host und Applikationsserver) Memory (SGA verteilt sich auf 3 Nodes) Ausfall eines Nodes betrifft max. 33% der User 30

31 Neue Projekte Aufbau eines zentralen RAC-Systems Oracle Standard Edition + ASM Aufbau eines zentralen RAC-Systems für Internet-Applikationen Oracle Standard Edition + ASM Probebetrieb eines RAC-Systems für Projekt MDE Oracle Standard Edition + ASM 31

32 Vielen Dank für Ihre Aufmerksamkeit Fragen & Antworten 32