Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

02.11.2005

VMware versus Virtual Server und Xen

Frank Kohler 
Die Server-Virtualisierungsprodukte von Microsoft, dem Open-Source-Projekt Xen und VMware verfolgen unterschiedliche Ansätze, die Firmen beachten müssen.
Die Virtualisierung lässt sich über zwei Ansätze realisieren: Entweder setzt ein schmaler Kernel direkt auf der Hardware auf (Typ A), oder es wird ein Basis-Betriebssystem genutzt, auf das Anwender zunächst die virtuelle Maschine und darauf die Gastsysteme installieren (Typ B).
Die Virtualisierung lässt sich über zwei Ansätze realisieren: Entweder setzt ein schmaler Kernel direkt auf der Hardware auf (Typ A), oder es wird ein Basis-Betriebssystem genutzt, auf das Anwender zunächst die virtuelle Maschine und darauf die Gastsysteme installieren (Typ B).
Durch Virtualisierung wird die Bindung der Gastsysteme an ihre physikalische Hardware aufgehoben.
Durch Virtualisierung wird die Bindung der Gastsysteme an ihre physikalische Hardware aufgehoben.

Der Zwang zum Sparen veranlasst immer mehr IT-Verantwortliche dazu, ihre Rechnerumgebungen physikalisch zu konsolidieren und zentral zu verwalten. Konsolidierung lässt sich durch Virtualisierung von Rechenzentren oder verteilter Server erreichen. Mit dem "ESX"- und dem "GSX"-Server (beide von VMware) sowie dem "Microsoft Virtual Server 2005" werden hierfür drei populäre Tools angeboten. Zusätzlich existiert mit "Xen" ein Virtualisierungswerkzeug der Universität Cambridge auf Open-Source-Basis, das seit Mitte April im Paket mit "Suse Linux Professional 9.3" ausgeliefert wird.

Beispiel für die Überwachung von ESX-Servern

Das Systemhaus RZNet bietet zwei Softwarelösungen, mit denen sich ESX-Server von VMware in einer Farm überwachen lassen. Anwender können damit die Verfügbarkeit gewährleisten und ein Disaster Recovery vornehmen. "Rics" (RZNet Infrastructure Cluster Services) wird auf dem "VMware Virtual Center Server" (ab Version 1.2) installiert und läuft unter Windows 2000, 2003 (Server-Versionen) oder XP. Das Tool erfordert mindestens zwei ESX-Server (ab Version 2.1) auf einer Intel- oder AMD-x86-Plattform und ist auf bis zu 16 Knoten skalierbar.

Das Programm überwacht die Funktion der ESX-Server sowie der virtuellen Maschinen und startet bei Bedarf bestimmte Gastsysteme auf einem anderen Host. Um die Abhängigkeiten der einzelnen Anwendungen abzubilden, werden Gruppen mit entsprechenden Bezeichnungen gebildet. Der Start dieser Systeme erfolgt dann nach dem vorher festgelegten Prioritätsgrad.

Die Konfiguration jeder virtuellen Maschine wird alle zwei Minuten aktualisiert. Da laufende virtuelle Maschinen physikalisch verlegt werden können, erkennt Rics die aktuelle Position der VMs. So lässt sich das Verschieben auf eine ausgefallene Hardware verhindern. Die Verfügbarkeit der Gastsysteme (VMs) wird mit dem Echo-Dienst überwacht. Die Software verteilt die Arbeitslast während des Normalbetriebs auf alle vorhandenen Maschinen. In der aktuellen Version wird dies noch manuell vom Administrator erledigt, in Zukunft soll es automatisch erfolgen.

Bei Ausfall eines ESX-Servers reagiert Rics mit einem automatischen Failover. Dazu werden VMs vom nicht mehr lauffähigen Server abgezogen und auf einen oder mehrere der verbliebenen ESX-Server verschoben und gestartet. Auf diesen Servern muss Vmotion aktiviert sein. Der Management-Zugriff auf die einzelnen Maschinen erfolgt über einen RSA-Schlüssel und mit einem Kennwort.

Für die Sicherung sowie Rücksicherung kompletter Gastsysteme im laufenden Betrieb eignet sich das zeitgesteuerte Voll-Backup-System "Centralized Infrastructure Disaster Recovery" (Cider). Das Programm soll Anwender unterstützen, die über keine hochverfügbare Installation oder kein gespiegeltes SAN verfügen. In Umgebungen mit gespiegeltem SAN lassen sich darüber hinaus definierte Zustände der VMs sichern.

Voraussetzung sind der ESX- (ab Version 2.1) oder der GSX-Server und eine Datensicherungslösung wie TSM. Die Sicherungen werden in der "Crontab" erzeugt, einem Scheduler in der Servicekonsole, der die Datensicherung nach Wunsch (zum Beispiel stündlich) initiiert.

Die Datensicherung und das Disaster Recovery sind für den Benutzer auch ohne die Kenntnis des verwendeten Gastsystems möglich, das heißt, es ist dann kein spezifischer TSM-Client (Dateisicherungs-Tool) erforderlich. Das vollständige Backup einer virtuellen Maschine erfordert bei einer Systemplattengröße von ungefähr 6 bis 8 GB einen Zeitraum von etwa zehn Minuten. Die VM wird dabei im laufenden Betrieb mit TSM in einer speziellen Datei gesichert. Die Rücksicherung nimmt der Anwender über das Web-Interface von TSM vor.

Fazit

• Die Leistungsfähigkeit bei kleinen Systemen (Microsoft Virtual Server und VMware GSX) ist etwa gleich gut.

• VMs von Microsoft und VMware unterstützen jeweils nur einen einzigen Prozessor, unabhängig davon, wie viele Prozessoren tatsächlich vorhanden sind.

• Ist eine Nutzung mehrerer Prozessoren wünschenswert, muss der ESX-Server von VMware eingesetzt werden.

• Xen ist eine Alternative nach der GNU-Lizenzierung und basiert auf dem ESX-Server ähnlichen Funktionen.

• Allerdings erreicht Xen in der aktuellen Version aufgrund der dafür notwendigen Änderungen im Linux-Betriebssystem noch nicht die Leistungsfähigkeit des ESX-Servers, und bietet auch nicht die von einem kommerziellen Produkt gewohnte Unterstützung.

Hier lesen Sie …

• wie sich die Virtualisierungsprodukte von VMware, Microsoft und Xen unterscheiden;

• was ihre wichtigsten Funktionen sind;

• wie die virtuellen Systeme verwaltet werden können.

Mehr zum Thema

www.computerwoche.de/go/

*82204: Neue Server-Lizenzen von Microsoft;

*78903: Grids und Supercomputer;

*82040: Anwendungen virtualisieren;

*80437: Multicore-CPUs.

Die Hardware

Die Hardware spielt bei der Virtualisierung eine wichtige Rolle. Während in kleineren Umgebungen für den Virtual Server 2005 oder den GSX-Server ein übliches Ein-Prozessor-System ausreicht, sollte man bei höheren Anforderungen mit unternehmenskritischen Systemen auf eine Plattform mit mindestens zwei bis acht CPUs zurückgreifen. Auf einem System laufen dann üblicherweise je nach der genutzten Anwendung bis zu 30 virtuelle Server.

Intel wird noch dieses Jahr eine Version seiner IA32- und IA64-Prozessoren mit speziellen Features herausbringen, die die Virtualisierung auf diesen Prozessoren erleichtern sollen. Die Server-Produkte auf AMD-Opteron-Basis sind bereits von VMware für den ESX-Server zertifiziert.

Mögliche Fallstricke

Beim Aufbau einer virtuellen Infrastruktur sind einige wichtige Aspekte zu beachten:

• Alle Dateien einer VM müssen genau wie ein physikalischer Server geschützt werden.

• Aus Performance-Gründen empfiehlt Microsoft, für virtuelle Server die Hyperthreading-Funktion generell zu deaktivieren und besser mit einem Dual-Core-System zu arbeiten.

• Wichtig bei der Dimensionierung der Hardware sind der Arbeitsspeicher und die Festplatten. Das Host-System kann an seine Gastsysteme nur so viel Arbeitsspeicher verteilen, wie physikalisch tatsächlich vorhanden ist.

• Der ESX-Server bietet die Möglichkeit des RAM-Sharing und kann den Anwendungen virtuell mehr Hauptspeicher zur Verfügung stellen (Memory-over-Commitment).

• Eine ausreichende Anzahl von Festplattenspindeln verhindert Engpässe bei I/O-intensiven Anwendungen.

• In einer virtuellen Umgebung sind physikalische Anschlüsse immer schneller als virtuelle.

• Der Prozessor selbst ist bei der Dimensionierung das unkritischste Bauteil.

• Nicht jede Anwendung lässt sich virtualisieren. Ungeeignet sind zum Beispiel Programme, die einen Hardware-Dongle erfordern.

• Unternehmen sollten im Vorfeld klären, ob eine Virtualisierung ihrer Systeme funktionieren kann.

Virtualisierung bedeutet, dass mehrere Betriebssysteme mit ihren Anwendungen parallel auf ein und derselben Hardware laufen. Dies wird mit einer Virtualisierungsschicht realisiert, die sich zwischen der Hardware und den verschiedenen Betriebssystemen befindet. Die Virtualisierungsschicht täuscht jedem Betriebssystem eine eigene Hardware mit eigenem Bios vor, quasi einen eigenen Rechner. Wichtig ist dabei die Isolierung, damit sich die virtuellen Maschinen (VM) auf Programmebene nicht beeinflussen.

Eine VM besteht immer aus einem Satz von Dateien. Daher lassen sich die Konfigurationen leicht auf andere Virtualisierungsumgebungen übertragen, sofern sie vom selben Hersteller stammen. Die virtuelle Hardware auf unterschiedlichen physikalischen Servern ist dabei nahezu identisch.

Für VMs gibt es zweierlei Ansätze. Typ A verwendet einen kleinen Kernel, der direkt auf der Hardware aufsetzt und die einzelnen Betriebssysteme virtualisiert. Dies sind beispielsweise der ESX-Server 2.5 oder Xen 2.0.

Typ B nutzt ein großes Basis-Betriebssystem, auf das die VM installiert wird und auf dem schließlich die Gast-Betriebssysteme mit ihren Anwendungen laufen. In diesen Bereich fallen der Microsoft Virtual Server 2005 mit der Basis Windows Server 2003 und der VMware GSX-Server 3.5, der eines der aktuellen Windows- oder Linux-Server-Systeme nutzt.

Abhängig von der Hardware

Beide Ansätze eignen sich zunächst für die Virtualisierung, wobei Typ B etwas mehr Ressourcen erfordert, dafür aber unabhängiger von der Hardware ist. Typ A muss die zur Verfügung stehende Hardware anerkennen, während die darüber liegenden Betriebssysteme Plug-and-Play-fähig sind. Als Hardware dienen in der Regel CPUs auf x86-Architektur, und außer Xen bieten die VMs bereits 64-Bit-Versionen.

Ein wesentlicher Vorteil der Virtualisierung besteht in der Möglichkeit, Betriebssysteme zwischen einzelnen VMs und auch Hardwaregeräten relativ einfach zu verschieben, da keine Bindung an den physikalischen Rahmen mehr besteht. Auf diese Weise lassen sich während der Spitzenzeiten zusätzliche Server für eine bessere Lastverteilung hinzunehmen. Auch Wartungs- oder Reparaturarbeiten können so ohne Verlust der Verfügbarkeit für den Anwender erledigt werden. Bei VMware heißt diese Technik "Vmotion" und wird ab Version 2.01 des ESX-Servers in Zusammenhang mit dem "Virtual Center" unterstützt, vorausgesetzt, es ist ein SAN-Storage vorhanden. Das Verschieben funktioniert während des laufenden Betriebs und innerhalb weniger Sekunden, wozu das VMware-Produkt den gesamten zugehörigen Hauptspeicher spiegelt. Das Produkt verwaltet zudem bis zu 1000 virtuelle Server von einer zentralen Stelle aus. Da die üblichen Anwendungen ihre Dienste per TCP/IP, also einem fehlertoleranten Protokoll, bereitstellen, gibt es keinerlei Probleme mit der Verzögerung.

Einschränkungen bei SAP-Programmen

Typische Lösungen sind hier File Server unter Windows, "Novell Directory Services" (NDS), Print-Server sowie Systeme für DHCP, DNS, Active Directoy, Update-Server, Firewalls und Network Address Translation (NAT). Bei SAP-Programmen gibt es Einschränkungen. Wenn die Lösungen auf VMware laufen, liefert der Softwareanbieter aus Walldorf keinen Support, wenn es sich um Produktivsysteme handelt. Für Test- und Integrationssysteme ist dies angedacht.

Auch Xen bietet seit der Version 2.0 die Möglichkeit, VMs zwischen Knoten zu verschieben. Allerdings ist nach Angaben aus dem Projekt die Lastverteilung zwischen den einzelnen CPUs noch nicht optimal gelöst und soll in der nächsten Version verbessert werden. Das Produkt bedient aus technischen Gründen aktuell nur Linux- und BSD-Betriebssysteme. Gastsysteme müssen gepatcht werden, was beispielsweise im Falle von Windows als Closed-Source-Software schwer realisierbar ist. Der Virtual Server 2005 und der GSX-Server können mit diesem Feature nicht aufwarten. Sie müssen zum Verschieben zwischen einzelnen Hardwarebasen heruntergefahren werden und sind in dieser Zeit nicht verfügbar.

Im Leistungsvergleich zwischen dem Virtual Server 2005 und dem GSX-Server lassen sich nur kleine Unterschiede feststellen. Beide Produkte können hier einer einzigen VM bis zu 100 Prozent der CPU zuteilen und arbeiten mit Systemen von bis zu 32 Prozessoren, wobei je VM maximal eine CPU ansprechbar ist. Insgesamt werden 64 GB RAM auf dem Host-Rechner unterstützt und je VM auf 3,6 GB zugegriffen. Hier zeigen sich bereits die Einschränkungen dieser beiden Produkte bei arbeitsspeicherintensiven Anwendungen. Xen ist ebenfalls multiprozessorfähig und bringt es auf 128 VMs, während der ESX-Server mit 16 Prozessoren arbeitet, bis zu 64 GB Host-Speicher sowie 256 TB Gesamtspeicher adressieren kann und einen Parallelbetrieb von 80 VMs ermöglicht.

Ressourcenzuweisung

Kernstück jeder Virtualisierung ist jedoch die Verwaltung der Systeme. Dort werden die einzelnen VMs ein- und ausgeschaltet, der Systemstatus abgefragt oder entsprechende Ressourcen zugewiesen. Anwendungen kann eine Priorität und damit auch Prozessorleistung sowie Bandbreite zugeteilt werden.

Microsoft wählt für den Zugriff auf die Konsole per Remote Client ein Web-Interface. Auf dem Host-Betriebssystem läuft ein einzelner Dienst, der Virtual Server (VS) Service, in dem mehrere Threads erzeugt und in denen die virtuellen Maschinen abgebildet werden. Der Virtual Server selbst wird über DCOM verwaltet, das Management-Interface ist der Internet Explorer. Alternativ kann auch mit einem VMRC-Client (Active-X-Plug-in) gearbeitet werden, der direkt auf den VS-Service zugreift, allerdings nur unter Windows.

Sollen mit dem Server zusätzlich die I/Os für Festplatten oder die Bandbreite für das Netzwerkumfeld verwaltet werden, ist der Einsatz des ESX-Servers anstatt eines GSX-Servers erforderlich. (kk/fn)