In nahezu allen großen und vielen mittelständischen Unternehmen ist Virtualisierung ein Thema. Insbesondere in schwierigen wirtschaftlichen Zeiten gewinnt sie aufgrund der damit zu erzielenden Kostenspareffekte zunehmend an Bedeutung. Der zunehmende Einsatz im produktiven Betrieb stellt neue Anforderungen an das Monitoring solcher Systeme: Zum einen müssen die Anwendungen im laufenden Betrieb bestimmten Performance-Ansprüchen genügen. Zum anderen beschränkt sich die virtuelle Umgebung nicht mehr nur auf Applikationen, sondern weitet sich auch auf Datenbanken aus. Nicht zuletzt die Ankündigung von Oracle, eine eigene Virtualisierungs-Umgebung (OracleVM) zur Verfügung zu stellen, schob das Thema Virtualisierung von Datenbanken in den Vordergrund.
Gute Gründe für Datenbank-Virtualisierung
Neben den bekannten Vorteilen der Server-Virtualisierung sprechen viele Gründe für die Virtualisierung von Datenbanken. Durch vordefinierte Templates verkürzt sich auch die Zeit, in der eine neue Datenbank eingerichtet werden kann, von Tagen auf Minuten. Dabei wird gewissermaßen das Gerüst der Datenbank mit allen wichtigen Parametern – jedoch ohne die Daten – kopiert. Dieses Template lässt sich bei Bedarf mit den aktuellen Daten füllen und kann, gegebenenfalls nach der Anpassung einzelner Parameter, sofort als neue Datenbank benutzt werden. Zeitaufwändige Schritte wie das Einspielen des Betriebssystems und der entsprechenden Patches, Installation und Konfiguration der Datenbank entfallen.
Bei allen Vorteilen der Virtualisierung ist es allerdings wichtig, eine Provisionierungs- beziehungsweise Deprovisionierungstechnik einzuführen. Besonders das einfache Klonen von Systemen birgt die Gefahr, das eigentliche Ziel, die Konsolidierung, aus den Augen zu verlieren. In der Praxis kommt es vor, dass im Unternehmen niemand mehr genau weiß, welche VMs genutzt werden und welche überflüssig sind.
Die heikle Frage nach dem Support
Wer eine produktive Datenbank in einer virtuellen Umgebung betrieben will, misst der Frage nach der Supportunterstützung durch den Hersteller eine hohe Wichtigkeit bei. Am Beispiel von Oracle stellt sich die Situation Stand heute wie folgt dar: Oracle hat seine Datenbank (ab 10.2.0) und andere Tools ausschließlich für den Betrieb auf der hauseigenen virtuellen Umgebungen OracleVM zertifiziert – aus Sicht des Datenbank-Anbieters durchaus verständlich. Wer jedoch etwas tiefer recherchiert, stößt bald auf die Information, dass für den Betrieb von Oracle Linux auch VMware und Xen als Hypervisor unterstützt werden. Ein weiteres Statement besagt, dass der Oracle-Support den Kunden bei Problemen im VMware-Umfeld durchaus unterstützt, der Kunde das Problem aber unter Umständen auf einer nicht virtualisierten Umgebung nachstellen muss.
In der Praxis scheint das die meisten Oracle-Anwender wenig zu stören. Auf Veranstaltungen wie der Deutschen Oracle Anwender Konferenz im Dezember 2008 war festzustellen, dass der Großteil der Anwendungen auf VMware ESX betrieben wird. Der folgende Abschnitt dieses Beitrags beleuchtet daher speziell das Thema des Monitoring von Oracle-Datenbanken auf VMware ESX.
Monitoring mit Tücken
Die Administration und der Betrieb der virtuellen Maschinen gestalten sich sehr einfach. Die Datenbank lässt sich wie gewohnt betreiben, Unterschiede im Handling gibt es nicht. Bei der Überwachung ist allerdings Vorsicht geboten. Ein Vorteil der Virtualisierung ist die dynamische Anpassung von CPU und Memory. Das bedeutet zwar, dass beim Hochfahren eines Servers diesem eine oder mehrere CPUs und ein bestimmter Memory-Anteil zugewiesen werden, diese Zuweisung erfolgt aber dynamisch. Also nur, wenn die Ressource benötigt wird und wenn höher priorisierte VMs diese Ressourcen gerade nicht beanspruchen, bekommt diese VM die Ressource. Es gibt die Möglichkeit, Ressourcen dediziert zu reservieren, nur geht dann ein großer Vorteil der Virtualisierung – die bessere Auslastung – verloren.
Bild 1: Aussagen über die CPU-Auslastung
sind bei einer virtuellen Datenbank mit Vorsicht zu genießen
Bei der Administration der Datenbank bedeutet dies aber, dass sich die CPU-Auslastung in der VM nicht mehr genau messen lässt. So ist unklar, was sich hinter der Angabe "CPU-Auslastung 90 Prozent" verbirgt. 90 Prozent wovon? Die Angabe könnte sich sowohl auf die physikalische CPU als auch auf den Anteil der CPU, welcher der VM in diesem Moment zugewiesen wurde, beziehen. Daraus können so genannte "Alarm Storms" entstehen: Hat beispielsweise der ESX-Server ein Problem, sind auch die möglicherweise definierten Schwellenwerte der Gastsysteme überschritten. Alle Systeme senden nun einen Alarm und lenken vom eigentlichen Problem des ESX-Servers ab.
Seite 1 von 2 Nächste Seite>>
