Database as a Service
Werbung
update Database as a Service Eine Oracle Private Cloud Datenbank-Strategie Ein Whitepaper der avato consulting ag Seite 2/33 update Gegenstand Dieses Dokument beschreibt eine Strategie für Database as a Service auf Basis einer Oracle Cloud. Betrachtet werden Anforderungen, technologische Konzepte, Architekturen, Migrationsstrategien sowie Erfolgsfaktoren bei der Einführung. Control Table Contact Person: Ronny Egner Lutz Fröhlich Gregor Bister Classification White Paper Oracle Database as a Service Functional Applicability: Last Revision Date: 27.01.2013 Version: 1.0 Change History Version Date Revision Description Revision Details, Authors 0.1 Initial Draft Gregor Bister 1.0 Anforderungskriterien, Architektur Ronny Egner, Lutz Fröhlich & Erfolgsfaktoren Seite 3/33 Inhalt update 1 Cloud-Strategie für Oracle Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Klassische Oracle Cloud-Konzepte auf Basis Oracle 11.x . . . . . . . . . . . . . . . . . 4 2.1 2.2 2.3 Database Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Database Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Database Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Kriterien & Anforderungen für die Oracle-Cloud der Zukunft . . . . . . . . . . . . 5 3.1 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 Investition & Return-on-Investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 Investitionssicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 Betriebskosten / Kostenverrechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Skalierbarkeit / Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Flexibilität / Individualität der Services & Agilität der Serviceanpassung . . . . . . . . 7 3.2.3 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.4 Compliance & Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Managebility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2 Flexibilität bei der Serviceerbringung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.3 Reduktion von Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.4 Release- & Patch-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Entwicklung einer zeitgemäßen Plattformstrategie . . . . . . . . . . . . . . . . . . . . . . 9 4.1Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2 Was ist zu beachten? Ein paar Erfahrungen aus der Praxis . . . . . . . . . . . . . . . . . . . 21 4.2.3 Virtualisierung – Ja oder Nein und wenn ja, wo? . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.4 Lizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5 Erfolgsfaktoren bei der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1 5.2 5.3 5.4 Flexibilität der Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Database Provisioning & Onboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1 Ressourcenanforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Migrationsstrategie und -support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Modelle zur Kostenverrechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6 Betrieb einer Oracle Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7 Ausblick: Oracle Private Cloud / Oracle 12c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1 Oracle Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.2 Oracle 12c: Pluggable Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Seite 4/33 1 update Cloud-Strategie für Oracle Datenbanken Manch einem mag es vorkommen wie die Quadratur des Kreises: die Anforderungen an eine Oracle Cloud unter einen Hut zu bringen, eine zeitgemäße Lösung zu entwickeln und „Alt-Systeme“ mit überschaubarem Aufwand auf eine Oracle Cloud zu migrieren. Dabei ist es heute keine Frage mehr, ob für Datenbankkonsolidierung Cloud-Computing die sinnvollste Plattformstrategie ist. Unbestritten sind die Kostenvorteile und die Flexibilität des Cloud-Computing. Es ist eher in der Diskussion, ob eine Public Cloud oder eine Private Cloud genutzt wird, ob universelle Infrastruktur Cloud oder spezialisierte Datenbank Cloud die richtige Antwort auf aktuelle und zukünftige Herausforderungen darstellen. Die Frage nach Public Cloud oder Private Cloud in Bezug auf Datenhaltung ist für die meisten Unternehmen durch regulatorische Anforderungen, benötigte individuelle Services und langfristige Kostenmodelle schnell beantwortet: Datenbanken gehören in eine Private Cloud. Somit bleiben wenige Fragen: Zunächst ist zu klären, ob man mit einer Private Infrastructure Cloud (IaaS, Infrastructure as a Service) oder einer spezialisierten Datenbank Cloud (PaaS, Platform as a Service) besser fährt. Wir wollen diese Frage hier für Oracle-Datenbanken intensiver betrachten und dies unter folgenden Gesichtspunkten tun: Was sind die Anforderungen an eine Oracle Cloud, was sind die Erfolgsfaktoren bei einer Implementierung. Zudem wollen wir beleuchten, welche Services Oracle zukünftig offerieren wird. 2 Klassische Oracle Cloud-Konzepte auf Basis Oracle 11.x Wenn Anforderungen an einen Database-Service formuliert werden um Cloud-Ansätze zu implementieren, treten immer sehr unterschiedliche oder sogar konkurrierende Anforderungen auf. Im Ergebnis findet man heute Cloud-Ansätze mit sehr unterschiedlichen Eigenschaften sowie Reifegraden implementiert. Dabei lassen sich die Ansätze, so verschieden sie auch sein mögen, in drei Kategorien zusammenfassen und zuordnen: • Database Machine: Dedizierter physikalischer oder virtueller Server • Database Instance: Dedizierte Datenbank auf einer Shared Plattform • Database Schema: Schema in einer Shared Database Allen Ansätzen sind Zielsetzungen wie Kostenoptimierung, Flexibilisierung der Services sowie Skalierbarkeit gemein. Zudem werden in den meisten Fällen Datenbanken auf eigens hierfür konzipierten und optimierten Plattformen betrieben. Manche Individualität der Plattform wurde in der Praxis dadurch gemindert, dass Basis-Technologien wie Hardware, Netzanbindung oder Storage vereinheitlicht sind. Seite 5/33 2.1 update Database Machine Der Begriff Database Machine lehnt sich am Konzept dedizierter Systeme an. Er beschreibt Installationen, bei denen eine Datenbank auf dedizierten physikalischen oder virtuellen Servern als eigenständige Datenbank betrieben werden. Die Database Machine basiert meist auf einer sogenannten Infrastructure Cloud (IaaS) und nutzt standardisierte oder virtualisierte Infrastruktur (Hardware, Storage, Virtualisierung sowie OS). 2.2 Database Instance Database Instance beschreibt die klassische Datenbank-Instanz, die sich mit weiteren Datenbank-Instanzen einen physikalischen oder virtuellen Server teilt. Realisieren lässt sich dies sowohl auf einer Infrastructure Cloud als auch auf einer für Datenbanken spezialisierte Cloud (PaaS). 2.3 Database Schema Das Database Schema ist in jüngster Vergangenheit gebräuchlicher geworden. Hier werden Datenbanken als Schema in eine gemeinsame Datenbank konsolidiert. In Kombination mit RAC kann eine Datenbank dann mehrere (virtuelle) Server nutzen und so eine große Skalierungsmöglichkeit für viele Schemas bieten. Der Ansatz verspricht die größten Kostenvorteile, birgt aber eine Vielzahl von Limitierungen. Abhilfe verspricht hier das Konzept der Pluggable Database aus der neue Version 12c (s.u. 7.2 Oracle 12c: Pluggable Database). 3 Kriterien & Anforderungen für die Oracle-Cloud der Zukunft Bevor wir Vor- und Nachteile einzelner Konzepte beurteilen, wollen wir typische Anforderungen an einen Database Service sammeln und hieraus eine Plattformstrategie ableiten. Was benötigt der Kunde? Er benötigt einen flexiblen Datenbank-Service zu geringen Kosten und in der Regel hoher Verfügbarkeit. Der Service soll den Compliance- und Security-Richtlinien des Unternehmens entsprechen und das Provisioning sollte möglichst zügig und unkompliziert erfolgen können (Self-service-Portal). Kosten Services Operations Investition & RoI Skalierbarkeit / Performance Manageability Investitionssicherheit Flexibilität / Individualität der Flexibilität bei der Serviceerbringung Services & Agilität der Serviceanpassung Betriebskosten & Kostenverrechnung Quality of Service Reduktion von Komplexität Compliance & Security Release- & Patch-Management Seite 6/33 update 3.1Kosten Die Kosten einer Cloud fallen in aller Regel geringer aus als die Summe der Kosten entsprechender Einzelsysteme. Die Kostenvorteile basieren im Wesentlichen auf der Verwendung von preiswerten Standardkomponenten und der effizienteren Nutzung solcher Komponenten. Zu beachten sind aber auch ganz wesentlich Lizenzkosten. Hier ergeben sich in den meisten Fällen klare Vorteile, wenn man auf eine dediziert Datenbank-Cloud (PaaS) setzt und primär Oracle Software wie OEL und OVM (Oracle Enterprise Linux, Oracle Vitual Machine) zum Einsatz kommt. 3.1.1 Investition & Return-on-Investment Möglichst geringe Investitionen fördern im Allgemeinen einen schnellen Return-on-Investment. Ideal für jede Investition ist, wenn ein Return-on-Investment noch innerhalb eines Budgetjahres erreicht werden kann. Deshalb sollten soweit wie eben möglich Standard-Komponenten, die sich bereits im Betrieb bewährt haben, eingesetzt werden. Hier sind vor allem x86-Hardware und Storage zu betrachten. Möglichst viel sollte out-ofthe-box genutzt werden können, ohne dass aufwändige, teure und zeitraubende Anpassungen und Zertifizierungen notwendig werden. Durch den primären Einsatz von Oracle-Produkten (zum Beispiel Oracle Linux als Betriebssystem)kann vieles ohne umfangreiche Anpassungen und eigenes Engineering direkt eingesetzt werden. Um die Investitionen zu minimieren, kann die Strategie auch lauten: Aufbau einer möglichst einfach skalierbaren Cloud und sukzessiver Move von Anwendungen auf die Oracle Cloud, zum Beispiel im Rahmen des nächsten Tech-Refresh oder der nächsten Release-Migration. 3.1.2 Investitionssicherheit Um eine langfristige Investitionssicherheit zu gewährleisten, sollten keine umfangreichen individuellen Standards für einen PaaS entwickelt werden. Entweder werden Standard-Komponenten des Unternehmens oder fertige Komponenten des Herstellers eingesetzt. Die Strategie des Herstellers muss bei allen Architekturentscheidungen im Auge behalten werden. Oracle wird zukünftig eine immer stärkere Integration des eigenen Produktportfolios verfolgen und versuchen, möglichst umfangreiche Vorteile durch „Engineered Systems“ zu bieten. Das verspricht langfristig auch Kostenvorteile. Um eine langfristige Plattformstrategie entwickeln zu können, sollte man ein möglichst genaues Bild zukünftiger Kundenanforderungen haben. Zudem sollte die Architektur der Plattform eine größtmögliche Flexibilität bei der Erweiterbarkeit und Managebarkeit bieten. Hierzu gehören auch Integration neuer Hardwarekomponenten, Software-Releases, Services sowie Service-Provider. Seite 7/33 update 3.1.3 Betriebskosten / Kostenverrechnung Betriebskosten sind stets ein wesentlicher Aspekt bei Plattformentscheidungen. Hier sind in erster Linie der Footprint im Rechenzentrum sowie die Aufwände im Operations zu nennen. Zudem sollte hier immer betrachtet werden, wie gut die Management-Tools sind, welche Kosten hier entstehen und wie deren Einbindung in die vorhandene Tool-Landschaft möglich ist. Die Einbindung der Plattform in vorhandene Operation-Standards (Tools, Prozesse) sowie in andere Services wie zentrales Monitoring sind weitere Aspekte, die die Betriebskosten einer Plattform wesentlich beeinflussen. Neben den Kosten spielen aber auch die Kosten-Verrechnungsmodelle eine zentrale Rolle. Die Kosten dedizierter Systeme sind im Allgemeinen einfach zu ermitteln, bei einer Cloud ist dies eine Herausforderung. Zentrales Anliegen eines Modells sollte hier immer sein: Die Verrechnung verursachergerecht, transparent und so einfach einfache wie möglich zu gestalten. Zudem sollte sie dem Kunden Möglichkeiten aufzeigen, durch Ressourcen-Einsparungen auch zu wirklichen Kostenreduktionen zu gelangen und sie sollten nicht im Widerspruch zur Strategie des Unternehmens stehen. Als Stellschrauben bieten sich neben dem Storage, CPU, Memory sowie I/O an. 3.2Services 3.2.1 Skalierbarkeit / Performance Die Skalierbarkeit eines Services basiert vor allem darauf, dass dem Nutzer ein einheitliches Interface für seine Anwendungen zur Verfügung gestellt wird. Zusätzliche Ressourcen müssen zeitnah und ohne wesentliche Einschränkungen bereitgestellt werden können. Das bedeutet auch, dass sich Anwendungen ohne größeren Aufwand auf leistungsstärkere Plattformen migrieren lassen, also auch ohne Anpassungen aus einer Oracle Cloud auf eine dedizierte Plattform wie beispielsweise Exadata migriert werden können. 3.2.2 Flexibilität / Individualität der Services & Agilität der Serviceanpassung Durch Plattformen wie Amazon AWS haben sich auch die Anforderungen an PaaS verändert. Rapid Deployment oder ein On-demand Provisioning über ein Self-Service-Portal sind heute gefragt. Soll die Plattform auch Kurzzeitnutzung, beispielsweise für Test- und Demosysteme, bieten? Wie flexibel kann die Ressourcen-Anpassung (CPU, Speicher, Storage) durchgeführt werden? Anforderungen an das Release-Management und Maintenance sowie spezielle Features spielen in der Diskussion eine große Rolle. 3.2.3 Quality of Service Unter Quality of Service sollen hier Service Level Anforderungen verstanden werden. Was kann eine Plattform grundsätzlich in Bezug auf Verfügbarkeit, Performance, Security sowie Reaktions- und Wiederherstellungszeiten leisten? Wie störanfällig ist die Plattform, wie lassen sich Incidents auf der Plattform isolieren und reduzieren und wie sind die Behebungszeiten von Incidents und Problems, welche Analyse-Möglichkeiten bietet die Plattform. Seite 8/33 update 3.2.4 Compliance & Security Ist auf Basis der gewählten Architektur die Umsetzung von Compliance- und Security-Anforderungen möglich? Da solche Anforderungen länderspezifisch oder auch anwendungsspezifisch sein können, muss die Oracle Cloud hier auch unterschiedliche Level ermöglichen. Die Auditierung muss möglich bleiben und die „Segregation of Duties“ darf nicht beeinträchtigt werden. Zudem müssen sich Anforderungen wie die Härtung von Datenbanksystemen, die Trennung der Zuständigkeiten, Authentifizierung, Autorisierung, Zugriffskontrolle, Verschlüsselung, Anonymisierung sowie die Auditierung und die Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten genauso implementieren lassen wie auf dedizierten Systemen. 3.3 Operations Im Operations sollten alle Standardtasks mit möglichst geringen Aufwänden durchgeführt werden können. In einer Mischumgebung von Oracle Cloud und dedizierten Systemen sollten gleiche Aufgaben nach Möglichkeit mit gleichen Tools erledigt werden. Die Plattform muss sich zudem ohne große Aufwände in bestehende Operations-Prozesse und –Tools integrieren lassen. Eine shared Plattform wird zunächst einmal mit deutlich reduzierten Aufwänden für das Patch-Management verbunden. Die Herausforderung liegt hier weniger im Patchen als vielmehr in der Organisation des Patch-Managements. Eine einfache und einheitliche Management-Plattform ist erforderlich, mit der sich alle wesentlichen Tätigkeiten ausführen lassen. Für Oracle-Datenbanken ist fast immer der Enterprise Manager die sinnvollste Lösung. 3.3.1 Manageability Wie oben bereits erwähnt, ist der Enterprise Manager 12c Cloud Control für Oracle-Datenbanken meist das geeignetste Werkzeug, für eine Oracle-Cloud ist er nach unserer Ansicht auf jeden Fall anzuraten, auch wenn die Funktionalität durchaus auch mit anderen Tools nachgebildet werden kann. 3.3.2 Flexibilität bei der Serviceerbringung Selbst bei Nutzung unterschiedlicher Dienstleister oder bei einem Wechsel von Dienstleistern sollten Anwendungen ohne großen Aufwand von einem Service Provider zu einem anderen verlagert werden können. Wenn unterschiedliche Support-Einheiten tätig sind, Off- / Near-Shoring von bestimmten Support-Tätigkeiten oder ein globaler 24*7 Support eine Rolle spielen, ist es zwingend erforderlich, dass eine Oracle Cloud entsprechende Rollen- und Security-Konzepte zulässt. Sollten Compliance-Anforderungen Separierungen oder Besonderheiten für Teile der genutzten Daten erfordern, muss dies auch auf einer Shared-Plattform realisiert werden können. 3.3.3 Reduktion von Komplexität Um die Komplexität erfolgreich zu reduzieren, sind Plattformstandardisierung, zentrales Plattform-Management, Reduktion von Releases, Vereinheitlichung von Tools und Dokumentation mit hohem Reifegrad erforderlich. Seite 9/33 update 3.3.4 Release- & Patch-Management Was ist die Realität in heutigen Infrastrukturen? Meist wird eine Vielzahl von Releases genutzt. Die Herausforderung der Oracle Cloud ist es nun, die Anzahl auf ein sinnvolles Maß zu reduzieren. Dies bedeutet, dass in aller Regel mehr als 1 Release zur Verfügung gestellt werden muss. Wir empfehlen jedoch, maximal 2 Releases zuzulassen. Die Patch-Strategie muss den Anforderungen des Unternehmens gerecht werden. Es ist zu empfehlen, ein vollständiges Lifecycle-Management aufzubauen. Sie gelangen hier zu unserem Whitepaper „Oracle Lifecycle- & Security-Management“. Als Tool ist hier der Enterprise Manager bzw. der Nachfolger Cloud Control die erste Wahl. 4 Entwicklung einer zeitgemäßen Plattformstrategie Anforderungen an Service Private Cloud oder Public Cloud: Für Datenbanken gelten im Grunde fast immer sehr hohe Compliance und Security-Anforderungen, wodurch sich in aller Regel eine Public Cloud verbietet. Eine Hybrid-Strategie, bei der neben Private Cloud auch Public Cloud-Dienste für Kurzzeit-Anforderungen genutzt werden, ist im Allgemeinen weniger zu empfehlen. Wenn, dann bietet es sich an, die Entwicklungsumgebungen in die Public Cloud und Test sowie Produktion in die Private Cloud zu legen Um möglichst flexible Services bieten und wesentliche Anforderungen an einen Datenbank-Service erfüllen zu können, wird in aller Regel eine Standard Infrastruktur Cloud (IaaS) nicht ausreichen. Eine Oracle Cloud-Strategie wird sich mit steigenden Anforderungen an den Service auf Basis einer PaaS-Architektur (Platform as a Service) wesentlich einfacher, flexibler und kostengünstiger realisieren lassen. Public Cloud Private Cloud PaaS auf Basis Public Cloud Oracle as a Service IaaS auf Basis Public Cloud IaaS auf Basis Private Cloud PaaS IaaS Compliance & Security-Anforderungen 4.1Services Aus Sicht des Kunden soll eine Anwendung genutzt werden, und es wird hierzu eine Datenbank benötigt. Die soll schnell, kostengünstig und hochverfügbar sein, muss schnell implementiert werden und sehr einfach skalieren. Im Allgemeinen ist für Kunden die Frage nach einem dediziertem System oder einer Oracle Cloud zweitrangig. Die Erfahrung zeigt: Mehr als 80% aller Oracle-Implementierungen sind in der Regel konsolidierungs- und Cloud-fähig. Seite 10/33 update 4.2Architektur Um auf Basis der oben erwähnten Anforderungen eine geeignete Plattformstrategie zu entwickeln, werden heute eine Reihe von Grundsätze stets ins Feld geführt: Standardisierung, Automatisierung sowie Virtualisierung auf Basis einer x86 Hardware-Plattform stehen im Vordergrund der Betrachtung. Im Ergebnis ließen sich nahezu alle formulierten Anforderungen auf Basis einer x86 basierten Oracle Cloud abbilden. Die in den Unternehmen entwickelten Plattformen entsprechen vielfach den aktuellen Technologie-Standards. Sie unterscheiden sich gegenüber einer Oracle Cloud aber in wenigen. So werden beispielsweise in einer Oracle Cloud sinnvollerweise OEL sowie Oracle VM (Oracle Enterprise Linux, Oracle Virtual Machine) eingesetzt, im Bereich Exadata wird selbstverständlich kein Standard-Storage eingesetzt. Application Database as a Service Oracle x86 Cloud • • • • • Oracle 11gR2 / 10.x Oracle Enterprise Linux 5.6 x64 RAC (optional) ASM (optional) OVM (optional) Exadata • • • • Oracle 11gR2 Oracle Enterprise Linux 5.6 x64 RAC ASM X86-Hardware Standard-Storage Database as a Service ermöglicht für alle Anwendungen eine einheitliche Applikationsschnittstelle. Um die Skalierbarkeit zu erhöhen oder um Hochlastdatenbanken zu betreiben, wird eine sinnvolle Plattformstrategie durch Oracle Exadata ideal ergänzt. Eine zeitgemäße Plattformstrategie setzt sinnvollerweise auf so genannte „Standardhardware“ auf. Dies sind heute X86-kompatible Server mit Intel- oder AMD-CPUs welche von vielen verschiedenen Herstellern (u.a. HP, IBM, Dell, ...) in verschiedenen Größen (von 1 bis 160 Cores und von ein paar GB bis 4 TB Arbeitsspeicher) geliefert werden können. Seite 11/33 update Die verschiedenen Komponenten sind in der folgenden Tabelle dargestellt und werden nachfolgend erläutert: Database Management Oracle Enterprise Manager 11 Database DR Oracle Data Guard 11gR2 3rd Party Applikationen Beliebiger Hersteller Database Software Oracle 11gR2 (11.2.0.x) Automatic Storage Oracle Automatic Storage Manager (ASM 11.2) Management (ASM) O/S Clusterware Oracle Grid Infrastruktur (CRS 11.2) O/S Oracle Enterprise Linux 5.x oder 6.x 64-bit Operating System Netzwerk Ethernet für Enduser und Applikationen; Infiniband (wenn nicht vorhanden, 10 Gbit Ethernet) für den Interconnect X86 Hardware Beliebiger Hersteller Storage Beliebiger Hersteller; FC-SAN empfohlen, iSCSI nur bei geringerem I/O 4.2.1.1Design-Grundsätze Das Design der Plattform folgt zwei Grundsätzen: KISS (Keep it Simple & Stupid) Kein Single-Point-of-Failure „KISS“ steht für „Keep it Simple Stupid“ und bezeichnet eine Maxime, bei der das einfachere Verfahren meist auch das bessere ist. Die andere Maxime bezieht sich auf alle Komponenten einer Plattform, zielt also auch auf einen durchgehend redundanten Aufbau der gesamten Infrastruktur – angefangen von der Stromverkabelung über die Server und den Storage bis hin zur Anbindung der Applikationen und Benutzer. Seite 12/33 update 4.2.1.2 Storage und Protokolle Als Storage für die Oracle Cloud kann im Grund jede Art von Storage jedes Hersteller verwendet werden. Einschränkungen gelten aber für die verwendeten Protokolle: So können für den Aufbau eines Clusters sowohl dateibasierte Protokolle wie NFS als auch blockbasierte Protokolle wie iSCSI oder normal SCSI über Fibre Channel zum Einsatz kommen. Allerdings hat die Wahl des Protokolls Auswirkungen auf Verfügbarkeit und Performance: NFS iSCSI, SCSI über Fibre Channel Das Network File System (NFS) stammt ursprünglich von SUN und liegt heutzutage in Version 4 vor. Es arbeitet dateibasiert und kann als „Shared Storage“ für einen RAC und dessen Datenbanken benutzt werden. Von Vorteil ist, dass ein NFS sehr flexibel ist, was die Speicherplatzzuteilung angeht und keine Fibre Channel-Infrastruktur benötigt wird. Problematisch sind die durch den Transport über Ethernet hervorgerufenen relativ großen Latenzen (1-2ms) im Vergleich zu Fibre Channel. Dies wirkt sich negativ auf die gesamte IO-Leistung aus. Zudem muss Hochverfügbarkeit des NFS-Storages selber sowie die Kommunikation zwischen NFS-Storage und Datenbankserver gewährleistet werden. Als weitere Nachteile sind der hohe Konfigurationsaufwand für die Platzierung der Voting Disk (diese kann nicht direkt auf einem NFS liegen, sondern muss über Umwege angebunden werden) sowie die je nach NFS-Server gar nicht oder nur mit hohem Aufwand vorhandene Möglichkeit Strechted Cluster aufzubauen zu nennen. iSCSI ist genau wie SCSI über Fibre Channel ein blockbasiertes Protokoll. Die Server nehmen den präsentierten Speicherplatz – die „LUN“ – als weitere Festplatte im System wahr. Bei iSCSI werden die Daten ähnlich wie bei NFS per Ethernet übertragen während bei einem klassischem Fibre Channel SAN die Daten per Lichtwellenleiter übertragen werden. iSCSI hat demnach genau wie NFS eine relativ hohe Latenz von 1-2 Millisekunden(ms, 10-3 Sekunden) im Vergleich zu wenigen Mikrosekunden (µs, 10-6 Sekunden). Ebenfalls ist die Realisierung von fehlertoleranten Verbindungen beim Einsatz von iSCSI schwieriger. Obwohl RACs auch mit NFS als Protokoll betrieben werden können, ist das bevorzugte Protokoll aufgrund der Probleme und Einschränkungen von NFS ganz klar entweder FC-SCSI oder - wenn keine Fibre Channel-Infrastruktur zur Verfügung steht - iSCSI. Im Zusammenspiel dieser Protokolle mit ASM (Automatic Storage Management) können sehr leicht hochverfügbare Cluster errichtet werden, die Verfügbarkeiten jenseits von 99,99% erreichen können. Seite 13/33 update Costs per Unit 4.2.1.3Hardware Als Hardwareplattform kann jedes X86-kompatible System zum Einsatz kommen. Ob hierbei CPUs von Intel oder AMD eingesetzt werden spielt ebenfalls keine Rolle. Bei der Anzahl der CPUs muss eine genaue Planung erfolgen, da jede vorhandene CPU auch lizenziert werden muss. Ausnahmen von dieser Regel sind im Abschnitt „Virtualisierung und Lizenzierung“ weiter unten beschrieben. Die Größe des Arbeitsspeichers lässt sich mit dem Satz „Je mehr, desto besser“ umschreiben. Hierbei sollte die Wirtschaftlichkeit allerdings nicht vernachlässigt werden. Häufig entwickelt sich der Preis und die damit einhergehende Größe des Arbeitsspeichers bis zu einem bestimmten Punkt linear um dann exponentiell zu steigen. Dieser Punkt stellt die wirtschaftlich sinnvollste Größe des Arbeitsspeichers dar. 32 64 128 Memory Außerdem sollten möglichst große interne Festplatten gewählt werden um möglichst viele unterschiedliche Datenbankversionen installieren zu können. Neben weiteren Standardkriterien wie redundanten Netzteilen und Lüftern ist zum einen die Anzahl der freien PCI-Slots für die Ausbaubarkeit und zum anderen die Anzahl der Netzwerkschnittstellen wichtig. In die freien PCI-Slots kommen später unter anderem Fibre Channel-HBAs für den Anschluss des Servers an ein SAN oder weitere Netzwerkkarten (Ethernet oder Infiniband). In jedem Fall müssen die HBAs für den Anschluss an egal welches Netzwerk (Ethernet, Infiniband, Fibre Channel) redundant ausgelegt werden um einen Single Point of Failure zu vermeiden. Best Practise ist jeweils zwei verschiedene HBAs – ggf. mit mehreren Ports pro HBA – zu verwenden. Es wird empfohlen alle Server im Cluster gleichmäßig auszustatten, auch wenn eine unterschiedliche Ausstattung der Systeme möglich ist. In diesem Fall kommt dem Ressourcenmanagement eine noch wichtigere Rolle zu. Seite 14/33 update 4.2.1.4Netzwerke Ein weiteres Kriterium bei der Auswahl der Hardware ist die Entscheidung welche Technologie für den Interconnect benutzt werden soll. Gegenwärtig stehen zwei zur Auswahl: Ethernet und Infiniband. Ethernet Infiniband Ethernet ist die „Standardtechnologie“ zur Realisierung eines Interconnects. Aufgrund der relativ hohen Latenz von Ethernet hat dies Auswirkungen auf die Performance des Gesamtsystems. Neben der Latenz ist hier die Bandbreite ein weiterer entscheidender Faktor. Hier sollte 1 Gbit/s als Mindestanforderung für kleine RACs gelten. Infiniband ist ein speziell auf geringe Latenz hin entwickeltes Protokoll. Es weist Latenzen im zweistelligen Nanosekundenbereich auf. Das ist ein Faktor 10-5 weniger im Vergleich zu Ethernet. Die Bandbreite beträgt bis zu 40 Gbit/s. Infiniband eignet sich vor allem für große Cluster mit viel Arbeitsspeicher und hoher Last. Leider benötigt Infiniband eine eigene Infrastruktur. Die erste Wahl bei großen Clustern sollte Infiniband sein. Sollte dies aus Kostengründen nicht favorisiert werden, so sollte zumindest die Wahl auf 10 Gbit/s Ethernet („10 GE“) fallen, da diese Technologie genügend Bandbreite für den Interconnect für die nächsten Jahre bietet. In keinem Fall sollten große Cluster mit 1 Gbit/s aufgebaut werden, da dies sehr schnell zum Flaschenhals wird. 4.2.1.5 Betriebssystem Auf X86-kompatibler Hardware läuft eine Vielzahl unterschiedlicher Betriebssysteme. Nur Windows, x86 Solaris und Linux sind derzeit für Oracle Datenbanken sinnvoll. Während Windows ein Betriebssystem mit unterschiedlichen Versionen ist, bezeichnet Linux eine ganze Gruppe von unterschiedlichen Distributionen: SuSE Linux, Debian, Red Hat, Ubuntu, Kubuntu, Gentoo, Oracle Enterprise Linux, Cent OS und viele mehr. Von diesen Distributionen sind aktuell nur vier von Oracle für den Einsatz mit der Oracle Datenbank zertifiziert: • • • • Asianux Red Hat Enterprise Server SuSE Linux Enterprise Server Oracle Linux Enterprise Server Die Empfehlung für das Betriebssystem für die Oracle Cloud fällt in diesem Paper auf Linux, genauer auf OEL (Oracle Enterprise Linux) in der aktuellsten Version 5.x oder sofern möglich 6.x. Seite 15/33 update Die Gründe für die Entscheidung gegen Windows und für Linux liegen vor allem in dem Fakt, dass Oracle selbst auf Linux entwickelt und auf alle anderen Plattformen im Anschluss portiert. Ebenfalls ist die installierte Basis von Oracle unter Linux weltweit gesehen am größten. Weiterhin gibt es nur relativ wenige große RAC Cluster, die auf Windows laufen, wohingegen die größten Cluster sowie Exadata auf Linux laufen. Oracle Enterprise Linux als Betriebssystem wurde unter anderem gewählt, weil der Support durch den gleichen Hersteller erfolgt – häufig wird hierbei von „Support aus einer Hand“ gesprochen. In der Praxis bietet dies eine schnellere Bearbeitung von Problemen. Natürlich ist die Realisierung einer Oracle Cloud auch mit Windows oder einer anderen Linux-Distribution möglich. Im Detail können die Konzepte sich hierdurch allerdings unterscheiden. 4.2.1.6Clusterware Die Clusterware bildet das Fundament des Gesamtsystems und stellt zentrale Infrasktruktur-Dienste wie ASM, Clustersynchronisation und Listener für den gesamten Cluster zur Verfügung. Die hierfür notwendige Komponente hieß früher „Oracle Clusterware“ und wurde mit Version 11g Release 2 in „Grid Infrastruktur“ umbenannt und muss für den Aufbau eines RACs zwingend installiert sein. Auch wenn andere Hersteller wie beispielsweise Symantec (ehemals Veritas) Clustersoftware anbieten, die sich mit der immer notwendigen Grid Infrastruktur verbinden lassen, besteht aus Sicht der Autoren keinerlei Anlass eine weitere Clustersoftware einzusetzen, da dies einerseits der Maxime „KISS“ widerspricht und andererseits die Grid Infrastruktur alle notwendigen Services bereits zur Verfügung stellt. Zudem ermöglicht sie auch eine problemlose Integration von Non-Oracle-Software. Zur eingesetzten Version gilt die Empfehlung: Stets die aktuellste Version der Grid Infrastruktur plus aktuellstem PSU nutzen (siehe hierzu auch avato Whitepaper Lifecycle and Security Management). Seite 16/33 update 4.2.1.7 Automatic Storage Management Das Automatic Storage Management - oder kurz ASM – regelt als eine Art Volume Manager alle den Speicherplatz betreffenden Funktionalitäten und ist der zentrale Layer zwischen Datenbank und Storage. Application Oracle Database Automatic Storage Management Das Automatic Storage Management (ASM) selbst ist ein plattformunabhängiges und High-Performance Cluster Filesystem, welches sowohl für die Speicherung von Oracle Datenfiles also auch als universell einsetzbares Filesystem eingesetzt warden kann. ASM ist in der Lage die, ihm anvertrauten Daten durch Spiegelung entweder doppelt oder dreifach vorzuhalten und somit eine sehr hohe Verfügbarkeit der Daten zu garantieren. ASM Cluster File System ASM Dynamic Volume Manager ASM Files for Oracle Database Operating System ASM organisiert den Storage intern in so genannte Disk Groups welche aus möglichst gleich großen LUNs bestehen. Von diesen Disk Groups gibt es genau zwei: DATA und FRA. DATA speichert alle Datenfiles (inklusive TEMP und UNDO), sowie jeweils eine Kopie des Control Files und einen Member einer jeden Redo Log Gruppe. FRA speichert die jeweils andere Kopie des Controlfiles und der Redo Log Member. Zusätzlich werden hier die Archivelogs, Flashback Logs, Exporte und RMAN-Backups gespeichert – eben alles, was mit der Wiederherstellung der Datenbank zu tun hat. Kern dieser Idee ist, dass die LUNs, die DATA und FRA bilden, nicht aus den gleichen Festplatten bestehen und im Optimalfall nicht zum gleichen Array im Storage gehören, so dass selbst ein Komplettverlust einer Disk Group zu keinerlei Datenverlust führt, da mit Hilfe der anderen Disk Group immer eine vollständige Wiederherstellung der Datenbank möglich. Seite 17/33 update Die Disk Groups selbst weisen eine von drei möglichen Redundanztypen auf: EXTERNAL: ASM kümmert sich nicht selbst um die Redundanz und verlässt sich einzig auf den Storage. NORMAL: ASM hält von jedem geschriebenen Byte eine Kopie. Die Daten sind also zwei Mal vorhanden. HIGH: ASM hält zwei statt einer Kopie von den Daten, so dass die Daten drei Mal vorhanden sind. Bei der Konfiguration der Redundanztyp werden die LUNs im Level NORMAL und HIGH in sogenannte Fail Groups eingeteilt. Eine Fail Group besteht dabei aus LUNs, die einen gemeinsamen Single Point of Failure teilen. Im folgenden Bild arbeitet ASM mit einer NORMAL Redunanz, welche garantiert, dass die Daten immer zwei Mal vorgehalten werden. Die LUNs selbst kommen von zwei verschiedenen Storages, und jeder Storage für sich bildet eine Failure Group. Durch diese Einteilung der LUNs wird ASM in die Lage versetzt zu verstehen, welche LUNs zusammengehören und demzufolge auch gemeinsam ausfallen können. In der Konsequenz sorgt ASM dafür, dass das Original und die Kopie der Daten niemals in der gleichen Failure Group liegen. ASM Fail Group 1 Fail Group 2 LUNs Storage-System 1 LUNs Storage-System 2 Aus diesem Grund ist es dringend empfohlen alle LUNs eines Storage-Systems einer gemeinsamen Fail Group zuzuweisen. Seite 18/33 update Durch die Kombination von Redundanzlevel und Fail Group erhält ASM seine wichtigste Eigenschaft: den Schutz vor einem Ausfall eines Storages (sofern als Redundanzlevel NORMAL oder HIGH gewählt wurde). Fällt ein Storage aus, so kann ASM dies kompensieren und die Datenbanken und der gesamte Cluster funktionieren ohne Unterbrechung weiter. Wird die Funktionsfähigkeit des ausgefallenen Storages später wiederhergestellt, so kann der Storage ebenfalls transparent und ohne Downtime wieder in das ASM integriert werden. Dies ist sogleich die zweite wichtige Eigenschaft von ASM: Das Hinzufügen und Entfernen von Storage zum ASM ist für die auf ASM aufbauenden Datenbanken und Applikationen ein absolut transparenter Prozess, der ohne Downtime abläuft. Selbst eine Migration von einem Storage zu einem anderen kann im laufenden Betrieb erfolgen. Als weitere Eigenschaft kann ASM ab Version 11g Release 2 nicht nur von den Datenbanken direkt benutzt werden sondern bietet auch ein auf ASM aufbauenden Clusterdateisystem an, welches von Anwendungen wie zum Beispiel Tomcat oder mySQL genutzt werden kann um diese ebenfalls hochverfügbar zu machen. Die Empfehlung der Autoren geht eindeutig dahin, ASM mit NORMAL Redundanz zu nutzen. Wo eine größtmögliche Fehlertoleranz erreicht werden soll, ist der Einsatz von HIGH als Redundanzlevel zu überlegen. 4.2.1.8 Database Software Als Datenbanksoftware kommt entweder die Standard oder Enterprise Edition (siehe auch unten Lizenzierung) zum Einsatz. Durch den Aufbau des Clusters und die Wahl des Betriebssystems ist es möglich jede Datenbankversion von 10g Release 1 bis 11g Release 2 einzusetzen. Einziges Kriterium ist, dass die Version der Grid Infrastruktur immer größer oder gleich der höchsten eingesetzten Datenbankversion ist. Sind die internen Festplatten ausreichend groß gewählt, können möglichst viele unterschiedliche Datenbankversionen eingesetzt werden. Allerdings sollte wenn möglich nur die aktuelle Version 11g Release 2 oder 11g Release 1 eingesetzt werden, da es nur für diese noch Support von Oracle gibt (siehe hierzu auch avato Whitepaper Oracle Lifecycle & Security-Management). 4.2.1.9 3rd Party Applikationen Die Grid Infrastruktur verfügt über ein anpassbares Framework mit dem auch Nicht-Oracle-Produkte einfach in den Cluster integriert werden können. So kann die Oracle Cloud um kleinere, eng mit der Datenbank oder einer Applikation verbundene Services erweitert werden (Database Machine). Bei der Integration ist allerdings ein zu starker Mischbetrieb von Datenbank und Applikation nicht ratsam, da der gesamte Server inklusive aller Cores für die Oracle Datenbank lizenziert werden muss. Wenn durch das parallele Betreiben anderer Applikationen ein größerer Teil der CPUs belegt wird so ist dies ineffektiv und teuer. Seite 19/33 update 4.2.1.10 Database Desaster Recovery Zum Schutz der Oracle Cloud vor Ausfällen wird neben dem RAC und dem zwischen zwei Storage spiegelnden ASM zusätzlich ein Data Guard mit aktiviertem Flashback empfohlen. Hier sind sehr unterschiedliche Varianten möglich: a) Stretched Cluster über zwei Datacenter mit Replikation in ein drittes Datacenter A Datacenter B Datacenter C RAC Standby Cluster RAC Stretched Cluster Dataguard Replication Node C Node A Node B Node D b) Cluster mit Replikation auf einen anderen Cluster in anderem Rechenzentrum Datacenter A Datacenter A RAC Cluster RAC Cluster Dataguard Replication Database A Replication B Replication A Database B Seite 20/33 update c) Stretched Cluster mit Replikation auf einen Standby-Node in einem der Datacenter Datacenter A Datacenter B RAC Stretched Cluster Node A Node B Dataguard Replication Standby Node • • Physically seperated Storage seperated RAC und ASM schützen gegen den Ausfall eines Servers oder eines Storages – nicht aber gegen Benutzerfehler. Eine gelöschte Tabelle ist auch in einem RAC gelöscht – hochverfügbar garantiert. Hier bietet sich Data Guard an um die Daten nochmal an eine andere Lokation zu spiegeln – wahlweise synchron, garantiert ohne Datenverlust oder asynchron, wenn geringfügiger Datenverlust akzeptabel ist. Data Guard schützt durch die Kombination mit Flashback vor Benutzerfehlern. Mittels Flashback kann eine Datenbank auf einen Punkt in der Vergangenheit zurückgesetzt, die versehentlich gelöschte Tabelle extrahiert und die Datenbank wieder mit der Primärdatenbank synchronisiert werden. Database Management Für das einfache Management und zur Überwachung der Datenbanken kommt Oracle Enterprise Manager Cloud Control 12c zum Einsatz. Es bietet neben dem detaillierten Monitoring zahlreiche weitere Features wie beispielsweise ein automatisches Provisioning von Datenbanken. Seite 21/33 update 4.2.2 Was ist zu beachten? Ein paar Erfahrungen aus der Praxis Der Aufbau einer Oracle Cloud kennt einige Fallstricke, von denen ein paar in diesem Abschnitt angesprochen werden sollen. 4.2.2.1 Platzierung der dritten Voting Disk Für den ordnungsgemäßen Betrieb eines Clusters sind zur Mehrheitsfindung mindestens 1 (EXTERNAL Reundanz), 3 (NORMAL) bzw. 5 (HIGH) Voting Disks notwendig. Von diesen müssen zu jeder Zeit mehr als die Hälfte (also > 50%) verfügbar sein. Ist dies nicht gegeben, so schalten sich der Cluster bzw. die betroffenen Knoten selbstständig ab. Daher kommt der Platzierung der dritten bzw. fünften Voting Disk eine besondere Rolle zu, welche nachfolgend für die am häufigsten vorkommende Konfiguration mit NORMAL Redundanz vorgestellt werden soll. Ein Cluster mit NORMAL Redundanz zeichnet sich durch das Vorhandensein von zwei möglichst völlig unabhängigen Storages aus. Auf jeden dieser Storages wird eine Voting Disk platziert. Die dritte Voting Disk kann nicht auf einen der beiden vorhanden Storages platziert werden, da beim Ausfall des Storages mit den dann zwei Voting Disks weniger als 50% der Voting Disks verfügbar wären, was zu einem Komplettausfall des Clusters führen würde. Daher muss die dritte Voting Disk auf einen dritten Storage platziert werden. In größeren Umgebungen kann das ein dritter Storage sein. Alternativ ist es auch möglich und von Oracle supported, iSCSI für die dritte Voting Disk zu nutzen, so dass ein bereits vorhandender Server als iSCSI Target (ein „Target“ stellt anderen Servern Speicherplatz zur Verfügung) konfiguriert werden kann, der dann den Clusterknoten die Voting Disk präsentiert. 4.2.2.2 Blades vs. Single Server Die Wahl zwischen Blades und Single Servern ist immer von den aktuellen Anforderungen und Standards abhängig. Blades bieten vor allem den Vorteil eines geringen Platzverbrauches, sind aber durch die Abhängigkeiten vom Chassis und deren Komponenten sowie der Software im Chassis aufwändiger in der Wartung als Single Server. Mitunter sind bei einem Problem in einem Bladechassis (oder Bladecenter) gleich mehrere Server betroffen – bis hin zum gesamten Cluster oder einem großen Teil davon. Daher geht die Empfehlung klar Richtung Single Server. Sollte dies aufgrund der Unternehmensstrategie nicht möglich sein, so sollten die einzelnen Knoten des Clusters auf mehrere Bladecenter aufgeteilt werden. In keinem Fall sollten alle Knoten im gleichen Bladecenter sitzen, da dies einen Single Point of Failure schaffen würde. Seite 22/33 update 4.2.2.3 Größe des Clusters Die Größe eines RAC ist durch die eingesetzte Datenbankversion beschränkt: Beim Einsatz von Oracle Standard Edition sind maximal vier Knoten und in Summe vier CPU-Sockel pro Cluster zulässig. Die Anzahl der Cores ist aktuell nicht limitiert. Die Enterprise Edition ermöglicht bis zu 100 Knoten. Zwei Knoten sind der kleinstmögliche sinnvolle Cluster (es ist auch möglich einen Knoten wie einen Cluster zu installieren um ihn später zu erweitern) und zugleich ein Sonderfall, weil eine Fehlerisolierung mit zwei Knoten nicht möglich ist. Erst mit drei Knoten wird eine Fehlerisolierung möglich und ein Cluster bestehend aus drei Knoten gilt gemeinhin als kleinster „richtiger Cluster“, der allerdings ebenfalls eine Besonderheit hat: Fällt ein Knoten aus besteht der Cluster wieder nur aus zwei Knoten und das oben Gesagte trifft wieder zu. Erst vier Knoten haben all diese Einschränkungen nicht, so dass bei größeren Umgebungen die Cluster aus mindestens vier Knoten bestehen sollten. Ein praktikables Limit würde der Autor bei 8 bis 16 Knoten sehen, da bei steigender Anzahl der Knoten auch der Wartungs- und Patchaufwand steigt. 4.2.2.4 Aufteilung der Ressourcen im Cluster Ressourcenkontrolle und -management sind in einem Cluster eine zentrale Aufgabe – insbesondere wenn einzelne Knoten unterschiedlich gut ausgestattet sind. Oracle selbst stellt mit der Einführung von Server Pools ein Instrument zur Verfügung mit dem nur noch angegeben wird, wie oft Ressourcen (Datenbankinstanzen und auch Drittsoftware) im Cluster laufen soll und welche Hosts hierfür in Frage kommen. Die Verteilung der Ressourcen auf die Knoten regelt die Clusterware selbst. Zusätzlich zu den Server Pools können die Ressourcen in der Datenbank selbst mit dem Parameter „CPU_ COUNT“ für die ganze Datenbank global limitiert und mittels des Ressource Managers innerhalb der Datenbank zugewiesen werden. 4.2.2.5 Zertifizierung beachten! Damit im Fehlerfall auch Support von den jeweiligen Herstellern in Anspruch genommen werden kann, ist es wichtig beim Aufbau der Plattform auf die Zertifizierung aller eingesetzten Komponenten zu achten. Insbesondere der Zertifizierung der Hardware, des Betriebssystems und der HBAs untereinander kommt hier eine zentrale Bedeutung zu, so dass keiner der Hersteller sich im Problemfall auf eine nicht vorhandene Zertifizierung zurückziehen kann. Seite 23/33 update 4.2.3 Virtualisierung – Ja oder Nein und wenn ja, wo? Virtualisierung als Möglichkeit, vorhandene Hardware besser zu nutzen, ist in aller Munde, und auch für die Realisierung der Oracle Cloud eine sinnvolle Möglichkeit. Allerdings hat diese Technologie für Oracle Datenbanken einige Grenzen, welche im Folgenden erläutert werden sollen. Technologisch kann Virtualisierung durch eine ganze Reihe von unterschiedlichen Ansätzen erreicht werden: • Softwarevirtualisierung - Virtualisierung mittels Containern (z.B. Solaris, BSD Jails, OpenVZ, ...) - Virtualisierung mittels Virtual Machine Monitors (aka „Hypervisor“) * ohne Anpassung des Betriebssystems: Hardware-Emulation (z.B. Bochs) Hardware-Virtualisierung (VMware, Xen, OVM) * mit Anpassung des Betriebssystems: Paravirtualisierung (auch VMware, Xen, OVM) • Hardwarevirtualisierung - Feste Partition - Dynamische Partition Virtualisierung mittels Container bezeichnet eine Technologie bei der eine komplette Betriebssystemlaufzeitumgebung virtuell innerhalb eines in sich geschlossenen Containers zur Verfügung gestellt wird. Hierbei wird allerdings kein neues Betriebssystem gestartet, so dass es nicht möglich ist, ein anderes Betriebssystem innerhalb eines Containers zu starten oder Treiber nachzuladen. Der Vorteil des Verfahrens liegt in der Geschwindigkeit, da keine wie auch immer geartete Emulation stattfindet. Zu den wichtigsten Technologien der Virtualisierung gehört die Hardware-Virtualisierung, bei der die virtuelle Maschine dem Gastbetriebssystem Teilbereiche der physikalischen Hardware in Form von virtueller Hardware zur Verfügung stellt. Diese virtuelle Hardware ist allerdings ausreichend damit das virtualisierte Betriebssystem in unveränderter Form betrieben werden kann. Bei der Paravirtualisierung wird keine Hardware emuliert oder virtualisiert. Stattdessen verwenden die Betriebssysteme eine abstrakte Verwaltungsschicht um auf Ressourcen zuzugreifen. Dies erfordert immer Anpassungen am Betriebssystem, verspricht aber die höchste Leistung verglichen mit den anderen Ansätzen. Wie oben gezeigt gibt es am Markt derzeit zwei dominierende Software-Technologien zur Virtualisierung: VMware und XEN. Während VMware ein Produkt bezeichnet, steht XEN für eine ganze Reihe von abgeleiteten Produkten, wie zum Beispiel der Citrix XenDesktop, SuSE Linux Enterprise Server mit Xen oder auch das Oracle-eigene Produkt Oracle Virtual Machine – OVM. Seite 24/33 update Aus Sicht des Autors ist es wichtig sich zu vergegenwärtigen, dass Virtualisierung immer mit einer Leistungseinbuße verbunden ist. Zudem entstehen durch die eingesetzte Virtualisierung Abhängigkeiten und Einschränkungen in den technischen wie auch organisatorischen Möglichkeiten, die es im Auge zu behalten gilt. Ebenfalls problematisch ist die Frage nach dem Support durch Oracle. Dieser ist - mit Ausnahme bei Einsatz des Produktes aus dem eigenen Haus - nicht gegeben. Aufgrund dieser Einschränkungen und technischen Limitationen kann eine Empfehlung für Virtualisierung nur für nicht-produktionsrelevante Datenbanken gegeben werden, bei denen Performance und Verfügbarkeit keine Schlüsselrolle spielen, sondern vielmehr Flexibilität gefragt ist. Häufig wird Virtualisierung auch als eine Methode zur Lizenzkostenkontrolle gesehen. Allerdings ist dies nur gegeben wenn gewisse Einschränkungen beachtet werden. Diese Einschränkungen werden im folgenden Abschnitt angesprochen. 4.2.4Lizenzierung 4.2.4.1 Standard / Enterprise Edition im RAC Je nach Größe des Clusters ist es möglich die Standard Edition statt der Enterprise Edition zu verwenden. Die entscheidenden Kriterien für die Möglichkeit des Einsatzes der Standard Edition sind: • maximal 4 Sockel (unabhängig von den Cores pro Sockel!) • auf maximal zwei Servern • ASM muss genutzt werden (kein NFS!) Doch nicht nur die Größe des Clusters diktiert diese Entscheidung, sondern vielmehr folgende Faktoren: • Größe der Datenbank • Benötigte Spezialfeatures wie zum Beispiel Partitioning • Parallelisierung bei Abfragen oder auch dem Backup 4.2.4.2 Virtualisierung und Lizenzierung Virtualisierung als Methode zur Lizenzkostenkontrolle folgt der Annahme, dass nur die der Virtuellen Maschine wirklich zugeteilten Ressourcen (hier vor allem die Anzahl der CPUs) auch lizenziert werden müssen und so auf einem auch für anderen Applikationen verwendeten Cluster Oracle Datenbanken mit nur geringen Mehrkosten mitbetrieben werden können. Dies ist nur bedingt so. Zunächst ist diese Art der Lizensierung nur beim Einsatz von so genanntem „Hard Partitioning“ möglich. Virtuelle Maschinen per se sind „Soft Partitioned“, so dass eine Lizenzierung basierend auf den der VM zugewiesenen CPUs nicht zulässig ist. Erst durch die Erfüllung spezieller Bedingungen, die gleichzeitig mit technischen Limitationen einhergehen, kann aus Seite 25/33 update einer „Soft Partitioned“ VM eine „Hard Partitioned“ VM im Sinne der Lizenzbedinungen von Oracle gemacht werden. Welche Virtualiserungsprodukte unter welchen Bedingungen als „Hard Partitioning“ anzusehen sind, ist im Oracle Whitepaper „Oracle Partitioning Policy“ beschrieben. VMware und andere Produkte sind hiervon generell ausgenommen, da immer der gesamte Cluster mit allen CPUs lizenziert werden muss. Da der Cluster in den allermeisten Fällen aus mehr als 4 CPU-Sockeln und zwei Hosts bestehen wird, muss dann sogar die teurere Enterprise Edition lizenziert werden. Solaris Container sind unter gewissen Bedingungen als „Hard Partitioned“ anzusehen, insbesondere dann, wenn keine Ressourcen dynamisch zugewiesen werden können und die Anzahl der CPUs statisch begrenzt wird. Bei Einsatz von Oracle VM sind virtuelle Maschinen als solche ebenfalls nur „Soft Partitioned“. Erst durch das „pinnen“ von Virtuellen Maschinen auf eine oder mehrere physikalische CPUs wird das geforderte “Hard Partitioning“ erreicht. Diese statische Zuweisung von CPUs zu virtuellen Maschinen geht mit zwei gravierenden Nachteilen einher: 1. Es muss manuell nachgehalten werden, welche VM welche physikalischen CPU benutzt, um so eine doppelte Belegung der gleichen CPU durch mehr als eine virtuelle Maschine zu vermeiden. Dieses Mapping muss kontinuierlich angepasst werden, da laufend Änderungen zum Beispiel durch den Start einer VM erfolgen. 2. Eine „Live-Migration“, also ein Verschieben der laufenden virtuellen Maschine von einem Host auf den anderen, ist durch das „pinnen“ auf bestimmte CPUs nicht mehr möglich. Hiermit geht eine Kernfunktionalität verloren. Seite 26/33 5 update Erfolgsfaktoren bei der Umsetzung Entscheidende Erfolgsfaktoren neben dem Management-Buy-in für die Etablierung einer standardisierten Plattform: 1. Flexibilität der Services Nicht zu unterschätzen ist die Frage nach Anzahl implementierter Oracle-Releases. Zudem sollte eine Plattform neben der Datenbank Instanz auch immer eine Datenbank Maschine bieten. 2. Database Provisioning & Onboarding Es müssen klare Kriterien für das Onboarding und den Verbleib auf eine Shared-Plattform definiert sein, zudem muss der Prozess schnell durchlaufen werden. 3. Migrationsstrategie und -support Sandbox-Systeme und umfangreicher Projektsupport sind partiell erforderlich, das Verhalten der Datenbank muss vor allem bei Systemen mit hoherI/O getestet werden. Unterstützung für Migration auf neue Version ist teilweise erforderlich. 4. Modelle zur Kostenverrechnung Die Kostenvorteile der Plattform müssen für Kunden greifbar sein und sich schnell realisieren lassen. 5.1 Flexibilität der Services Eine zentrale Frage für jeden Oracle Cloud-Service lautet: Wie viele Releases sollen bereitgestellt werden? Eine Release-Policy, der nur ein Teil der Anwendung genügen kann, ist unter dem Gesichtspunkt Kosten- und Aufwandsreduktion wenig erfolgversprechend. Grundsätzlich zwei unterschiedliche Release-Stände (aktuell 10.x / 11.2) anbieten zu können, kann im Einzelfall die Anzahl der Nutzer beträchtlich erhöhen und am Ende die Vorteile für alle Nutzer überwiegen lassen. Ein zweites Kriterium für den Erfolg der Oracle Cloud-Services sind die Wartungsfenster, die angeboten werden können. Erscheinen individuelle Wartungsfenster für eine Anwendung erforderlich, sollte nicht der Versuch unternommen werden, Anwendungen durch Kostenvorteile entgegen ihrer eigentlichen Anforderungen auf eine Plattform zu locken. Durch das Konzept der Datenbank-Instanz mit geringer Verdichtung auf Servern (virtuell oder physikalisch) kann hier ausreichend Individualität geboten werden. Gleiches gilt für die Patch-Strategie. Sind spezielle Features erforderlich oder werden solche zukünftig benötigt, kann man solchen Anforderungen durch die Database Instance sowie der Database Machine begegnen. Zu solchen Anforderungen können external data access, access to external data by user out of database (e.g. external tables, UTL_FILE operations …), special database options, external OS access by application users, national language settings, global objects (e.g. directory, scheduler), special interfaces (e.g. Mail, FTP …), non Oracle RDBMS components sowie Database parameter customization gehören. Seite 27/33 update Weitere Individualität an Services entsteht durch Anforderungen an Backup, Recovery und Archiving. Hier sind Backup schedules, Recovery max. time for database backup, Backup method, Backup Redundancy, Backup incremental strategy, Backup further requirements, Archiving, Flashback auf verschiedenen Ebenen angesprochen. 5.2 Database Provisioning & Onboarding Jede Oracle Cloud ist selbstverständlich immer eine Shared-Plattform. Damit sind die wesentlichen Kriterien für ein Onboarding skizziert: Jede Anwendung muss die Spielregeln der Plattform einhalten. Kann eine Anwendung diesen Regeln nicht mehr genügen, muss sie auf eine andere Infrastruktur weichen. Aber was sind empfehlenswerte Regeln, wie kann man sie sinnvoll abstufen für die offerierten Services? Regeln und Onboarding-Kriterien lassen sich im Grunde in zwei Kategorien zusammenfassen: Services (s.o. 27 Flexibilität der Services) sowie Ressourcenanforderungen. 5.2.1Ressourcenanforderung Ressourcenanforderungen stehen hinter den Services erst an zweiter Stelle. Für die meisten Anwendungen stößt man bei einer modernen x86-basierten Oracle Cloud-Architektur selten an Grenzen. Size-Restrictions sollten aber immer formuliert werden. Ab einer gewissen Leistungsanforderung sollte über ein Scale-out auf die Exadata-Plattform oder eine dedizierte Database-Machine nachgedacht werden. 5.3 Migrationsstrategie und –support Nachdem eine Datenbank als Kandidat für eine Migration in die Oracle Cloud auf Basis von technischen und geschäftlichen Kriterien identifiziert ist, müssen die Voraussetzungen für die Migration geschaffen werden. Im betrachteten Modell „Database as a Service“ ist es nicht notwendig, die Infrastruktur in der sich die Datenbank befindet, zu verwalten. Es kann also davon ausgegangen werden, dass die Infrastruktur bereit steht. Damit beschränkt sich die Migrationsstrategie auf die Rahmenbedingungen. Dabei sollte nicht außer Acht gelassen werden, dass die Datenbank mit einer Applikation verknüpft ist, die wiederum den Cloud-Dienst „Application as a Service“ verwendet oder auch nicht. Seite 28/33 update Dieser Ansatz erscheint sehr attraktiv, allerdings müssen wichtige Punkte für Migration und Betrieb beachtet werden. Dazu gehören: • • • • • Erwartungen an den Service Level Portabilität der Daten Kosten auf lange Sicht Verwaltung von Benutzern Sicherheit Erwartungen an den Service Level Der Anbieter muss ein SLA mit Aussagen zur allgemeinen Verfügbarkeit, Skalierbarkeit und Performance zur Verfügung stellen. Dazu gehören auch klare Aussagen über Wartungsfenster und die Durchführung von Upgrades. Skalierbarkeit kann durch Hinzunahme vom Hardware-Ressourcen, Parallelisierung oder Erweiterung eines Clusters realisiert werden. Der Provider muss adäquate Ressourcen in der Hinterhand haben, um kurzfristig auf solche Forderungen reagieren zu können. Portabilität der Daten Der Kunde muss in die Lage versetzt werden, über die Daten seiner Applikation zu herrschen. Dazu gehört auch die Möglichkeit, diese in gängige Formate zu exportieren und einfach an andere Applikationen weiterreichen zu können. Für die Initiale Migration müssen entsprechende Schnittstellen zum Laden von Daten zur Verfügung gestellt werden. Um dieses Prinzip umzusetzen, müssen dem Kunden die notwendigen Rechte an den Daten gewährt werden. Für große Datenbanken ist zu berücksichtigen, dass für Export- und Importaktivitäten der entsprechende freie Festplattenplatz zur Verfügung steht. Darüber hinaus muss der Kunde die Möglichkeit haben, Aufträge für das Cloning stellen zu können. Der Provider sollte Standard-Cloning-Verfahren, zum Beispiel mit dem RMAN, anbieten und vorsehen. Kosten Rechtemäßig sollte eine strikte Trennung zwischen Datenmanipulationen und Schema-Änderungen erfolgen. Während das Recht auf Datenmanipulation dauerhaft erteilt werden sollte, muss das Recht auf Schema-Änderung im Normalbetrieb entzogen und nur für das Einspielen neuer Releases erteilt werden. Auch in der Oracle Cloud müssen die Regeln des Change Request Verfahrens angewandt werden können. Das Modell „Database as a Service“ kann sowohl für mittelständische Unternehmen als auch für große Konzerne, die keine großen Investitionen in die eigene Infrastruktur getätigt haben, finanziell attraktiv sein. Insbesondere die Initialkosten sind sehr gering. Allerdings sollte mit wachsendem Datenvolumen und wachsender Anzahl von Benutzern auch die Langzeitkosten betrachtet werden (Cost of Ownership). Die Entwicklung der Langzeitkosten ist abhängig vom Kostenmodell des Service. Aus Sicht des Providers ist die Größe der Datenbank nicht zwangsläufig der Kostenfaktor Nummer eins. Andere Faktoren wie die Anzahl von neuen Releases oder auch die Userverwaltung können die Kosten in die Höhe treiben. Seite 29/33 update Verwaltung von Benutzern / Sicherheit Für Applikationen mit einer großen Anzahl von Benutzern werden normalerweise Directory-Dienste für die Zugriffskontrolle verwendet. Häufig schlagen sich Änderungen (Hinzunahme oder Entfernen von User-Accounts) nicht automatisch auf die „Database as a Service“ nieder. Dies kann ein zusätzliches Arbeits- und ein Sicherheits-Risiko für die IT-Administratoren bedeuten. Die Sicherheitsvorschriften in den meisten Unternehmen fordern eine regelmäßige Re-Zertifizierung von Benutzern. Diese müssen entsprechend umgesetzt werden. In den Datenbanken können sich sensible Daten befinden. Deshalb sollte der Service Provider seine Sicherheitspolicies offen legen und für den Benutzer transparent machen, damit dieser eigenständig verifizieren kann, ob die Datenbanksicherheit seinen Anforderungen entspricht. Definition und Umsetzung von Sicherheitsrichtlinien für die Datenbank können sich sehr aufwändig entwickeln. Sie umfassen viele Themenbereiche, über die Umsetzung von Passwort-Regeln über die individuelle Rechte-Vergabe, das Auditing von Zugriffen bis hin zur Intrusion Detection-Kontrolle. Einerseits muss der Provider kritische Privilegien sperren, andererseits muss er dem Kunden noch Spielraum für eigene Gestaltung lassen. Für die Migration sind Randbedingungen wie der Zeichensatz in der Datenbank oder ein verändertes Verhalten von Datenbank und SQL-Anweisungen im Falle einer Migration auf eine andere Version stets im Auge zu behalten. Im Fall von Oracle bietet sich der Einsatz des Tools „Real Application Testing“ an, mit dem der reale Workload vorab auf die neue Umgebung gebracht werden kann. Seite 30/33 5.4 update Modelle zur Kostenverrechnung Eine der zentralen Fragen beim Betrieb jeder Plattform ist die Verrechnung von Kosten. Wie werden Kosten verursachergerecht verrechnet, wie wird das Modell einfach und praktikabel gehalten und wie flexibel kann es sich verändernden Anforderungen angepasst werden? Grundsätzlich können mehrere Komponenten einzeln berechnet werden und pro Nutzungsdauer ausgewiesen werden. Mögliche Komponenten sind DBA- und SA-Kosten, Lizenzen sowie Hardware und Storage. Database Administration Standard 2nd and 3rd level support not including database provisioning, changes and project support like optimization System Administration Standard 2nd and 3rd level support not including OS provisioning and changes Licences Could be integrated into Cloud Units Hardware Cloud-Unit Cloud Unit: Server Hardware, CPU, Memory, Datacenter Costs Storage Storage used by databases, not including storage needed for system 5.4.1.1 Kosten Database Administration Die Kosten der Datenbankadministration lassen sich einfach pro Datenbank-Instanz und Monat ausweisen. Wichtige Fragen sind hier, ob zwischen unterschiedlichen Service-Leveln unterschieden werden soll und welche Leistungen in einem Basis-Support enthalten sein sollen. Ein Hinweis sei noch mit Blick auf das Schema-Konzept gegeben: Werden Schemata nicht stark standardisiert (User, Tablespaces), können sie schnell einen höheren Betriebsaufwand produzieren als Datenbank-Instanzen. 5.4.1.2 Kosten System Administration Auch die Kosten der Systemadministration lassen sich pro Database Machine ausweisen und, um es möglichst einfach zu halten, mit festem Schlüssel auf Datenbank-Instanzen verteilen. Auch hier stellt sich die Frage, ob unterschiedliche Service Level angeboten werden sollen und welche Leistungen im Basis-Support enthalten sein sollen. Seite 31/33 update 5.4.1.3Lizenzen Lizenzkosten können sich an Cloud-Units orientieren (s.u.). 5.4.1.4Hardware Ein sinnvolles Konzept ist es, Cloud-Units zu definieren. Ein Gesamtsystem kann so inklusive seiner Spareparts, des benötgten Storage für das Basissystem und seiner Wartungskosten auf Cloud-Units aufgeteilt werden. Hierbei empfiehlt sich eine feste Zuordnung von Speicher und CPU zu einer Unit. 5.4.1.5Storage Storage kann nach bekannten Modellen verrechnet werden. So lange beim Schema-Konzept die Richtlinie ein Tablespace pro Schema eingehalten wird, können Storage-Einheiten nach Nutzung monatlich verrechnet werden. 6 Betrieb einer Oracle Cloud Lifecycle-Management auf einer Shared-Plattform unterscheidet sich grundsätzlich von dedizierten Plattformen. In erster Linie sind hier Release-Stände und Patch-Level zu erwähnen. Aber auch in Bezug auf Event-Monitoring und die Vereinbarung von Schwellwerten ergeben sich deutliche Unterschiede. Eine der größten Herausforderungen stellt die Wartung dar. Wie viele Datenbanken können auf einem System gemeinsam mit einem gemeinsamen Wartungsfenster betrieben werden? Können unplanmäßige Wartungsfenster erzwungen werden und welchen organisatorischen Aufwand muss man hierbei betreiben? Wann und mit welchem Aufwand können neue Versionen und/oder Patches durchgesetzt werden, wie sehen Testprozeduren aus? Ähnliches gilt für das Change Management. Changes können eine Vielzahl von Anwendungen betreffen und müssen deshalb mit besonderer Sorgfalt vorbereitet und getestet werden. Das User Management wird immer dann zu einer besonderen Herausforderung, wenn Schemas genutzt werden. Wenn also auf Schemas nicht verzichtet werden soll, ist eine Reduktion der User pro Schema grundsätzlich zu empfehlen. Im Idealfall existieren pro Schema zwei User: Schema Owner und Access User. Die Rollenverteilung zwischen DBA und Systemadministrator (SA) bedarf auf der hier empfohlenen Architektur durch den Einsatz von ASM einer besonderen Betrachtung. Oracle bewirbt diese Architektur unter anderem mit den Vorteilen in der Administration. Die Aufgaben im Bereich der Unix Sytemadministration und im Storage-Management können in Teilen über den Enterprise Manager vom DBA übernommen werden. Dies ist sicher richtig, erfordert aber neue Konzepte bei der Rechtevergabe, da der DBA hier zumindest temporär über Zugriffsrechte verfügen muss, die so im Standard nicht vorgesehen sind. Auch beim Backup und Restore steht man immer dann vor besonderen Herausforderungen, wenn ein Schema-Konzept genutzt wird. Empfehlenswert ist hier, ein Schema immer auf genau einen Tablespace zu begrenzen, um hier bei Bedarf point-in-time Recovery des Tablespaces durchführen zu können. Betrachtet man das Gesamtrisiko bei Ausfall, so bleibt festzuhalten: Die Ausfallwahrscheinlichkeit lässt sich bei der vorgeschlagenen Architektur minimieren und der Aufwand hierzu ist auf Einzelanwendungen gerechnet sicher bedeutend geringer als dies bei Einzellösungen der Fall wäre. Kommt es dann doch einmal zu Ausfällen oder Fehlern, ist auf der anderen Seite auch immer eine Vielzahl von Systemen betroffen. Seite 32/33 7 Ausblick: Oracle Private Cloud / Oracle 12c 7.1 Oracle Private Cloud update Oracles Database Cloud Service als Private Cloud stehen kurz vor der Markteinführung. Auch wenn noch nicht alle Details feststehen, bewirbt der Hersteller die Services bereits. Womit ist zu rechnen? Oracle wird in seinen Database Cloud Service Tools zum Laden von Daten, zum Entwickeln und Ausführen von SQL sowie zum Anzeigen von Daten und Datenstrukturen integrieren. Zudem soll es einen Wizard zur Erstellung von RESTful Web Services geben, der SQL oder PL/SQL Code ausführen kann und Werte im JSON-Format, CSV-Format oder beliebigen anderen Formaten zurückliefert. Die gesamte Development und Deployment-Architektur des Oracle Database Cloud Service ist in die Oracle Datenbank integriert. Dadurch können Applikationen und sogenannte RESTful Web Services auf jede andere Oracle Datenbank verschoben werden, unabhängig wo diese betrieben wird. Oracle Application Express, ist eine weitere zentrale Komponente des Oracle Database Cloud Service. Nach Oracle handelt es sich um eine robuste Entwicklungsumgebung, die inzwischen von mehr als 100.000 Entwicklern weltweit genutzt wird, um geschäftskritische Anwendungen zu erstellen. Oracles Database Cloud Service ist auf Exadata implementiert und nutzt somit alle Features (u.a. EHCC, Smart Scanning, Cell Offloading, und viele mehr), die aktuell durch Exadata geboten werden. 7.2 Oracle 12c: Pluggable Database Das Konzept der Pluggable Database (PDB) ist aus anderen Umfeldern bereits bekannt. Es handelt sich hierbei um eine Datenbankinstanz, welche viele einzelne, unabhängige Datenbanken enthält. Die Realisierung in der Version 12c unterscheidet zwischen der „Container Database“ (CDB) und den „Pluggable Databases“ (PDB). Das Konzept der Pluggable Database bietet viele Vorteile. So ist die Datenbankkonsolidierung nun sehr einfach, weil eine vorhandene Datenbank in eine CDB eingeklinkt und sofort genutzt werden kann. Eine Konsolidierung verschiedener Applikationen durch Trennung in verschiedene Schemata ist nicht mehr notwendig. Weiterhin spart dieses Verfahren Zeit beim Datenbankupgrade, da ein Upgrade zwischen verschiedenen Datenbankversionen ab 12c im Hintergrund erfolgt – die Datenbank kann sofort genutzt werden. Über das Fast Provisioning kann eine vorhandene PDB in eine neue PDB geclont werden. Hierbei wurde der RMAN so erweitert, dass ein Recovery auf Ebene der PDB möglich ist. Zum Transport der PDBs können diese „unplugged“ werden. Die Datenfiles der PDB können dann kopiert und in eine neue CDB wieder eingefügt (Oracle spricht hier vom „plug-in“) werden. Dieses Verfahren funktioniert ab der Version 12c auch zwischen verschiedenen Datenbankversionen und soll das neue Standardverfahren für Datenbankupgrades werden. Zudem bietet PDB eine saubere Rollentrennung sowohl für Administration als auch für Applikation. Seite 33/33 8 update Links & Literatur • Lifecycle- & Security Management für Oracle Datenbanken avato Whitepaper beschreibt eine Filecycle-Strategie für Oracle Datenbanken (Release- und PatchManagement). • Oracle Whitepaper “Oracle Partitioning Policy“ Beschreibt welche technologischen Plattformen Soft- und Hard-Partioning ermögli­chen und welche Lizenzbestimmungen jeweils gelten. • Oracle Whitepaper „Database Consolidation onto Private Clouds“ Das Dokument beschreibt, wie Oracle Datenbanken (11g) in unterschiedlichen Mo­dellen erfolgreich konsolidiert werden können.
