Erfahrungsbericht, Konsolidierung und Administration Real Application Cluster

Transkript

1 Erfahrungsbericht, Konsolidierung und Administration Real Application Cluster

2 Themen Über mich Projekt RAC bei Heine Probleme Resultate Fragen 2

3 Über mich virtual7 GmbH Jürgen Bouché Zeppelinstraße Karlsruhe Tel.: +49 (721) Fax.: +49 (721) 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

4 Projektübersicht Start des Projektes Analyse des IST & SOLL Systems DataGuard oder RAC Beschaffung der Hardware, Konzeption Installation & Testmigration (der 4 wichtigsten Systeme) Abnahme des Systems % aller Anwendungen migriert bis heute 85% aller Anwendung migriert 4

5 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

6 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 ( ) > Oracle 9i ( , , ) > Oracle 10g (10.1.x) > Oracle 10g R2 ( ) 6

7 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

8 Analyse IST System 3/4 Übersicht über das kleine Chaos Migrationsumfang einschätzen Speicherplatzbedarf kalkulieren Sicherungsbedarf feststellen Konsolidierungsmöglichkeiten für Systeme 8

9 Analyse IST System 4/

10 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

11 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

12 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

13 Hardware Serverraum 1 Serverraum 2 Interconnect DL585 DL385 DL380 DL385 DL585 DL585 DL385 DL385 SAN Grid DL360 13

14 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 Q

15 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

16 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

17 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

18 Abnahme Erfolgte am Geprüft und abgenommen wurden: > Funktionalität > Hochverfügbarkeit > Backup Tests wurden wirklich am produktiven System durchgeführt 18

19 Das System heute 6 DB Server + 1 Grid Control Server Betriebssystem: Oracle Linux 4.5 (64bit) Oracle Versionen: 10g R2 ( Umstieg auf 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 ( ) als zentrales Monitoring 19

20 Vorher Nachher 20

21 Vorher Nachher Serverraum 1 Serverraum 2 Interconnect DL585 DL385 DL385 DL585 DL585 DL385 SAN 21

22 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

23 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

24 Fragen Fragen? 24