Als Oracle im Herbst 2008 mit der ersten Database Machine auf den Markt kam, wurde diese vielfach als Appliance angepriesen. Das passte auch zur allgemeinen Vorstellung von einer Appliance:

• Kombination aus Hard- und Software,

• für spezifische Anwendungen optimiert,

• vorintegriert und konfiguriert für die jeweilige Problemstellung,

• keine kundenseitigen Anpassungen zugelassen,

• Aktualisierung der Software nur mit definierten automatischen Abläufen.

Gerade die beiden zuletzt genannten Punkte lösten jedoch große Skepsis bei den Kunden aus. Worauf Oracle in der Folge die Bezeichnung Appliance konsequent vermied und von "Engineered Systems", die "preconfigured & balanced" seien, sprach.

Erst die im Herbst 2011 auf den Markt gebrachte "Oracle Database Appliance" (ODA) schmückte sich wieder mit der restriktiveren Bezeichnung.

Flexibilität - Komplexität

Oracles Datenbanksoftware gibt es für eine große Anzahl unterschiedlicher Plattformen. Diese Flexibilität in der Wahl von Hardware und Betriebssystem ist ein Vorteil für die Akzeptanz im Markt. Die Anwender wollen sich schließlich nicht einschränken lassen.

Die Variabilität der Konfiguration birgt aber auch Gefahren. Systeme mit dem Ziel höchster Verfügbarkeit, maximaler Performance und zugleich flexibel in der Skalierung zu implementieren verlangt auf Anwenderseite Fachwissen und langjährige Erfahrung. Für den Anbieter ist es eine Herausforderung, für jede Rechnerkonfiguration, jedes Betriebssystem-Release, jede Storage-Anbindung, beliebige Netzwerktopologien und alle Typen von Applikationen eine passende Lösung zu finden.

Standards als Lösung

Das bedeutet, es gibt viele Möglichkeiten, eine Infrastruktur zu implementieren. Am problematischsten ist es, wenn man jedes Mal anders vorgeht. Somit macht sich jeder Betreiber von mehr als einer Datenbankplattform Gedanken über eine Standardisierung. Das beginnt bei der Wahl der strategischen Hardwareplattform und reicht über die Definition von Betriebssystem und Datenbanksoftware bis hin zu betrieblichen Aspekten wie der Überwachung, Backup-Läufen oder dem Installieren von Patches.

Der höchste Nutzen wird erreicht, wenn Standards mit automatisierten Setups umgesetzt werden. Wiederholte Installation und Konfiguration von Software-Stacks für gleiche Aufgaben, zum Beispiel als Datenbank-Server, lassen sich gut automatisieren. Dadurch erreicht man eine konstant hohe Qualität, ist schnell und personenunabhängig.

Appliance als Standard

Die Lieferanten sind sich der Vorteile von Standard-Setups bewusst. Je nach Möglichkeit tun sie sich zusammen, um ein konfiguriertes Paket aus Hard- und Software zu schnüren. Oracle hat das 2008 für die "Exadata Database Machine V1" gemeinsam mit Hewlett-Packard realisiert. So richtig interessant wurde es für Oracle aber erst mit der Akquisition von Sun Microsystems 2010. Seit der "Exadata Database Machine V2" auf der eigenen Hardware baut Oracle sein Portfolio rund um die Engineered Systems aus.

Für spezifische Aufgaben ausgelegt, mit einem komplexen Softwarestack gebaut und zum Teil mit Funktionen versehen, die nur in diesen Systemen verfügbar sind, sollen sich Mehrwerte und Alleinstellungsmerkmale ergeben. Der Nachbau wird verhindert, indem im Falle der Exadata DB Machine die intelligente Software der Storage-Zellen nicht einzeln verfügbar ist. Kunden haben allerdings die Möglichkeit, die Konfiguration im Betrieb zu ändern. Oracle ist diesbezüglich immer noch flexibel, weil auf den Datenbankknoten die exakt identische Software wie auf Nicht-Appliance-Systemen eingesetzt wird.

Die Bedingungen für die Anerkennung als validiertes Sys-tem sind hauptsächlich durch die eingesetzten Software-Releases und deren Patch-Levels für alle involvierten Komponenten definiert. Diese Angaben kann der Kunde in sogenannten MOS (My Oracle Support) Notes nachlesen und hat so trotz Appliance die Möglichkeit des kundenspezifischen Einsatzes. Die Vorteile eines solchen Lieferantenstandards sind:

• Einsparung bei der Evaluation einer Plattform,

• kurze Lieferzeiten für das Gesamtsystem,

• keine Installations- und Konfigurationsaufwände für das Grundsystem,

• kein Know-how für das Aufsetzen von komplexen Systemen notwendig,

• Kosteneinsparungen im Betrieb der Plattform durch eine Aufgabenkonzentration als Appliance-Administrator,

• besserer Support, da die Konfiguration der Systeme bekannt ist und von den Erfahrungen anderer profitiert werden kann, und

• einfaches und sicheres Patchen dank spezifischer Appliance-Patch-Bundles.

Database Appliance vs. Exadata DB Machine

Beide Systeme sind Datenbank-Server-Plattformen von Oracle, die die gesamten Enterprise-Edition-Funktionen mit Clustering und Storage-Redundanz beinhalten. Exadata zeichnet sich durch hohe Scale-out-Möglichkeiten (Wachstum über mehrere Datenbankknoten hinweg) aus und wird im Highend- Segment für höchste Performance-Ansprüche eingesetzt. Die aktuelle Version X3 ist erhältlich vom 1/8-Rack bis zum achtfachen Full-Rack. Integriert ist auch viel Kapazität an Flash-Cache-Speicher, was mit entsprechender Komprimierung praktisch einer In-Memory-Datenbank gleichkommt.

Die Konfigurationsvarianten werden im Vorfeld über einen Fragebogen aufgenommen und dann von Oracle bei Inbetriebnahme implementiert. Der Kunde ist dabei nicht involviert, erhält aber ein lauffähiges hochverfügbares Datenbank-Server-System mit integriertem redundantem Storage.

Die Oracle Database Appliance (ODA) liegt in einer Preiskategorie darunter und besitzt nicht dieselben Skalierungsmöglichkeiten sowie I/O-Performance-Kennzahlen wie Exadata. Oracle positioniert ODA für kleinere Unternehmen oder auch als dedizierten Abteilungs-Datenbank-Server. Die Konfiguration funktioniert einfach über ein GUI. Der grafische Appliance Manager ermöglicht es, mit wenigen Klicks die Verfügbarkeit von Datenbankservices und Storage zu definieren und implementieren. In vielen Unternehmen stellt die auf CPU-Cores basierende Softwarelizenz ein Kostenproblem dar. Die ODA kann durch das Abschalten von Cores passgenau mit der benötigten Rechenleistung betrieben werden. Nicht benutzte CPUs müssen auch nicht in Lizenz genommen werden.

Exadata und ODA lassen sich als sogenannte Building-Blocks in einer IT-Infrastruktur-Strategie als Datenbank-Server-Einheit einsetzen. Ob das eine oder andere Engineered System zur Anwendung kommt, hängt grundsätzlich von den Anforderungen im Bereich Skalierung und Performance ab. Die angebotenen Standards passen jedoch nicht immer zu den eigenen Standards. Durch ein paar wenige Konfigurationsvarianten lassen sich diese Fälle aber meistens gut abdecken.

Die Appliance löst nicht alle Aufgaben

Dass Oracle im Fall von ODA ein gutes System zu moderaten Kosten anbietet, ist sicher interessant. Kunden dürfen jedoch nicht davon ausgehen, dass damit alle Datenbank-Server-Aufgaben gelöst sind. Um die Integration der Appliances in die bestehende IT-Landschaft und die Migration der Daten auf die neue Plattform müssen sich die Anwender kümmern. Zu den weiteren Aufgaben gehören ein sicheres Backup, im Bedarfsfall ein Restore der Datenbank sowie das Monitoring der Umgebung mit den richtig gesetzten Metriken für Warnung und Alarmierung im Fehlerfall.

Die Plattformen zeichnen sich zwar durch Hardwareredundanzen aus, Desaster-Toleranz lässt sich damit aber nicht erreichen. Das Aufsetzen von zum Beispiel Data-Guard-Funktionalität und eventuell automatischem Failover im Fehlerfall werden durch das Initial-Setup, respektive durch die Appliance-Konfiguratoren, nicht abgedeckt. Hier sind noch Engineering-Leistungen nötig, die entsprechendes Wissen erfordern.

Fazit

Appliances sind von Lieferanten vorkonfigurierte Hard- und Software-Gesamtlösungen, die den Installationsaufwand und die Fehlerquote reduzieren. Im Oracle-Umfeld ist das kundenspezifische Konfigurieren immer noch möglich, was das Einsatzgebiet vergrößert. Neben den Kostenvorteilen beim Aufsetzen und im Betrieb lassen sich auch kürzere Bereitstellungszeiten für neue Systeme erreichen, die dank höherer Stabilität auch eine bessere Verfügbarkeit gewährleisten können. Bei ODA, bei den Exadata-Systemen sowieso, sind jedoch Ressourcen für die Integration und den Infrastrukturbetrieb über den gesamten Lebenszyklus der Plattform nötig. Problemfälle im Bereich Datenverlust oder Performance sowie die Überwachung bedingen gleichwohl ein großes Maß an Wissen und Erfahrung. (ba)