IT-Abteilungen kommen heute kaum noch an Techniken zur Virtualisierung vorbei. Die theoretischen Vorteile und die damit verbundenen Auswirkungen für eine effizientere und flexiblere IT-Infrastruktur sind überzeugend. Mit den Möglichkeiten der Virtualisierung wächst allerdings auch die Begriffsvielfalt rund um die diversen Virtualisierungsvarianten und Software-Tools. Zu Beginn der Entwicklung wurden hauptsächlich Server im Data Center virtualisiert . Längst hat die Virtualisierung aber auch in Netzwerke , Storage – und Desktop-Systeme Einzug gehalten.
Wir klären, was hinter den Schlagworten steckt und beleuchten die Vor- und Nachteile der vielen unterschiedlichen Virtualisierungsformen.
Wann lohnt sich Server-Virtualisierung?
Virtualisierung trennt Software (Anwendungen etc.) von der darunter liegenden Hardware (Server, Speicher) durch eine logische Schicht. Besteht die IT-Infrastruktur nur aus ein oder zwei Systemen, dann ist die Virtualisierung und Konsolidierung von Servern und deren Peripherie nicht besonders interessant. Betreibt 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. Darüber hinaus wird der Lifecycle von Applikationen von der Hardware entkoppelt und erhöht somit die Laufzeit von Systemen. 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.
Wie kann Virtualisierungssoftware die Hardware optimal nutzen?
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.
Welche zusätzlichen Vorteile bietet die Server-Virtualisierung?
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 Backup-Möglichkeiten und vereinfacht die Wiederherstellung (Recovery) der Gast-Betriebssysteme 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. Wichtig ist dabei aber ein Regelwerk beziehungsweise ein Lifecycle-Management für VMs, damit ein Wildwuchs verhindert wird und Unternehmen jederzeit Herr ihrer Infrastruktur sind.
Im Gegensatz zu klassischen Emulatoren arbeiten Systeme zur Server-Virtualisierung (Server-Virtualisierer) direkt mit dem physikalischen Prozessor und dem Hauptspeicher der Host-Hardware. Lediglich Einsteckkarten (Grafikkarte, Netzadapter, Festplatten-Controller) und Peripherie werden emuliert. Dabei gibt es bei einigen Herstellern auch die Möglichkeit, Hardwarekomponenten direkt mit der virtuellen Maschine zu verbinden. Dabei verlieren Nutzer aber die Beweglichkeit der VM. Das bedeutet, dass sie nicht mehr in der Lage sind, eine VM im laufenden Betrieb auf einen anderen Host zu verschieben. Es kann dem Gastsystem aber auch, statt des physikalischen Geräts, ein nicht vorhandenes logisches Gerät bereitgestellt werden. So lassen sich die physikalischen Ressourcen optimal ausnutzen. Durch die Nutzung von logischen Geräten wird eine Hardwareunabhängigkeit erreicht.
Ein Nachteil hat sich bei der Virtualisierung bis heute gehalten: Da das Gastsystem über den physikalischen Prozessor Bescheid weiß und das Betriebssystem entsprechend arbeitet, ist eine aktive Migration zwischen Host-Systemen mit Prozessoren unterschiedlicher Herstellern – etwa AMD und Intel – nicht möglich.
Welche Formen der Server-Virtualisierung gibt es?
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 Paravirtualisierungs-Software genutzt werden, ist eine Unterart der Komplett-Virtualisierung entstanden.
Technisch gesehen wird bei der Komplett-Virtualisierung jedem Gastsystem, unabhängig von der realen Host-Hardware, eine angepasste standardisierte virtuelle 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, andere 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 Hersteller von Virtualisierungssoftware arbeiten aber daran, die Treiber für die virtuellen Komponenten weiter zu optimieren, um den Virtualisierungschwund weiter zu reduzieren.
Die VMs und damit die im Gast installierten Betriebssysteme wissen nichts von der virtuellen Hardware, arbeiten also wie mit richtiger Hardware und benötigen daher im einfachsten Fall nur die vom Hersteller mitgelieferten Treiber.
Bei den Komplett-Virtualisierern 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 beispielsweise auf dem Windows Server 2003 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 Data Center etabliert haben, wiederum setzen dagegen 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 Server und Microsoft Hyper-V sind Hypervisor-Produkte.
Hinsichtlich der Geschwindigkeit ist die Hosted-Virtualisierungslösung dem Hypervisor-Produkt unterlegen, punktet jedoch bei der Treiberunterstützung.
Stärken und Schwächen Hypervisor-Virtualisierung
Plus
- keine Anpassung der Gast-Betriebssysteme notwendig;
- vom Host und anderen Gästen unabhängige Gastsysteme (Betriebssystem-Typ, -Version);
- vielseitige Gast-Hardware möglich;
- flexible Anpassung der Gast-Hardware (teilweise auch während der Laufzeit).
Minus
- Hardware muss durch die Virtualisierungssoftware unterstützt werden;
- manche Hardware lässt sich im Gastsystem nicht abbilden (etwa Faxkarten);
- virtuelle Hardware wird für jede VM als Prozess abgebildet (“Schwund” / Leistungseinbußen);
- Prozessorvirtualisierung erforderlich (mit Ausnahme von VMware ESX);
- Installation von Tools im Gast notwendig, um optimale Leistung zu erzielen;
- es werden hohe Systemkapazitäten pro Gast benötigt.
Anders als bei der Komplettvirtualisierung 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.
Das Problem, dass die Unterstützung der Betriebssystemhersteller benötigt wird hat beispielsweise auch VMware erkannt. Der Hersteller bietet jetzt die Möglichkeit, teilweise mit paravirtualisierten Komponenten zu arbeiten. So haben die Betriebssystemhersteller nur die Verpflichtung, passende Treiber zu liefern; eine Anpassung des Kernels ist nicht notwendig.
Plus
- flexible Anpassung der Gasthardware (teilweise auch während der Laufzeit);
- nur ein Prozess zur Abbildung der virtuellen Hardware erforderlich;
- verbesserter Zugriff auf die virtuelle Hardware durch das Gast-Betriebssystem.
Minus
- Hardware muss durch die Virtualisierungssoftware unterstützt werden;
- manche Hardware lässt sich im Gastsystem nicht abbilden (etwa Faxkarten), es gibt aber zum Teil Lösungen extern benötigte Schnittstellen via IP zu nutzen;
- Anpassung der Gast-Betriebssysteme notwendig;
- unter Umständen ist eine Anpassung bei Updates des Hosts/Gasts erforderlich;
- hohe Systemkapazitäten pro Gast notwendig.
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 virtuelle Maschine (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 an Betriebssystemen voraussetzt. Wichtigster Aspekt auch bei dieser Form der Virtualisierung: Alle Gäste müssen getrennt und unabhängig voneinander agieren können.
Plus
- sehr hohe Geschwindigkeit im Gast;
- flexible Anpassung der Gasthardware (teilweise auch während der Laufzeit);
- Nutzung von Teilen des Host-Betriebssystems;
- optimierter Zugriff auf die virtuelle Hardware durch das Gast-Betriebssystem;
- große Hardwareunterstützung (Microsoft Windows oder Linux)
- geringe Systemkapazitäten pro Gast benötigt.
Minus
- Homogene Gast-Betriebssysteme (Host = Gast-OS);
- manche Hardware lässt sich im Gastsystem nicht eins zu eins abbilden (etwa Faxkarten);
- Betriebssystem-Updates des Hosts betreffen den Gast.
- Was versteht man unter Desktop-Virtualisierung?
Der erstmals durch VMware geprägte Begriff der “Virtual Desktop Infrastructure” (VDI) bezeichnet den Betrieb von Desktop-Betriebssystemen wie Windows XP, Vista oder Windows 7 in einer virtuellen Maschine (VM) als Ersatz für den Desktop des Benutzers. Dabei wird die virtuelle Session direkt im Data Center zur Verfügung gestellt. Die Desktops werden auf einer der bekannten Virtualisierungsplattformen zur Verfügung gestellt. Durch die zentrale Bereitstellung lassen sich Synergien zwischen den unterschiedlichen Desktops nutzen. Der Anwender greift über die Protokolle ICA, RDP oder PCoIP auf “seinen” virtuellen Desktop zu. Als Endgeräte kommen optimalerweise Thin-Clients zum Einsatz, die für das genutzte Protokoll optimiert sind. Die Sitzungen selbst werden über Software-Broker gesteuert. Dabei erfolgt die Zuweisung der Sessions über das angeflanschte Active Directory (AD).
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 Umleiten 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. Mittlerweile sind die Produkte aller namhaften Hersteller nur bei nutzbaren Virtualisierungsfunktionen der Prozessoren installierbar.
Durch die 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. Snapshots sind aber keine dauerhafte Datensicherung. Alle Änderungen am Gast, welche nach einem Snapshot erfolgen, werden in ein separates File geschrieben. Dieses kann auch größer werden als das eigentliche Festplattenfile, denn es werden ja alle Änderungen festgehalten. Das kann dann dazu führen, dass die LUN auf der die VM beheimatet ist voll läuft und der Betrieb aller VMs auf der Platte gestört ist.
Eine Datensicherung selbst kann mit klassischen Mitteln erfolgen über einen Agenten im Gast. Alternativ gibt es Lösungen, die direkt auf das File-System des Hosts zugreifen können oder es werden Agenten im Hostsystem genutzt.
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 zur Verfügung zu stellen. Kommt mehr als ein Host mit gesharetem Storage zum Einsatz, liegt die Verfügbarkeit weitaus höher, als bei Standalone-Systemen, und das auch ohne auf hochverfügbare Softwarekomponenten im Gast zurückgreifen zu müssen.
Wie kommt man zu virtuellen Servern?
Durch die Unabhängigkeit von der Host-Hardware erhalten Nutzer die Option, physikalische Systeme mit passender Software (P2V, physical to virtual) einfach zu virtualisieren. So können bereits bestehende Systeme ohne Neuinstallation virtualisiert werden. Ansonsten ist die Neuinstallation einer VM identisch mit der Installation eines physikalischen Servers.
Sind virtuelle Umgebungen skalierbar?
Eine wesentliche, sowohl die Organisation als auch Administration betreffende Eigenschaft von virtuellen Maschinen (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 gibt Planungssicherheit im Hinblick auf die Anforderungen an die Server-Systeme; die Hardware-Ressourcen kommen allen Systemen zugute.
Können sich virtuelle Maschinen (VMs) gegenseitig stören?
Aus Sicherheitsgründen ist die Virtualisierung nur dort sinnvoll, wo virtuelle Maschinen (VMs) gegeneinander und gegenüber dem Host-System isoliert sind. Ein ungewollter Datenzugriff muss verhindert werden und Fehler oder der Absturz eines Gasts dürfen nicht zum Ausfall anderer Gäste führen.
Mit dem Begriff Netzwerk-Virtualisierung werden verschiedene Funktionen bezeichnet. Letztendlich ist das “VLAN-ing” ein wichtiger Baustein für die Virtualisierung von Servern. Mit dieser Funktionalität ist es möglich, unterschiedliche VMs mit verschiedenen Netzwerksegmenten zu verbinden, ohne dass für jedes Netz eine eigene physische Netzwerkkarte benötigt wird. Durch die Auswertung des VLAN Tag Bits wird das passende Netzwerk der VM zugeordnet. So ist es möglich, schon mit zwei physischen Netzwerkkarten ein ausfallsicheres Netzwerk in virtuellen Umgebungen aufzubauen, ohne Einschränkungen der Konnektivität.
Auch innerhalb der Server-Hardware gibt es Bestrebungen, das Netzwerk zu virtualisieren. Dieser Ansatz ist im Umfeld der Blade-Server besonders interessant: Der Hardwarehersteller fügt zwischen der Netzwerkkarte im Blade-Server und dem physikalischen Netzwerk eine Virtualisierungsschicht ein. Diese Schicht präsentiert eine virtuelle MAC-Adresse ins Netz, anhand derer der Server identifiziert werden kann. Über ein zu definierendes Profil wird die virtuelle MAC mit der physischen MAC des Servers verbunden. Der Vorteil liegt auf der Hand: Muss ein Server getauscht werden, dann wird dem neuen Server einfach das Profil des Alten zugewiesen und alle Freischaltungen gelten für das neue System, weil sich das Netzwerk ja auf die virtuelle Adresse referenziert.
Was sind virtuelle Fibre-Channel Netzwerke?
Fibre-Channel-Netzwerke (FC) können ebenfalls virtualisiert werden. Auch dieser Ansatz ist im Umfeld der Blade-Server verwirklicht. Der Hardwarehersteller fügt zwischen der FC-Karte im Blade-Server und dem physikalischen Fibre-Channel-Netzwerk eine Virtualisierungsschicht ein. Diese Schicht präsentiert eine virtuelle WWN (World Wide Number) ins FC-Netz, anhand derer der Server identifiziert werden kann. Über ein zu definierendes Profil wird die virtuelle WWN mit der physischen WWN des Servers verbunden. Der Vorteil: Muss ein Server getauscht werden, dann wird dem neuen Server einfach das Profil des Alten zugewiesen und das Zoning für das neue System ist erfolgt, ohne das ein Administrator des FC-Netzes Hand anlegen muss.
Auch im Storage Umfeld gibt es Ansätze für eine Virtualisierung. Es findet auch hier eine Entkopplung von Server- und den Storage-Komponenten statt. Die Storage-Virtualisierungsinstanz hat an sich zwei Funktionen. Zum Einen ist sie die Instanz, die den Servern Speicherkapazität zur Verfügung stellt, zum Anderen verwaltet sie die eigentlichen Storage-Boxen. Wo liegt nun der Vorteil? Eine Schicht zur Storage-Virtualisierung ist dazu in der Lage, einen Spiegel zwischen zwei Boxen zu erstellen ohne, dass Sie vom Storage Hersteller Lizenzen dafür kaufen müssen. Die Funktion ist auch gegeben, wenn der Spiegel zwischen Boxen unterschiedlicher Hersteller aufgebaut werden soll. So sind Sie bei einer Aufrüstung, Erweiterung oder Migration von Storage-Kapazitäten nicht auf einen Hersteller festgelegt.
Konkret: Unternehmen können also ein hochwertiges Storage-System des Anbieters A mit einem preiswerteren Speicher von Anbieter B kombinieren und so einen relativ preiswerten Spiegel aufzubauen. Baut man Spiegel mit herstellereinheitlichem Storage auf, dann müssen die Systeme immer identisch sein. Daraus ergibt sich ein weiterer Vorteil, nämlich Storage Migrationsszenarien von Hersteller A zum Hersteller B.
Es gibt Produkte, die den angeschlossenen Servern vorgaukeln, dass die angeschlossene LUN die maximal mögliche Größe haben, obwohl beispielsweise nur 150 GByte zur Verfügung gestellt werden. Damit ist aber eine einfache Erweiterung des Server-Storage möglich, ohne weitere Arbeiten am Server vornehmen zu müssen.
Bei der Applikations-Virtualisierung wird dem Anwender eine Applikation zur Verfügung gestellt, ohne dass diese auf dem Client installiert werden muss. Alle für die Ausführung benötigten Komponenten werden in einem Container installiert. Dieser Container enthält nicht nur die benötigten Informationen für die Applikation sondern auch die zur Ausführung benötigten Betriebssystemkomponenten. Der Container ist auf jedem System lauffähig, und zwar unabhängig davon, welches Betriebssystem auf dem Client installiert ist oder auf welchem System der Container für die Applikation erstellt worden ist.
Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche . (cvi)