Database as a Service

Seite 1 von 4
Database as a Service
Eine Oracle Private Cloud-Datenbankstrategie
Manch einem mag es vorkommen
wie die Quadratur des Kreises: Die
Anforderungen an eine Cloud für
Oracle Datenbanken unter einen
Hut zu bringen, eine zeitgemäße Lösung zu entwickeln und ein
„Alt-System“ mit überschaubarem
Aufwand auf eine Cloud zu migrieren. Dabei ist es heute keine
Frage mehr, ob für Datenbankkonsolidierung Cloud Computing die
sinnvollste Plattformstrategie ist.
Unbestritten sind mittlerweile die
Kostenvorteile und die Flexibilität
des Cloud Computing.
Es ist eher in der Diskussion, ob
Public Clouds oder Private Clouds
genutzt werden, ob universelle
Cloud-Infrastrukturen oder spezialisierte Clouds für Datenbanken
die richtige Antwort auf aktuelle
und zukünftige Herausforderungen darstellen. Die Frage nach
Public oder Private 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 eine
Private Infrastructure Cloud (Infrastructure as a Service) oder
eine spezialisierte Database Cloud
(Platform as a Service) besser geeignet ist. Diese Frage wird hier
für Oracle Datenbanken unter
folgenden Gesichtspunkten intensiver betrachtet: Was sind die
Anforderungen an eine Oracle
Cloud? Was sind die Erfolgsfaktoren bei einer Implementierung?
Kriterien & Anforderungen für die Oracle Cloud der Zukunft
Vor der Beurteilung der Vor- und
Nachteile einzelner Konzepte,
werden typische Anforderungen
an einen Database Service gesammelt und hieraus eine Plattformstrategie abgeleitet.
Was benötigt der Kunde? Er benötigt einen Datenbankservice
zu geringen Kosten mit flexiblen
Services und meist auch hoher
Verfügbarkeit. Der Service soll den
Compliance- und Security-Richtli-
nien des Unternehmens entsprechen und das Provisioning sollte
möglichst zügig und unkompliziert
erfolgen können (Self-Service-Portal).
Kriterien & Anforderungen für die Oracle-Cloud der Zukunft
Kosten
Investition & ROI
Investitionssicherheit
Services
Skalierbarkeit / Performance
Flexibilität / Individualität der Services
& Agilität der Serviceanpassung
Betriebskosten & Kostenverrechnung Quality of Service
Compliance & Security
Operations
Manageability
Flexibilität bei der Serviceerbringung
Reduktion von Komplexität
Release- & Patch-Management
Seite 2 von 4
Kosten
Investitionssicherheit
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 dabei auch ganz wesentlich
Lizenzkosten. Es ergeben sich in
den meisten Fällen klare Vorteile,
wenn man sich für auf eine dedizierte Datenbank-Cloud entscheidet und hier auch vornehmlich
Oracle Software (Oracle Enterprise Linux, Oracle Virtual Machine)
zum Einsatz kommt.
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 des ersten Budgetjahres
erreicht werden kann. Deshalb
sollten bei der Auswahl Standardkomponenten, die sich bereits im
Betrieb bewährt haben, berücksichtigt werden. Vor allem x86Hardware und Storage sind zu betrachten und möglichst viel sollte
„out of the box“ genutzt werden.
Vieles von dem, was Oracle heute
bietet, kann ohne umfangreiche
Anpassungen und eigenes Engineering eingesetzt werden.
Um Investitionskosten zu minimieren, kann die Strategie auch
auf dem Aufbau einer möglichst
einfach skalierbaren Cloud basieren. Move von Anwendungen auf
die Cloud-Plattform können bis
zum nächsten Tech-Refresh oder
bis zur nächsten Release-Migration aufgeschoben werden.
Um eine langfristige Investitionssicherheit zu gewährleisten, sollten
keine umfangreichen individuellen Standards für einen PaaS entwickelt werden. Entweder werden
Standardkomponenten 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. Diese Vorgehensweise bietet langfristig auch Kostenvorteile. Um eine
zukunftsträchtige Plattformstrategie entwickeln zu können, sollte
man ein möglichst genaues Bild
späterer Kundenanforderungen
haben. Zudem ist es sehr wichtig,
dass die Architektur der Plattform
eine größtmögliche Flexibilität bei
der Erweiter- und Handhabbarkeit
bietet. Hierzu gehört auch die Integration neuer Hardwarekomponenten, Software-Releases, Services sowie Service-Provider.
Skalierbarkeit / Performance
Die Skalierbarkeit eines Services
basiert ganz wesentlich 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 Cloud auf
eine dedizierte Plattform wie bei-
spielsweise Exadata migriert werden können.
Durch Plattformen wie Amazon
haben sich auch die Anforderungen an PaaS verändert. Rapid Deployment oder ein On-Demand
Provisioning über ein Self-ServicePortal sind heute gefragt. Soll
die Plattform auch Kurzzeitnutzung beispielsweise für Test- und
Demosysteme bieten und wie
flexibel kann die Ressourcenanpassung (CPU, Speicher, Storage)
durchgeführt werden?
Anforderungen an das ReleaseManagement und Maintenance
sowie spezielle Features spielen
in der Diskussion eine große Rolle.
Seite 3 von 4
Entwicklung einer zeitgemäßen Plattformstrategie
Private oder Public Cloud: Für Datenbanken gelten im Grunde fast immer sehr hohe
Compliance- und Security-Anforderungen,
durch die sich in aller Regel eine Public Cloud
verbietet. Eine Hybrid-Strategie, bei der neben Private Cloud für Kurzzeitanforderungen
auch Public Cloud-Dienste genutzt werden,
ist im Allgemeinen weniger zu empfehlen.
Wenn Public Cloud-Dienste genutzt werden
sollen, 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 zu können und wesentliche Anforderungen
an einen Datenbankservice erfüllen zu können, wird in aller Regel eine Standard Infrastructure Cloud nicht
ausreichen. Eine Cloud-Strategie für Oracle wird sich mit steigenden Anforderungen an den Service auf Basis
einer Platform as a Service-Architektur wesentlich einfacher, flexibler und kostengünstiger realisieren lassen.
Diese Plattformen entsprechen vielfach den aktuellen
Technologiestandards zahlreicher Unternehmen. So werden beispielsweise oftmals Oracle Enterprise Linux sowie
Oracle VM eingesetzt und im Bereich Exadata wird kein
Standard-Storage verwendet.
Database as a Service ermöglicht für alle Anwendungen
eine einheitliche Applikationsschnittstelle. Um die Skalierbarkeit zu erhöhen, wird eine sinnvolle Plattformstrategie idealerweise um Exadata ergänzt.
Eine zeitgemäße Plattformstrategie setzt am besten 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
wenigen GB bis 4 TB Arbeitsspeicher) geliefert werden
können.
Die verschiedenen Komponenten sind in der folgenden Tabelle dargestellt:
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
Management (ASM)
Oracle Automatic Storage Manager (ASM 11.2)
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 GB
Ethernet) für den Interconnect
X86 Hardware
Beliebiger Hersteller
Storage
Beliebiger Hersteller; FC-SAN empfohlen, iSCSI nur bei geringerem I/O
Seite 4 von 4
Erfolgsfaktoren bei der Umsetzung
Neben dem Management-Buy-in sind entscheidende Erfolgsfaktoren für die Etablierung einer standardisierten Plattform:
1.
Flexibilität der Services
Services müssen sehr flexibel angeboten werden können. Nicht zu unterschätzen ist die Frage nach
der Anzahl der implementierten Oracle Release. Können zwei Releases parallel angeboten werden,
kann dies die Akzeptanz der Plattform deutlich erhöhen. Zudem sollte eine Plattform neben der
Datenbankinstanz auch immer auch immer eine Datenbankmaschine bieten.
2.
Database Provisioning & Onboarding
Es müssen klare Kriterien für das Onboarding und den Verbleib auf einer Shared-Plattform definiert
sein. Der Prozess muss schnell durchlaufen werden. Ideal sind einfache Self-Service-Portale.
3.
Migrationsstrategie und -support
Sandbox-Systeme und umfangreicher Projektsupport sind partiell erforderlich, das Verhalten der
Datenbank muss vor allem bei Systemen mit hoher I/O getestet werden. Eine Unterstützung für die
Migration auf eine 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.
Zudem dürfen die Modelle nicht zu komplex werden. Bewährt haben sich Modelle, bei denen
DBA-Kosten, SA-Kosten, Storage und Cloud-Units (Hardware, RZ, Lizenzen) separat ausgewiesen
werden.
Impressum
Datum: Dezember 2012
Autor:
Ronny Egner
Lutz Fröhlich
Kontakt:
[email protected]
www.avato-consulting.com
Haben Sie weitere Fragen? Wir beraten Sie gerne:
[email protected]
© 2012 avato consulting