© kasim1, 123RF.com

Werkzeuge zum Verwalten von Cloud-Infrastrukturen unterstützen nahezu jeden Hypervisor. Auch wer “einfach nur virtualisieren” möchte, kann – Libvirt sei Dank – nahezu frei wählen. Ein Test mit einer Compile-Farm zeigt, dass es doch noch Unterschiede in der Leistungsfähigkeit gibt.

Die eigene Rechnerfarm zu bauen erfordert einige Vorarbeit. An Virtualisierung geht fast selbstverständlich kein Weg mehr vorbei, doch bereits die ersten Recherchen in den Feature-Listen hinterlassen Admins gern ratlos. Bei der Wahl des richtigen Hypervisors sind die wenig hilfreich, denn welcher der richtige für den geplanten Zweck ist, ergibt sich oft nur mehr aus ausgiebigen Tests.

Zusammengerückt: Hypervisoren und Cloudmanager

In den Funktionen immer ähnlicher, durch Hilfsmittel wie die Libvirt vereinheitlicht, buhlt eine beachtliche Anzahl von Virtualisierungslösungen um die Gunst der Admins, um in Cloudinstallationen oder einfach “klassisch” eingesetzt zu werden. Dass es sich lohnen kann, selbst bei einer einfachen Problemstellung nicht einfach blind der erstbesten Lösung sein Adminherz zu schenken, zeigt der folgende Artikel, der sich Xen, KVM, VMwares ESXi und Virtualbox vornimmt.

Alles an Bord, überall

Fast alle Hypervisoren bringen für den Rechenzentrumsbetrieb nötige Basistechnologien wie Live-Migration mit, die es ermöglicht, aktive virtuelle Maschinen im laufenden Betrieb von einem Hostsystem annähernd unterbrechungsfrei auf ein anderes umzuziehen. Das ist komfortabel, wenn der Admin Hardwarewartungen durchführen oder aus Stromspargründen Hosts an- oder abschalten möchte. Bestenfalls gelingt das sogar automatisch, wenn der Cloudmanager Maschinen eigenständig und bedarfsorientiert nach einer Policy an- und ausschaltet.

Diese Live-Migration, die vor wenigen Jahren noch ein Herausstellungsmerkmal von VMware war [1], bringt heute selbst der eigentlich auf dem Desktop angesiedelte Virtualisierer Virtualbox mit. Unterstützung für eine breite Auswahl an 32- und 64-Bit Betriebssystemen, entsprechende Virtualisierungsflags, das Ausnutzen mehrerer Prozessoren und jeder Menge Arbeitsspeicher gehören inzwischen zur Selbstverständlichkeit für alle Kontrahenten.

Auch ein Durchreichen von PCI-Geräten wie Grafikkarten in die virtuelle Maschine ermöglichen heute die meisten Systeme [2]. Selbst wer nicht nur auf x86-Architekturen setzt, hat bald die Wahl: KVM arbeitet an einem ARM-Port [3], um Xen Paroli bieten zu können, das da schon ein wenig weiter ist (Abbildungen 1 und 2)

Abbildung 1: KVM hat sich schnell viele Freunde gemacht. Praktisch jede Distribution unterstützt es.

Abbildung 2: Der Citrix Xen Server bietet eine leistungsfähige und quelloffene Virtualisierungslösung mit einer leistungsfähigen Managementoberfläche.

Alleinstellungsmerkmale?

Die unterschiedlichen Hypervisoren sind sich in vielen Optionen sowie beim Leistungsumfang in den letzten Jahren immer ähnlicher geworden, sodass ihnen langsam die Alleinstellungsmerkmale ausgehen. Hinzu kommt, dass sie praktisch alle unter der Libvirt [4] friedlich vereint werkeln. Für den Systemverwalter bedeutet dies, dass er sich nicht mehr mit der Syntax der einzelnen Hypervisor-spezifischen Adminbefehle herumschlagen muss, weil die Libvirt die Eigenheiten der einzelnen Lösungen abstrahiert. Er kann einheitliche Libvirt-Werkzeuge wie die Virsh (Abbildung 3) oder den Virt-manager (Abbildung 4) einsetzen oder dank geeigneter APIs eigene Lösungen implementieren.

Abbildung 3: »virsh«, das auf Libvirt aufbauende CLI für die Verwaltung von virtuellen Maschinen, beherrscht viele Hypervisoren.

Abbildung 4: Der Virt-manager verwaltet KVM und Xen in einer einfachen grafischen Oberfläche.

Auch die gängigen Cloudmanager, also Werkzeuge wie Open Stack [5] oder Open Nebula [6], unterstützen so auf Linux praktisch jeden Virtualisierer, durch entsprechende Erweiterungen sogar den in reinen Linux-Umgebungen exotischen Hyper-V von Microsoft [7].

Virtuelle Buildfarm

Aber trotz dieser Abstraktionsstufen ist es keine gute Idee, die Entscheidung für den einen oder anderen Hypervisor leichtfertig zu treffen. Das zeigt sich gut am folgenden Beispiel der Evaluierung des Hypervisors für eine virtualisierte Buildplattform. Für ein fiktives Softwarehaus, das regelmäßige, umfangreiche Compilejobs ausführen muss, wie sie auch bei Nightly Builds im Zuge von Continous Integration immer populärer werden, soll eine Virtualisierungsumgebung her.

Das Ziel ist quasi eine private Cloud, deren Hauptaufgabe das Hantieren mit Compiler, Buildwerkzeugen und Quelltextarchiven sein wird. Die Anforderungen an eine solche virtuelle Buildfarm gestalten sich übersichtlich: die Unterstützung mehrerer 32- und 64-Bit-Linux-Distributionen unterschiedlicher Versionen, administrierbar an der Kommandozeile und mit einem grafischen Frontend.

Funktionen wie das Durchreichen von PCI-Geräten stehen hingegen nicht auf der Agenda, die Live-Migration dagegen ist erwünscht. Die Anforderungen an die virtuellen Maschinen zeichnen sich durch moderaten Ressourcen-Bedarf an RAM, CPU und I/O-Durchsatz aus und entsprechen dem, was Admins häufig für Infrastrukturdienste zur Verfügung stellen müssen.

Kandidaten

Die Wahl fiel auf die üblichen Verdächtigen: Xen, KVM und VMware ESXi – allesamt regelmäßige Gäste im Linux-Magazin ([8], [9], [10]). Als funktionsreichen Exoten nahmen die Tester auch Virtualbox (Abbildung 5) mit ins Testfeld auf, auch weil der beliebte Desktopvirtualisierer auf dem Papier die gestellten Anforderungen zu erfüllen verspricht. Mangels Linux-Bezug und Linux-Integration blieb Microsofts Hyper-V aber außen vor.

Abbildung 5: Auf dem Server zwar nicht erste Wahl, bietet Virtualbox auf dem Desktop eine freie Lösung zur Virtualisierung einer breiten Auswahl an Gastsystemen.

Die Gastsysteme und mit Ausnahme von VMwares ESXi auch die Hostsysteme haben die Tester mit dem Cent-OS-Klon des im Unternehmenseinsatz weit verbreiteten Red Hat Enterprise Linux sowie dem mit aktuelleren Paketen ausgelieferten Open Suse installiert. Die Versionen der eingesetzten Komponenten sind im Kasten “Versionsstände” verzeichnet. Das virtuelle Gastsystem war, außer beim ESXi-Hypervisor, jeweils gleich dem Hostsystem.

Da im Vordergrund der Betrachtung die Leistung der einzelnen Virtualisierungslösungen stand, wurden die Systeme möglichst minimal installiert. Die Tester führten also eine kleinstmögliche Basisinstallation ohne grafische Oberfläche und Zusatzdienste durch und installierten die für die Compile-Umgebung notwendigen Pakete und Abhängigkeiten nach. Auf mögliche Optimierungen haben die Tester verzichtet, da sich die Konfiguration möglichst nah an dem bewegen sollte, was die Distributoren ausliefern und an Voreinstellungen vorsehen.

Software für Host und Gast

Dies bedingt, dass die Pakete so weit wie möglich aus den Repositories der Distributoren stammten, was bei Open Suse ohne Probleme möglich war. Beim Cent-OS-Setup dienten die Pakete des “Xen made easy!”-Projekts von Steven Haigh mit dem Kernel 3.9.2-1.el6xen.x86_64 [11] als Grundlage, für Virtualbox gab es die neuesten Pakete von Oracle und das einzige proprietäre Produkt im Vergleich, VMwares ESXi kam in Version 5.1.u1 zum Einsatz.

Nach jedem Hypervisor-Test installierten die Tester sowohl die Hostsysteme als auch die Gastsysteme komplett neu, um etwaige Hinterlassenschaften zu vermeiden, die eventuell die Testergebnisse beeinflussen könnten. Aufgrund seiner Größe wählten die Tester als zu übersetzendes Softwarepaket das Archiv der Samba-Quellen aus, das nach dem Entpacken die üblichen »configure« – und »make« -Schritte verlangt. Ein kleines Bash-Skript (analog zu Listing 1) führt die drei Schritte mehrfach hintereinander aus und protokolliert die benötigte Zeit. Diese Workload haben die Tester sodann unter beiden Distributionen sowohl direkt auf der Hardware als auch im virtuellen Gast gestartet.

01 #!/bin/bash
02 for run in 1 2 3 4 5
03 do
04 echo run $run
05 (time bash -c 'tar xf samba-3.6.15.tar.gz ; cd samba-3.6.15/source3 ; time ./configure ; time make')>& logfile-$OS-$VIRTTYPE-$CPU- $run
06  rm -rf samba-3.6.15
07 done

Um Seiteneffekte zu minimieren, war jeweils nur eine virtuelle Maschine aktiv. Ausreißer, wie sie durch einen zufällig laufenden Cronjob auftreten, ließen sich dabei erfolgreich eliminieren, beispielsweise durch Deaktivieren anderer Dienste oder aber durch simples Aufpassen und Beobachten.

Bereits zu Beginn zeigte sich bei den Messungen ohne Virtualisierung ein deutlicher Laufzeitunterschied des Kompiliervorgangs zwischen Cent OS und Open Suse. So produzierte die Cent-OS-VM die Kompilate immer wesentlich schneller als der Gast aus Nürnberg. Das zeigt, dass oft kleine Details einen großen Unterschied machen, da bei den beiden Betriebssystemen andere GCC-Versionen zum Einsatz kommen, denen das wohl hauptsächlich geschuldet ist.

In den Testläufen hängte Xen mit Paravirtualisierung die Konkurrenz teils deutlich ab. Schlusslicht war erwartungsgemäß Virtualbox. Aus den gemittelten Gesamtlaufzeiten des Compilejobs ergab sich unter den einzelnen Betriebssystemen die prozentuale Performance in Bezug auf die Laufzeit direkt auf der Hardware. Abbildung 6 stellt die Leistungsfähigkeit der einzelnen Ansätze dar. Als 100-Prozent-Referenzwert dient die Laufzeit des Compilevorgangs ohne Virtualisierung (ganz links). Die Werte von Cent OS und Open Suse sind durch unterschiedliche Compilerversionen nicht direkt miteinander vergleichbar, die Werte für die verschiedenen Hypervisoren jedoch schon.

Abbildung 6: Prozentuale Leistungsfähigkeit

Cent OS oder Open Suse? Voll- oder paravirtualisiert?

Verglichen mit dem Kompiliervorgang auf dem Hostsystem zeigt sich, dass die Hypervisorlösungen recht unempfindlich auf die Art ihrer Gäste reagieren. Mal ist der Virtualisierungsoverhead bei Open Suse, mal mit Cent OS als Gast ein wenig geringer. Den einzig sichtbaren Ausreißer leistet sich dabei Xen mit Paravirtualisierung: Beim Open-Suse-Setup tritt trotz ähnlicher Xen-Version wesentlich weniger Verlust als bei der Cent-OS-Installation auf.

Eventuell spielt hier die neuere Kernelversion in der virtuellen Maschine des Red Hat-Klons eine wichtige Rolle und verursacht das schlechtere Ergebnis. Die Wahl des Betriebssystems ist dagegen weniger wichtig, Admins können und sollten sie von den anderen Anforderungen an die Umgebung abhängig machen.

Der Admin, dessen Herz für Xen schlägt und der noch hadert, Xen para- oder vollvirtualisiert einzusetzen, steht vor einer leichten Entscheidung: Wer Paravirtualisierung nutzen kann, sollte das tun. Der Geschwindigkeitsvorteil ist sowohl im Open-Suse-Setup als auch in Kombination mit Cent OS beträchtlich. Doch gilt das nicht bei Vollvirtualisierung: Zwar kann Xen mit Paravirtualisierung die anderen Lösungen deutlich hinter sich lassen, muss aber im vollvirtualisierten Betrieb sowohl ESXi als auch KVM an sich vorbeiziehen lassen.

Auch wenn KVM inzwischen einige paravirtualisierte Treiber enthält, erscheint der Vergleich mit der Vollvirtualisierung unter Xen am fairsten. Hier sollte der Admin im Zweifel auf KVM setzen, da der Hypervisor bei beiden Gastsystemen einen wenn auch kleinen Vorsprung herausholt. Eventuell bieten hier die angepassten Treiber ein kleines Plus an Leistung. Wer statt Cent OS das kommerzielle RHEL installieren will, profitiert mit KVM vom Enterprise-Support von Red Hat – im selbst gebauten Setup mit Xen wird dies schwierig, schließlich haben die Rothüte mit der Red-Hat-Enterprise-Linux-Version 6 die Unterstützung für Xen gestrichen.

VMware und Virtualbox

Betrachtet man die Leistungen von VMware ESXi im Testaufbau, so schafft der Platzhirsch eine gute Leistung. Zwar kann er Xen mit Paravirtualisierung nicht schlagen, liefert aber ein deutlich besseres Ergebnis als KVM. Die Stärke von ESXi liegt definitiv auch in seiner weiten Verbreitung vor allem jenseits der Linux-Welt, dem guten Support sowie Eigenschaften, die sich der Admin aber teuer erkaufen muss, speziell wenn er auf übergeordnete Managementwerkzeuge angewiesen ist,.

Den Gedanken, Virtualbox im beschriebenen Szenario produktiv zu betreiben, sollte der Admin schnell wieder verwerfen. Zu deutlich fällt der Hypervisor hinter den Mitbewerbern zurück. Da hilft auch keine Live-Migration oder die brauchbare Kommandozeile. Bei gut dreimal so langen Laufzeiten im Vergleich zu Xen mit Paravirtualisierung gehen schnell die Argumente aus, die den Einsatz im Rechenzentrum rechtfertigen. Im interaktiven Betrieb auf dem Desktop zählen jedoch vielleicht andere Eigenschaften.

Augen auf bei der Hypervisor-Wahl

Die Ergebnisse bestätigen die Vermutung, dass auch im Zeitalter flexibler Cloudmanagement-Lösungen und der vereinheitlichenden Libvirt man die Wahl der Virtualisierungsschicht nach wie vor nicht leichtfertig treffen sollte. Auch wenn die durchgeführten Messungen nur einen Aspekt der Leistungsfähigkeit moderner Virtualisierungslösungen beleuchten und die nackten Zahlen bei einem anderen Testszenario, einer höheren Auslastung oder Ausstattung der Hostsysteme vielleicht anders aussehen, zeigt sich vor allem eins: Die Unterschiede sind größer als die Produktbeschreibungen es vermuten lassen.

Farmville

KVM hat in vielen Aspekten zur Konkurrenz aufgeschlossen, der Klassiker Xen hat nach wie vor seine Daseinsberechtigung und wer in seiner Umgebung bereits Lösungen wie VMwares V-Spehere mit ESXi (Abbildung 7) einsetzt, kann dies auch weiterhin tun. Die Virtualisierung von und mit Linux ist vielseitiger geworden. Ein Admin, der eine zweckgebundene Rechnerfarm für seine Cloud aufbauen will, sollte sich Zeit nehmen, die verschiedenen Hypervisoren zu testen und sich auf überraschende Ergebnisse vorbereiten. Administrieren wird er seine freie Farm am Ende ohnehin mit Open Stack, Open Nebula oder der Libvirt selbst.

Abbildung 7: VMwares V-Sphere war lange Vorreiter in Sachen Cloud- und Hypervisor-Management. Doch sowohl bei Leistung als auch bei den Features für Live-Migrationen hat die Konkurrenz zu ESXi aufgeholt.

Der Autor

Holger Gantikow hat an der Hochschule Furtwangen Informatik studiert und ist bei der Science + computing AG in Tübingen als Senior Systems Engineer tätig. Dort beschäftigt er sich mit der Komplexität heterogener Systeme im CAE-Berechnungsumfeld und betreut Kunden aus dem technisch-wissenschaftlichen Bereich.