Virtualisierung von Datenbanken

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 die Essential Bytes GmbH & Co. KG, die 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 Hostsystem 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 Virtualisierungscluster 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 Peter Geigle, Geschäftsführer von Essential Bytes, 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 Hostsystem den Anforderungen entspricht. Wichtig ist, dass das Hostsystem 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 Hostsystem 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 lizensiert, wodurch Unternehmen möglicherweise gegenüber teuren Datenbankoptionen sparen können.

Für die Datenbank-Virtualisierung empfiehlt Peter 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 Hostebene 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 Datenbankserver (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 es 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 Datenbankservices realisiert ist. Zur Anwendung nach außen wird nur eine Verbindung dargestellt, nach innen wird die Auslastung auf mehrere Knoten verteilt.