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.
Die Technik
Als Virtualisierungs-Software 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 4-Prozessor-Systeme. Mit vier Intel-Xeon-Prozessoren, 16 Gigabyte Arbeitsspeicher und SAN-Anbindung haben die Rechner ausreichend Reserven, um mehrere VMs zu hosten. Zwei Emulex-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 Virtual Center 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.
Auf einen Blick
Virtualisierungs-Hardware
Standard-x86-Server als Vier-Prozessorsystem mit 16 GB RAM und SAN-Anbindung;
zwei Emulex-Hostbus-Adapter (Verbindung zum SAN)
pro Rechner vier Gigabit-Netzwerkkarten;
kleinerer Server für die Management-Konsole.
VM-Standardkonfiguration
Virtueller Doppelprozessor;
512 MB virtueller RAM;
16 GB virtueller Speicherplatz;
Windows Server 2003.
Kein Backup von virtuellen Maschinen in der Testumgebung
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.