Zunehmend mehr Technologien der Mainframe-Architektur finden ihren Weg in den PC-Server-Bereich. Eine wesentliche davon ist die Virtualisierung. Auf einem Großrechner erhält kein operatives Betriebssystem direkten Zugriff zu Speicher, Prozessoren oder I/O-Kanälen. Ein Virtualisierungs-Layer zwischen Maschine und eigentlichem Systembereich verwaltet alle Ressourcen und weist den darauf aufsetzenden Systeminstanzen die zugehörigen Ressourcen zu.

Was auf dem Mainframe zur Grundarchitektur gehört, ist auf der PC-Plattform bei erster grober Betrachtung noch wenig sinnvoll. Warum sollte man mehrere Betriebssysteme, die sich generell jede verfügbare Hardware eines Systems unter den Nagel reißen und nie wieder abgeben, gemeinsam in eine Box stecken und ihnen falsche Hardware vorgaukeln? Dabei muss zwangsläufig ein wenig Performance auf der Strecke bleiben, und die virtuelle Umgebung wird nur eine eingeschränkte Hardware unterstützen können.

Diese Begrenzungen treffen Clients, nicht aber Server. Maschinen für Standard-Aufgaben wie Mail-, Web-, File- oder Infrastrukturdienste benötigen keine besonders spezielle Hardware, und sie verlangen auch keine exorbitant hohe CPU-Performance.

Steckbrief

ESX-Server 2.5

Hersteller: Vmware

Charakteristik: Betriebssystem für virtuelle Server

Kurzbeschreibung: Ein ESX-Server beherbergt mehrere virtuelle Server auf einer Hardware. Das System, lässt sich sehr flexibel verwalten und einsetzen. Mit einem SAN lassen sich Cluster bauen und ein zentrales Maschinenmanagement-Tool »Virtual Center« nutzen, das virtuelle Systeme zur Laufzeit von einem physischen Server auf einen anderen verschieben kann.

Web: www.vmware.com/de

Preis: ESX-Server für 2 physische CPUs: 3750 Dollar. Ein »Virtual Node«, bestehend aus einer Lizenz für ESX, Virtual-Center-Agent, Virtual-SMP und VMotion kostet 5000 Dollar pro 2 physische Host-CPUs. Das vorgestellte Test-Setup kostet folglich: 20000 Dollar für acht CPUs, plus 5000 Dollar für den Virtual-Center-Management-Server.

Ein Administrator wird sich hüten, wechselnde Maschinen mit exklusiver Hardware zu verwenden, weil er dann keine Standard-Installationsimages hernehmen kann und ein riesiges Archiv an Treibern verwalten muss. Auch spielt die reine CPU-Performance eher eine untergeordnete Rolle, denn wirft man einen kritischen Blick auf die CPU-Loads von Standard-Servern mit den gerade genannten Diensten, finden sich selten Systeme die längerfristig mit mehr als 30 Prozent Auslastung arbeiten.

Die Vorteile virtualiserter Server liegen daher auf der Hand. Das zentrale Maschinen-Management liefert die virtuelle Plattform gleich mit. Eine große Maschine offeriert genügend Leistung für mehrere moderat ausgelastete Systeme, und wenn es bei einem Server zu Leistungsspitzen kommt, kann dieser auf bessere Leistungsreserven zurückgreifen als bei einem kleinen, dezidierten Server.

Ein Pionier der Virtualisierungstechnik auf der PC-Plattform ist Vmware. Die Wurzeln des Unternehmens liegen etliche Jahre in der Vergangenheit. Ursprünglich tüftelte Vmware an Virtualisierungstechniken im OS/2-Bereich. Schließlich nutzen diese Plattform hauptsächlich IBM-Kunden, die ohnehin mit virtuellen Systemen aus der Großrechnerwelt vertraut sind. Mit dem Verfall von OS/2 sattelte Vmware um auf den Windows und den Linux-Bereich. Die Vmware-Workstation erlaubt, auf einem Linux- oder Windows-PC parallel andere Betriebssysteme zu nutzen. Ein reguläres Betriebssystem als Host schränkt die Virtualsierungmöglichkeiten jedoch ein, besonders bei der Performance. Viel interessanter für den IT-Administrator ist daher der Vmware-ESX-Server. Diese Umgebung läuft physisch auf der Serverhardware und hat daher eine wesentlich bessere Kontrolle über die zur Verfügung stehenden Ressourcen. Die Software unterstützt Cluster mit mehreren Servern und erlaubt mit einem Zusatzprodukt namens »VMotion«, dass sich virtuelle Systeme zur Laufzeit von einem physischen ESX-Server auf einen anderen verschieben lassen.

Network Computing hat in den Real-World Labs eine Vmware-Serverfarm mit allem, was dazu gehört, aufgesetzt und über einen Zeitraum von sechs Monaten intensiv getestet. Nahezu alle seit Herbst 2004 veröffentlichten Tests von Betriebssystemen und Software fanden in virtuellen Maschinen dieses ESX-Clusters statt.

Virtuelle Umgebung booten

Anders als Microsofts »Virtual Server« oder dem Vmware »GSX-Server« startet der ESX-Server 2.5 direkt auf dem zu virtualisieren-den Server und verzichtet auf ein zu Grunde liegendes Standard-Betriebssystem. Der Rechner benötigt mindestens zwei LAN-Adapter, einen für die Management-Konsole und einen für die virtuellen Server. Zudem sollten zwei Storage-Controller, ebenfalls getrennt für virtuelle Maschinen und Konsole, zur Verfügung stehen. Vmware kann einen Storage-Controller aber auch beiden Welten zur Verfügung stellen.

Das Kernstück der Virtualisierung ist Vmwares ESX-Kernel. Dieses Betriebssystem setzt auf die physische Server-Hardware auf und virtualisiert den Bereich für verschiedene Gastsysteme. Als Operating System benötigt der ESX-Server eigene Treiber für die vorliegende Hardware. Das schränkt die möglichen Plattformen ein wenig ein, da der ESX-Server nicht alle auf dem Markt verfügbaren SCSI-, LAN- oder FC-Adapter unterstützt. Da bei regulären PC-Servern ohnehin nur zwei bis drei verschiedene Hersteller die Komponenten fertigen, kommt der ESX-Server mit fast allen handelsüblichen Server-Plattformen zurecht.

Der ESX-Server nutzt im Prinzip zwei OS-Instanzen. Ein auf Redhat basierendes Linux dient als Management-Konsole und als Loader für den eigentlichen ESX-Kern. Der Bootvorgang startet zunächst Linux und setzt dabei einen Vmware-eigenen Spezialtreiber ein, der Hardware ausblendet, die später nur Vmware zur Verfügung steht. Sobald das Linux läuft, startet Vmware einen eigenen Loader. Dieser prüft die vorliegende Hardware und Konfiguration und lädt den eigentlichen ESX-Kern. Die Linux-Maschine läuft parallel weiter, im Prinzip in der ersten virtuellen Maschine des Rechners. Für die Konfiguration und Wartung der Virtuellen Maschinen stellt Linux ein Web-Interface, FTP, SMB/CIFS-, NFS-Clients und eine Secure-Shell bereit. Zudem offeriert Vmware einen eigenen Management-Client für Windows oder Linux.

Die Installation des ESX-Servers richtet eine kleine ext3-Partition auf der ersten Platte ein, davon starten Vmware und Konsole. Dazu gibt es eine Swap-Partition. Später richtet der Amdinistrator noch ein Swap-File ein. Die Swap-Partition benötigen Linux- und ESX-Kern, das Swap-File dient als Puffer, falls den virtuellen Maschinen das physische RAM ausgeht. Weitere Platten des Vmware-Servers kann der Verwalter entweder direkt einzelnen Gastsystemen zuweisen oder mit dem Vmware-eigenen VMFS2-Dateisystem formatieren. Die Laufwerke virtueller Server bildet Vmware in diesem Fall als Datei innerhalb des VMFS2-Systems ab.

VMFS2 arbeitet als Cluster-fähiges Dateisystem. Es erlaubt, dass mehrere Vmware-Server im SAN gemeinsam auf VMFS2-Volumen arbeiten. Der Hersteller liefert für die Linux-Shell eine Reihe von Management-Tools für VMFS2-Volumen.

Für LAN-Zugriffe der Gastserver generiert Vmware virtuelle Switche, die wahlweise nur hostintern arbeiten, oder Verbindung zu einem physischen LAN-Adapter des Host-PCs erhalten. So kann der Verwalter komplette virtuelle LANs für Tests oder sicherheitsrelevante Bereiche einrichten oder die Maschinen über den virtuellen Switch in das produktive LAN einblenden.

Virtuelle Maschinen unter Vmware ESX-Server unterstützen bis zu 3,9 GByte Arbeitsspeicher, multiple virtuelle SCSI-Festplatten, IDE-CD-ROM-, Floppy-Laufwerke und LAN-Adapter. Zudem kann das System einzelnen Maschinen den Zugriff zu seriellen und parallelen Ports sowie einzelnen SCSI-IDs erlauben. Den Zugriff auf Floppy und CD-Laufwerke schaltet der Administrator entweder direkt auf die physischen Laufwerke, oder er lenkt diese in Dateien um. In der Regel nutzt Vmware ISO-Abbilder von CD-ROMs, um den Maschinen echte Laufwerke vorzugaukeln. Noch ein wenig Schwierigkeiten scheint Vmware allerdings mit ISO-Abbildern von DVDs zu haben – mal funktioniert’s, mal nicht. Auch die Port-Zugriffe auf parallele und serielle Schnittstellen lassen sich in Dateien oder Named-Pipes umleiten. Mit der Option Virtual-SMP generiert Vmware virtuelle Server mit Dual-CPUs. In kommenden Versionen des ESX-Servers will Vmware bis zu vier CPUs virtualisieren.

Network Computing richtet für den Test insgesamt drei ESX-2.5-Server ein. Ein Tyan »Transport TX46« nutzt vier Opteron-846-Prozessoren und 4 GByte RAM. Ein Dual-Opteron-Eigenbausystem baut auf dem Tyan-Motherboard »K8S Pro« auf und läuft mit zwei Opteron-248-CPUs und 4 GByte RAM. Zudem steht ein Intel-Barebone-Server mit dem Serverboard »SE7520JR2« bereit, den zwei 2,8-GHz-Xeon-CPUs mit 4 GByte RAM antreiben. Die Opteron-Systeme arbeiten dabei mit jeweils acht registered DDR-333-Modulen (Infineon) zu je 512 MByte. Im Intel-Server stecken vier 1-GByte-Kingston-Value-RAM-Module DDR-333. Die beiden Opteron-Server nutzen PCI-X-Fibre-Channel-Controller »LSI7202XP-LC« zur SAN-Anbindung (siehe Kasten) und verzichten auf lokale Platten. Der Intel-Server hingegen setzt einen Adaptec-Ultra-320-SCSI-Controller ein und adressiert darüber fünf externe SCSI-Laufwerke Seagate »ST3146854LC« mit 146 GByte Kapazität.

Die Installation verläuft – nach Konfiguration des SANs – bei allen drei Maschinen in etwa gleich ab. Der ESX-Server 2.5 startet die Installation von CD-ROM und setzt dafür das Redhat-Konfigurationstool »Anaconda« ein. Theoretisch unterstützt der ESX-Server das Hyper-Threading der Xeon-CPUs. Eine eigene Konfigurationsoption aktiviert diesen Dienst. Im Test funktioniert die HT-Option jedoch nicht. Mit eingeschaltetem HT hängt sich der ESX-Kernel beim Laden auf, während es ohne HT keine Probleme gibt.

Während der Installation fragt die Routine nach dem LAN-Adapter, der exklusiv dem Konsole-System zur Verfügung steht und dessen IP-Konfiguration. Beim Intel- und Transport-System baut Network Computing jeweils eine zusätzliche Intel-PCI-100-MBit/s-Karte für das Management-Interface ein, damit beide Gigabit-Ports den virtuellen Servern zur Verfügung stehen. Das K8S-Pro integriert ohnehin drei LAN-Adapter, zwei mit 1 GBit/s und einen mit 100 MBit/s. Die FC- und SCSI-Kanäle müssen sich die Konsole und die virtuellen Maschinen teilen. Je nach Zahl der simultan laufenden virtuellen Systeme benötigt die Management-Konsole zwischen 192 (acht Maschinen) und etwa 500 MByte RAM (unbegrenzt) reservierten Speichers. Abschließend legt der Verwalter das Root-Passwort und erste Benutzer fest. Nach dem Neustart steht das Admin-Web-Interface des Vmware-Servers bereit. Zunächst konfiguriert der Adminstrator hier das Swap-File, weitere Plattenressourcen und mindestens einen virtuellen Switch.

Dann lassen sich die ersten virtuellen Server einrichten. Um die ISO-Abbilder der System-CDs dem ESX-Server zur Verfügung zu stellen, stehen dem Verwalter verschiedene Möglichkeiten offen. Der ESX-Server selbst kann per NFS oder SMB/CIFS Freigaben anderer Windows/Linux-Server mounten. Je nach der gewählten Sicherheitsstufe des ESX-Servers lässt dieser auch eingehende Verbindungen via FTP oder SCP zu.

Ein simpler Web-Wizzard führt durch die Grundkonfiguration der Maschine. Zunächst fragt Vmware nach dem Namen und dem Typ des Systems. Unterstützt werden alle Windows-Varianten seit NT, BSD, Linux und Netware. Solaris x86 kann, aber muss nicht funktionieren und wird vom Hersteller (noch) nicht offiziell als Gastsystem unterstützt. OS/2 funktioniert auf keinen Fall. Nur für die offiziell unterstützten Gastsysteme liefert Vmware die »Vmware Tools«. Dieser Dienst arbeitet innerhalb der Maschine und kommuniziert mit dem ESX-Kern. Die Tools informieren den Host, wie viel RAM und CPU-Load die virtuelle Umgebung tatsächlich benötigt, und ermöglicht damit dem ESX-Server, die Ressourcen dynamsich anzupassen. Die Tools verwalten ferner Skripte, die auf dem Gastsystem ablaufen, ausgelöst von Events des Hosts.

Der Administrator kann bei der CPU-Last und der Netzwerkbanbreite Grenzen nach oben und unten setzen. Somit lassen sich virtuelle Maschinen priorisieren oder mit garantierten CPU-Lasten versehen.

Die Konfiguration der virtuellen Maschine legt der ESX-Server im Home-Verzeichnis des aktiven Anwenders ab. Nach System und Namen legt der Administrator die Zahl der CPUs – derzeit werden Single- und Dual-Konfigurationen für Linux oder Windows unterstützt – und die Größe des RAMs für die VM fest. Die Virtual-SMP-Option verschafft der virtuellen Maschine zwar mehr Rechenleistung, frisst dafür aber deutlich mehr Host-Ressourcen, auch zum Nachteil anderer VMs auf der gleichen Plattform. Zudem lassen sich Dual-CPU-VMs nicht ohne weiteres zwischen mehreren ESX-Servern mit unterschiedlicher CPU-Plattform hin- und herschieben. VMs mit Uni-Prozessor-Konfiguration laufen im Test sowohl auf der Opteron- als auch auf der Xeon-Plattform. Eine auf Xeon installierte VM lässt sich später problemlos auf einen Opteron-Server schieben oder kopieren und umgekehrt. Dual-CPU-Maschinen hingegen arbeiten in der Regel nur auf der Chip-Plattform, auf der sie installiert wurden.

Anschließend bekommt die Maschine eine oder mehr Festplatten. Dabei kann der Verwalter neue virtuelle Laufwerke in Form von Dateien innerhalb des VMFS2-Dateisystems anlegen, bestehende virtuelle Laufwerke übernehmen oder der VM den direkten Zugriff zu einer physischen LUN im SAN geben. Die Performance bleibt beim Zugriff einer VM auf eine physische LUN oder ein virtuelles Laufwerk innerhalb des VMFS2-Dateisystems in etwa gleich. Die Bandbreite begrenzt hier eher das SAN als die VMFS2-Performance. Im Test setzt Network Computing daher durch die Bank virtuelle Laufwerke innerhalb von VMFS2-Partitionen ein. Diese Laufwerke lassen sich dynamisch verwalten. Die VMFS2-Tools auf den Vmware-Server gestatten, bestehende virtuelle Laufwerke zu vergrößern. Das Gastsystem benötigt dann einen passenden Volume-Manager, der die Änderungen dem lokalen Dateisystem beibringt. Sollte ein Anwender bereits mit der Vmware-Workstation bis Version 4.x oder dem GSX-Server bis 3.x gearbeitet haben, kann er bestehende Laufwerksdateien auf ein ext3-Volumen des ESX-Servers kopieren und dann über die VMFS2-Tools in ein ESX-kompatibles Format konvertieren.

Soll ein Gastsystem Zugriff auf ein SCSI-Gerät wie ein Bandlaufwerk oder eine Tape-Library am ESX-Host erhalten, kann der Verwalter die SCSI-IDs in die Konfiguration einblenden. Auch das physische CD-Laufwerk des ESX-Servers darf virtuellen Maschinen zur Verfügung stehen. In der Praxis erweist es sich als schneller und komfortabler, ISO-Abbilder der wichtigsten System-CDs zu erstellen und diese Abbilder in die VMs einzubinden.

Für den Netzwerkzugriff offeriert Vmware zwei LAN-Adaptertypen. Einer davon »vmlance« simuliert eine AMD-Netzwerkkarte, die nahezu jedes Gastsystem ohne zusätzliche Treiber unterstützt. Schneller arbeitet der Kartentyp »vmxnet«, der allerdings einen besonderen Treiber im Gastsystem verlangt.

Virtuelle Maschine mit eigenem BIOS

Der Zugriff auf die virtuellen Server erfolgt über eine Vmware-eigene Konsole, welche das Admin-Interface zum Web-Download für Linux oder Windows anbietet. Diese Konsole verhält sich wie eine reguläre PC-Konsole. Beim Systemstart kann der Verwalter das BIOS-Setup der virtuellen Maschine aufrufen und hier typische Änderungen vornehmen. Das Gastsystem kann von LAN, CD-ROM, Floppy oder Festplatte starten.

Die Geschwindigkeit der Grafikausgabe variiert von System zu System. Ältere Linux-Versionen mit »XFree86-Server« oder Windows 2000 liefern eine flüssige Bildschirmwiedergabe. Distributionen mit »X.Org«-Server arbeiten stellenweise nur mit Einschränkungen, und bei Windows-2003-Servern ruckelt die Maus auch schon mal recht heftig. Die Vmware-Tools für das jeweilige Gastsystem enthalten passende Bildschirmtreiber und bei Windows auch LAN- und SCSI-Treiber. Dennoch hält sich die grafische Performance in Grenzen. Wer Windows-2003-Server unter Vmware betreibt, sollte diese bevorzugt über eine RDP-Konsole verwalten, da diese deutlich schneller arbeitet. Bei Linux-Servern empfehlen sich entsprechend SSH-Clients für den Text- und X-Server für den Grafikmodus. Die Vmware-eigene Konsole sollte nur für die Installation oder Verwaltungsaufgaben zum Einsatz kommen.

AMD vor Intel

Bei den Performancemessungen ergeben sich teilweise überraschende, teilweise erwartete Werte. Der ESX-Kern unterstützt Numa-Architekturen, und das nicht nur bei IBM-Servern mit »xScale«-Architektur oder vergleichbaren Großsystemen. Der Kern erkennt bei dem Quad-Opteron-System des Tests nicht vier CPUs mit insgesamt 4 GByte Arbeitsspeicher, sondern vier Prozessoren zu je 1 GByte RAM. Stecken alle RAM-Bausteine in den Sockeln der ersten CPU, funktionieren beim Quad-Opteron-Server zwar reguläre Betriebssysteme, aber nicht der ESX-Server. Dieser erwartet, dass jede CPU auf eigenen Speicher zugreifen kann. Mit dem auf vier CPUs verteilten Speicher stehen den virtuellen Systemen somit acht DDR-RAM-Kanäle zur Verfügung, der Dual-Opteron arbeitet mit vier Channels, während das Dual-Xeon-System mit dem zentralen MCH-Chip mit zwei Kanälen vorlieb nehmen muss.

Im regulären Laborbetrieb arbeiten dauerhaft zehn Server auf den zwei Opteron-Systemen. Vier Windows-2003-Server liefern Dienste wie Exchange-2003, Dateidienste, Anti-Virus, Domain-Controller, Backup-Domain-Controller und Infrastrukturdienste wie DNS und DHCP. Ein Windows-2000-Server arbeitet als Notes-Domino-6.5-, ein zweiter als SQL-2000-Server. Zudem läuft eine Netware 6.5 als Gast mit sowie seit einiger Zeit auch ein Novell-Open-Enterprise-Linux-Server, basierend auf Suse-Linux mit Netware-Diensten. Zwei Linux-Server für Web-Services und Remote-Installation runden die Serverfarm ab. Der Xeon-ESX-Server außerhalb des SANs verwaltet zwischen drei und zehn Windows- und Linux-Clients für Tests. Zudem betreibt Network Computing eine Serie weiterer Clients- und Server mit Linux oder Windows, die je nach anstehenden Tests zusätzlich zu den Infrastrukturmaschinen aktiv sind.

In der Regel arbeiten sechs Server auf dem Quad und vier auf dem Dual-Opteron-System. Die zwei ADS- und NDS-Systeme laufen dabei stets auf getrennter Hardware, um bei Ausfällen die Basisdienste weiter anbieten zu können. Bei geplanten Downtimes eines der beiden Opteron-Systeme übernimmt der zweite kurzfristig auch mal alle Server. Der Labor-Alltag mit rund zehn ständigen Clients generiert natürlich keine Anforderungen eines mittelgroßen oder gar großen Unternehmens. Alle drei ESX-Server operieren daher in der Regel mit CPU-Loads unter 10 und RAM-Auslastung unter 30 Prozent. Unter Stress-Bedingungen ändert sich das Bild ein wenig, die befürchteten dramatischen Performance-Einbrüche bleiben jedoch aus. Schwächen zeigt hier jedoch in erster Linie das Xeon-System, das bereits beim simultanen Start von vier Gästen die Performance einer bereits laufenden Maschine spürbar senkt. Weniger lassen sich hier die Opteron-Systeme beeindrucken, speziell das Vier-Wege-System lässt sich nur mit großem Aufwand in die Knie zwingen.

Um eine – zumindest grundlegende – Übersicht über die tatsächliche Leitung zu erhalten, hat Network Computing Benchmark-Tests in virtuellen Maschinen vorgenommen, und die Ergebnisse mit Werten physischer Server verglichen. Als Benchmark-Tool diente hierbei »Sandra 2005« von »Sisoftware« (www.jaggedonline.com). Für die Messungen generierte Network Computing zunächst eine virtuelle Maschine mit Windows-XP-Professional SP2, den aktuellsten Patches und der Sandra-Software. Mithilfe der Vmware-Tools klonte das Test-Team die Maschine elf Mal und verteilte sie auf die drei Server. Jeder ESX-Server betrieb somit vier XP-Clients zu je 256 MByte RAM mit einer virtuellen 8-GByte-Platte. Drei der vier Testsysteme bekamen nur eine CPU, während die vierte Maschine über Virtual-SMP zwei Prozessoren nutzen konnte.

Die CPU-Messungen übernahm Sandras Multimedia-Benchmark, der mehrere Threads einsetzt und daher von Dual-CPU-Umgebungen profitiert. Erstaunlicherweise zeigen die CPU-Benchmarks bei den Xeon-CPUs massive Unterschiede zwischen physischen Windows-Systemen im Vergleich zu virtuellen Bereichen. Eine virtuelle Maschine mit zwei 2,8 GHz CPUs schneidet hier rund 30 Prozent schwächer ab als ein physischer Server mit zwei 2,4-GHz-CPUs (ohne HT). Eine physische Opteron-Workstation mit einer CPU liefert dagegen die gleichen Ergebnisse wie Messungen in virtuellen Systemen mit jeweils einer CPU. Konfiguriert mit zwei Prozessoren, leistet das Opteron-Gastsystem dann den doppelten Wert des Single-Opteron-Systems. Das Dual-Opteron-System auf der Quad-Opteron-Maschine erreicht dann Leistungswerte, die einem physischen Dual-Xeon-System mit aktiviertem Hyper-Threading nahe kommen. Bei gleicher CPU-Zahl liefern die Opteron-Systeme fast die doppelte Performance im direkten Vergleich zu virtuellen Maschinen mit Xeon-CPUs. Dieser Leistungsunterschied zwischen Opteron und Xeon überrascht ebenso wie die Tatsache, dass VMs mit Xeon deutlich langsamer als physische Server arbeiten, während dies bei den Opterons nicht der Fall ist. Das erstaunt umso mehr, als das physische Xeon-System zwar mit dem gleichen Chipsatz wie der virtuelle Server, jedoch mit 2,4- statt 2,8-GHz-CPUs arbeitet.

Eine Ursache liegt voraussichtlich im Vmware-Kern selbst. Ab der Version 2.5 unterstützt der ESX-Server die 64-Bit-Erweiterungen des Opteron auf der Host-Seite, bietet die 64-Bit-Extensions aber noch nicht für Gastsysteme an. Jedoch kann Vmware die Erweiterungen für das systeminterne Speichermanagement nutzen. Bei der Testkonfiguration mit nur 4 GByte pro System dürfte das aber noch nicht so schwer ins Gewicht fallen. Ein dem Opteron ebenbürtigerer Gegner dürfte Intels neuer Xeon mit »EM64T« und dem schnelleren Lindenhurst-Chipsatz sein. Zum Startzeitpunkt des Vmware-Tests im Labor von Network Computing standen diese Systeme jedoch noch nicht zur Verfügung, und eine Vier-Wege-Konfiguration mit neuen Xeons gibt es derzeit noch nicht. Die Real-World Labs planen jedoch einen oder zwei der neuen Intel-Server in den laufenden Vmware-Cluster zu integrieren und deren Messwerte nachzureichen.

Die Benchmark-Messungen auf allen Plattformen bedienen sich der gemeinsamen Befehlssätze MMX, SSE und SSE2. Die Messungen können dabei nur grobe Anhaltspunkte für die Performance geben, da es sich um synthetische Benchmarks handelt. Die Messungen auf den virtuellen Plattformen schwanken dabei zudem um bis zu 10000 Instructions/s. Der Vmware ESX-Server passt sich dynamisch an die Last der Maschinen an und optimiert Speicher und CPU-Zugriffe, so dass bei wiederholten Messungen die Ergebnisse der virtuellen Rechner stärker steigen als bei physischen Systemen.

Eindeutig fallen die Messungen der Speicherbandbreite aus, und das war auch so zu erwarten. Während das Xeon-System mit einem dualen DDR-Speicherkontroller 2 GByte/s schafft, erreichen die Dual- und Quad-Opteron-Systeme 3 bis 4 GByte/s. Hier zeigen sich auch Leistungsschwächen und -stärken bei höher ausgelasteten ESX-Servern. Der Quad-Opteron-Server mit seinen acht Speicherkanälen zeigt sich wenig beeindruckt, wenn die I/O-Last im System steigt. Die Speicherbandbreite bleibt im Bereich zwischen 3 und 4 GByte/s. Das Dual-Opteron-System fällt auf 2 bis 3 GByte/s zurück, während der Dual-Xeon auf weniger als 1 GByte/s einbrechen kann.

Virtuelle Umzüge

Für ESX-Serverfarmen liefert Vmware ein Management-Tool namens Virtual-Center. Diese Software arbeitet auf einem externen Windows-Server mit SQL-Datenbank vor Ort oder auf einem weiteren Datenbank-Server. Das Virtual-Center stellt eine Verbindung zu allen ESX-Servern im LAN her und liefert eine zentrale Management-Plattform für alle Gastsysteme. Ein spezieller Virtual-Center-Client stellt von der Workstation des Administrators aus eine Verbindung zum VC-Server her. Diese Verbindung kann auch remote über einen VPN-Tunnel erfolgen. Der VC-Client liefert eine übersichtlichere und komfortablere Management-Oberfläche als das Web-Interface des jeweiligen ESX-Servers. Zudem integriert sich das Management-Tool in die Benutzerverwaltung eines Active-Directory und verwaltet damit Zugriffsrechte auf einzelne Maschinen oder Farmen virtueller Server.

Die Konfigurationen der Maschinen sichert VC in der SQL-Datenbank über ODBC. Mit VC kopiert der Administrator fertig konfigurierte virtuelle Maschinen in einen externen »Template«-Pool. Aus diesem Pool heraus lassen sich dann zügig neue Server als Klone der Templates erstellen. VC unterstützt dabei Windows-Deployment-Tools wie »Sysprep«, um Klone von Windows-Servern mit neuen System-IDs und Namen auszustatten. Neben ESX kann das Virtual-Center auch GSX-Server verwalten.

Als Option zum Virtual-Center 1.2 können Anwender eine Lizenz für »VMotion« erwerben. Dieses Zusatztool erlaubt dann, virtuelle Maschinen im laufenden Betrieb von einem physischen Vmware-Server zu einem anderen zu verschieben. Um das zu ermöglichen, müssen die physischen Server allerdings einen gemeinsamen Zugriff zu den VMFS2-Volumen mit den Plattenabbildern der Gastsysteme haben und über ein Gigabit-Ethernet-Link verbunden sein. Vmware empfiehlt ein dezidiertes Netzwerk für »VMotion«. Einfache Umgebungen mit zwei ESX-Servern kommen dabei noch ohne SAN-Switch aus.

Erste Tests führten die Real-World Labs mit zwei Servern durch, die über zwei FC-Loops ohne Switch an ein Nexsan »ATA-Beast« angebunden waren. Im weiteren Verlauf der Tests erweiterte Network Computing das SAN um einen 1-GBit/s-FC-Switch »Sphereon 3016« von McData und zwei weitere SAN-Speichersysteme: Eine »CX-500« von »EMC2« und ein »SATA-Blade« von Nexsan.

Vmotion erfüllt eine Reihe von Funktionen. Es kann abgeschaltete virtuelle Maschinen von einem ESX-Server auf einen anderen transportieren, ohne dass beide Maschinen Zugriff auf ein gemeinsames VMFS2-Volumen haben. Dabei können die ESX-Server mit unterschiedlichen CPU-Architekturen arbeiten, sofern sich die Gastsysteme automatisch daran anpassen. Im Test beförderte Network Computing verschiedene Windows- und Linux-Systeme von den Opteron-Servern mit SAN-Anbindung auf das Xeon-System mit lokalen Platten und zurück. Virtuelle Rechner mit Single-CPU-Konfiguration zogen dabei stets fehlerfrei um. Windows-Systeme mit Dual-CPU-Konfiguration überlebten den Umzug nicht immer.

Der Live-Umzug eines laufenden Systems klappte im Test stets ohne Probleme, mit Maschinen aller getesteten Gastsysteme. Vmotion führt dazu zunächst einen Snapshot des Speicherinhalts einer Gastmaschine aus und kopiert diesen Snapshot auf den ESX-Zielrechner. Danach friert es die VM auf dem Quellsystem für wenige Sekunden ein, gleicht die in der Zwischenzeit geänderten Daten mit dem Zielrechner ab. Der Zielrechner sendet derweil ein ARP-Update zum Ethernet-Switch, um den virtuellen LAN-Port des umziehenden Gastsystems auf seinen Port umzuschalten. Abschließend übergibt das Quellsystem den Zugriff auf das Plattenabbild innerhalb des VMFS2-Dateisystems an den Ziel-ESX-Server, und dieser taut die virtuelle Maschine wieder auf. Das Gastsystem selbst merkt nichts vom Umzug ebenso wenig wie Clients, die während des Umzugs mit der VM kommunizieren. Das kurze Einfrieren des virtuellen Bereichs bleibt in der Regel unter den Timeout-Zeiten der gängigen Netzwerkprotokolle. Auch verbindungsorientierte Protokolle wie FTP überstehen den Umzug.

Vereinzelt berichten Anwender, dass sie mit sehr hoch belasteten virtuellen Maschinen sowie der den VMotion-Prozess zum Erliegen bringen können. Im Labor ließ sich diese Blockade mit den vorliegenden Maschinen jedoch nicht nachvollziehen.

Das Virtual-Center überwacht die Zustände der einzelnen virtuellen Maschinen physischen Hosts und stellt deren Ressourcen-Nutzung grafisch dar. Ein Alarmsystem überwacht dabei definierbare Maschinenzustände. Über die in den VMs laufenden Vmware-Tools erhält das Virtual-Center einen Heartbeat. Stürzt eine Maschine ab, geht der Heartbeat-Status von Grün auf Gelb und nach einer gewissen Zeitspanne auf Rot. Zu jeder Status-Änderung kann der Administrator Aktionen festlegen, die Mails versenden, ein Skript ausführen oder die Maschine neu starten. Richtig mächtige Aktionen muss sich der Administrator allerdings selbst schreiben. Eine Power-Aktion wie: »Beim Absturz des ESX-Server 1 bitte alle zu diesem Zeitpunkt aktiven VMs auf ESX 2 starten« fehlt in der Grundausstattung. Solche Failover-Optionen für VM-Umgebungen liefern Drittanbieter als externe Tools.

Info

So testete Network Computing

Für die ersten Tests richtete Network Computing im Labor zunächst einen Dual-Opteron-248-Server »K8S Pro« mit lokalen SCSI-Laufwerken, 4 GByte RAM und dem ESX-Server 2.1.2 ein. Nach ersten Erfahrungen mit virtuellen Maschinen, dem Web-Interface und der Vmware-Konsole erweiterte die Labor-Crew den Bereich mit dem Quad-Opteron-846-Server »TX46« mit 4 GByte RAM und dem »ATA-Beast« von Nexsan als SAN-Speicher. Als FC-Kontroller setzte Network Computing ausschließlich PCI-X-Adapter »LSI7202XP-LC« oder »LSI7102XP-LC« von LSI Logic ein. Der SQL-Server-2000 des Labors, ein Dell »Poweredge 2650« mit zwei Xeon-CPUs unter Windows-2003-Standard Edition, erhielt das Virtual-Center 1.1 und Vmotion für das Maschinen-Management. Kurz darauf folgte der Dual-Xeon-Server von Intel mit lokalen SCSI-Platten. Da diese Maschine eine andere CPU-Architektur verwendete, konnte sie problemlos ohne SAN-Anbindung mitarbeiten, denn zur Laufzeit lassen sich keine Gastsysteme vom Opteron auf den Xeon schieben, wohl aber im abgeschalteten Zustand.

Alle drei Server waren mit je drei LAN-Adaptern ausgerüstet, einer 100-MBit/s-Karte für das Management-Interface und zwei 1-GBit/s-Adaptern für die Netzanbindung der virtuellen Maschinen. Der Dual-Xeon hing mit einem dieser Interfaces im produktiven Netzwerk, mit dem zweiten Controller in der DMZ. So ließen sich komfortabel Test-Server für Mail- und Webdienste im internen Netzwerk aufsetzen und später per Mausklick in die DMZ umschalten, um sie im Internet zur Verfügung stellen.

Die Umstellung des SANs von der simplen Dual-Loop-Architektur auf switched mit dem »Sphereon 3016« von McData bracht die ersten Schwierigkeiten. Im switched SAN wollte das Nexsan ATA-Beast nicht fehlerfrei mit dem ESX-Server 2.1.2 zusammenarbeiten. Auf manche LUNs konnten die ESX-Server zugreifen, andere sperrten sich.

Ohne Probleme funktionierte das Speichersystem »CX 500« von »EMC2«. Dieses Testgerät kam mit 30 FC-Laufwerken zu 146 GByte und weiteren 30 ATA-Laufwerken zu je 320 GByte Kapazität. Network Computing generierte auf der CX 500 zunächst eine Reihe kleiner LUNs mit 16 und 32 Gbyte, die auf RAID-1-gespiegelten FC-Laufwerken lagen. Diese schnellen und sicheren LUNs dienten verschiedenen Testsystemen und den ESX-Servern als Startlaufwerk und ließen sich bei Bedarf als physische LUNs beim ESX-Server einblenden. Dazu kam eine Reihe von RAID-5-LUNs auf FC- und ATA-Laufwerken. Diese Laufwerke wies Network Computing beiden ESX-Servern zu und ließ sie mit VMFS2 formatieren. Wichtige virtuelle Platten wie Startlaufwerke der Server lagen dabei auf FC-LUNs, während weniger relevante Daten und Testlaufwerke mit den ATA-Arrays vorlieb nehmen mussten.

Im Lauf der Tests sandte Vmware das Produkt-Update »ESX 2.5« mit Virtual-Center 1.2. Zunächst stellte Network Computing den Management-Server und Client um, und dann nacheinander alle drei Server.

Abschließend fügte Network Computing noch das »SATA Blade« von Nexsan in das SAN ein und stellte es den ESX-Servern zur Verfügung. Anders als das ATA-Beast am Beginn des Tests ließen sich die LUNs des SATA-Blade sofort von den ESX-Servern ansprechen.

Im Verlauf der Tests kam es zu keinen Ausfällen oder Abstürzen der physischen Server, von provozierten Störungen abgesehen. Auch die virtuellen Systeme liefen nahezu ohne Aussetzer. Lediglich der Netware- und der Exchange-Server hängten sich aus ungeklärten Gründen ein- bis zweimal im Testzeitraum auf. Für den einzigen Totalausfall des Testbereichs sorgte der »Sphereon 3016«. Bei Wartungsarbeiten kappte ein Labor-Mitarbeiter versehentlich beide Stromzuführungen und schoss damit auf einen Schlag alle laufenden VMs ab – die sich aber sämtlich ohne Datenverluste erholten.

Fazit

Anfangs sah man Vmware als eine praktische Plattform für Softwaretests und plattformübergreifende Entwicklungen an. Eine leistungsfähige Umgebung wie der ESX-Server tritt jedoch als komfortable Konsolidierungs-Plattform für produktive Serversysteme auf. Der Installationsaufwand und die Treiberpflege fallen fast vollständig aus, da alle VMs intern gleich aussehen. Alle Funktionen lassen sich remote erledigen, ohne dass jemand echte CDs in Laufwerke legen müsste. Vmware abstrahiert zudem die Eigenheiten der physischen Hardware und deren mögliche Inkompatibilitäten zu Gastsystemen. Diverse Anwender trennen sich beispielsweise nach wie vor nicht von ihren NT-4-Servern, die auf moderner Serverhardware jedoch gar nicht mehr laufen.

Als Gastsysteme unter Vmware gibt es hingegen keine Probleme, und ein zeitgemäßer Standard-Server mit zwei Prozessoren und 2 bis 4 GByte Arbeitsspeicher kann locker vier bis acht NT-4-Server bedienen. Über das Virtual-Center und Vmotion fallen zudem geplante Downtimes produktiver Server weg. Soll ein physischer Server umgebaut werden, schiebt man einfach die VMs temporär auf ein anderes System, ohne dass Server und Clients davon etwas merken.

Natürlich ist Vmware nicht die eierlegende Wollmilchsau, die sämtliche Server aller Couleur beherbergen kann. Maschinen mit vielen externen I/O-Verbindungen sind besser auf physischen Plattformen aufgehoben, ebenso wie Server mit permanent hoher CPU- und Speicherauslastung. Mittelgroße und große Datenbankerver sollten also weiterhin auf dezidierten SMP-Maschinen mit eigener Storage-Anbindung und viel RAM bleiben. Die »üblichen Verdächtigen« wie kleine bis mittelgroße Mailserver, Infrastrukturmaschinen, Web- und einfache File-Server laufen jedoch hervorragend unter Vmware. Bei der Planung der Infrastruktur sollten Administratoren folglich den Ressourcenbedarf ihrer Server über einen längeren Zeitraum messen. Alles, was längerfristig unter 50 Prozent CPU- und Speicherauslastung herumdümpelt, lässt sich problemlos in virtuellen Umgebungen betreiben. Vmware liefert für Umsteiger ein gesondertes Tool Namens »P2V-Assistant«. Diese Software konvertiert einen physischen Server in eine virtuelle Maschine für ESX- oder GSX-Server.

Nach den bisherigen Erfahrungen in den Real-World Labs von Network Computing eignet sich die AMD Opteron-CPU als Hardware-Basis für virtuelle Server besser als Intels Xeon. Der wesentliche Vorteil der Plattform liegt dabei weniger bei der schieren Rechenkraft als bei der dezentralen RAM-Verwaltung. Noch fehlen Testergebnisse der neuen Xeon-CPUs mit EM64T. Allerdings skalieren diese Systeme vorerst nur bis zwei CPUs.

Eine gute und im Test solide Plattform ist der Vier-Wege-Opteron. In der von Network Computing verwendeten Konfiguration kostet ein 2-HE-Rackmount-System mit vier CPUs vom Typ 846 und 4 GByte RAM knappe 7000 Euro Straßenpreis (ohne Platten). Für das gleiche Geld gibt es mit Intel-Architektur nur ein Zwei-Wege-System. Eine stabilere Quad-Opteron-Plattform mit Hot-Swap-Netzteilen, schnelleren 252-CPUs und 8 GByte RAM liegt dann im Bereich um 15000 Euro und ersetzt 8 bis 16 herkömmliche Server. [ ast ]