Kaum ein neuer Server stellt seine Ressourcen einer einzigen Betriebsystem-Instanz zur Verfügung. Nur wenige Applikationen sind überhaupt in der Lage, die komplette Leistung eines Rechen-Boliden mit acht Kernen und 24 GByte RAM voll auszuschöpfen. Daher setzen Administratoren auf Hypervisoren, welche die Maschinen virtualisieren. Neben dem Marktführer Vmware [1] (»Vphere 4 [2]«) offerieren auch Microsoft [3] (»Hyper-V [4]«) und Citrix [5] (»Xen [6]«) Lösungen. Network Computing hat sich die großen drei im Labor Poing intensiv angesehen.

Hyper-V

Microsoft integriert den hauseigenen Hypervisor als »Rolle« in das Server-Betriebssystem Windows-Server-2008. Ein kluger Schachzug, denn so kann Microsoft jeden verkauften Windows-2008-Server als Hyper-V-Installation zählen. So kann es sich somit zu einem der wichtigsten Player im Virtualisierungsmarkt erklären – egal ob die Anwender Hyper-V tatsächlich nutzen. Auf der anderen Seite werden natürlich viele Administratoren Hyper-V genau deshalb einsetzen, da es ohnehin zur Grundausstattung des Windows-2008-Servers gehört.

Steckbrief

Hyper-V

Hersteller: Microsoft [3]

Charakteristik: Hypervisor

Preis: Hyper-V-Standalone-Server. gratis, Hyper-V mit Windows-2008 Standard,

etwa 800 Euro

Web: www.microsoft.com/germany/windowsserver2008/virtualisierung.mspx [4]

Plusminus

+ Gute Integration in Windows-Server-2008

– Remote-Administration nur von Vista oder neueren Windows-Arbeitsstationen

– sehr eingeschränkte Unterstützung von Gastsystemen

Der Anwender hat die Wahl: Er kann einen vollständigen Windows-Server mit GUI und zusätzlichen Server-Diensten aufsetzen oder Hyper-V mit einem fast nackten Core-Server betreiben. Letzteren offeriert Microsoft als Gratis-Download.

Die Verwaltung von Hyper-V erfolgt über ein MMC-Plug-In (Microsoft-Management-Console). Das gibt es zunächst einmal nur auf dem Windows-2008-Server mit GUI. Im Internet finden sich Windows-Administrations-Tools für Vista und Windows 7, mit welchen der Administrator von seinem Arbeitsplatz aus den Hyper-V-Server verwalten kann. Dieses Werkzeug gibt es aber nicht für XP oder Windows-2003.

Als weiteren Stolperstein authentisiert der Windows-2008-Server einen Remote-Benutzer nicht mehr klassisch über die Inter-Process-Communication (SMB-Share //servername/ipc$). Die ermöglichte es bisher, dass Nutzer mit gleichem Namen und Passwort auf verschiedenen Maschinen Zugriff erlangen konnten. Jetzt behandelt Windows jedoch den Nutzer »server/user1« getrennt von »client/user1«.

Im Klartext: Auf dem Windows-2008-Testserver »SRV13« existiert der Benutzer »ast« mit den passenden Rechten, um die lokale Hyper-V-Installation zu verwalten. Meldet sich »ast« an seiner Admin-Arbeitsstation »CLT05« mit Windows 7 an, kann er auf die für »ast« freigegebenen Verzeichnisse auf SRV13 zugreifen (Authentisierung über ipc$).

Allerdings darf »CLT05/ast« nicht den Hyper-V-Server verwalten, weil er eben nicht »SRV13/ast« ist. Damit die Fernwartung des Windows-2008-Hyper-V-Servers also funktioniert, müssen beide Systeme zwangsweise Mitglied eines ADS (Active-Directory-Services) werden, denn hier gibt es verzeichnisweit nur einen »NWCADS/ast«.

Gerade kleine Installationen könnten jedoch sehr gut auf einen ADS-Domain-Controller verzichten und nur mit der klassischen Benutzer/Gruppe-Authorisierung leben. Außerdem nutzt dem Administrator der kostenfreie Hyper-V-Server herzlich wenig, wenn er dann doch eine Windows-2008-Lizenz für einen ADS-Controller erwerben muss.

Für Ubuntu als Gastsystem unter »Hyper-V« von Microsoft gibt es keine Netzwerkkarte.

So richtig mau wird es allerdings erst, wenn der Verwalter die Kompatibilitätsliste des Hyper-V-Servers konsultiert. Als virtuelle Gastsysteme werden offiziell nur Windows-XP ab SP2, Vista, Windows-2003 mit und ohne R2 sowie Windows-2008 unterstützt. Windows 7 und Windows-2008-R2 sollen folgen. Im Kleingedruckten findet sich noch der Windows-Server-2000 mit SP4 und Suse-Enterprise-Linux 10.

Letzteres wird wohl nur deshalb als einzige Linux-Distribution unterstützt, da Novell und Microsoft einen teuren Kooperationsvertrag unterzeichnet haben. Vereinfacht gesprochen kann Hyper-V Windows unter Windows laufen lassen. Im Test zeigt sich, dass Linux als Gast tatsächlich unerwünscht scheint. Die Installation eines Ubuntu-Servers schlägt fehl, da dieser unter Hyper-V keine Netzwerkkarte findet. Die Text-Dialoge der Linux-Installation im Framebuffer-Modus bauen sich unendlich langsam auf. Der Betrachter glaubt fast schon, dass Hyper-V die Bildschirmdarstellung absichtlich verlangsamt, um Linux möglichst schlecht darzustellen.

Weder die anderen Hypervisoren noch ein fünf Jahre alter PC verzögern im Labor die Framebuffer-Ausgabe dermaßen stark. Client-Tools für VMs mit Linux liefert Microsoft nicht mit. Obwohl Microsoft mit »ältere Netzwerkkarte« angeblich einen LAN-Adapter mit DEC-Chip kompatibel für ältere Systeme simulieren soll, findet die Linux-Installation kein LAN-Interface – obwohl jedes Linux den DEC-Treiber integriert hat. Allerdings hat Microsoft nach dem Test nachgelegt und Open-Source-Code für den Linux-Kernel veröffentlicht, damit Linux-VMs unter Windows besser laufen (Network Computing berichtete [9]).

Selbst die Installation von Windows-XP unter Hyper-V gestaltet sich kompliziert, da der XP-Gast anfangs keinen Zugriff auf die Maus bekommt. Der Anwender muss die Installation nur per Tastatur durchführen. Eine XP-Installation von der Original-CD ohne SP2 geht auch nur bedingt. Die Hyper-V-Tools mit den nötigen Treibern lassen sich in der VM nicht installieren, so lange kein SP2 läuft.

Fazit: Die Funktionen von Hyper-V beschränkt Microsoft darauf, Windows von Gestern unter Windows von Heute laufen zu lassen. Hyper-V ist daher unflexibel und kann vom Funktionsumfang nicht mit den anderen Hypervisoren mithalten. Selbst die simple Open-Source-Lösung Kernel-Virtual-Machine [10] (KVM) unter Linux hat hier mehr zu bieten. Ein Firstlook der KVM findet sich auf Networkcomputing.de [11].

Xen 5

Das Xen-Projekt (Open-Source) ging ursprünglich mit einem paravirtualisierenden Hypervisor an den Start. Gastsysteme mussten einen modifizierten Kern verwenden. Dank der neuen Virtualisierungsfunktionen in den CPUs von AMD und Intel arbeitet Xen auch als Vollvirtualisierer. Eine Reihe kommerzieller Implementierungen nutzen Xen. Dazu gehört unter anderem auch Virtual Iron, ein Unternehmen das unlängst von Oracle übernommen wurde.

Steckbrief

Xen 5

Hersteller: Citrix [5]

Charakteristik: Hypervisor

Preis: kostenlos

Web: www.xenserver5.com [6]

Plusminus

+ Kostenloser Hypervisor mit Profi-Funktionen

+ Gute und übersichtliche Admin-GUI

+ Automatischer Paravirtualisierungs-Support für Linux-Gäste

Citrix kaufte 2007 den kommerziellen Unternehmenszweig »XenSource«. Der Hypervisor an sich bleibt der Community jedoch erhalten. Ursprünglich verkaufte Citrix die kommerzielle Xen-Implementierung. Seit einigen Wochen gibt der Hersteller diesen Xen-Server-5 jedoch gratis aus.

Dieser installiert sich als exklusives System auf einem Rechner, der eine 64-Bit-CPU mit VT-Funktionen benötigt. Während der Installation muss ein LAN-Interface für den Remote-Management-Zugang passend konfiguriert werden.

Die Verwaltung des Xen-Servers übernimmt das Windows-Tool »XenCenter«. Einen Management-Server wie bei Vmware gibt es hier nicht. Der jeweils erste Xen-Server innerhalb eines Verbandes übernimmt die Rolle des Masters.

Mit dem Xen-Center stellt der Administrator die Verbindung zum Master und damit auch den weiteren Servern her und verwaltet deren Ressourcen sowie die VMs. Zuerst werden auf den Host-Systemen logische Netzwerke deklariert, auf die die virtuellen Maschinen Zugriff erhalten. Die LANs lassen sich mit einem oder zwei Netzwerk-Interfaces (Bonding) verbinden, oder arbeiten als internes Netzwerk.

Ebenso legt der IT-Manager Speicherpools für die VMs an. Xen unterstützt FC- (Fibre-Channel) sowie iSCSI-SANs und NFS-Freigaben. Um Maschinen im laufenden Betrieb von einem Xen-Server zu einem anderen zu verschieben, müssen diese auf SAN- oder NFS-Laufwerke liegen.

Um ISO-Dateien als virtuelle CD-Laufwerke verwenden zu können, muss der Administrator dafür gesonderte ISO-Libraries via SMB/CIFS oder NFS erstellen. Im Test funktionierte das mit NFS jedoch nicht. Citrix verweist ohnehin darauf, dass Xen NFS-Verbindungen als Hard-Links mountet. Ein Verbindungsproblem zum NFS-Server kann den Xen-Server blockieren oder gar zum Absturz bringen.

Über wenige Klicks erstellt der Verwalter virtuelle Windows- oder Linux-Maschinen. Gut gefällt dabei, dass der Verwalter im Kontext einer VM die Boot-Quelle (DVD, Netzwerk, Disk) auswählen kann – ein Komfort-Feature das es auch bei Hyper-V gibt, aber bei Vmware leider fehlt. Xen unterstützt eine Reihe von Linux-Distributionen mit Install-Wizzards. Der Verwalter braucht dafür keine Installations-Medien. Ein NFS- oder Http-Verzeichnis mit den Distributions-Dateien genügt. Xen richtet dabei automatisch den passenden, paravirtualisierten Kernel ein, um Ressourcen zu sparen.

Das »XenCenter« von Citrix verwaltet virtuelle Maschinen (VMs), Ressourcen und Virtualisierungshosts.

Ebenfalls gefällt am Xen-Center, dass sich die Konsolen-Verbindung zu einer VM zoomen lässt. Nutzt die VM eine höhere Auflösung als das Xen-Center, verkleinert die Software das Bild, so dass der Administrator trotzdem ohne Scrollbars das komplette GUI sieht. Nach Installation einer Maschine sollte der Verwalter die Xen-Tools innerhalb einer VM einrichten, welche die virtualisierte Hardware möglichst gut unterstützen.

Fazit: Im Test auf dem Dual-Opteron hinterlässt Xen 5 eine gute Figur. Windows und Linux-VMs laufen zuverlässig. Allerdings zickt der Hypervisor ein wenig bei dem Versuch, Linux-VMs über CD oder PXE ohne den vorgeschlagenen Wizzard zu installieren. Das stört jedoch kaum, da es mit Hilfe des Wizzards umso besser funktioniert.

Der Funktionsumfang von Xen 5 liegt auf Höhe des Vmware-Server 3.x. Mit Vsphere 4 kann der Citrix-Hypervisor jedoch nicht mithalten. Es fehlen die meisten Hochverfügbarkeitsfunktionen. Zudem weist Xen Ressourcen wie RAM und Disk statisch zu, während Hyper-V und Vmware Thin-Provisioning beherrschen.

Für viele mittelständische und kleine Unternehmen reicht der Funktionsumfang von Xen 5 jedoch völlig aus. Die Software kostet nichts und lässt sich auch von Administratoren mit wenigen Vorkenntnissen bedienen. Daher eignet sich diese Lösung sehr gut für Installationen mit zwei bis drei physikalischen Servern, die um die 30 bis 50 VMs enthalten.

Vshpere 4

Nachdem die Konkurrenz sehr nahe zum Marktführer Vmware aufgeschlossen hatte, lag es an der EMC-Tochter, die Messlatte höher zu legen. Vsphere 4 soll nun das erste wahre Cloud-Operating-System sein, schenkt man den Verkaufs-Strategen glauben. Lässt man den Marketing-Hype »Cloud« beiseite und wirft einen kritischen Blick auf die tatsächlichen Produkte, trifft man im Kern der Lösung auf den ESX-Server 4 mit dem Virtual-Center-Server 4. Wie bisher kontrolliert der ESX-Server die physikalischen Rechner eines Vmware-Clusters. Der Vcenter-Server verwaltet einen oder mehrere Verbände von ESX-4-Maschinen.

Steckbrief

Vsphere 4

Hersteller: Vmware [1]

Charakteristik: Hypervisor

Preis: ab etwa 800 Euro (Standard-Edition) bis etwa 3500 Euro (Enterprise-Plus) pro CPU-Sockel.

Web: www.vmware.com/de [15]

Plusminus

+ Sanfter Umstieg von Version 3 auf Version 4

+ Management-GUI erhält Look & Feel trotz neuer Funktionen

+ Leistungsfähige neue Sicherheitsfunktionen und Fault-Tolerance für VMs

Ab der Version 4 abstrahiert Vmware das Management stärker vom eigentlichen Host und macht den ESX-4-Node zum simplen Virtualisierungsknecht. Ein aufwändigeres Benutzersystem erlaubt es, sehr detaillierte Rechte auf Maschinen, Ressourcen und VM-Gruppen zu vergeben. Nach dem Provider-Prinzip könnten mehrere Administratoren auf ein und demselben Vsphere-Cluster eigene VM-Gruppen betreiben.

Sie haben dabei keinen Zugriff auf die VMs und Gruppen anderer Verwalter. Ein gegenüber der Vorgängerversion wesentlich detaillierteres Reporting gibt einen genauen Aufschluss über den Ressourcenverbrauch der VMs. Zudem hat Vmware die Alarmierung verbessert, so dass der Verwalter frühzeitig über drohende Engpässe informiert wird. Mehrere Vcenter-Server lassen sich ausfallsicher gruppieren.

Auch der ESX-4-Server legt gehörig an Funktionalität zu. Ein Cluster aus mehreren Servern kann jetzt Ausfallsicherheit für VMs offerieren. Eine laufende VM wird dabei in Echtzeit auf einen zweiten ESX-Host gespiegelt. Fällt der erste aus, läuft die VM auf dem zweiten ohne Neustart weiter. Ein ESX-Cluster kann nun CPUs verschiedener Typen enthalten.

Die zu den VMs durchgereichten CPU-Funktionen werden dabei auf den kleinsten Nenner reduziert. Im Test setzt Network Computing beispielsweise Server mit Penryn-Xeons und Nehalem-Xeons ein. Der Cluster schränkt die CPU-Features für VMs auf die Penryn-Instruktionen ein und kann mit Vmotion laufende Maschinen zwischen den Nodes verschieben. Die virtuellen Platten laufender Maschinen lassen sich nun per GUI von einem Speicher zum anderen verschieben (Storage-Vmotion). Dieses Tool gibt es bereits seit ESX 3.5, bislang war es aber nicht über den Vcenter-Client nutzbar.

Die virtuelle Hardware der VMs erlaubt nun mehr Geräte wie 10 NICs, 8 CPUs oder 256 GByte RAM. Der Verwalter kann zudem einer laufenden VM neue Disks zuweisen. Um bestehende VMs vom alten Hardware-Level 4 auf 7 zu bringen, muss der Administrator zuerst die Vmware-Tools innerhalb der VM aktualisieren und die Maschine herunterfahren. Dann erfolgt das Upgrade und die Maschine startet mit den neuen Funktionen.

Der ESX-4-Server legt virtuelle Festplatten nicht mehr statisch mit voller Größe auf den SAN-Laufwerken via FC, iSCSI oder auch NFS an. Wie bei der Vmware-Workstation gibt es nun ein Thin-Provisioning-Disk-Format. Die Konfiguration bestehender Maschinen mit statischen Disks lässt sich dabei über Vmotion auf das neue Format umstellen.

Am Anfang des Tests gibt es in den Real-World Labs Poing noch einen ESX-3.5-Server mit allen Labor-VMs und einen Virtual-Center-Server 2.5. Zunächst richtet das Labor-Team auf dem neuen Wortmann-Server den ESX-4-Node ein. Dann erfolgt das Upgrade des Virtual-Center 2.5 auf 4. Das verläuft ohne Probleme und konvertiert die bestehende Konfiguration.

Binnen weniger Stunden ist der Laborcluster mit allen VMs von »ESX 3.5« mit »VirtualCenter 2.5« auf »Vsphere 4« von Vmware aktualisiert.

Beim ersten Start des alten Vcenter-Clients auf einer XP-Arbeitsstation führt der Client ein automatisches Upgrade durch. Im Hintergrund bleibt der Vcenter-Client 2.5 parallel zum Vsphere-4-Client erhalten, so dass IT-Verwalter parallel neue und alte Vmware-Cluster managen können.

Der neue ESX-4-Server tritt als nächstes dem Cluster bei. Network Computing passt zunächst die FC-SAN-Konfiguration für den neuen Knoten an und verschiebt dann alle abgeschalteten VMs vom alten auf den neuen Server. Dort erhalten sie zunächst das Vmware-Tools-Update und anschließend den neuen Hardware-Level. Das Test-Team fügt zudem den Thinkserver mit ESX-4 zum Cluster hinzu und aktiviert die EVC-Funktion (Enhanced-Vmotion-Compatibility). Da Vsphere 4 keine neue Version des VMFS-Dateisystems einführt, können ESX-3- und -4-Server parallel auf dem Cluster-Filesystem arbeiten.

Fazit: Vmware führt mit Vsphere 4 unzählige neue Funktionen ein, von welchen Network Computing im ersten Schritt nur einen Bruchteil getestet hat. Die neuen Backup- und Virtual-LAN-Funktionen bleiben aktuell noch außen vor. Trotz der enormen Funktionserweiterung hat der Hersteller einen sanften Migrationspfad geschaffen, über den sich binnen weniger Stunden bestehende ESX-3.x-Cluster auf die neue Version hieven lassen – der Umstieg von ESX 2.x auf 3 war deutlich komplexer.

Im Labortest schaffen rund 30 VMs den Umstieg von ESX 3 auf 4 in etwa einer Stunde. Die laufenden VMs kommen dabei mit zwei Neustarts (Migration & Update der virtuellen Hardware) und somit einer geringen Downtime von wenigen Minuten aus.

Vsphere 4 bleibt das Maß aller Dinge in Sachen Server-Virtualisierung und die erste Wahl bei großen Installationen. Dafür muss der IT-Manager je nach Funktionen und Größe der Installation aber auch etliche Euros auf den Tisch legen. Allerdings hat Vmware die Preise gesenkt und packt deutlich mehr Funktionen in die Software als bisher.

Testverfahren Hypervisoren

Für die Tests der Server-Virtualisierungslösungen setzt Network Computing fünf verschiedene Server ein. Der Citrix-Xen-Server arbeitet auf einem AMD-Opteron-Server mit zwei 2,6-GHz-Dual-Core-CPUs und 8 GByte RAM. Das System nutzt zwei gespiegelte 80-GByte-Sata-Laufwerke für das Betriebssystem. Alle VMs sichert der Rechner im FC-SAN, an welches er mit zwei 4-GBit/s-Ports über einen Emulex-HBA-LPe-11002 (Host-Bus-Adapter) angebunden ist.

Der Hyper-V-Server läuft auf einem Lenovo-Think-Server RD220. Dieses System setzt zwei neue Quad-Core-Xeons vom Typ E5540 (Nehalem-Architektur) mit 2,6 GHz Takt und 24 GByte RAM ein. Der Rechner nutzt einen SAS-Raid-5-Verband (Serial-Attached-SCSI) mit drei 72-GByte-2,5-Zoll-Platten als Systemlaufwerk an einem LSI-SAS-Controller. Die SAN-Anbindung erfolgt über einen Qlogic-QLe 2562, der im 4-GBit/s-Modus arbeitet. Nach Abschluss der Hyper-V-Tests installiert Network Computing einen zusätzlichen Vmware-ESX-4-Server auf der Lenovo-Plattform.

Das primäre Vmware-Setup läuft auf einem Wortmann-Terra-Server 4302. Der Rechner arbeitet mit zwei Quad-Core-CPUs E5420 (Penryn) á 2,5 GHz und 16 GByte RAM. Für das System sowie einige lokal gesicherte VMs und Templates setzt der Server ein Raid-5-Verbund aus vier 450-GByte-Cheetah-Laufwerken 15k6 von Seagate ein. Ein Qlogic-QLe-2462 stellt die Verbindung zum SAN her.

Der bereits etwas ältere Wortmann-Terra-S5000 beherbergt zu Beginn der Vmware-Tests einen ESX-Server 3.5 und alle VMs des Labors. Der 1-HE-Rechner setzt zwei Intel-Dual-Core-Xeons E5150 mit 2,6 GHz und 8 GByte RAM ein. Das System sichert der Server auf gespiegelten 2,5-Zoll-SAS-Laufwerken. Zudem rüstet Network Computing vier 2,5-Zoll-Laufwerke »Constellation« von Seagate (500-GByte, S-ATA) als Raid-5-Daten-Array nach. Die SAN-Anbindung übernimmt ein Emulex-LPe-12002 im 4-GBit/s-Modus.

Im Laufe des Tests migriert das Labor-Team bestehende VMs von ESX 3.5 auf den neuen Terra-4302 mit ESX 4 und prüft das Online-Update von ESX-3.5 auf ESX-4. Nach Abschluss der Tests wird der Terra-S5000 das Labor nach fast zwei Jahren Betrieb ohne Fehler verlassen. Seine Nachfolge übernimmt der Terra-4302.

Zudem setzt Network Computing einen Server Marke Eigenbau mit einer Intel-Core-Quad-CPU 6600, Supermicro-Server-Motherboard und 4 GByte RAM ein. Das System beherbergt Ubuntu 9.04 mit KVM (Kernel-Virtual-Machine) und Libvirt. Ein Emulex-LP 11002 verbindet die Maschine mit dem SAN. Eine lokale Platte gibt es hier nicht. Der Rechner startet direkt von einem FC-SAN-Laufwerk.