© kozinia, 123RF

Auf dem Markt für virtualisierte Standardserver agieren VMware und Citrix auf Augenhöhe. Seit Kurzem führen beide Spieler neue Versionen ins Feld, um den Gegner in Schach zu halten. Der folgende Artikel stellt beide Produkte gegenüber und bewertet insbesondere die Strategien bei HA und Monitoring.

Laut der Analyse [1] halten VMware und Citrix drei Viertel des deutschen Hypervisor-Markts (siehe Abbildung 1). Seit Sommer 2011 zieht die Version Vsphere 5 [2] aus dem Hause VMware in die Serverracks ein. Mitten in die Recherchen zu diesem Artikel platzte passenderweise Citrix mit der Veröffentlichung von Xen Server 6.0 [3]. Damit stehen die Kunden vor der Qual der Wahl – der Artikel soll ihnen beim Sondieren helfen.

Gern hätte die Redaktion das Marktaußenseiter-Produkt Red Hat Enterprise Virtualization [4] in der kommenden Version 3 in den Test aufgenommen. Die Rothüte waren Apple-artig aber auch nach internen Konsilien nicht bereit, den laufenden Betatest für die Presse zu öffnen.

Zurück zum Marktführer: Konnten VMware-Kunden bei Vsphere 4 pro CPU-Sockel noch – je nach Lizenzmodell – sechs oder zwölf Cores betreiben, führt Vsphere 5 ein neues Modell ein, das sowohl auf CPU-Sockel als auch auf den so genannten VRAMs fußt. Das Lizenzkonstrukt VRAM errechnet sich aus den aktiven virtuellen Maschinen (VMs) und deren zugeordnetem RAM. Kunden einer Enterprise-Lizenz hätten beispielsweise maximal 32 GByte RAM pro CPU-Sockel einsetzen dürfen (siehe Tabelle 1, Spalte “Alt”). Wer die Schwelle überschreitet, muss Sockel-Lizenzen nachordern. Da offenbar wichtige Kunden gegen das neue Modell ins Feld zogen, revidierte VMware die Pläne [5] und hob die VRAM-Limits an (Tabelle 1, Spalte “Neu”).

Abbildung 1: Anteile am deutschen Markt primärer Hypervisors. (Quelle: [1])

Limits fallen

Zur Technik: Xen Server 6.0, der auf Xen 4.1 basiert, ist in der Lage, einer Virtual Machine 128 GByte RAM und 16 virtuelle CPUs bereitzustellen [6]. Vsphere 5 kann einer Instanz laut VMware maximal 32 virtuelle CPUs und 1 TByte RAM [7] zuordnen – das Vierfache gegenüber dem Vorgänger.

Steht die Migration von einer 4er Version auf Vsphere 5 an, so ist ein Update der jeweiligen virtuellen Maschine zwar keine Pflicht für den Admin, wird aber nötig, wenn er in den Genuss der neuen Funktionen und der VM-Hardware-Version 8 kommen will – beispielsweise UEFI oder USB 3.0. Die Umstellung erfolgt analog zu der früheren Migration: Backup der VM, Installation der aktuellen VMware-Tools, Shutdown der VM, Rechtsklick auf die VM und »Upgrade Virtual Hardware« , einschalten und testen.

Mit Vsphere 5 gelingt es VMware, auch Apple-Serverbetriebssysteme als virtuelle Maschinen zu betreiben. Offiziell unterstützt VMware Mac OS X 10.6 Server. Voraussetzung ist eine VM mit EFI, da Apple seine Hardwaresysteme seit Langem nur mit EFI ausliefert.

Die Version 8 von VM Hardware bietet erstmals eine Grafik-3-D-Beschleunigung. Sie unterstützt die Aero-Funktionalität virtueller Windows-Systeme. Citrix geht einen Schritt weiter und unterstützt offiziell GPU-Passthrough, das direkte Zuordnen physikalischer Grafikkarten zu einer virtuellen Maschine. Des Weiteren stockt Xen Server 6.0 den Gastsupport um sieben Betriebssysteme auf.

Mit Xen Server 6.0 und Vsphere 5 erweitern beide Hersteller die Partitionsgrößen für virtuelle Maschinen von 2 TByte auf bis zu 64 TByte (VMware). Jedoch lassen sich weiterhin virtuelle Festplatten nur bis 2 TByte anlegen [8].

Als wichtige Neuerung entfernt VMware den ESX Server aus dem Portfolio. Den so genannte Gold-Standard bedient ab sofort der ESXi Server. Er bietet ein schlankes System, das problemlos auf einem USB-Stick oder einer SD-Karte installierbar ist. VMware verspricht sich eine einfachere Updatepolitik, da nicht zwei Server, ESX und ESXi, zu pflegen sind. Citrix bietet weiterhin mit dem schlanken Xen Server ein Hypervisor-Produkt an.

Hochverfügbarkeit

Clusterdienste wie VMware HA hat der Hersteller für Vsphere 5 komplett neu geschrieben. Ein isolierter Host sorgte beispielsweise im Falle eines Netzwerkausfalls in der Vergangenheit nämlich für Probleme: Er unterbrach die Erreichbarkeit von ESX Server und damit die Kommunikation mit anderen Clustermitgliedern. Das sorgte je nach Cluster-Einrichtung für einen ungewollten Shutdown der virtuellem Maschine.

Um dem vorzubeugen, bietet VMware nun die Funktion an, den Cluster-Heartbeat auf Storage-Ebene einzusetzen. Voraussetzung hierfür sind allerdings zwei VMFS-Datastores (ESX-Vsphere-spezifische Dateisysteme, in denen die VMDK-Containerdateien der Gastsysteme liegen, [9]). So sind die ESXi Server in der Lage, im Falle eines Netzwerkausfalls auf der separaten I-SCSI- oder Fibre-Channel-SAN-Infrastruktur weiterhin zu kommunizieren.

Damit gewinnt der Admin an Sicherheit, da das Setup die Kommunikation auf zwei unabhängigen Wegen garantiert. Außerdem ändert Vsphere 5 das Clusterkonzept vom Primary-Secondary- in ein Master-Slave-Konzept, bei dem der erste ESXi Server die Master-, jedes weitere Clustermitglied die Slave-Rolle zugeordnet bekommt [10].

Die neue Version hält jetzt alle HA-Aktivitäten in einer einzigen Logdatei fest – jedes Clustermitglied schreibt im »/var/log/fdm.log« des Fault-Domain-Managers die gesamte Kommunikation nieder. VMwares Hochverfügbarkeit arbeitet nun auf Basis von IP-Adressen und nicht mit DNS-Namen. Zuvor ließ bei jedem DNS-Ausfall der Crash des HA-Clusters nicht lange auf sich warten, wenn der Admin die DNS-Einträge der Clustermitglieder nicht vorsorglich in die »/etc/hosts« aller ESX(i) Server eingetragen hatte.

Citrix verfolgte schon früher den Ansatz der Quorum-Disk. Dabei legt Xen Server eine virtuelle Disk an, die so genannte Shared Quorum Disc, die jeder physikalische Xen-Server verwendet, um über seinen Status zu informieren. Anders als beim ESXi Server, der den SAN-Weg nur als Backup benutzt, setzt Citrix auf beide Wege. Hier kommunizieren alle Clustermitglieder immer gleichzeitig via LAN und SAN. Mit Version 6.0 kann Citrix die Heartbeat-Kommunikation außerdem über einen NFS-Server abwickeln.

Storage DRS

Eine neue Funktion, die das Portfolio an Clusterdiensten von VMware ergänzt und ab der “Enterprise Plus”-Ausgabe dazugehört, ist der Storage Distributed Resource Scheduler. SDRS verschiebt auf SAN-Ebene virtuelle Systeme automatisiert. Das Migrieren einer VM auf Plattenebene erfolgt beispielsweise bei schlechten Latenzwerten, um bestimmte Plattenbereiche zu entlasten. Es gewährleistet darüber hinaus, dass die VMFS-Partition stets einen festgelegten Füllstand einhält (siehe Abbildung 2).

Interessant ist Storage DRS für Systeme mit hoher Performance, die unter keinen Umständen Latenzprobleme bereiten dürfen. Je mehr virtuelle Systeme auf einem Plattenbereich agieren, desto mehr wachsen dessen Latenzwerte. Steigt nun beispielsweise bei einer LUN auf SATA-Festplatten die I/O-Latenz an, da zu viel Traffic darauf lastet, so verschiebt Vsphere VMs von einer LUN auf eine SAS- oder SSD-LUN, die dem I/O-Bedarf gerecht wird.

Abbildung 2: Vsphere 5 lässt sich so konfigurieren, dass der Storage Distributed Resource Scheduler automatisch die virtuellen Maschinen einer überlasteten LUN migriert.

Wann umverteilen?

Bis auf HA nutzten alle Vsphere-5-Komponenten im Betrieb das Vcenter. So ist etwa DRS für die dynamische Lastverteilung abhängig von dessen Funktionieren. Ist es als Dienst nicht erreichbar, fällt das dynamische Verteilen der virtuellen Maschinen flach – und damit das kontrollierte Auslasten der ESXi Server.

Xen Server 6.0 verfolgt eine andere Strategie: Eine Virtual Appliance, die Citrix auf Basis eines Linux-Systems bereitstellt, verteilt pro eingerichtetem Pool die virtuellen Systeme dynamisch. Vorteil: Ist das Xen Center mal nicht erreichbar, bleibt diese virtuelle Appliance in Kontakt mit allen im Pool eingerichteten Xen Servern, was weiterhin die dynamische Verteilung virtueller Systeme gewährleistet. Das von Citrix Workload Balancing getaufte Verfahren benötigt eine dedizierte Appliance pro eingerichtetem Pool.

Sowohl VMware als auch Citrix haben ihre Switch-Technik überarbeitet, um den Datenverkehr besser zu steuern. VMware optimiert den Distributed Switch durch den Switched Port Analyzer (SPAN, eine offenbar von Cisco übernommene Terminologie) und das Link Layer Discovery Protocol (LLDP), was sowohl bei der Fehlerbehebung als auch der Überwachung hilfreich sein soll. Citrix hat das bis zur Version 5.6 eingesetzte Linux-Bridging durch das Produkt Open Vswitch abgelöst, um das NIC-Bonding (zwei Network Interface Cards teilen sich eine MAC-Adresse und ein Device) zu verbessern.

Die Management-Zentralen

Alle großen Virtualisierungslandschaften erfordern eine zentrale Monitoring- und Management-Plattform. Sowohl Vcenter als auch Xen Center bieten die Möglichkeit, mehrere ESX beziehungsweise Xen Server samt ihren virtuellen Systemen zu administrieren. VMware sah als Basis für die Managementplattform aller Versionen vor Vsphere 5 ein Windows-Betriebssystem vor. Mit Vsphere 5 führen die Amerikaner nun alternativ ein Vcenter als Virtual Appliance ein, die SLES 11 SP1 in der 64-Bit-Variante als Unterlage benutzt (Abbildung 3).

Wenige Handgriffen genügen, um das aufgesetzte System einer Vsphere-Umgebung hinzuzufügen. Innerhalb von Minuten steht es bereit und der Admin ist in der Lage, ESX(i) und die virtuellen Maschinen zu administrieren. Es deutet einiges darauf hin, dass VMware künftig die Vcenter-Lösung mit Linux-Appliance vorziehen wird und die Windows-Variante vielleicht gänzlich abschafft. Anders Xen Server 6: Der braucht weiterhin ein Windows-Betriebssystem.

Fürs Anmelden an beiden Lösungen benötigt der Admin weiterhin einen Windows-Client. VMware hat dies offenbar als Problem identifiziert und wertet seinen Webclient auf. So ist der neue in der Lage, ESX(i) Server in den Wartungsmodus zu setzen und per Drag&Drop Migrationen auf Basis von Vmotion zu absolvieren. Damit eignet sich der Webclient etwa für Administrationsarbeiten in der Cloud, die Kunden virtueller Systeme selbst via Web erledigen sollen.

Abbildung 3: VMware Vcenter als Virtual Appliance mit Suse Linux Enterprise Server 11.

Monitoring

Sowohl Xen Center als auch Vcenter bieten dem Admin an, die eingesetzten Systeme zu überwachen, beispielsweise die Gesamtauslastung von CPU, RAM, Netzwerk und Festplatte aufzurufen. Wer nachvollziehen will, wie groß der Bedarf an Ressourcen der letzten Zeit gewesen ist – vielleicht auch, um die Ressourcen für die Zukunft und Aufrüstungen planen zu können –, greift zu der Performance-Anzeige in Form von Graphen (Abbildung 4). Die zeigt den Ablauf in Echtzeit oder tage-, wochen-, monatsweise oder aufgeteilt in Jahre.

Abbildung 4: Graphen zeichnen den Verlauf der Ressourcennutzung beim Xen Server nach.

VMware Vcenter hat eine Reihe vordefinierter Alarme eingerichtet (Abbildung 5). So kann das System bei Ausfall eines ESX(i) Server per SNMP-Trap oder E-Mail Alarm schlagen, damit der Admin schnellstmöglich den Fehler beheben kann. Darüber hinaus protokolliert Vsphere alle Events und manuell durchgeführten Tasks – das ist Gold wert für jeden Systemverwalter, der Ungereimtheiten zu analysieren hat.

Abbildung 5: In VMwares Vcenter verwaltet der Admin vordefinierte und eigene Alarme.

Eines trübt das heile Bild in Sachen VMware-Überwachung: Gestattete es die ESX-Plattform dem Admin noch, RPM-Pakete auf dem Hostsystem zu installieren, um Überwachungsagenten des jeweiligen Hardwareherstellers einzurichten, versagt ein ESXi Server ohne Vcenter dem Admin dieses Vorgehen. Der Weg, um die Firmware eines ESXi nachträglich anzupassen, führt künftig nur über den VMware Update Manager. Der verteilt via Vcenter die so genannten Extensions auf die ESXi. Dann installiert der Admin eine virtuelle Appliance, die sich auf das Monitoring beispielsweise der Hardwaresensoren konzentriert.

Wenn zum Beispiel eine Festplatte im Raid-Verbund ausfällt, ist diese Appliance des Serverherstellers in der Lage, die Hardware auszulesen und ein SNMP-Trap oder eine E-Mail an den Admin zu versenden. Weitere besondere Alarme des Hardwareherstellers ergänzen die von VMware ursprünglich angelegten. Serverhersteller bieten Xen Server auch als angepasste Version an. Damit installiert der Admin den Xen Server mit Agenten auf einen Rutsch. Anschließend nimmt er diesen in seine vorhandene Überwachungssoftware auf.

Wettkampfwertung

VMware und Citrix haben ihre neuen Produkte durchaus mit interessanten Features ausgestattet – zum Wohle der zahlungsbereiten Kundschaft. Mit Blick auf Vsphere 5 stellt sich aber langsam die technische Frage, ob ein einziger Backendserver zum Management noch zeitgemäß ist, denn bei Vcenter ballen sich die Abhängigkeiten. Citrix verfolgt mit dem Clustered Management Layer wohl den aussichtsreicheren Weg, er stellt viele Funktionen als Virtual Appliances bereit, zum Beispiel Workload Balancing und Vswitch Controller.

Vsphere 5 beginnt mit Vcenter als virtueller Linux-Appliance aber die offene Flanke zu decken. Gleichwohl verfolgen beide Lösungen des Systemmanagements aber eine zögerliche Linux-Strategie, da viele Funktionen nur mit dem Vsphere- beziehungsweise Xen-Center-Client für Windows nutzbar sind. Wie das angekündigte RHEV 3.0 wohl aussehen und ob damit ein dritter König oder ein Opfer-Bauer das Spielfeld betreten wird, weiß zurzeit nur Red Hat. (jk)