Die etablierten Hersteller von Unix-Servern haben Virtualisierungstechniken längst in ihre Betriebssysteme integriert. So potenzieren sie die Auslastung schon im bei Einstiegsmodellen.

Virtualisierung boomt. Kein Wunder, dass klassische Lieferanten von Unix-Servern wie IBM, Sun oder HP nicht zurückstehen und sich mit eigenen Lösungen bereits im Entry-Level-Segment ein Stück vom Kuchen sichern wollen. Schließlich prognostizieren Analysten diesem Marktsegment hohe Zuwachsraten und einen Umsatz von mehr als 2,2 Milliarden US-Dollar [1] bis 2007.

Die Erfolgsmeldungen der einschlägigen Softwarehersteller scheinen das zu belegen: VMware kürt sich selbst zum am schnellsten wachsenden Unternehmen der gesamten Softwarebranche [2] und auch Konkurrent SWsoft, der auf allen gängigen 32- und 64-Bit-Plattformen mit seinen virtuellen Virtuozzo-Servern vertreten ist, meldet 160 Prozent Wachstum und eine Verdopplung der Mitarbeiteranzahl im vergangenen Jahr [3]. Sein freier Ableger OpenVZ [4] ist im Open-Source-Sektor ebenfalls nicht alleine: Mit Xen [5] konkurriert er um den Einzug in den Linux-Kernel. Daneben existiert eine breite Palette von Alternativen.

Dem stehen Lösungen gegenüber, die Virtualisierungstechniken von vornherein ins Betriebssystem integrieren und mit leistungsfähiger, maßgeschneiderter Hardware zu attraktiven Paketen kombinieren. Was sie dem Nutzer bieten, hat sich das Linux-Magazin beispielhaft an zwei Testkandidaten angesehen.

IBM System P5 505

Zuerst erreichte die Redaktion ein IBM System P5 505 [6]. Die geräuschvolle Flunder im Format einer Höheneinheit enthielt bereits ein vorinstalliertes Betriebssystem AIX 5L 5.3 sowie den so genannten Virtual I/O-Server (VIOS), der in dieser Konfiguration als zentrale Instanz alle I/O-Ressourcen des Systems verwaltete. Er übersetzt die physikalisch vorhandenen Platten, Netzwerkinterfaces oder optischen Laufwerke in Ressourcen für die virtuellen Maschinen, die hier auch logische Partition, kurz LPAR, heißen. Zudem benötigen die LPARs auch RAM und entweder einen dedizierten Prozessor oder das Nutzungsrecht (Entitlement) für ein garantiertes Mindestquantum Rechenleistung aus einem gemeinsamen Prozessor-Pool, das der Admin beginnend mit 0,1 CPU in Hundertstelschritten verteilen kann.

Alle diese Zuweisungen erfolgen statisch, was bedeutet: Die einer LPAR zugeteilten Betriebsmittel sind für andere Partitionen nicht mehr erreichbar und Änderungen im laufenden Betrieb der Partition sind nicht möglich. Für nachträgliche Anpassungen ist allerdings nur die betroffene Partition zeitweise zu deaktivieren, ein Rebooten des ganzen Servers ist unnötig.

Der VIOS stellt außerdem die Schnittstelle zum Benutzer, und zwar in Gestalt des Integrated Virtualization Manager [7]. Er ersetzt die bei IBMs großen Servern übliche Hardware Management Console (HMC), für die sonst ein eigener Rechner nötig wäre. Neben einem Command Line Interface bietet der IVM auch ein intuitives Web-GUI, über das sich die virtuellen Partitionen konfigurieren lassen. Für diese Arbeit offeriert ein Assistent seine Hilfe, der in den meisten Fällen auch sinnvolle Defaultwerte zur Hand hat, sodass kaum besondere Vorkenntnisse nötig sind (Abbildung 1).

Abbildung 1: Eine neue logische Partition hat das Licht der Welt erblickt: Der Virtualisierungsmanager fasst alle Einstellungen noch einmal zusammen.

Abbildung 2: LPARMon zeigt die Auslastung des Prozessor-Pools durch die virtuellen Partitionen grafisch an. Im Beispiel erhielt die am stärksten belastete erste Instanz per Konfiguration einen größeren Anteil der CPU-Leistung.

Virtuelles Quintett

Der erste Test erfolgte mit fünf logischen Partitionen mit jeweils einem Enterprise-Linux, dem SLES 9 [8] von Novell. Auf jeder virtuellen Linux-Maschine wurde ein Webserver eingerichtet, den ein externer Client mit Abfragen traktierte. Dafür kam Siege [9], ein Tool für HTTP-Regressionstests zum Einsatz. Zunächst sollten parallel laufende Instanzen des Benchmark von einem, zwei, drei, vier und schließlich allen fünf virtuellen Servern die maximale Anzahl Seiten abzurufen versuchen.

Das erzwingt die Aufteilung der Ressourcen unter die beteiligten Verbraucher entsprechend ihrer Gewichtung, die hier zunächst einheitlich bei 0,2 CPU-Entitlements pro LPAR lagen. Folglich steigt mit der Anzahl der gleichzeitig beanspruchten virtuellen Server die Antwortzeit jedes einzelnen, während Durchsatz oder Transaktionsrate ungefähr umgekehrt proportional sinken (Abbildung 3).

Addiert man aber die von allen Servern erzielten Resultate beispielsweise für Durchsatz oder Transaktionsrate, so ergibt sich ungefähr wieder der von einer Solo-Instanz erreichte Wert. Daraus ist zu schließen, dass die Virtualisierung an sich offenbar keinen nennenswerten Overhead verursacht.

Abbildung 3: Die Leistung der virtuellen Maschinen auf den Einstiegssystemen von IBM und Sun bewegte sich in derselben Größenordnung und nahm unter Volllast proportional zur Anzahl konkurrierender Instanzen ab.

Ohne Konkurrenzdruck

In einem weiteren Versuch pausierte der Benchmark vor jedem Seitenabruf eine zufällige Zeit von längstens einer Sekunde. Dadurch überlappen sich die Zugriffe der einzelnen virtuellen Server auf die Systemressourcen viel seltener und die Lastverteilung kommt einem realistischen Szenario näher als der Volllast-Test. Nun hatte die Anzahl parallel laufender Webserver praktisch keinen Einfluss mehr auf ihre Transaktionsrate. Die gleichzeitig unter AIX auf der Wirtsmaschine der virtuellen Server ermittelte Auslastung der CPUs zeigt, dass mit steigender Anzahl aktiver Webserver nur die Leerlaufzeit der Prozessoren zurückgeht (Abbildung 4). Mehrere LPARs können also ansonsten brachliegende Leistungsreserven nutzen, ohne sich gegenseitig auszubremsen – jedenfalls solange sie nicht an ihre Grenzen gehen müssen.

Abbildung 4: Bei gemäßigter Konkurrenz hängt die Leistung des einzelnen virtuellen Servers kaum von der Anzahl gleichzeitig werkelnder Kollegen ab – dagegen nimmt das Däumchendrehen der Prozessoren ab.

Sun Fire X4100

Als zweite Testmaschine stand den Testern ein Einstiegsmodell von Sun zur Verfügung. Der Rechner des Typs Sun Fire X4100 war ebenfalls mit zwei Prozessoren (in diesem Fall Doppelkern-Opteron 280) und 8 GByte RAM bestückt. Vorinstalliert war Solaris 10, das mit seinen Zonen eine eigene Virtualisierungstechnik bietet [11]. Auf den ersten Blick ist das Konzept dem von IBMs logischen Partitionen ähnlich: Hier wie dort lassen sich mehrere Applikationen in jeweils eigener Ausführungsumgebung vollständig voneinander isolieren und mit einem definierten Anteil der Systemressourcen ausstatten.

Auf den zweiten Blick sind aber auch deutliche Unterschiede zu erkennen. Der gravierendste: Zonen in Solaris verwenden automatisch das Solaris ihrer Wirtsmaschine. Dadurch läuft einerseits nur eine Betriebssysteminstanz, andererseits sind verschiedene OS-Versionen oder gar andere Betriebssysteme nicht möglich. Zumindest zurzeit – eine Erweiterung in Gestalt des Framework Brandz (siehe Artikel “Doppelgänger”) ist bereits für Open Solaris verfügbar.

Zweitens kennt ein Ressource-Pool, der die Betriebsmittel einer Zone vereint und von anderen Zonen abgrenzt, derzeit lediglich einen Ressourcen-Typ, den Prozessor. Daher ist es im Unterschied zur Lösung von IBM nicht möglich, auf der Ebene der Zonendefinition RAM für eine Zone zu reservieren.

Gleichwohl kann man – wenn auch vergleichsweise umständlich – ein oberes Limit für den Speicherverbrauch bestimmter Applikationen innerhalb einer Zone festlegen. Dazu muss der Admin auf die Solaris-eigene Ressourcenverwaltung in Form der so genannten Projekte zurückgreifen, die sich auch innerhalb von Zonen verwenden lässt. Auf ähnliche Weise ist auch die garantierte Mindestmenge an Rechenleistung pro Zone einstellbar. Diese Zuteilung lässt sich jederzeit dynamisch anpassen.

Mehrarbeit durch Pausenkürzung

Das Einrichten und Starten einer Zone muss der Admin unter Solaris auf der Kommandozeile bewältigen. Zwar ist auch ein GUI verfügbar, doch gehört es nicht direkt zu Solaris. Das ist aber kein Beinbruch, die Konfiguration ist schnell und einfach erledigt (Abbildung 6). Die Tester konfigurierten analog zum obigen Beispiel wieder fünf Zonen und aktivierten in jeder einen Webserver. Dann ließen sie die bereits beschriebenen Benchmarks laufen.

Abbildung 5: Die Summe der Benchmark-Leistungen aller Teilnehmer bleibt konstant. In diesem Beispiel knabbert eine zunehmende Anzahl Solaris-Zonen offenbar kaum an der Systemleistung der Sun Fire X4100.

Abbildung 6: Konfiguration und Installation einer neuen Zone gehen auf dem Sun-Server schnell von der Hand, wenige Kommandos reichen aus.

Die absoluten Werte eines einzelnen Benchmark erlauben selbstverständlich keine umfassende Leistungsbeurteilung – das war auch nicht das Ziel des Tests. Immerhin liegen die gemessenen Werte auf beiden Systemen in derselben Größenordnung. Mit Blick auf die Virtualisierung ergibt sich auch bei Sun das zu erwartende Testresultat: Volllast erzwingt die Aufteilung der Ressourcen unter die Teilnehmer des Benchmark. Die Summe ihrer Teilleistungen bleibt aber annähernd konstant, was dafür spricht, dass auch hier die Virtualisierung als solche keinen nennenswerten Overhead erzeugt (Abbildung 5).

Bei gemäßigter Konkurrenz – was eher realen Verhältnissen entspricht – ist mit einer Hand voll virtueller Server noch längst nicht das Ende der Fahnenstange erreicht. Sie bewirken unter Solaris nur einen Rückgang der Leerlaufzeit um rund zehn Prozentpunkte. Vor einer Ausweitung wäre nur zu bedenken, dass mehr virtuelle Server natürlich auch mehr RAM, Plattenplatz und Schnittstellen erfordern.

Fazit

Im Unterschied zu Linux oder Windows haben etliche traditionelle Unix-Dialekte Virtualisierung bereits fest integriert. So verursacht sie so gut wie keinen Overhead und passt sich nahtlos in die Systemadministration ein. Zusammen mit leistungsfähiger Hardware, die im Einstiegsbereich nicht mehr weit vom PC-Preisniveau entfernt ist, ergibt sich so ein sehr interessantes Angebot.

Die Unterschiede zwischen den Kandidaten liegen in Details. So bietet das IBM-System flexiblere Nutzungsmöglichkeiten seiner virtuellen Maschinen und das einfachere Ressourcen-Management. Für den erfahrenen Solaris-Admin, der seine Anwender auf dieser Plattform restlos zufrieden stellt, hat aber sicher auch die verlustfreie Virtualisierung mit Bordmitteln ihren Reiz.