FAQ zu 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 unterschiedlichen Prozessoren – etwa AMD und Intel - nicht möglich.

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

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 werden „emuliert“. Diese werden je nach Notwendigkeit durch die Virtualisierungsschicht angepasst.

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 daher 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 XenServer, Virtual Iron), VMware ESX und Microsoft Hyper-V sind Hypervisor-Produkte.

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

Anders als bei der Komplett- wird bei der Paravirtualisierung der Kernel des Gastsystems so angepasst, dass dieser 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 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) können 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.

Dieses Verfahren bedient sich der Partitionierung des vorhandenen Betriebssystems und nicht der vorhandenen Hardware. Somit werden bei der Erstellung der Gäste nur die Individualdaten für die VM angelegt. Alle „gleichen“ Betriebssystemdaten (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 im Vergleich zur Komplettvirtualisierung) bei verhältnismäßig bescheidender 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 getrennt und unabhängig voneinander agieren können. Bekanntester Vertreter dieser Kategorie ist Parallels (vormals „Virtuozzo“), entwickelt vom gleichnamigen Unternehmen (vormals „SWsoft“).

Der erstmals durch VMware geprägte Begriff der „Virtual Desktop Infrastructure“ 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.

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.

Besteht die Infrastruktur nur aus ein oder zwei Systemen, dann ist die Konsolidierung von Servern und deren Peripherie nicht besonders interessant. Hat ein Unternehmen hingegen Dutzende oder Hunderte Server, lassen sich je nach Virtualisierungslösung realistische Konsolidierungsraten von 1:5 bis 1:100 erzielen. Dadurch sinken die Betriebskosten (Energie, Platz, Klimatisierung) sowie der Wartungs- und Administrationsaufwand für die Hardware erheblich. Die hohen Konsolidierungsraten sind auf die geringe durchschnittliche Auslastung physikalischer Server zurückzuführen, die mit nur einem Betriebssystem und meist sehr wenigen Applikationen betrieben werden.

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 lässt sich demnach eine Symbiose zwischen Ressourcenkonsolidierung und gleichzeitiger Leistungsoptimierung der Anwendungen erreichen.

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 Appliances) werden können.

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

Aus Sicherheitsgründen ist die Virtualisierung 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.

Durch Verwendung von „Snapshots“ ist es 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 einfach in virtuelle Server (P2V, physical-to-virtual) umwandeln. Daher fällt die Entscheidung häufig zugunsten von P2V gegen einen Neuinstallation.

Eine wesentliche, sowohl die 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 im Hinblick auf die Anforderungen an die Server-Systeme.

— Autor: Dennis Zimmer 30.01.2008, 18:33