Es gibt heute kaum ein Unternehmen, das noch nicht über Virtualisierung im Rechenzentrum nachgedacht hat. In vielen Firmen ist die Server-Virtualisierung, die anfangs wegen der hohen Kosten primär größeren Organisationen vorbehalten war, sogar fester Bestandteil der IT-Strategie geworden. Aufgrund des enormen Marktpotenzials ist mit der Konkurrenz inzwischen auch das Produktangebot deutlich gewachsen: Big Player in nahezu allen Hard- und Softwarebereichen werben mit eigenen Virtualisierungslösungen oder bieten ergänzende Produkte an.

Virtualisierung als neue Infrastruktur?

Werden nur ein oder zwei Systeme in der Infrastruktur betrieben, ist die Konsolidierung von Servern und deren Peripherie - einer der Hauptgründe für Virtualisierung - nicht besonders interessant. Werden hingegen Dutzende oder Hunderte Server betrieben, lassen sich je nach der Virtualisierungslösung durch realistische Konsolidierungsraten von eins zu fünf bis eins zu hundert enorme Einsparungen erzielen. Dadurch sinken die Betriebskosten (Energie, Platz, Klimatisierung) sowie Wartungs- und Administrationskosten der Hardware erheblich. Die hohen Konsolidierungsraten sind auf die geringe durchschnittliche Auslastung physikalischer Server zurückzuführen, die mit nur einem Betriebssystem und meist nur einer oder sehr wenigen Applikationen betrieben werden.

Die Virtualisierungsprodukte unterstützen dies durch die clevere Verwaltung bestehender Hardwareressourcen. Mit Hilfe so genannter Resource-Manager können sowohl virtuelle Maschinen (VM) gegenüber anderen VMs priorisiert als auch die physikalische Hardware nach vielen verschiedenen Kriterien partitioniert werden. Manche Produkte erlauben es sogar, VMs - abhängig von der Last des physikalischen Basissystems (Host) - im aktiven Zustand auf andere, weniger belastete Systeme zu verschieben. Durch intelligente Ressourcenverwaltung ist eine Symbiose zwischen Ressourcenkonsolidierung und gleichzeitiger Leistungsoptimierung der Anwendungen zu erreichen.

Aus Sicherheitsgründen ist die Virtualisierung allerdings nur dort sinnvoll, wo VMs gegeneinander und gegenüber dem Host-System isoliert sind, also ein ungewollter Datenzugriff verhindert wird und Fehler oder der Absturz eines Gasts nicht zum Ausfall anderer Gäste führen.

Die Vorzüge der Hardwareunabhängigkeit

Ein weiteres Plus ist die durch Einführung einer Virtualisierungsschicht zwischen physikalischer Hardware und den logischen Teilen (Gast-Betriebssystem und Applikation) erzielte Hardwareunabhängigkeit. Sie eröffnet neue Sicherungsmöglichkeiten und vereinfacht die Wiederherstellung der Gäste erheblich. Letztere ist räumlich nicht beschränkt, so dass virtuelle Systeme auch über das Internet verteilt (Virtual Machine Marketplace) werden können.

Die Nutzung von Templates beziehungsweise das schnelle Klonen oder Erstellen von VMs ist ein wichtiger Vorteil virtueller Umgebungen, führt ohne entsprechendes Regelwerk oder Lifecycle-Management allerdings schnell zum Wildwuchs.

Schnelle Rückkehr zum ursprünglichen Systemzustand

Durch Verwendung von "Snapshots" ist es zudem möglich, Systemstände innerhalb weniger Sekunden einzufrieren, um sie zu sichern oder wieder zu ihnen zurückzukehren. Wird etwa eine wichtige Aktualisierung der Gastanwendung vorgenommen, lässt sich anhand eines zuvor angelegten Snapshots das Gastsystem jederzeit auf den Ursprungszustand zurücksetzen.

Mit der Hardwareunabhängigkeit fließen bisher eher aus Highend-Umgebungen oder Cluster-Systemen bekannte Funktionen in die Basisfähigkeiten virtueller Systeme ein und ermöglichen es zum Beispiel, kostengünstig hochverfügbare Server einzurichten. Dank der vom Host-System unabhängigen, immer gleichen Hardware virtueller Systeme lassen sich bestehende physikalische leicht in virtuelle Server (P2V = physical-to-virtual) umwandeln. Daher fällt die Entscheidung häufig zugunsten von P2V gegen einen Neuinstallation.

Eine wesentliche, sowohl Organisation als auch Administration betreffende Eigenschaft von VMs ist ihre hohe lineare Skalierbarkeit, wodurch sie auf veränderte Anforderungen reagieren können. Konkret: Droht eine Komplettauslastung der Host-Systeme durch die VMs, lassen sich neue physikalische Server ohne Störung der bestehenden Systeme in die virtuelle Infrastruktur integrieren. Das gewährt Planungssicherheit bei den Server-Anforderungen.

Ein weiterer Trend, der das Überspringen der Server- auf die Client-Virtualisierung beschreibt, ist die "Virtual Desktop Infrastructure". Dieser als Konzept erstmals durch VMware geprägte Begriff bezeichnet den Betrieb von Desktop-Betriebssystemen wie Windows XP oder Vista in einer VM als Ersatz für den Desktop des Benutzers. Der Zugriff auf die VMs erfolgt über Software-Broker und Thin Clients.

Produkte zur Server-Virtualisierung

Im Gegensatz zu Emulatoren arbeiten Server-Virtualisierer direkt mit dem physikalischen Prozessor und dem Hauptspeicher der Host-Hardware. Lediglich Einsteckkarten (Grafikkarte, Netzadapter, Festplatten-Controller) und Peripherie (USB, serielle und parallele Schnittstellen) werden emuliert. Statt des physikalischen wird also ein nicht vorhandenes logisches Gerät für den Gast bereitgestellt. Dadurch lassen sich die physikalischen Ressourcen optimal ausnutzen, dennoch wird Hardwareunabhängigkeit durch die emulierten Geräte erreicht. Einen Nachteil hat die Virtualisierung derzeit noch: Da das Gastsystem über den physikalischen Prozessor Bescheid weiß und das Betriebssystem entsprechend arbeitet, ist eine aktive Migration zwischen Host-Systemen mit sehr unterschiedlichen Prozessoren - etwa AMD und Intel gemischt - nicht möglich.

Die verschiedenen Virtualisierungsansätze

Bei der Server-Virtualisierung lassen sich grob drei Ansätze unterscheiden: Komplett-, Para- und Betriebssystem-Virtualisierung. Zudem ist mit der Einführung von Prozessorvirtualisierungstechniken (AMD-V, Intel VT-x), die primär als Erweiterung durch Paravirtualisierungssoftware genutzt werden, eine Unterart der Komplettvirtualisierung entstanden.

1 Komplettvirtualisierung Technisch gesehen wird bei der Komplettvirtualisierung jedem Gastsystem, unabhängig von der realen Host-Hardware, eine angepasste standardisierte Hardware präsentiert. Letztere wird für jede aktive VM in einem eigenen unabhängigen Prozess durch die Virtualisierungsschicht bereitgestellt, also: 10 VMs = 10 x Hardwareprozess. Prozessor- und Hauptspeicherzugriffe werden direkt (jedoch nicht zwingend unverändert) an die physikalische Hardware durchgereicht, alle anderen Geräte "emuliert". Diese werden je nach Notwendigkeit durch die Virtualisierungsschicht angepasst.

In dieser Kategorie agieren Microsoft und VMware. Durch die Nutzung von Prozessorvirtualisierung gesellen sich Xen-basierende Produkte und Microsofts kommender Hyper-V hinzu.

Die Emulierung der Hardware (Massenspeicher, Netz und Grafik) kostet jedoch Systemleistung, die dem Gesamtsystem verloren geht ("Virtualisierungsschwund"). Der Leistungsverlust bewegt sich je nach Virtualisierungssoftware und Zugriffsart der Gastsysteme zwischen zwei und 25 Prozent.

Die VMs und damit im Gast installierte Betriebssysteme wissen nichts von der virtuellen Hardware, arbeiten also wie mit Physik und benötigen im einfachsten Fall keine Anpassungen.

Bei den Komplettvirtualisierern wird zwischen "Hosted"- und "Hypervisor"-Produkten unterschieden: Ein Hosted-Produkt (etwa VMware Server, Microsoft Virtual Server) benötigt ein auf der Hardware installiertes Betriebssystem, das heißt: Microsoft Virtual Server wird auf dem Windows 2003 Server installiert. Die Virtualisierungslösung nutzt den Hardwarezugriff des Host-Betriebssystems und greift selbst nicht direkt auf die Hardware zu.

Hypervisor-Produkte, die sich als Standard für die Virtualisierung im Rechenzentrum etabliert haben, wiederum setzen direkt auf der Hardware auf und benötigen keine vorherige Betriebssystem-Installation. Das setzt allerdings vom Hypervisor unterstützte Hardware voraus. Xen (Xen-basierende Produkte: Citrix Xen Server, Virtual Iron), VMware ESX und Microsoft Hyper-V sind Hypervisor-Produkte.

In Sachen Geschwindigkeit ist die Hosted-Virtualisierungslösung dem Hypervisor-Produkt unterlegen, punktet jedoch bei der Treiberunterstützung.

Bevor die x86/x64-Prozessoren von AMD und Intel Virtualisierung unterstützten, mussten bestimmte privilegierte Anfragen ("Ring0"-Anfragen) durch das Gast-Betriebssystem an die CPU von der Virtualisierungsschicht abgefangen und manipuliert werden, um Störungen des Gesamtsystems zu vermeiden. Der Hintergrund: x86-Systeme waren ursprünglich lediglich für den Betrieb eines aktiven Betriebssystems gedacht und erwarteten daher auch nur Ring0-Anfragen eines Betriebssystems. VMware umging dieses Problem als erster Anbieter durch das Abfangen und Umbiegen dieser Anfragen über die Virtualisierungsschicht und nutzt dieses Verfahren bis heute in dem Produkt VMware ESX Hypervisor. Xen verwendete zunächst Paravirtualisierung als Gegenmittel, ist damit aber auf anpassbare Betriebssystem-Quellen angewiesen.

Dank der neuen Funktionen in AMD- und Intel-Prozessoren sind die CPUs nun in der Lage, mit privilegierten Anfragen aus mehreren gleichzeitig aktiven Betriebssystemen umzugehen. VMware nutzt dieses Verfahren nur in bestimmten Fällen (64-Bit-Gastsysteme, manuelle Aktivierung), Xen und Microsofts Hyper-V jedoch funktionieren nur bei nutzbaren Virtualisierungsfunktionen der Prozessoren, wenn nicht paravirtualisiert wird. Auch Xen-basierende Produkte wie Citrix Xen Server und Virtual Iron nutzen ausschließlich die CPU-Funktionen zur Virtualisierung der Gastsysteme und lassen sich ohne diese nicht betreiben.

2 Paravirtualisierung Anders als bei der Komplett- wird bei der Paravirtualisierung der Kernel des Gastsystems so angepasst, dass er direkt mit der von der Virtualisierungsschicht bereitgestellten und nicht mit der physikalischen Hardware kommuniziert, sprich: die VM weiß von der virtuellen Hardware. Auf diese Weise muss die physikalische Hardware nicht für jede einzelne VM gesondert virtualisiert werden. Vielmehr greifen die Gast-Betriebssysteme direkt und optimiert auf eine angepasste Hardware zu.

Xen, der bekannteste Vertreter des Paravirtualisierungs-Modus, erlaubt es, die Hardware dynamisch in die für den Betrieb der Gastsysteme benötigten Ressourcen aufzuteilen. Das User-API des Gast-Betriebssystems wird nicht verändert, so dass nur dessen Kernel anzupassen ist, alle sonstigen Daten (etwa Betriebssystem, Programme) hingegen unverändert bleiben. Die Anpassung des Betriebssystem-Kernels erfordert Einblick in die Programmquellen, was etwa eine Windows-Portierung ohne die Hilfe von Microsoft unmöglich macht. Der Virtualisierungsschwund bei der Paravirtualisierung fällt deutlich geringer aus und beträgt zwischen 0,1 und fünf Prozent.

3 Betriebssystem-Virtualisierung Dieses Verfahren bedient sich der Partitionierung des vorhandenen Betriebssystems und nicht direkt der vorhandenen Hardware. Somit werden bei der Erstellung der Gäste nur die Individualdaten für die VM angelegt. Alle "gleichen" Betriebssystem-Daten (etwa Betriebssystem-Bibliotheken) des Host-Systems werden demnach von den Gästen mitgenutzt. Das gilt auch für die laufenden Prozesse. Abweichende Daten werden im Heimatverzeichnis der VM abgelegt. Dank dieser Technik besteht eine VM in der Grundausstattung nur aus sehr wenigen Dateien und verbraucht deutlich weniger Festplatten- und Hauptspeicher als ein normal installierter Server. Betriebssystem-Virtualisierung steht für sehr hohe Ausnutzung der Systemressourcen beziehungsweise geringen Virtualisierungsschwund (ein bis drei Prozent). Ferner ist aufgrund der geringen Leistungsansprüche der Gäste eine sehr hohe Anzahl VMs (größer Faktor zehn gegenüber der Komplettvirtualisierung) bei verhältnismäßig bescheidener Hardwareausstattung möglich. Größter Nachteil ist die Abhängigkeit des Gastsystems vom Host, was eine homogene Basis voraussetzt. Wichtigster Aspekt auch bei dieser Form der Virtualisierung: Alle Gäste müssen unabhängig voneinander agieren können. Bekanntester Vertreter ist Virtuozzo, entwickelt von dem Unternehmen SWsoft (demnächst "Parallels"). (kf)