MOBILE RISIKEN

28 Produkte & Praxis 20/13
Appliance-Einsatz
richtig planen
Anbieter wie Oracle setzen immer stärker auf Appliances. Zwar versprechen die
vorkonfigurierten Systeme, die Komplexität zu reduzieren, doch dürfen Anwender
nicht übersehen, dass einzelne Aufgaben auch weiter zu erledigen sind.
Von Konrad Häfeli*
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.
Mit den Datenbankmaschinen
der Exadata-Serie forciert Oracle
seine Appliance-Strategie.
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 Appli kationen
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 Hardund
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 „Exa data 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 System
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 kun-
Foto: Oracle