Virtualisierte Umgebungen liegen im Trend, denn durch das Zusammenlegen mehrerer ehemals physischer Server auf eine einzige physische Maschine lassen sich erhebliche Betriebskosten einsparen. Außerdem sind Aufgaben wie Server-Provisionierung und Ressourcenzuteilung in virtuellen Umgebungen ungleich einfacher und zeitsparender zu bearbeiten.
Andererseits entsteht durch die Virtualisierung auch eine weitere Komplexitätsebene. Schon an der Frage nach dem Ressourcenverbrauch scheitern herkömmliche Ansätze. Die Angabe der CPU-Auslastung ist beispielsweise wenig aussagekräftig. Um sie zu beurteilen, werden Zusatzinformationen darüber benötigt, wie viele CPU-Ressourcen der virtuellen Maschine (VM) vom Hypervisor in einem speziellen Moment zugeteilt waren. Zudem ist eine hohe CPU-Belastung in einer VM erst in Verbindung mit Wartezuständen ("CPU Ready … %") ein Indiz für einen CPU-Engpass.
Von Überallokation zur Überlastung
Die Mehrfach-Belegung des Hauptspeichers ist in virtuellen Umgebungen durchaus gewollt, um vorhandene, aber die meiste Zeit ungenutzte Ressourcen besser auszulasten. Durch diese Überallokation kann es jedoch zu Engpässen kommen, wenn doch einmal mehrere VMs gleichzeitig den ihnen zugewiesenen Hauptspeicher beanspruchen. Sollte kein physikalischer Speicher mehr zur Verfügung stehen, wird zunächst die Ballooning-Technik, eine Art Light-Variante des Swappings, angewendet. Die VMs werden dabei aufgefordert, nicht mehr benötigten Speicher freizugeben. Genügt dies nicht, werden die VMs angewiesen, besonders speicherintensive Prozesse zu beenden, was den normalen Betrieb zum Beispiel von Datenbanken erheblich stören kann. Beim Monitoring virtueller Umgebungen sollte demnach das Ballooning als Hinweis auf einen Memory-Engpass gedeutet werden.
Die Entstehung eines Flaschenhalses
Eine besondere Herausforderung stellt der Speicher dar. Dies betrifft insbesondere virtualisierte Datenbanken oder auch Exchange-Server. Oft sind deren Input- und Output-Kapazitäten (I/O) beschränkt, da beispielsweise durch eine Konsolidierung ehemals physischer Altsysteme zu virtuellen Maschinen eine Reduktion der Festplattenzahlen und damit der I/O-Kapazitäten erfolgte. Außerdem führt deren Virtualisierung dazu, dass weniger Ressourcen mehr Leistung bringen müssen, etwa weil die Benutzerzahl auf diesem einen physischen System gestiegen ist.
Es ist nahezu unmöglich zu sagen, wie viel Prozent Overhead Virtualisierung im I/O-Bereich erzeugt. Ist die Last auf der virtuellen Umgebung niedrig oder nur mäßig hoch, sind kaum Unterschiede zu den herkömmlichen physischen Systemen erkennbar. Jedoch kann bei hoher Last sehr viel Overhead erzeugt werden, da das virtuelle System selbst an seine Leistungsgrenzen stößt. Hier muss also besonderes Augenmerk auf die I/O-Antwortzeiten sowohl aus Sicht der Physik als auch aus Sicht der VM gelegt werden.
Provisioning und Deprovisioning
Um die virtuelle Umgebung als Ganzes unter Kontrolle zu halten und Wildwuchs einzudämmen, hilft ein Lifecycle-Management. Temporär benötigte Maschinen werden nach Gebrauch wieder beseitigt. Bei VMs im dauerhaften Einsatz ist eine Chargeback-Lösung sinnvoll, um den Ressourcenverbrauch der VMs messen und gegebenenfalls in Rechnung stellen zu können. Die Abrechnung kann auf verschiedenen Wegen erfolgen: Die Berechnung auf Basis zuvor festgelegter Tier-Klassen bietet finanzielle Planungssicherheit, da zum Beispiel fixe Kostensätze pro verfügbare CPU angesetzt werden. Ein MRU-gestütztes (Measured Resource Utilization) Chargeback-Verfahren berücksichtigt nur die tatsächlich verbrauchten Ressourcen wie konsumierte CPU-Takte, Hauptspeicher, I/O-Volumen und effektiven Storage-Verbrauch.
Zudem ist es sinnvoll zu kontrollieren, wie viel von dem für die VMs allozierten Speicherplatz tatsächlich auch genutzt wird. Die Betrachtung lohnt sich, denn noch immer sind die Gesamtkosten für Storage auf Enterprise-Level beträchtlich.
Eine Antwort auf diese Herausforderung kann Thin Provisioning sein, um von vornherein nur den tatsächlich genutzten Speicherplatz zuzuteilen. Wie viel Speicher die VM beansprucht, lässt sich nur in ihr selbst feststellen. Meist ist es deutlich weniger als das sonst üblicherweise für die Zuteilung angesetzte Maß, das etwa der Größe der physischen Dateien der VM entspricht. Es gibt Produkte, die beide Aspekte auch in komplexen SAN/NAS-Umgebungen (Storage Area Network/Network Attached Storage) mit Tausenden von VMs zusammenbringen.
Korrelation der Daten
Beim Monitoring virtueller Systeme sollten demnach Daten aus der physischen und der virtuellen Sicht korreliert werden, damit man Aussagen über die Auslastung und mögliche Engpässe des Systems treffen kann. Nur dann lässt sich auch im Vorfeld sagen, wann und wo ein Ressourcenengpass entstehen wird, wann der Speicher auf physischer oder virtueller Ebene vollläuft und auf welche Anwendungen sich ein Engpass auswirken würde. Vorausschauend lässt sich dann ebenso einschätzen, ob bei physischem Clustering (zum Beispiel ESX-Cluster) genügend Ressourcen zur Verfügung stehen, um den Ausfall eines oder mehrerer Cluster-Knoten verkraften zu können, und ob die Ziele hinsichtlich der Ressourcenauslastung und damit der Kosteneinsparung erreicht werden. Erst eine umfassende Datenanalyse erlaubt es, zu beurteilen, ob und wo weitere Konsolidierungsmöglichkeiten bestehen. Solche proaktiven Alarme setzen neben einer regelmäßigen Messung der einschlägigen Auslastungs- und Performance-Daten auch ein intelligentes und vor allem automatisch vorgenommenes "Trending" voraus, um den zuständigen Administrator oder Operator rechtzeitig zu warnen.
Ein vornehmliches Ziel sollte es daher sein, die Virtualisierungsschicht nicht als neuen "Silo" in der Unternehmens-IT zu sehen, sondern Performance- und Verfügbarkeitsdaten der verschiedenen Subsysteme (Hypervisor, Betriebssystem, Anwendung, Storage etc.) zusammenzuführen und zu korrelieren. Ein solches gemeinsames Repository erlaubt das direkte Vergleichen von Performance-relevanten Daten aus Anwendungen, Datenbanken, den Betriebssystemen der beteiligten Server und der Virtualisierungsschicht.