Praxisbericht: Extended Distance RAC 11g

Transkript

1 Praxisbericht: Extended Distance RAC 11g Andreas Ellerhoff Deutsche Messe Hannover Schlüsselworte: RAC, ASM, DataGuard, RMAN, Upgrade, MAA, OEM, Deutsche Messe, 11g, Solaris, Cluster, Oracle, Tuning Einleitung Die Deutsche Messe betreibt die Oracle RAC Technologie nun seit ca. 3 Jahren ohne nennenswerte Ausfälle und über 3 Rechenzentren verteilt. Zuvor wurde der Betrieb der Datenbank mit einem cold failover Cluster über 2 Rechenzentren sichergestellt. Rechenzentrum RZ1 pluto - in DMZ Zone Rechenzentrum RZ2 Rechenzentrum RZ3 Pluto1 SRDF Pluto2 neptun - im internen Netz Sicherungen neptun1 SRDF neptun2 ramses Abb. 1: Cold-Failover-Cluster Das Storage System (EMC Symmetrix) sorgte für die Verteilung der Daten. Die nur für den Notfall reservierten cold failover Server konnten bei einem Ausfall des primären Servers angefahren werden.

2 Da gerade in der DMZ unsere schnellsten und teuersten Server jährlich erneuert wurden, und eine weitere Anwendung diese Infrastruktur aus Synergieeffekten zusätzlich nutzen sollte, war der Schritt zum RAC notwendig. Mit dem RAC können nun alle Server in den jeweiligen Rechenzentren bei erhöhter Ausfallsicherheit aktiv genutzt werden. Die eingesetzte Server Hardware (3x FSC PrimePower 450 mit 4CPUs SPARC) hat alle bisherigen Anforderungen optimal abarbeiten können. Die von Oracle angekündigte Skalierung des RAC klappte perfekt. Auch das anfangs skeptisch betrachtete ASM mit host based mirroring basierter Spiegelung der Daten innerhalb der ASM DataGroups, war bzgl. seiner IO - Leistungsfähigkeit sehr ordentlich. Mit dem Solaris 64Bit Betriebssystem konnten wir das bei uns schon jahrelang bewährte Betriebssystem in der höheren Version Solaris 10 einsetzen. Public Net RZ1 RZ2 RZ3 1 KM amun1 amun3 amun2 Private Net 1 KM 1 KM Voting Disk3 1 KM Storage Net EMC Storage Tower 1 Voting Disk1 LUNs1 EMC Storage Tower 2 Voting Disk2 LUNs2 OCR1 OCR2 Abb.2: extended distance RAC mit seinen wesentlichen hardware Komponenten Im oben dargestellten Schaubild sehen sie den 3-Knoten-RAC bzgl. seiner Hardware schematisch dargestellt. Die Rechenzentren befinden sich etwa 1 km voneinander entfernt. Das nächste Schaubild zeigt die RAC Infrastruktur schematisch aus Sicht des DBA. Nun bilden die LUNs aus der EMC eine für die ASM nutzbare Diskgruppe DISK1. Es wird deutlich, dass jeder Knoten über genau eine ASM Instanz verfügt und letztendlich auch die ASM Datenbank eine Oracle Clusterdatenbank mit globalen Ressourcen ist, aber keinen direkten Zugriff für die Anwender zulässt. Die erheblich mehr Ressourcen verschlingende gewöhnliche Nutzdaten Clusterdatenbank für die Anwender verfügt über lokale und globale

3 Ressourcen. Die Kommunikationswege sind horizontal, also über den Interconnect zu den gleichartigen ClusterDB Instanzen und vertikal zum Storage (ASM Prozess) und den Anwendern (Oracle Server Prozesse). Die Listener besorgen das match making, indem sie dem Anwenderprozess die von der Last günstigste Clusterinstanz zuteilen. Unsere Bewertungskriterien haben wir auf die CPU Last beschränkt und die in den Listenern registrierten Services dementsprechend eingestellt. Um Knotenausfälle schnellstmöglich zu reparieren, werden sogenannte VIP Strukturen (virtuelle IP) benutzt. Der ausgefallene Knoten kann damit als virtueller Knoten weiterarbeiten, die tatsächliche Verarbeitung wird auf einen noch intakten übertragen. Public Net RZ1 RZ2 RZ3 1 KM ClusterDB ONS LISTENER1 LISTENER3 LISTENER2 amun1-vip amun3-vip amun2-vip DB-Instanz1 DB-Instanz3 Globale Prozesse und Resourcen ClusterDB DB-Instanz2 ASM DB Private Net ASM1 ASM3 Globale Prozesse und Resourcen ClusterDB 1 KM ASM2 1 KM Centrix Store Sicherungs Server Voting Disk3 1 KM Storage Net ASM DISK1 LUN1_15 LUN1_14 EMC Storage Tower 1 Voting Disk1 EMC Storage Tower 2 Voting Disk2 OCR1 OCR2 Abb.2: extended distance RAC bei der Deutschen Messe aus DBA Sicht Im RAC werden Knotenausfälle, Probleme mit Prozessen oder diverse andere Probleme, wie timeouts von Prozesskommunikation, in der Regel erkannt und durch die Clusterware gesteuert. Reparaturen werden möglichst automatisiert vorgenommen. Damit dies reibungslos funktioniert, bekommt der Cluster ein gespiegeltes Cluster Repository (OCR) und eine ungerade Anzahl an Voting Lokationen. Das Voting dient als Entscheidungshilfe für das Auflösen von Split-Brain Situationen. Die Deutsche Messe hat bei der Einführung von Oracle 11g noch weitere Bausteine aus der MAA Strategie von Oracle in die eigene Infrastruktur eingebaut, wie z.b. Oracle Data Guard.

4 Dieser wird zum einen als Absicherung des RAC gegen Ausfälle aller Art (Blockkorruption, write losts, etc.) in Form einer physical standby eingesetzt. Da sowohl Primary (RAC) als auch Standby DB (Single Instance) im Flashback Database ON Modus betrieben werden, kann die Standby jederzeit in eine Snapshot Standby konvertiert werden. Danach kann die Datenbank geöffnet werden und einen wertvollen Beitrag für going-life-tests, Lasttests und vieles mehr an Informationen liefern. Gerade in der Version 11g ist die Administration einer solchen Snapshot Standby Datenbank erheblich einfacher geworden. Wir verwenden hierfür den DataGuard Broker und können damit das Gebilde RAC + Data Guard als verbundenes System einheitlich administrieren. Auf ein automatisiertes Failover durch den Broker wurde verzichtet, da die RAC Infrastruktur der Deutschen Messe so komplex ist, dass in einer Fehlersituation der geschulte DBA unbedingt eine Option auf einen manuellen Eingriff haben muss. Public Net RZ1 RZ2 ONS LISTENER1 LISTENER3 LISTENER2 amun1-vip amun3-vip amun2-vip ClusterDB wwwdup DataGuard wwwppdg1 wwwpp1 wwwpp3 wwwpp2 Globale Prozesse/Resourcen ASM1 ASM3 Globale Prozesse/Resourcen ASM2 Private Net (failover bundle) RZ3 Storage Net 1 KM Distanz LUN1_15 LUN2_15 LUN3_15 LUN1_14 LUN2_14 LUN3_14 ASM DISK1 EMC Storage Tower 1 Voting Disk1 OCR1 EMC Storage Tower 2 Voting Disk2 OCR2 Voting Disk3 Abb 3: extended distance RAC bei der Deutschen Messe aus DBA Sicht nach dem Upgrade auf Oracle11g Sie sehen in dem Schaubild neben Data Guard noch eine duplizierte Datenbank wwwdup. Diese wird periodisch (z.b. alle 6h) aus den FRA Backupsets aufgebaut. Hiermit erhalten wir neben einer rudimentären Absicherung des ASM Storage auch eine Validierung der RMAN Sicherung und realistische Zeiten von Restore + Recovery in einer Desaster Situation.

5 Gründe für den Umstieg auf Oracle 11g Warum soll ein unter 10g eingefahrenes RAC System nach schon 2 Jahren wieder umgestellt werden? Natürlich stellt der Manager diese Frage und letztendlich gab es in unserem Fall eine erdrückende Vielfalt an überzeugenden Argumenten den RAC auf Oracle11g umzustellen: 1. Die Kosten für das Upgrade konnten extrem niedrig gehalten werden, da auf das eigene Personal und Know How zurückgegriffen werden konnte. Auf den Test RAC sethos wurden seit Dezember 2008 immer wieder Oracle11g Datenbanken getestet. Zur CeBIT 2009 wurde eine Real Application Testing Teststellung aufgebaut und mit unterschiedlichen Parametereinstellungen das Replay gefahren. Da dies gut lief und auch Oracle11g auf dem Test RAC einen sehr stabilen Eindruck hinterließ, konnte das Upgrade auf Oracle11g für die RAC Testdatenbanken schon in 05/2009 problemlos erfolgen. Das Upgrade von Clusterware und ASM auf Oracle 11g wurde aus Gründen der Stabilität schon in 11/2008 vorgezogen. Das Upgrade der Datenbank ist daher ein konsequenter Schritt zur Harmonisierung der Infrastruktur und Nutzung sämtlicher Fortschritte in 11g auch in der ASM. 2. Aufgrund nur sehr weniger (eigentlich gar keine) down time Fenster bei der Deutschen Messe bleibt es meistens nur ein Wunsch, das aktuelle CPU (critical patch update) einzuspielen. Mit dem Upgrade nach 11g und dem aktuellem CPU erhöht sich auch automatisch die Sicherheit vor unerwünschten Angriffen in der DMZ. 3. Die Tests konnten aufzeigen, dass eine Reorganisation die Datenbankgröße in Oracle11g halbiert. Da Plattenressourcen aufgrund von Sparmaßnahmen knapp geworden sind, ist dies ein sehr positiver Nebeneffekt des Upgrade. Eine reorganisierte Datenbank ist letztendlich auch langfristig erheblich performanter. 4. Die Datenbankversion selbst bringt aus technischer Sicht viele Fortschritte mit sich, die in Oracle11g nutzbar sind. (Fehleranalyse, Tuning, Compression, u.a.) 5. Die Werkzeuge wie RMAN, Data Guard, OEM und viele mehr haben sich im RAC Umfeld weiterentwickelt und erleichtern dem DBA in stark wachsenden Infrastrukturen den Überblick zu behalten. 6. Der DBA bekommt noch bessere Tuning Werkzeuge in die Hand um Effizienzpotentiale in der Infrastruktur auszuschöpfen. (RAC Advisors) 7. Das verbesserte Tuning ist auch ein Garant dafür, dass erhebliche Kosten im Bereich Hardware vermieden werden konnten. Während, wie in den Vorjahren üblich, jedes Jahr ein Doppelpack (cold-fail-over) an großen Servern benötigt wurde, konnte nun im dritten Jahr in Folge trotz erhöhter Anforderungen sehr stabil auf gleicher Hardware (3x FSC Prime Power 450) die Datenbank betrieben werden. Um Strom zu sparen wird immer wieder mal überlegt einen Knoten in der veranstaltungsfreien Zeit herunterzufahren. 8. Ein Upgrade auf eine neue Version ist auch ein günstiger Zeitpunkt, um neue Technologien an den Start zu bekommen. Wir haben die Data Guard Technologie von Oracle eingeführt. Die Schulung auf DataGuard war daher der wesentliche aber unverzichtbare Kostenfaktor für das Upgrade nach Oracle11g.

6 Wie wurde das Upgrade durchgeführt? Die für das Upgrade bestimmten produktiven RAC Datenbanken ( wwwp/ Internet, obsp/ OnlineBestellsystem ) haben ein Datenvolumen von <100GB und es bietet sich an, die schnelle parallelisierbare Oracle Data Pump als Export-/Import-Tool einzusetzen. Altanwendungen sollten vorher unbedingt auf Kompatibilität zur neuen 11g Datenbank getestet werden. Bei uns gab es z.b. noch Oracle8i OCI Clients zusammen mit Anwendungen, die bei einer Umstellung nach Unicode Zeichensatz nicht mehr unter 11g lauffähig gewesen wären.da die Hardware, wie zuvor ausgeführt, nicht verändert wurde, konnte dediziert zu den bestehenden ORACLE_HOME Strukturen ein weiteres RAC Oracle11g OH aufgebaut werden. Das OH bekam den Patchset Level mit den empfohlenen Bundle Sets aus dem Metalink. Um Data Guard zu betreiben, wurde ein zusätzliches OH für Single Instances mit selbigem Patchstand wie im 11g-RAC aufgesetzt. Die aufgesetzten Oracle11g RAC Datenbanken wurden anschließend ausgiebig getestet. Die Produktion auf Oracle10g konnte natürlich wie gewohnt weiterlaufen. Die Umstellung selbst lief, nach vielen Export + Import Tests, mehr oder weniger automatisch und durch Skripte gesteuert, ab. Da die Indizes in der Data Pump einen wesentlichen Zeitverzug bedeuten (die Data Pump schaltet hierfür immer auf parallel=1), empfiehlt es sich, die Generierung der Indizes manuell durchzuführen und zuvor den Parallelisierungsgrad zu erhöhen. Nachdem der Import abgeschlossen war, mussten die zuvor heruntergefahrenen RAC Services auf die neue RAC DB umkonfiguriert und wieder angefahren werden. Hierzu benötigen Sie übrigens ein 11g-fähiges OEM Grid Control( ) oder dbconsole(11g). Der DBCA ist in der Version11g nicht mehr für die Konfiguration der Services vorgesehen. Der Austausch des JDBC Treibers für den Zugriff der Anwendung auf die Datenbank kann zu einem späteren Zeitpunkt erfolgen, da der 10g JDBC-Thin-Treiber auch mit einer 11g Datenbank vollständig kompatibel ist. Zu guter letzt bestand zu jedem Zeitpunkt eine perfekte Rückfallebene auf die noch bestehende RAC Datenbank in der Version 10g. Probleme beim Umstieg auf Version 11g Der Data Pump Import gegen die RAC Datenbank (nur die RAC DB) führte teilweise zu timeout Situationen, die einen Reboot des entsprechenden Knotens erforderten. Wurden Indizes und Statistiken vom Import ausgeschlossen, lief der Import (parallel=4) problemlos durch. Im späteren Verlauf haben wir den Oracle Grid Agenten der Version mit einem Agenten in der Version ausgetauscht. Nun konnten auch die Indizes und Statistiken im Import wieder berücksichtigt werden. Probleme im WAIT Interface ( other WAIT ) führten nicht mehr zum Reboot eines Clusterknotens. In unseren Tests hat sich gezeigt, dass unter Verwendung von ASM auf der Standby Seite keine Verzögerungen im Vergleich zur Primary beobachtet werden konnten ( transport lags / apply lags ). Verwenden Sie unbedingt Data Guard (standby) und RAC (primary) mit selben Storage Typ und möglichst mit ASM! Dies ist offensichtlich ein Gespann, das optimal aufeinander abgestimmt ist. Die transport/apply lags befinden sich bei massivem Data Pump Import bei nur noch <10 Sekunden. Data Guard führte bei uns im lokalen Filesystem zu nicht nachvollziehbaren Problemen und schied als mögliche Lösung aus.

7 Die RAC-Datenbanken laufen im Betrieb stabil, obwohl wir die vorhandene Infrastruktur erheblich beansprucht hatten. Es liefen zeitweise zusätzlich zu den 2x produktiven RAC Datenbanken (10g) noch 2x upgrade RAC Datenbanken (11g), 2x Data Guard Datenbanken und 4x mittels rman duplizierte Desaster Datenbanken im lokalen FS. Die Oracle 11g RAC Datenbank im Betrieb Ist die Datenbank erst einmal in Betrieb, muss sich der DBA mit vielen neuen Aspekten vertraut machen. Im Oracle Enterprise Manager sind viele neue Technologien mehr oder weniger gut administrierbar, so dass sie schnell adaptiert werden können. Von den Oracle Technologien, die wir bei der Deutschen Messe im Einsatz haben, möchte ich ein paar vorstellen: 1. Wir nutzen RMAN Sicherungen mittels Catalog Datenbank und globalen parametrisierbaren rman Skripten. Die RAC Datenbank wird mittels unterschiedlicher rman Skripte für die archivelogs, Vollsicherungen (level0), inkrementellen Sicherungen (level1 - kumulativ inkrementell), Absicherung der FRA und Bereinigung der FRA -backupsets abgesichert. Mittels crosscheck -Skripte können die Sicherungs policies durchgesetzt werden. Um die Rücksicherung (restore/recovery) zu beschleunigen, wie oben angedeutet, dienen inkrementelle Sicherungen und die blockchange-tracking Technologie. Abb 4: globale parametrisierbare RMAN Skripte in der CATALOG Datenbank

8 2. Der RMAN ermöglicht auch das duplizieren der Datenbank aus der FRA heraus in das lokale file system eines Knotens. Um einem Desaster Fall auszuweichen (z.b. ASM fällt aus), kann mit erträglichem Datenverlust, auch beim Totalverlust der ASM die Datenbank (lokal im file system) schnell wieder in Betrieb gehen. 3. Der DataGuard, im Verbund mit dem Broker und Flashback Database, ist bei der Deutschen Messe ebenfalls in Betrieb. Die Option eines Failover ( welche Fehler auch immer im RAC auftreten ) ist die Lösung mit dem geringsten Datenverlust. (liegt unter 10 Sekunden). Neben der Absicherung durch die physical standby, nutzen wir auch die Möglichkeit der snapshot standby. Die Datenbank kann also für Auswertungen aller Art kurzzeitig geöffnet werden und danach wieder zurück in die physical standby umgewandelt werden. 4. Zusätzlich zu den oben genannten MAA Technologien benutzen wir auch immer tägliche logische Sicherungen mit der Data Pump, um Entwickler zu unterstützen und um die Möglichkeit zu haben, Datenobjekte im Nachhinein noch zu prüfen. 5. Die Steuerung für die Sicherungs-Jobs selbst erfolgt im OEM Scheduler. Das zentrale Management Werkzeug (OEM) für das Oracle Grid bei der Deutschen Messe ist in der Lage zentral (OEM Repository) über den Scheduler ganze Prozessketten (Typ Multi-Task) abzufahren und zu steuern. Mit wenigen Klicks haben wir eine vollständige Übersicht über die Probleme bei den Jobs und den eingestellten Metriken. Eine tägliche Mail um 07:00Uhr gibt schon beim ersten Blick in das Postfach Auskunft zu kritischen Fehlern:

9 Abb 5: Guten Morgen Mail für den DBA - generiert aus OEM gridcontrol 6. Das Tunen der Datenbank ist eine der besonderen Spezialitäten bei der Deutschen Messe. Gerade in der Version 11g wird das Tunen mittels global auswertenden RAC Advisern unterstützt.

10 Abb 6: global informierende Übersichtsdiagramme für den RAC 11g (Instanzen, Services, Waits) Die Übersicht in der TopActivity der RAC Datenbank als ganzes liefert die wesentlichen Erkenntnisse, wo ein Problem auftritt. Waits, Services, Instanzen, Prozesse, TOP SQLs und TOP Sessions sind sehr übersichtlich dargestellt. 7. Der SQL Tuning Advisor sammelt in 11g automatisch Vorschläge, um SQL - Zugriffe auf Daten zu beschleunigen. Ein täglicher Blick in die Vorschlagsliste zeigt, was alles an Effizienzpotentialen gehoben werden kann. Zu mehr als der Hälfte der untersuchten SQLs wurden Verbesserungen gefunden. Das sollte sich der DBA genauer Anschauen und bei Bedarf implementieren.

11 Abb 7: Übersicht automatic SQL Tuning für den RAC 11g Trotz erheblicher Tuning Anstrengungen seitens des Softwareherstellers und implementierter Zugriffsverbesserungen, findet der Advisor immer wieder neue Vorschläge.

12 Abb 8: Report von zu untersuchenden SQL Tuning Sets In der Liste finden Sie die besten Vorschläge ganz oben, auch Oracle interne SQLs (z.b. Enterprise Manager) können demnach noch potentiell getuned werden. Nun aber zu einem Beispiel, dass aufzeigt, was denn tatsächlich noch möglich ist:

13 Abb 9: SQL Tuning Set mit Vergleichsbetrachtung im RAC 11g Das SQL konnte um den erstaunlichen Faktor von beschleunigt werden. Im Übrigen ist es das TOP SQL Nr1 und wir erzielen damit eine wesentliche Verbesserung in der Performance der Gesamtanwendung. 8. Für die Administration nicht unwesentlich, aber gegeben, ist die Transparenz des RAC 11g zur einfachen Single Instance Datenbank. Sind Sie mit einer RAC Datenbank verbunden, stehen Ihnen alle Merkmale einer gewöhnlichen Oracle Datenbank zur Verfügung. 9. Das Loadbalancing ist im RAC ein wesentlicher Faktor zur planbaren performence Steigerung und funktioniert trotz komplexer Infrastruktur erstaunlich gut.

14 Abb 10: CPU Lastverteilung der 3 RAC Knoten während der CeBIT2009 Wir hatten zur CeBIT 2009 eine Lastkurve, die uns ein funktionierendes load balancing bzgl. der CPU-Last anzeigt. Sie zeigt auch, dass ein einzelner Knoten (FSC PP450 mit 4xCPU sparcv64) die angefallene Last nicht problemlos bewältigt hätte. Abb 11:Oracle Load Map als Hilfe für das Monitoring

15 10. Einen interessanten Monitoring Ansatz finde ich die Oracle Load Map. Sämtliche Datenbankziele aus dem Grid werden mit unterschiedlichen Farben und Größen dargestellt. Hier gelegentlich reinzuschauen könnte helfen, Resourcen Probleme zu entdecken (grün=cpu, gelb=wait, blau=io). Bewertung und Ausblick Mit Einführung des RAC11g plus Data Guard11g können neue Horizonte im Bereich von Datenabsicherung, Testen von Anwendungen, Reports und Lasttests erschlossen werden. Der Aktiv Data Guard ermöglicht sogar binärkompatible rman Sicherungen außerhalb der Zieldatenbank und lesende Zugriffe welche ideal für Katalogabfragen wären. Die Vorgehensweise beim Upgrade auf die neue Version11g erzwang eine Datenreorganisation welche das Datenvolumen auf die Hälfte zusammenschrumpfen ließ. Eine kleinere Datenbank bedeutet auch einen permanenten Performance Vorteil. Ohne irgendeine Veränderung in der Hardware, konnte allein durch Software Upgrades ein enormer Performance Gewinn erzielt werden. In dem genannten Beispiel war es ein Faktor von Insgesamt hat der DBA nun Stellschrauben an der Hand, welche über reale Wettbewerbsvorteile in der Infrastruktur entscheidenden Einfluss haben. Guten Gewissens können wir behaupten über einen Zeitraum von 3 Jahren die Performance der Anwendungen mindestens verzehnfacht zu haben. Die Kosten beschränken sich dabei für die Deutsche Messe im Wesentlichen auf die Schulungen, um die Technologien zu adaptieren. Wir sind zuversichtlich, dass auch in den kommenden drei Jahren erhebliche Performance Steigerungen um ähnliche Faktoren mit Oracle Technologien möglich sind und der Kauf von Hardware vermieden werden kann. Der DBA sieht die 11g RAC Datenbank nun im Enterprise Manager auch als einheitliche Struktur und erkennt Probleme auf einen Blick. Eine Analyse ist damit erheblich schneller und die Probleme werden gezielt beseitigt. Der Aufwand für Einkauf, Aufstellung und Betrieb von Hardware kann mittels RAC Betrieb reduziert werden. Die gesamte Hardware arbeitet aktiv. Performance Gewinne durch den Einsatz moderner Software ermöglicht Spielräume auch weitere Oracle Technologieen nutzbringend einzusetzen. Der 11g RAC ist der zentrale Baustein für die Hochverfügbarkeit der wichtigsten Datenbanken bei der Deutschen Messe. Diesen gilt es mit weiteren MAA Bausteinen, wie z.b. Data Guard, abzusichern. Der Weg zur Oracle MAA ist für die Infrastruktur der Deutschen Messe noch nicht erreicht, da der Data Guard immer jeweils auf einen der RAC Knoten mitläuft. Es wird also ein eher ökonomischer Ansatz gegangen (ecomaa). Einen Desasterschutz mit einer unabhängigen Data Guard Datenbank wäre aus Sicht des Datenbank Administrators erstrebenswert.

16 Kontaktadresse: Andreas Ellerhoff Messegelände D Hannover Telefon: +49(0) Fax: +49(0) Internet: