Datenbank-Virtualisierung ist kein Allheilmittel
Die Virtualisierung von Datenbanken kann sich lohnen – aber nicht um jeden Preis. Zuvor ist für
jedes Unternehmen individuell zu untersuchen, ob sich die Erwartungen an eine solche Maßnahme in
der jeweiligen Umgebung überhaupt erfüllen lassen. Speziell Lastverhalten und Ressourcenbedarf der
Datenbank müssen im Vorfeld sorgfältig ermittelt werden. Diese Empfehlung gibt Essential Bytes aus
Hohberg, ein Unternehmen, das auf die Konzeption leistungsfähiger Datenbanklösungen spezialisiert
ist.
Zu den Vorteilen der Datenbank-Virtualisierung zählen üblicherweise die Schaffung von
Redundanzen und eine optimale Auslastung vorhandener Hardware. Daneben gelten die einfache
Verwaltung des Hardwaresystems und die Unabhängigkeit der virtuellen Maschinen gegenüber Änderungen
in der Infrastruktur als Pluspunkte eines solchen Konzepts. Zudem erwarten Unternehmen von einer
Virtualisierung auch Ersparnisse in Bezug auf Hardware-Ressourcen, Wartung und Strom. Dem gegenüber
steht jedoch bei ungenauer Planung das Risiko, dass Engpässe im Host-System auftreten können, weil
immer mehr Ressourcen benötigt werden.
Werden Oracle-Produkte bei der Software-Virtualisierung genutzt, sind zudem alle Prozessoren,
auf die der Virtualisierungs-Cluster zurückgreift, zu lizenzieren. Dies kann die Lizenzkosten
deutlich in die Höhe schrauben. Als weitere mögliche Schwachstelle einer Datenbank-Virtualisierung
sehen die Experten von Essential Bytes auch, dass manche Datenbankhersteller erst dann Support
leisten, wenn ein Problem zuvor mit einer nicht virtualisierten Hardware nachgestellt wurde.
"Virtualisierungen sind seit einigen Jahren sehr populär geworden und inzwischen stark
verbreitet. Jedoch löst ein Virtualisierungsprojekt keinesfalls automatisch alle Probleme der IT",
gibt Geschäftsführer Peter Geigle zu bedenken. "Das Lastverhalten und der Ressourcenbedarf müssen
im Vorfeld exakt gemessen werden, um Überraschungen im Livebetrieb zu vermeiden." Die
Projekterfahrungen von Essential Bytes zeigen, dass vor allem häufig falsch beurteilt wird, welches
Host-System den Anforderungen entspricht. Wichtig ist, dass das Host-System für den Bedarf
entsprechend groß dimensioniert ist. So müssen vor allem auch die Spitzen bestimmt werden, die das
System abfangen muss. Stellt ein Host-System zu geringe Kapazitäten bereit, wenn mehrere Server auf
ein Plattensystem zugreifen, dann entsteht an dieser Stelle ein neuer Engpass. Daher sollten auch
unter Volllast betriebene Server generell nicht virtualisiert werden – es sei denn, dies dient
Redundanzzwecken oder dem Ausfallschutz. Prüfen sollten Unternehmen hingegen auf jeden Fall, ob es
sich lohnt, eine Hochverfügbarkeit zu schaffen. In den meisten Fällen sind ohnehin bereits Features
wie VMware Vmotion lizenziert, wodurch Unternehmen möglicherweise gegenüber teuren
Datenbankoptionen sparen können.
Für die Datenbank-Virtualisierung empfiehlt Geigle ein Maßnahmenbündel auf mehreren Ebenen, um
ein Maximum an Flexibilität, Performance und Ausfallsicherheit zu erreichen. Zum einen wird das
Unternehmen durch den Betrieb der Datenbank in einer virtuellen Umgebung unabhängig von der
Hardware und kann Redundanzen auf Host-Ebene konsequent nutzen. Zum anderen wird bei der
zusätzlichen Storage-Virtualisierung Abstraktion des physikalischen Speichersystems geschaffen.
Dadurch lässt sich der Speicherbereich sehr flexibel verwalten. Weiterer Speicher kann
beispielsweise hinzugefügt werden, ohne dass die Datenbank hierzu umkonfiguriert werden muss.
Bei der Virtualisierung der Datenbank innerhalb eines Clusters werden mehrere Datenbank-Server
(Knoten) zusammengeschlossen, die auf dem gleichen Datenbestand arbeiten. Diese werden im Betrieb
möglichst gleich ausgelastet, sodass die Leistung aller Knoten für die Anwendung zur Verfügung
steht. Ein Knotenausfall wird durch die geschaffenen Redundanzen so kompensiert, dass er nahezu
keine Auswirkungen auf die Anwendung hat. Bei Oracle können Anwender hier auf das Konzept "Real
Application Cluster" zurückgreifen, bei der die Virtualisierung auf der Ebene der
Datenbank-Services realisiert ist. Zur Anwendung nach außen wird nur eine Verbindung dargestellt,
nach innen wird die Auslastung auf mehrere Knoten verteilt.
LANline/jos
