Exadata Database Machine Resource Management teile und herrsche!

Transkript

1 Exadata Database Machine Resurce Management teile und herrsche! Knrad Häfeli Trivadis AG CH-3014 Bern Schlüsselwrte: Oracle Database Machine, Exadata, Ressurce Manager, IORM, DBRM Einleitung Die Exadata Database Machine zeichnet sich durch enrme Perfrmance aus. Dies auch im OLTP Bereich, was sie auch als ptimale Knslidierungsplatfrm einsetzen lässt. Sbald ich aber mehrere Datenbanken auf dem System der mehrere Applikatinsschemas in einer Datenbank habe, habe ich knkurrenzierende Vrgänge welche früher der später zu Engpässen führen können. Wie stelle ich nun sicher, dass meine wichtigste Anwendung immer minimale Systemresurcen bekmmt? Den Database Resurce Manager gibt es schn seit einiger Zeit. Mit Exadata wurde der I/O Resurce Manager eingeführt welcher auf Stragezellenebene die verfügbare Bandbreite den verschiedenen Anwendergruppen zuteilen lässt und smit eine Pririsierung der I/O Requests macht. In diesem Vrtrag werden Knzepte swie die scriptmässige Umsetzung vn Inter-Database und Intra- Database Knfiguratinen anhand eines Kundenprjektes aufgezeigt.

2 Über die Evaluatin der Oracle Exadata Database Machine als strategische DB Server Platfrm ist schn einiges geschrieben wrden, dies sll nicht Gegenstand dieses Berichtes sein. Kurz aufgelistet waren bei meinem Kunden (grsses Unternehmen in der Telc Branche) flgende Beweggründe ausschlaggebend: Ersatz der Strage Systeme geplant Bestehende Standby System waren nicht gleichwertig der Primary Systeme Standby Systeme waren nicht mehr ausreichend Einsatz vn Oracle 11gR2 geplant Bestehende Backup Infrastruktur und Abläufe zu kmplex Energieverbrauch nicht mehr angemessen an heutige Standards Mehrere Platfrmknslidierungen standen an Lizenz-Kstenreduktin gewünscht Auch das Standard-Setup vn Oracle ACS (Advanced Custmer Services) ist bekannt und die Migratin einer Datenbank mit Oracle Glden Gate (Near Zer Dwntime Migratin) auf die jungfräuliche Database Machine habe ich an der letzten DOAG Knferenz in einem Vrtrag 1 präsentiert. Ich gehe im Flgenden auf die Überlegungen und Knzepte beim Einsatz als Knslidierungsplatfrm ein. IST Situatin, Zielplatfrm Das zu knslidierende Mengengerüst bestehe aus ca. 50 Datenbanken unterschiedlicher Grösse (100GB bis mehrere Terabyte), verschiedener Versinen, hauptsächlich Oracle , meist single Instanz, aber auch RAC Datenbanken. Die Infrastruktur wird applikatinsbezgen vn zwei Teams betrieben, welche im DB Bereich eng zusammenarbeiten. Die Verfügbarkeit wird meist mittels Failver-Cluster-Knfiguratin gemacht, wbei da ein Stretched Veritas Cluster über zwei nahegelegene (3km) Datacenter im Einsatz steht. Die bestehende RAC Knfiguratin ist mittels Dataguard zu einem MAA (Maximum Availability Architecture) System zusammen gefasst. Das Sizing der Exatada Platfrm wurde mittels Trivadis Cnfiguratin Manager (TVD-CnfMan TM ) unterstützt. Über alle bestehenden Systeme wurden Metriken (KPIs) definiert und gemessen und danach mit den perfrmancerelevanten Zahlen auf der Exadata verglichen. Dabei stellte sich heraus, dass eine Half-Rack Knfiguratin ausreicht um die bestehende Last zu bewältigen swie für die geplanten neuen Datenbanken genügend Reserve bereit zu stellen. Durch die Verfügbarkeitsanfrderungen im Telc Bereich (24*365) war auch eine MAA Knfiguratin (je ein Half-Rack in zwei Datacenter 80km getrennt) nötig. Knzeptüberlegungen und Bewertung Durch das Zusammenfassen aller Datenbank-Infrastrukturen und deren Betrieb in einem Team (neue, hrizntale Organisatin) können die applikatinsbezgenen Unterteilungen der Datenbanken ausser Betracht gelassen werden. Es stellt sich aber dennch die Frage b eine der beiden Extremvarianten überhaupt untersucht werden sll: 1:1 Migratin, d.h. für jede alte DB eine Neue auf der Exadata 1 Dwnlad ab

3 all in ne DB, alle prduktiven DB-Schemas werden in eine Datenbank migriert/knslidiert Bei der ersten Variante werden keine Synergien und Möglichkeiten der verfügbaren RAC Infrastruktur genützt: Servicehch- (höchst) Verfügbarkeit Scaleut-Möglichkeit Reduktin der Ressurcen im Bereich Memry, Backgrund-Przesse und Anzahl Tablespaces Die zweite Variante gibt Prblempunkte im Bereich Abhängigkeiten bzw. Abgrenzung der einzelnen bestehenden Applikatinsschemas: Z.T. sind viele glbale Synnyme im Einsatz (erst nch mit gleichen Namen über die verschiedenen Applikatins-DBs hinweg) Überprivilegierte User Changemanagement unterschiedlich Klumpenrisik bzw. Seiteneffekte untereinander Es kristallisiert sich als ein Kmprmiss heraus, bei dem die Anzahl der Datenbanken (massiv) reduziert werden sll, dies aber in Anbetracht der Gemeinsamkeiten bzw. Unterschiede. Flgende Definitin wurde als generelle Grundlage für die Knslidierung auf (Exadata) RAC Infrastruktur gemacht: 1. Alle Applikatinen verbinden sich nur nch über Datenbank-Service Namen und haben keinen Bezug mehr zur physischen DB resp. zum DB Namen 2. Die Applikatinen sind fähig (einerseits mittels Oracle Net Knfiguratin, andererseits im Handling der Oracle Verbindungen) einen kurzfristigen Verbindungsabbruch zu überstehen und einen neuen Verbindungsaufbau zu machen Die erste Anfrderung lässt eine Abstraktin des Datenzugriffs zu, sdass es keine Rlle spielt w sich diese physisch befinden. Die Zweite ist nötig, damit die Verschiebung der DB-Services über die RAC- Knten (und evtl. MAA Knten) hinweg keine Applikatins-Abstürze hervrruft. Knzeptbeschrieb: Auf den vier Knten des Exadata-Half-Rack sllen die bestehenden Daten themenspezifisch auf möglichst wenigen Datenbanken knslidiert werden. Die Zugriffe darauf werden über DB-Service Namen abstrahiert. Alle Themen-DBs haben gestartete Instanzen auf jedem Knten, wbei die Applikatinsservices einer DB immer nur auf einem Knten laufen und mittels Servicefailver hchverfügbar gehalten werden. Die Services werden s auf die Knten verteilt, damit eine ausgeglichene Last auf dem System ist. Vrteile: Durch die Zusammenfassung der Datenbanken können bestehende Datenbanklinks weggelassen werden. Ein spezifischer DB-Service ist hchverfügbar, da ein Failver auf eine schn gestartete Instanz erflgen kann. Eine mögliche Cachefusin-Prblematik wir umgangen, da die jeweiligen Verbindungen auf dieselben Daten nicht über verschiedenen Instanzen hinweg gemacht wird (per

4 default kein scaleut, da die meisten Applikatinen nicht RAC-aware sind). Eine gute Lastverteilung ist auf der Granularität DB-Service sehr einfach möglich. Die flgende Abbildung 1 zeigt zusammengefasst die redundanten Daten in den Exadata Strage Cells und darüber die vier Datenbank-Knten mit der Oracle Grid-Infrastruktur (Cluster-Schicht), den ASM Instanzen (pr Server) und den verschiedenen thematisch knslidierten Datenbanken (TH[ad]). In der Grafik sind es 4 Datenbanken welche jeweils eine Instanz (I[1-4]) pr Knten haben und auf denen die Services (S[a-d]) der Datenbanken verteilt sind. Abbildung 1: Knzeptgrafik Exadata Database Knslidierung auf DB-Services Mit dem Einsatz einer Exadata Platfrm ist die beim alten Knzept mittels Streched Cluster sichergestellte Desaster-Redundanz nicht gewährleistet. Aus diesem Grund wird beim neuen Knzept eine Maximum Availability Architecture (MAA) definiert. Diese stellt mittels Dataguard (Redlgtransprt und Apply) eine datenbankseitige Absicherung dar, welche im Fehlerfall die definierten Services hchfahren und bereitstellen kann. Ebenfalls ist mit Active Dataguard die Möglichkeit gegeben readnly Services auf den Standby Datenbanken anzubieten, welche das transaktinsrientierte (Primary-)System entlasten können. Die Abbildung 2 stellt die beiden Datacenter dar, welche im Wechsel der sgar gemischt die Datenbanken im Primary und Standby-Mdus beherbergen. Eine Überwachung kann ptinal aus einem dritten Datacenter gemacht werden, in dem ein sgenannter Dataguard-Observer knfiguriert wird, der den Failver der Primary-Site auf die Standby Site im Fehlerfall selbständig durchführt.

5 Abbildung 2: Knzeptgrafik Exadata MAA Knfiguratin Umsetzung der Knslidierung Die Zusammenfassung der Datenbanken sllte nach flgenden Kriterien erflgen: Datenzusammengehörigkeit Gleiche Applikatinsfamilie Gemeinsame Daten (Ersatz vn DB-Links) Explizite Datentrennung Security Verfügbarkeit Trennung wegen nötiger Unabhängigkeit Klumpenrisik Sensitive Daten Schema braucht hhe Privilegien

6 Multi Instanz DB Single Instanz DB Dataguard DG Prtectin Level RDBMS Versin Majr/Minr Releases Patch/Patchset Für die Umsetzung der Knslidierung musste zuerst ein Katalg aufgestellt werden, der die Kriterien der Zusammenfassung der Datenbanken auflistet und pr DB bewertet. Diese zuerst als einfache Matrix gedachte Liste, stellte sich dann aber dch als recht aufwändig heraus, weil die verschiedenen Kriterien sich zum Teil ausschlssen, andererseits die verschiedensten Applikatins-, Platfrm-, Service-, und andere Manager dazu befragt werden mussten. Dass bei den meisten Verantwrtlichen mehr Risik als Vrteil in der Zusammenlegung der Datenbank gesehen wurde, liegt auf der Hand. Die Krdinatin der verschiedenen Aktivitäten über einen grösseren Teil der kmplex verstrickten Funktin eines Telc-Unternehmens war aber dch recht schwierig und bedurfte eines einflussreichen Prjekt-Spnsrs. Dieser umfangreiche Knslidierungs-Fragebgen hatte flgende Grbstruktur: Technische Infrmatin pr Datenbank (Name, Versin, Grösse, Ressurcenverbrauch, ) Applikatrische Infrmatinen pr Datenbank (Name, Art der Applikatin, Art des Datenbankzugriffs, Anfrderungen, an Verfügbarkeit und Sicherheit, ) Betriebliche Infrmatinen (Backup, Mnitring, Datenfilesystemtyp, Batch-Jbs, ) Verantwrtlichkeiten (Manager, Team, DBA, Lieferant, ) Test/Integratins Umgebung (Setupart, Testdaten, Skalierung, ) Infrmatinen zu Migratins Szenari (Versinen, Anpassungen, Ksten für Anpassungen, Knslidierungsfähigkeit, ) Die Auswertung er gesammelten Daten, wbei nicht für alle Prjekte innert nützlicher Zeit alle Infrmatinen beschafft werden knnte, ermöglichte flgende Aufteilung und Pririsierung: Implementatin aller neuen Datenbank-Ressurceanfragen auf der neuen Platfrm Migratin vn ein paar unkritische Datenbanken als quick wins, für die Lieferung vn nötigen Erfahrungswerten in der Migratin und Betrieb Identifikatin der zeitlich kritischen Datenbanken und Behandlung mit Prjektleiterfkus, damit auch diese dann termingerecht knslidiert sind Erfahrungen Der hhe Innvatins-Rhythmus in der Unternehmung machte die schnelle Umsetzung der Knslidierungsplatfrm nötig. Flgende Aufgaben mussten zuerst angegangen werden: Namensknzepte für Datenbanken, Instanzen und Services

7 Entwicklung vn Templatescripts für die Erstellung vn standardisierten Datenbanken Entwicklung vn Scripts für die Knfiguratin der Datenbanken und Services im Cluster Knzept und Implementatin des Ressurcen-Managements (Exadata IORM, DBRM) Implementatin des Backupknzepts Implementatin des Mnitringknzepts Die Angst der invlvierten Applikatins-Verantwrtlichen und Betreiber vr dem Zusammenlegen ihrer Daten in einer Datenbank war um einiges grösser als erwartet. Der Widerstand gegen die Knslidierung hatte zu einem grssen Teil damit zu tun, dass Mehraufwand durch Abgabe vn bestehenden Privilegien befürchtet wurde und Reduktin der Verfügbarkeit durch Abhängigkeiten vn weniger stabilen Systemen. Durch ein mderates Auslegen des Knslidierungsdrucks, indem die heikelsten Datenbanken eins-zu-eins migriert wurden, knnten die Anwender vn der guten Funktinalität der Platfrm überzeugt werden und sind s eventuell in einer späteren Phase bereit das Datenbankschema mit anderen zusammen zu legen. Erst der prduktive Betrieb hat die Nützlichkeit der MAA Knfiguratin wirklich aufgezeigt. Durch Switchver vn einem Datacenter auf das Andere, knnten grsse Systempatches hne Risik implementiert werden. Auch bei den aufgetretenen technischen Fehlern (Diskausfall, Mtherbard Austausch) welche nicht immer hne Prbleme gelöst werden knnten, war das zweite System vn gutem Nutzen. Durch die Übernahme der Services war der nötige Hardware-Austausch hne Last durchführbar. Wichtig beim Betrieb einer Exadata-Platfrm ist eine enge Zusammenarbeit mit dem Oracle Supprt, welcher sich speziell bei Exadata-Service-Requests sehr engagiert und zeitnahe Lösungen bringt. Denn eines ist klar die Platfrm, Sftware wie Hardware, braucht ein intensives Lifcycle-Management und dazu gehört das beheben vn unvrhergesehenen Prblemen dazu. Die Kstenfrage wird natürlich bei s einer Knslidierung immer wieder in den Vrdergrund gestellt. Die Erfahrungen im Bereich Lizenzen waren sehr gut, wbei da natürlich auch nch gute Verhandlungen mit Oracle als Early-Adpter der Exadata-Technlgie geführt werden knnten. Der Betreibsaufwand, nach den nicht zu vernachlässigenden Setup-Anstrengungen, kann gegenüber der herkömmlichen Platfrm als definitiv kleiner ausgewiesen werden. Ist dem DBA das Betriebssystem bzw. Netzwerk nicht unbekannt und hat er keine Abneigung unter Anweisung slche Aufgaben auch durchzuführen, kann dieser eine Exadata-Platfrm nach dem Setup unterhalten. Es gibt nch viel Interessantes im Bereich Funktin und Anwendung beim Einsatz der Exadata Database Machine als knslidierter Datenbankserver zu erzählen, der Autr steht gerne für Fragen zur Verfügung. Kntaktadresse: Knrad Häfeli Trvadis AG Papiermühlestrasse 73 CH-3014 Bern Telefn: +41(0) Fax: +41(0) knrad.haefeli@trivadis.cm Internet: