Für die Virtualisierung von Servern eignen sich mehrere Ansätze. Derzeit haben in Bezug auf Vielseitigkeit und Leistungsfähigkeit die Bare-Metal-Hypervisoren die besten Karten. Zu den neueren Produkten gehören Xenserver 5.5, Hyper-V 2008 Release 2 und Vsphere 4. Dabei erlaubt die Live-Migration den geplanten Umzug von VMs ohne Ausfallzeiten.
Der Dell »Poweredge R510« eignet sich für Virtualisierung.
Die früheren Hypervisoren, wie etwa der »GSX-Server« von Vmware oder Microsofts »Virtual Server«, benötigen noch eine Betriebssystemschicht auf der Hardware. Erst darauf setzt dann die Hypervisor-Software auf. Diese Lösungen gelten im Server-Umfeld als antiquiert und werden über kurz oder lang verschwinden.
Betriebssystem-Virtualisierung spart Ressourcen
Eine andere Konzeption ist die Betriebssystem-Virtualisierung. Hiermit arbeiten einige Unix-Versionen (wie IBMs »AIX«). Von Parallels gibt es die »Virtuozzo Containers«. Im Opensource-Bereich ist diese Software in einer etwas abgespeckten Form als »OpenVZ« verfügbar. Bei ihr setzt die virtuelle Abstraktionsschicht auf dem Betriebssystem des Hosts auf und nicht auf der Hardware.
Die virtuelle Schicht erzeugt auf einem Server und der Betriebssysteminstanz zahlreiche isolierte virtuelle Umgebungen, das sind die Container, in denen je ein virtueller Desktop läuft. Die Folge: Die Hardware muss nicht virtualisiert und das Betriebssystem nur einmal auf dem Server installiert werden und nicht zusätzlich in jedem einzelnen Container.
Flexibilität geht verloren
Architektur alter Hypervisoren. Grafik: Microsoft
Daher ist diese Lösung nur dann eine gute Wahl, wenn ein Unternehmen mit identischen Betriebssystemen agiert – etwa mehreren Windows-Server-Plattformen. Diese Art der Server-Virtualisierung erfreut sich bei Hostern großer Beliebtheit – vor allem wenn sie nur den »LAMP«-Stack (Linux, Apache, MySQL und PHP) für die Kunden vorhalten müssen.
Moderne Bare-Metal-Hypervisoren brauchen CPU-Erweiterungen
Prinzip der Bare-Metal-Hypervisoren. Grafik: Microsoft
Dagegen verfolgt die ältere ESX-Technik von Vmware einen Ansatz, der auch mit normalen Prozessoren zurechtkommt. Das hat dann aber seinen Preis, denn der ESX-Hypervisor muss alle Treiber für die Hardware selbst vorhalten. Damit reduzieren sich die Einsatzmöglichkeiten dieses Produkts auf die definierte Kompatibilitätsliste bei der Hardware. Wer einen anderen Server verwenden möchte, kann auf massive Probleme stoßen.
Xenserver und Hyper-V ähneln sich
Die Unterschiede von Xenserver und Hyper-V sind konzeptionell nicht besonders groß. Beide benötigen eine eigene Partition oder Domäne, um die Kontrolle über den Hypervisor selbst auszuüben und um die Interfaces zur Hardware herzustellen. Bei Xenserver kommt eine speziell abgehärtete Version von Linux für diese Partition zum Einsatz, beim Hyper-V eine entsprechend gehärtete Version von Windows Server 2008.
Mit Release 2 des Hyper-V und Windows Server 2008 R 2 Hyper-V hat Microsoft den nächsten Schritt vollzogen. Damit eignet sich diese Virtualisierungs-Lösung für den Produktiveinsatz in Unternehmen, die mehr Funktionalität benötigen, als sie die Vorgängerversion zu bieten hatte.
Vor allem der Aspekt der Migration von virtuellen Maschinen (VMs) von einem physischen System zu einem anderen ist hier zu nennen. Bislang konnte der Hyper-V nur mit einer »Quick Migration« aufwarten. Dabei wurden aktiven VMs angehalten und auf ein anderes System verschoben. Dort musste man sie dann wieder neu starten. Das hatte zur Folge, dass es für die Anwender eine merkbare Unterbrechung gab.
Hyper-V R2 holt bei Live-Migration auf
Das wird nun mit der »Live-Migration« anders. Sie hilft beim transparenten Verschieben einer VM auf ein anderes System, wobei die Applikation sowie der Anwender dabei nichts merken sollten. Derartiges hatten die Konkurrenten Xenserver und vor allem VMwares ESX-3.x-Familie (unter der Bezeichnung »Vmotion«) schon parat. Hier hat Microsoft nun nachgezogen.
Allerdings hilft die Live-Migration nur bei einem geplanten Umziehen einer VM. Sollte eine VM ausfallen, weil zum Beispiel der darunterliegende physische Server auf Grund eines nicht behebbaren Hardware-Defekts seinen Dienst quittiert, fallen auch alle VMs auf diesem Hypervisor aus. Hier hilft nur die Kombination mit einem ausfallsicheren Konzept, das auf der Cluster-Technologie beruht und das über einen gemeinsamen Speicher verfügt.
Konsolidierungsraten unterscheiden sich
Die einzelnen Funktionen der vier verschiedenen Bezugsmöglichkeiten für die Virtualisierungs-Lösung von Microsoft sind in der Tabelle zusammengefasst. Ein Anheben der maximalen Prozessorkerne auf 32 (außer bei der Standard-Version) reicht für Server mit acht Quadcore-Prozessoren. Kommt aber Intels »Hyper-Threading«-Technik in den CPUs zum Einsatz, können nur deren vier Quadcores unterstützt werden. Beim Vorgänger waren es anfangs nur 16 Kerne, das wurde dann mit dem Hotfix KB956710 auf 24 Kerne erhöht – vor allem wegen der Sechskern-Opterons von AMD.
Der Hyper-V 2008 kann im Vergleich zu seinen Brüdern ganz erstaunliche Funktionen liefern – zumal es sich dabei um eine lizenzkostenfreie Variante handelt. Er entspricht aber vom Prinzip her einer »Server-Core«-Version – sprich er verfügt über keine übliche grafische Benutzerschnittstelle.
Hier ist für die direkte Verwaltung in erster Linie die Kommandozeile angesagt. Es besteht allerdings die Option, einen Hyper-V-Server von einem anderem System – etwa einem PC mit Windows Vista – remote zu verwalten. Dazu können Tools wie der »Hyper-V Manager« auf dem PC installiert werden. Damit steht dem Administrator dann auch wieder die gewohnte Point & Click-Umgebung für die Verwaltung zur Verfügung.
Erst Verwaltungs-Tools machen Hypervisor komplett
Auch »System Center Virtual Machine Manager« (SCVMM), die Verwaltungs-Software für Microsofts Hypervisor, lässt sich remote einsetzen und kann dann sehr komfortabel einen Hyper-V-Server betreuen. Ein weiteres interessantes Tool in diesem Zusammenhang ist noch der »Failover Cluster Manager«. Er dient dem Aufsetzen und dem Verwalten eines Clusters, um die Virtualisierungs-Hosts auf Basis eines Hyper-V (oder Windows Server 2008) ausfallsicher zu gestalten.
Die interessanteste Funktion des Hyper-V R2 ist aber die Live-Migration von VMs. Damit lässt sich eine VM in einem geplanten Szenario von einem Host auf einen anderen verschieben, wobei kein Datenverlust oder keine merkbare Unterbrechung des von der VM ausgeführten Dienstes für die Anwendungen auftritt. Das bedeutet aus technischer Sicht, dass der letztendliche Umschaltvorgang innerhalb eines Zeitfensters erfolgen muss, so dass die TCP/IP-Schicht keinen Timeout an die anderen Schichten im Software-Stack meldet.
Live-Migration benötigt gemeinsamen Speicher
Live-Migration bei Hyper-V R2. (Grafik: Microsoft)
Zuerst werden die Konfigurationsdaten der betreffenden VM vom Quellknoten zum Zielsystem kopiert. Das läuft in der Regel über das Netzwerk. Die Transferzeit ist daher von der verfügbaren Netzwerkbandbreite abhängig. Eine kritische Zeitvorgabe fällt hier nicht an, denn die eigentliche VM läuft immer noch aktiv auf dem Ursprungsknoten.
Dann geht es an das Übertragen der Arbeitsspeicherinhalte der betreffenden VM (also die zugehörigen Infos im DRAM) von einem Knoten zum anderen. Hier können große Datenmengen anfallen, etwa wenn eine VM den maximal machbaren Speicher (64 GByte) zugewiesen bekommen hat.
Netzwerkanbindung entscheidet über Geschwindigkeit
Bei einem 100-MBit/s-Ethernet dauert das seine Zeit. Daher wird es in der Regel vorkommen, dass sich die Arbeitsspeicherinhalte für die zu kopierende VM ändern. Diese Änderungen muss die Live-Migration mit protokollieren und sie anschließend auf das Zielsystem kopieren. Dieser Teilschritt wird sich so oft wiederholen, bis irgendwann so gut wie alles auf dem Zielsystem vorliegt.
Erst dann erfolgt ein kurzfristiges Anhalten der laufenden VM auf dem ursprünglichen Knoten – in dieser kurzen Zeitspanne (kürzer als das Timeout-Fenster beim Protokoll TCP/IP) werden dann die letzten Arbeitsspeicherinhalte sowie die betreffenden Prozessorregisterinhalte auf den Zielknoten kopiert. Danach folgt noch die Zuweisung des virtuellen Festplattenspeichers auf dem Zielserver – in der Regel werden dazu nur Zeiger kopiert. Das geht sehr schnell über die Bühne.
Danach befindet sich die VM auf dem Zielsystem in einem konsistenten Zustand. Erst dann wird die Ausführung der VM wieder angestoßen – diesmal bereits auf dem Zielsystem. Im nächsten Schritt sind noch die Switch-Tabellen des physischen Netzwerk-Switches so umzustellen, dass der neue Port den betreffenden Netzwerkverkehr für diese virtuelle Maschine zugestellt bekommt. Und schließlich wird die »alte« VM auf dem Quellsystem entfernt.
Erst Clustering garantiert Ausfallsicherheit
Wichtig in diesem Zusammenspiel ist der Einsatz eines gemeinsamen Speichers. Hier bietet Windows Server 2008 R2 mit den »Cluster Shared Volumes« (CSV) eine weitere Verbesserung. Diese CSV sind eine absolut notwendige Voraussetzung für die Live Migration, denn erst damit ist es zwei VMs möglich, auf dieselbe LUN zu schreiben.
Dieser Service stellt einen konsistenten Namensbereich für die Dateien auf allen Failover-Cluster-Knoten zur Verfügung. Damit können mehrere Cluster-Knoten gleichzeitig auf eine LUN auf einem gemeinsamen Speichersystem zugreifen.
Für eine VM sieht ein CSV-Volume so aus, als wäre sie in der VM-eigenen LUN abgelegt. Doch der gesamte Speicher einer VM liegt in einer einzigen LUN und jeder Cluster-Knoten kann auf die Volumes über denselben »FQPN« (Fully Qualified Path Name) zugreifen. In Bezug auf die Speichergeräte unterstützt CSV sowohl SAN- als auch NAS-Konfigurationen wie auch die Anbindung über ISCSI.
Generell setzt die Live-Migration direkt auf der Ebene der VMs an. Das bedeutet, dass die Applikationen und Betriebssysteme in der VM von diesem Vorgang nichts mitbekommen und auch keinerlei Vorkehrungen in Applikation oder Gastbetriebssystem zu treffen sind.
Prozessor-Architektur und -Generation sind wichtig
Allerdings ist dabei eine Besonderheit zu beachten: Das Verschieben funktioniert nur zwischen Systemen, die eine einheitliche physische CPU-Familie verwenden. Ein Umzug von einer Intel-basierten x64-Server auf einen mit AMD-x64-Prozessoren ist damit nicht möglich. Und selbst wenn man innerhalb einer CPU-Familie bleibt, muss man die Chip-Generation beachten. Ein Umziehen von einem neueren Server etwa mit einem »Nehalem«-Prozessor (»Xeon 55xx«) auf ältere CPUs (etwa ein »Merom«-Design) birgt Probleme.
Der Grund liegt im unterschiedlichen Applikations-Befehlssatz – bei Intel lautet dafür die Bezeichnung »Streaming SIMD Extension« (SSE). Er ist für eine möglichst effektive Verarbeitung von Aufgaben wie etwa im Bereich Video-Codierung, 3-D-Imaging oder Grafikdarstellung zuständig. Für das Verschieben der VMs geben die CPU-Generationen den Ausschlag. Intel verwendet zum Beispiel bei der älteren »Merom«-Architektur die SSE 3. Bei der Nehalem-Generation ist bereits die SSE 4.2 mit zusätzlichen Befehlen im Einsatz. Will man nun eine VM von einem Rechner mit Nehalem-Prozessoren auf ein System mit »Merom«-CPUs verschieben, kann es dazu kommen, dass die alte Hardware einen der neueren Befehle ausführen soll, den sie allerdings nicht versteht. Dann wird es zu einem entsprechenden Fehler kommen, der unter Umständen die komplette VM runterzieht. Ein blauer Bildschirm in der VM ist die Konsequenz.