Erfahrungsbericht, Konsolidierung und Administration Real Application Cluster
Themen Über mich Projekt RAC bei Heine Probleme Resultate Fragen 2
Über mich virtual7 GmbH Jürgen Bouché Zeppelinstraße 2 76185 Karlsruhe Tel.: +49 (721) 619 017 0 Fax.: +49 (721) 619 017 29 Email: bouche@virtual7.de Seit 5 Jahren betreue ich die gesamte Oracle Infrastruktur (Application Server, Portal, DB und RAC) für die Heinrich Heine GmbH Karlsruhe 3
Projektübersicht 05.2007 Start des Projektes 05.2007 Analyse des IST & SOLL Systems 05.2007 DataGuard oder RAC 06-09.2007 Beschaffung der Hardware, Konzeption 09.2007 Installation & Testmigration (der 4 wichtigsten Systeme) 01.10.2007 Abnahme des Systems 11.2007 50% aller Anwendungen migriert bis heute 85% aller Anwendung migriert 4
Start des Projektes Startschuss Anfang Mai Gründe für die weitreichende Veränderung des Systems > 3 der wichtigsten Systeme waren mit dem alten Konzept an ihre Grenzen gestoßen Unzureichend verfügbarer Speicherplatz Performance ungenügend Hardware zu alt (teilweise über 5 Jahre) > personelle Veränderungen 5
Analyse IST System 1/4 ca. 20 DB Server unterschiedliche Betriebssystemstände > Redhat 2.1 > Redhat 3 > Redhat 4 > Sun Solaris > Windows NT & 2000 unterschiedliche Oracle Versionen > Oracle 8i (8.0.5.0.0) > Oracle 9i (9.2.0.2, 9.2.0.4, 9.2.0.5) > Oracle 10g (10.1.x) > Oracle 10g R2 (10.2.0.3) 6
Analyse IST System 2/4 unterschiedliche Hardware jeder Server diente einem bestimmten Zweck > ca. 20 verschiedene SID s Storage: Lokale Festplatten mit RAID 1 oder RAID 10 Kein zentrales Monitoring, lokale EM s Prinzip der Anschaffung: Neuer Dienst => Neuer Server geringe Nutzung der verfügbaren Ressourcen 7
Analyse IST System 3/4 Übersicht über das kleine Chaos Migrationsumfang einschätzen Speicherplatzbedarf kalkulieren Sicherungsbedarf feststellen Konsolidierungsmöglichkeiten für Systeme 8
Analyse IST System 4/4 2.1 3.0 4.5 2.1 2.1 2.1 3.5 3.0 2.1 2.1 2.1 2.1 4.0 2.1 3.5 2.1 2.1 9
Anforderungen & Ziele (SOLL) Server und Datenbanken sollten sukzessive zusammengefasst und auf Oracle 10g migriert werden. Darüber hinaus sollte eine Infrastruktur entstehen, die ohne hohen Personalaufwand administriert werden kann. Verfügbarkeit, Ausfallsicherheit und Lastverteilung der Datenbanken standen im Mittelpunkt der Überlegungen. 10
DataGuard oder RAC als Lösung 1/2 Vorteile Verfügbarkeit Bedingt skalierbar Lesender Zugriff auf Logical Standby Nachteile keine echte Lastverteilung Umschalten auf Standby mit Script, dauert einige Minuten 11
DataGuard oder RAC als Lösung 2/2 Vorteile Hochverfügbarkeit Voll skalierbar Lastverteilung kein Umschalten bei Ausfall Nachteile Kosten gegenüber DataGuard kein KnowHow 12
Hardware Serverraum 1 Serverraum 2 Interconnect DL585 DL385 DL380 DL385 DL585 DL585 DL385 DL385 SAN Grid DL360 13
Hardware 4 Knoten + 1 Grid zu Begin > 3x HP DL585 G2 (2x AMD Opt. 2,4 mit 8GB Ram) > 1x HP DL380 G4 (2x Xeon 3,2 mit 4GB Ram) > 1x HP DL360 G4 (1x Xeon 3 mit 2GB Ram) Ausbau auf 6 Knoten > 2x HP DL385 (2x AMD Opt. 2,6 mit 16GB Ram) Änderungen > 3x HP DL585 G2 auf 24GB Ram > 1x HP DL380 G4 ersetzt durch 1x HP DL385 (wie oben) > 1x HP DL360 G4 ersetzt durch 1x HP DL380 G4 (Grid) Ausbau auf 7 Knoten geplant für Q1 2008 14
Installation Vorraussetzungen > Installiertes OS > Public, Private, Virtual IP > Interconnect (Private LAN) > SAN Verbindung und Storage inklusive der Voting Disks und Cluster Registry Installation Cluster Ready Services Installation Datenbank Software Konfigurieren von ASM Konfigurieren der Instanzen Installation Grid Agent 15
Migration Selbstgeschriebenes Script (migrate.sql) startup restrict Export aller User Export aller Rollen Export aller Public Synonyms Export aller Grants Full Export der Daten Die Exporte erfolgen als fertige SQL Scripte die zum Import in das neue System genutzt werden können 16
Installation & Testmigration Die Systeminstallation an den 4 Knoten und Aufsetzen des Grids, sowie die Einrichtung des Storages erfolgten im Vorfeld, um die eigentliche RAC Installation nicht zu behindern Die Testmigrationen erfolgten Nachts Installation und Testmigration war mit 10 Tagen geplant, konnten allerdings nach bereits 8 Tagen erfolgreich abgeschlossen werden Die umgestellten Anwendungen wurden danach intensiv getestet 17
Abnahme Erfolgte am 01.10.2007 Geprüft und abgenommen wurden: > Funktionalität > Hochverfügbarkeit > Backup Tests wurden wirklich am produktiven System durchgeführt 18
Das System heute 6 DB Server + 1 Grid Control Server Betriebssystem: Oracle Linux 4.5 (64bit) Oracle Versionen: 10g R2 (10.2.0.3 - Umstieg auf 10.2.0.4 in Planung) Cluster erfüllt alle Anforderungen > Konsolidierung auf 7 SID s (Export, Portal, Apps, DWH, usw.) Storage: HP EVA 5000 & HP EVA 6000, Anbindung über FibreChannel Grid Control (10.2.0.4) als zentrales Monitoring 19
Vorher Nachher 20
Vorher Nachher Serverraum 1 Serverraum 2 Interconnect DL585 DL385 DL385 DL585 DL585 DL385 SAN 21
Probleme Lago Tuning Anwendung wesentlich langsamer wegen parallel query dadurch hin und wieder ORA-600 bzw. ORA-7445 Grid Control & Agent Probleme Sammelte nicht alle Werte bzw. unmögliche Werte (z.b. negative CPU Auslastung) Erneuern des Grid Repositorys 1 Knoten ist eingefroren 2 Port FC Karten, 1 Port war defekt beim Switch auf den 2. Port schmierte der Server ab HP Insight Manager auf Oracle Linux 4.5 Kein Support?! 22
Resultate Administrativer Aufwand senkte sich deutlich Die Zentrale Verwaltung und Überwachung mit Grid Control zeigen Wirkung, genauso wie die einheitliche Systemumgebung! Fehler an Knoten können ohne kritische Ausfälle behoben werden Räumliche Trennung, Brandschutz Das Online Backup mit RMAN erlaubt einen lückenlosen 24/7 Betrieb Einheitliches Backupkonzept für alle Instanzen Stromverbrauch senkt sich 23
Fragen Fragen? 24