Kosten sparen durch virtualisierte Oracle Umgebungen - Erfahrungen aus der Praxis

Transkript

1 Kosten sparen durch virtualisierte Oracle Umgebungen - Erfahrungen aus der Praxis Wolfgang Höfer Fujitsu Technology Solutions München Schlüsselworte: - Grid Computing - Vorkonfigurierte, integrierte und vorgetestete Komplettlösung. - Virtualisierung - OS /Oracle Instanz Provisionierung - Server Virtualizierung unter Linux via Oracle VM - Messbar mehr Zuverlässigkeit, Effizienz und Flexibilität. Einleitung Kurzlebigere Geschäftsmodelle und der Ertragsdruck in Unternehmen wirken sich unmittelbar auf IT-Organisationen aus. Immer mehr IT-Verantwortliche erkennen, dass es Zeit ist, umzudenken. Weg von starren Systemen mit festen Zuordnungen. Hin zu flexiblen Lösungen, die sich wechselnden Anforderungen weitgehend automatisch anpassen und die HW Infrastruktur effizienter ausnutzen können. In vielen IT-Abteilungen gilt heute die Maxime flexibler, effizienter, zuverlässiger. Commodity Hardware ist im Preis-Leistungsverhältnis sehr attraktiv (insbesondere unter Berücksichtigung der Oracle Lizenzen) und die zunehmende Zuverlässigkeit von Linux als Server Betriebssystem trägt dazu bei, dass Grid Computing und Server Virtualisierung eine ernsthafte - und in meinen Augen die bessere - Alternative zu der Serverkonsolidierung auf wenige und grosse SMP Server sind. Die Virtualisierung von Oracle Umgebungen ist auf die Dauer ein notwendiger Schritt, um die Effektivität des Betriebs, besonders im Rechenzentrum zu erhöhen und wird bereits von vielen Kunden zur Zeit angegangen bzw. steht ganz oben in der Prioritätenliste. Hauptmotivaton ist neben einer erhöhten Flexibilität natürlich auch eine Kostenoptimierung des Betriebs und damit eine Steigerung der Wettbewerbsfähigkeit. Besonders relevant ist dies für Hosting Anbieter. Dieser Erfahrungsbericht basiert auf einem Projekt in welchem Oracle Enterprise Linux, Oracle VM und FlexFrame for Oracle zum Einsatz kommen.

2 Notwendigkeit und Vorteile einer Server-Virtualisierung a. HW Performance Immer mehr Anwendungen (besonders OLTP) sind nicht mehr in der Lage, einen Server auszunutzen. So wächst die Leistungsfähigkeit der Intel/AMD Hardware schneller als der Resourcenbedarf der meisten Applikationen. Zum Beispiel schafft eine Fujitsu PRIMERGY RX300 S5 mit 2x Intel Xeon Quad-Core X GHz und 96 GB RAM tpse ( TPC-E, resultid 25). Also annähernd dieselbe Performance wie ein 4 socket server mit älterer Intel CPU, d.h. die Performance per core hat sich verdoppelt. Seit 24-Sept :12 AM [GMT]: 2 socket server stossen in die Top Ten vor oder eine RX300 S5 wie oben aber mit 48 GB RAM SAP Sales and Distribution (SD) 2tier SAPS SAP enhancement package 4 for SAP ERP 6.0 (Unicode) (Certification number: ). Dies entspricht ohne Unicode und zurückgerechnet auf SAP Release 4.7 der Performance von 32 CPU Sparc Systemen vor 5 Jahren!! Die extrem gute Performance der Intel Nehalem CPUs lässt sich auch daran ableiten, dass Oracle s Exadata Version 2 ( The First Database Machine for OLTP ) auf dieser CPU und Linux basiert und nicht auf SPARC und Solaris.

3 b. Server - Auslastung und Konsolidierung Zudem haben die meisten Anwendungen immer begrenzte Hochlastphasen. Der Betrieb von mehreren Anwendungen auf einem Server in unabhängigen Umgebungen ( VM= virtuelle Maschine) ist also zwangsläufig erforderlich, um eine hohe Server-Auslastung zu erreichen. Und eine hohe Server-Auslastung führt automatich zu einer Server-Konsolidierung, da weniger Server benötigt werden. c. Oracle DB Konsolidierung ist keine Voraussetzung Weitherin bietet eine Virtualisierung der Oracle Instanzen den grossen Vorteil, dass die Anwendungen nicht auf wenige DBs konsoliert werden müssen, um dieses Betriebskonzept zu ermöglichen. Eine DB Konsolidierung ist für den Kunden in der Regeln mit hohem Aufwand, Risiko (verhält sich die Applikation noch so wie früher?) und keinem direkten Nutzen ausser ggf niedrigeren Administrationskosten verbunden. Letztere müssen zuerst einmal über die Jahre die Aufwende amortisieren. Ausserdem zertifizieren nicht alle Applikations-Hersteller zügig die aktuellsten Oracle DB Versionen, was die Kunden öfters zum parallelen Betrieb von verschiedenen Versionen oder zumindest Patch Sets zwingt. VMs ermöglichen eine 1:1 Übernahme bestehender DB Anwendungen in eine flexible, leistungsfähige Infrastruktur. d. Einfache Administration und Abrechnung Zusätzlich bieten VMs eine erhöhte Flexibilität und bessere Abrechnungsmöglichkeiten durch Resourcenkontrolle. Die HW Resourcen (CPU, Memory) können sehr schnell durch einen Neustart der VM verändert werden. Oracle VM ermöglich es zudem, nur die Cores lizenzieren zu müssen, die die VM benutzt, (phys. Cores müssen den virtuellen CPUs dann aber explizit in der Konfiguration zugeordnet werden; sogenanntes Hard Partitioning ). Zudem kann eine VM sogar im laufenden Betrieb umziehen. Allerdings ist hier OVM in der Version unter Last noch nicht 100% erfolgreich. e. Lastverteilung und Hochverfügbarkeit Oracle VMs werden beim Starten automatisch dem Hypervisor (Server) mit der geringsten Last aus dem Server Pool zugeordnet. Sie kann aber auch manuell durch den Administrator einem dedizierten Server zugeordnet werden.

4 Fällt ein Server aus, werden die VMs automatisch auf die übrigen Server verteilt. Die Server Auslastung in der Startkonfiguration könnte auch so gewählt werden, dass die übrigen Server beim Ausfall eines Servers dessen Last noch zusätzlich übernehmen. Da bisher nur ein Server die Rolle des Server Pool Master übernehmen kann, bleibt der Ausfall desselben ein single point of failure. Hinweis: Für die Version 2.2. sind mehrere Server Pool Master je Server Pool geplant. f. RAC und single Instanzen auf native Servern Obwohl der Overhead bei der Paravirtualisierung (OVM benutzt Xen) mit maximal 10-15% sehr passabel ist, kann es für manche sehr IO-intensive Anwendungen zu viel sein, d.h dass dann die Performance eines solchen Servers nicht mehr ausreicht und diese single Instanz dann auf einem nativen OS laufen muss. Zudem empfehle ich aus heutiger Sicht RAC auf nativem OS einzusetzen. Da die meisten Kunden 2 Node Cluster einsetzen, geht durch den Ausfall eines Servers die Hochverfügbarkeit und die Performance (ein Node anstelle von 2) verloren, d.h. innerhalb kürzester Zeit sollte diese 2te Instanz auf einem anderen Server (Node) wieder verfügbar sein. Die Herausforderung: Wie kann die Hochverfügbarkeit von OVM, RAC (nach InstanzAusfall im 2 Node cluster) und single Instanzen (auf nativem OS) gewährleistet werden? Die Lösung FlexFrame for Oracle ist die erste Grid Computing-Infrastrukturlösung für eigenentwickelte und Standard-Applikationen basierend auf Oracle Datenbank (RAC/single instance) und

5 Oracle Application Server. Alternativ gibt es die Lösung auch in einer reinen DB-Variante, wenn z.b. 3rd party Application Server zum Einsatz kommen. Bei dem hier vorgestellten Kundenprojekt wurde die Mid-Tier via VMware virtualisiert und die DB -Tier via Oracle VM. FlexFrame for Oracle ist eine vorkonfigurierte, integrierte und vorgetestete Komplettlösung. Neben der gesamten Hardware enthält sie die Virtualisierungssoftware von Fujitsu, die Oracle-Software und alle Dienstleistungen. Die Server sind in Server-Klassen (Server Domains) organisiert, um einer verschiedenen HW Ausstattung bzw. Verschiedenen Anforderungen (z.b mehr Memory für DB Server) gerecht zu werden. Innerhalb einer Serverklasse kann es für n Server auch einen ausgezeichneten Failover Node geben, d.h. es liegt ein N:1 Failover vor. Der Vorteil ist, dass auf den Application Nodes keine Cluster SW für diesen Failover installiert werden muss. Der Failover Node kann ausgeschaltet bleiben (green spare) oder eine Test-Application läuft darauf. Letztere wird dann nach einem Serverausfall runtergefahren und der Failover Node fährt die ausgefallene(n) Instanz(en) des ausgefallenen Servers hoch. Das OS (nativ oder Hypervisor) wird via FC boot gestartet. Die anwendungsspezifischen Volumes/LUNs oder das OVM repository können NAS (NFS) oder SAN attached sein. Da eine Anwendung so innerhalb von 10 Minuten wieder zur Verfügung steht, ist nur bei einer geringeren geforderten Ausfallzeit RAC oder Data Guard erforderlich.

6 Die Anwendungen innerhalb einer Serverklasse können priorisiert werden. So können auch ohne Failover Node Anwendungen mit höherer Priorität solche mit niedrigerer im Failover- Fall verdrängen. Damit kann garantiert werden, dass die Anwendung mit der höchsten Priorität läuft, solange zumindest ein Server in der Serverklasse verfügbar ist. Zudem kann für den Desaster Fall (Ausfall eines RZs) genau festgelegt werden, welche Anwendungen auf welchen Server im Backup RZ wieder anlaufen sollen. Der Netapp Metrocluster war in diesem Fall von Kunden schon vorgegeben. FlexFrame for Oracle unterstützt alle gängigen Daten Replikations-Mechanismen.

7 Kundenvorteile Da FlexFrame for Oracle einen Instanz-Failover auf einen anderen Server innerhalb von zirka 10 Minuten ermöglicht und alle Anwendungen des Kunden mit dieser Ausfallzeit leben können, benötigt der Kunde kein RAC. Nebst den Lizenzkosten reduziert der Kunde dadurch auch die Komplexität der Lösung. Da auch alle Instanzen nicht besonders IO intensiv sind, und sich der Overhead durch die Virtualizierung im Rahmen hält, läuft jede DB Instanz in einer VM. Da die gelieferte Performance in absehbarer Zukunft ausreicht, ist jede DB via NFS (1xGbE redundant) angeschlossen. Der Kunde hat immer die Möglichkeit, spezielle Hot Tablespaces als LUNs über den vorhanden FC Anschluss des Hypervissors, den VMs via virtueller Platten zur Verfügung zu stellen. Die Netzwerkanbindung eines Oracle VM Servers ist in der folgenden Grafik dargestellt:

8 Die Anbindung der DB, d.h. die NFS Mounts, wurde für die VM abstrahiert, da in dem vorgesehenen Hosting Modell der Endkunde auch nicht als Superuser in der VM auf die NFS Mounts zugreifen soll. Nähere Details erfahren Sie im Vortrag, zudem Sie herzlich eingeladen sind. Kontaktadresse: Wolfgang Höfer Fujitsu Technology Solutions Domagkstrasse 28 D München Telefon: +49(0) Internet: