Die Leistungsfähigkeit aktueller Server-Generationen hat in den letzten Jahren zu einem wahren Virtualisierungs-Boom geführt. Statt einer einzigen Installation kann jeder Rechner mehrere virtuelle Maschinen (VMs) hosten. Diese Konsolidierung spart nicht nur Hardwarekosten und Stauraum im Rack, mindestens ebenso wichtig ist das verbesserte Management. Virtuelle Maschinen lassen sich wesentlich komfortabler und zeitsparender administrieren als ihre physikalischen Pendants. Aus diesem Grund werden Entwicklungs- und Testumgebung heute als virtuelle Maschinen aufgesetzt. Entwickler brauchen häufig den parallelen Zugriff auf Installationen mit verschiedenen Versionsständen, und nur durch die Virtualisierung kann der Hardwarebedarf im wirtschaftlich sinnvollen Rahmen gehalten werden.

Um den Umstieg von physikalischen zu virtuellen Maschinen zu beschleunigen, empfiehlt es sich, auf zwei Dinge zu achten:

Zum einen sollte die Virtualisierung einer großen Testumgebung in einer zentral verwalteten Server-Farm stattfinden, um das Entstehen wartungsintensiver Insellösungen zu vermeiden.

Zum anderen sollte man vorhandene Prozesse nach Möglichkeit weiter nutzen und neue Prozesse so entwickeln, dass sie aus der Virtualisierung den maximalen Nutzen ziehen.

Bestandteile dervirtuellen Infrastruktur

Als Virtualisierungssoftware in Rechenzentren hat sich der ESX Server 3.0 von VMware etabliert. Derzeit gibt es keine andere Software in diesem Bereich, die ähnlich ausgereift ist. Die Hardware besteht aus Standard-x86-Servern, die allerdings über mehrere CPUs und viel RAM verfügen sollten, beispielsweise Vier-Prozessor-Systeme. Mit vier Intel-Xeon-Prozessoren oder vergleichbaren AMD-CPUs, 16 Gigabyte Arbeitsspeicher und SAN-Anbindung haben die Rechner ausreichend Reserven, um mehrere VMs zu hosten. Zwei Hostbus-Adapter stellen die Verbindung zum SAN her, außerdem braucht jeder Rechner vier Gigabit-Netzwerkkarten. Eine Netzwerkkarte ist für die VMware-ESX-Verwaltungskonsole reserviert, eine weitere wird vom VMotion-Feature belegt. Die virtuellen Maschinen teilen sich die Bandbreite der verbleibenden beiden Schnittstellen. Für das Management der virtuellen Maschinen mit VMware Virtualcenter 2.0 reicht ein kleiner Server.

Es ist sinnvoll, die VMs in Gruppen zu je 20 Maschinen aufzuteilen, damit man auch bei großen Installationen die Übersicht behält. Weil Virtualcenter nicht Clusterfähig ist, erreicht man die Redundanz über einen Umweg. Und zwar wird die Datenbank des Virtualcenter auf einem geclusterten und damit ausfallsicheren SQL Server abgelegt. Sollte der Virtualcenter-Server ausfallen, steht eine entsprechende VM als Ersatz bereit, die dann händisch mit der Datenbank verbunden wird. Das kann Ausfallzeiten des Virtualcenter bei einem Defekt zwar nicht völlig vermeiden, aber auf ein Minimum reduzieren.

Hochverfügbares SAN schützt bei Plattendefekten

Für die in der Testumgebung laufenden VMs braucht man - anders als bei physikalischen Systemen - weder Backup noch Disaster Recovery, da bei einem Server-Ausfall kein Produktionsstillstand zu befürchten ist. Als Speicher für die VMs dient das hochverfügbare SAN, damit sind sie gegen einfache Festplattendefekte ausreichend geschützt. Die wichtigen Daten von Fileserver und Code-Repository sollten im Gegensatz zu den VMs regelmäßig gesichert werden. Wenn es zu einem Server-Ausfall kommt, lassen sich alle betroffenen VMs in kurzer Zeit wiederherstellen.

Auf allen Windows-Server-Installationen ist ein - beispielsweise mit der Altiris Deployment Solution - geskripteter Installationsprozess möglich. Hierüber werden zusätzlich zum Betriebssystem aktuelle Security-Patches, Antivirensoftware und System-Management-Agenten eingespielt. Altiris kommt zum Einsatz, um die Master-VMs zu installieren, die dann als Vorlagen dienen. Individuell angepasst werden sie entweder mit dem Virtualcenter-Wizard von VMware für einzelne Kopien oder mit einem VMclone-Skript, wenn mehrere VMs gleichzeitig erstellt werden sollen. Wenn sie nicht gerade geklont werden, sollten die Master-VMs eingeschaltet bleiben, damit sie schnell Windows-Patches einspielen und immer aktuell bleiben. Außerdem ist alle drei Monate ein Rebuild der Master-VM mit Altiris sinnvoll. Mit Altiris lassen sich auch ESX-Installationen auf neuer Server-Hardware ausrollen.

Zeit sparen mit Standardkonfigurationen

Eine Standardkonfiguration für alle neuen VMs vereinfacht den Administratoren die Arbeit, nur in begründeten Ausnahmen sollte von ihr abgewichen werden. Diese Konfiguration hat sich in der Praxis für die gängigen Anforderungen bewährt: ein virtueller Doppelprozessor, 512 Megabyte virtueller RAM, 16 Gigabyte virtueller Speicherplatz sowie der Windows Server 2003 mit den aktuellsten Patches als Betriebssystem. Der Standard vereinfacht sowohl das Klonen als auch das Wiederherstellen von VMs. Da alle VMs die gleiche Konfiguration haben, können die Administratoren neue VMs mit einem Minimum an Aufwand erstellen.

Flexible Lastverteilung mit VMotion und DSR

Das Verschieben virtueller Maschinen im laufenden Betrieb ist unter ESX Server dank VMotion möglich. Das Feature wird häufig genutzt, um die Lasten zwischen den physikalischen Servern sinnvoll zu verteilen. Mit Virtualcenter werden stark ausgelastete physikalische Server identifiziert und VMs von dort auf Server verschoben, die noch Ressourcen freihaben. In der Regel laufen auf einem Server vier VMs pro Prozessor, ein Rechner mit vier Prozessoren kann also im Schnitt 16 VMs hosten.

ESX Server 3.0 unterstützt darüber hinaus Distributed Resource Scheduling (DSR). Das Feature ist eine große Hilfe, wenn die Lasten über viele physikalische Server verteilt werden müssen. Es handelt sich im Prinzip um ein richtlinienbasiertes VMotion. Der Administrator kann selbst festlegen, welchen Grad an Automatisierung er wünscht. Die Bandbreite reicht von einer reinen Benachrichtungsfunktion bis zum vollautomatischen Verschieben. Bei entsprechender Konfiguration kann das Tool die virtuellen Maschinen komplett ohne manuellen Eingriff zwischen den Servern umsetzen.

Eine weitere sinnvolle Funktion des ESX Server 3.0 ist VMware High Availability (HA). Diese Funktion erkennt physikalische Server-Fehler und verlagert die VMs dann auf einen anderen Server, um Ausfälle zu vermeiden.

Legacy-Systeme in VMs umwandeln

Viele alte Server-Installationen eignen sich prinzipiell für die Virtualisierung. Problematisch ist allerdings, dass die dort installierten Anwendungen häufig auf alte Hardware angewiesen sind, daher kommt eine klassische Migration auf standardisierte virtuelle Maschinen nicht in Betracht. Stattdessen nutzen Administratoren Server-Tools von VMware und Platespin für die Umwandlung der alten physikalischen Systeme in virtuelle Maschinen, die so genannte Physical-to-virtual-Konvertierung. Die Tools ähneln in vielen Punkten herkömmlichen Imaging-Programmen. Meistens wird der physikalische Server remote über die Netzwerkkarte via PXE (Preboot Execution Environment) gestartet, damit spart sich der Administrator den Gang zum Server, um dort ein Boot-Medium einzulegen. PXE lädt dann entweder ein Windows PE oder einen Linux-Kernel herunter. Diese Mini-Betriebssysteme erstellen anschließend ein Festplatten-Image. Im nächsten Schritt wird das Image um Treiber ergänzt, damit es unter ESX Server lauffähig ist. Das Image wird dann zum ESX Server kopiert, der die virtuelle Maschine startet. Durch Skripte kann dieser Prozess bei vielen Systemen parallel erfolgen.

Andere Varianten dieser Technik erlauben es, bei Bedarf aus VMs wieder physikalische Maschinen zu erstellen, oder auch die Konvertierung virtueller Maschinen in einen anderen Standard.

Leider nicht virtualisierbar: die Bürokratie

Alles in allem steigt die Geschwindigkeit, mit der Testmaschinen bereitgestellt werden, durch die Virtualisierung deutlich. Gleichzeitig lässt sich der Bestand an physikalischen Servern stark reduzieren, ohne dass es hierdurch zu Leistungseinbußen kommt. Was sich allerdings durch die Virtualisierung nicht ändert, ist der bürokratische Aufwand, um ein Testsystem genehmigen zu lassen. Auch virtuelle Maschinen verbrauchen Systemressourcen, und ihre Software muss korrekt lizenziert sein, was das Budget der jeweiligen Abteilung belastet. Also muss ein virtuelles Testsystem den gleichen Genehmigungsprozess durchlaufen wie ein physikalischer Server. Die meisten Firmen ordnen virtuellen Maschinen inzwischen genauso Kostenstellen zu, wie das bei Test-Servern der Fall ist. Anders als früher werden Testsysteme heute aber praktisch nur noch als VM genehmigt. Bei praktisch gleicher Leistung sind sie wesentlich preiswerter als ihre physikalischen Pendants und zudem wesentlich angenehmer zu administrieren. (ue)