IT-Mittelklasse mit Hypervisor

Network Computing berichtete in der Ausgabe 05/06 2006 ausführlich über Servervirtualisierung auf x86- und x86-64-Systemen. Ursprünglich stammt die Technologie jedoch von den Großrechnern und hat sich in Folge dessen in den vergangenen Jahren auch auf großen Unix-Systemen etabliert. Große AIX-, HP-UX- und Solaris-Rechner nutzten dabei in erster Linie dezidierte Prozessorgruppen für physisch unabhängige Partitionen. In der Zwischenzeit haben die Hersteller auch auf Unix-Systemen Virtualisierungstechnologien eingeführt, die mehrere Systeminstanzen auf einer einzelnen CPU erlauben. Dabei gehen die Hersteller HP, IBM und Sun unterschiedliche Wege. So erlauben die Virtualisierungslösungen von HP und IBM den gemischten Betrieb verschiedener Systeme, während sich Sun auf die Partitionierung von Solaris 10 konzentriert. Network Computing hat die drei Unix-Derivate und deren unterschiedliche Ansätze zur Servervirtualisierung in den Real-World Labs genauer angesehen.

IBM Power Virtualization
IBM gehört zu den Pionieren der Servervirtualisierung und hat diese Technik von den hauseigenen Großrechnern auf die Unix-Systeme portiert. Dort laufen parallel verschiedene AIX-Versionen, Linux und OS/400, Letzteres nur mit spezieller Zusatzhardware. Bis zum Power-4-Prozessor gestaltete sich das Ganze jedoch recht statisch. So musste der Administrator jeder virtuellen Maschine mindestens einen kompletten Prozessor zuweisen. Mit der Power-5-CPU führte IBM so genannte Micro-Partitions ein, die ein Power-5-Hypervisor verwaltet. Das VM-Management erledigt bei IBM ein Mix aus besonderen VM-Kommandos der CPU und der Firmware, welche diese Kommandos nutzt. Der Power-Hypervisor klemmt sich somit zwischen die physischen CPUs und das Betriebssystem. Große AIX-Server mit vielen CPUs setzen einen eigenen, externen Steuercomputer ein, welcher mit dem Power-5-Hypervisor kommuniziert und die VMs verwaltet. Das ist bei kleinen Power-5-Systemen wie dem IBM Eserver p505 aber nur wenig sinnvoll. Daher kann dieser Rechner VMs über den integrierten VMM steuern. Der p505 kommt als flacher 1-HE-Server und integriert eine Power-5+-CPU mit zwei Kernen. Um den integrierten VMM nutzen zu können, bedarf es einer privilegierten Systempartition mit AIX oder Linux.

Diese erste Maschine übernimmt die Steuerung der vorhandenen Hardware und virtualisiert I/O-, SCSI- und LAN-Komponenten für weitere VMs. Als privilegierte Partition kann nicht jedes Linux-Derivat herhalten, da IBM besondere Binärtreiber verwendet, um die virtuellen I/O-Ressourcen für VMs bereitzustellen. AIX 5.3 funktioniert in jedem Fall. Der Systemabsturz einer privilegierten Partition hätte zur Folge, dass alle VMs den Zugriff auf ihre virtuellen Geräte verlieren und dann entweder selbst abstürzen oder mit der Außenwelt nicht mehr kommunizieren können. Daher kann IBM mehrere privilegierte Partitionen einrichten, die redundante I/O-Pfade für die VMs schaffen.

Die Power-5-Virtualisierung erlaubt dem Administrator sehr präzise Ressourceeinstellungen pro VM. So bekommt jede VM mindestens eine virtuelle CPU in Form einer zehntel-physischen CPU zugewiesen. Damit hat die Maschine eine garantierte Mindestperformance. Der Administrator darf diese Grenzwerte erhöhen, indem er der Maschine mehr CPU-Zeit oder mehrere virtuelle CPUs gibt. Auch kann die VM zusätzliche CPU-Zeit aus einem Pool ungenutzter CPU-Ressourcen abzapfen. Ähnliches gilt für den Arbeitsspeicher. Den VMs lässt sich RAM zur Laufzeit zuweisen oder wegnehmen. Derzeit ist nur AIX dazu in der Lage, im laufenden Betrieb den Arbeitsspeicher zu vergrößern oder zu verkleinern, bei Linux geht das noch nicht. VMs nutzen als Festplatten wahlweise LUNs aus dem SAN oder einzelne Partitionen eines Host-Laufwerks. Für die LAN-Kommunikation greifen die VMs entweder auf gemeinsam genutzte oder private LAN-Adapter zu.

Die Administration des Power-5-Hypervisors erfolgt über ein sehr übersichtliches Web-GUI. Auf einen Blick sieht der Systemverwalter alle definierten VMs und deren Status. Integrierte Tools erlauben, bestehende Maschinen zu klonen, um daraus neue Systeme oder Sicherungskopien zu erstellen.

Die Power-5-Virtualization gehört zu den besten Hypervisors auf dem Markt. Dabei müssen Anwender des integrierten VMM in kleinen Power-5-Systemen wie dem p505 geringe funktionelle Abstriche gegenüber großen Systemen mit separatem Steuercomputer hinnehmen. Die Performance des Power-5 ist sehr hoch, sodass auch virtuelle Maschinen mit Zehntel-CPUs gut performen.

Solaris-10-Container
Einen ganz anderen Virtualisierungsansatz verfolgt Sun. Hier gibt es keinen Hypervisor, der mehrere Systeme mit unterschiedlichen Kernen parallel betreiben kann. Um komplett getrennte Systeme auf Sun-Hardware laufen zu lassen, bedarf es einer großen Maschine mit vielen CPUs und Cell-Boards. Dort kann Sun – wie alle anderen Unix-Server-Hersteller – Physical-Partitions verwalten. Diese Trennung gibt jeder Systeminstanz aber auch definierte I/O-Geräte und eine feste Zahl von CPUs und RAM-Bänken. Mit der T1-CPU hat Sun einen Prozessor für massiv parallele Aufgaben zur Hand, der förmlich nach Virtualisierung schreit. Daher integriert Sun seit Solaris 10 eine Virtualisierungstechnik in das Betriebssystem. Die Solaris-Container benutzen dabei den Systemkern des Grundsystems und virtualisieren die Anwendungsumgebung. Ähnliche Technologien finden sich in PC-Produkten wie Virtuozzo für Windows und Linux sowie den freien Implementierungen Open VZ oder Linux VServer.

Ein Container verfügt über ein Basisverzeichnis, ähnlich einer chroot-Sitzung. Dieses Verzeichnis kann überall im Verzeichnisbaum des Grundsystems hängen und arbeitet damit unabhängig von der Hardware oder dem Dateisystem. Innerhalb des Containers gelten eigene Zugriffsrechte. Jeder Container verfügt über seinen eigenen Superuser, der aber keinerlei Zugriffsrechte auf andere Container oder gar das Grundsystem erhält. Analog hierzu verwaltet jeder Container eigene User- und Gruppenkonten, die ebenfalls keine Rechte auf andere Container oder die Systembasis haben. Die virtuellen Systeme schotten Speicher- und Prozesszugriffe voneinander ab. Die Memory-Fenster eines Containers bleiben für andere ebenso unsichtbar wie die Prozessliste. Der Zugriff auf das LAN erfolgt über logische Adapter. Nutzt das Grundsystem beispielsweise die physische Schnittstelle »hme0«, erhält ein Container mit »hme0:2« ein logisches Interface, das Daten via hme0 ans LAN überträgt.

Im direkten Vergleich zu virtuellen Maschinen lassen sich Container sehr viel einfacher verwalten. Hier muss der Administrator keine neue Systeminstanz innerhalb der VM installieren, wie das beispielsweise bei Power-5 der Fall ist. Hier genügen einige wenige Befehle auf der Kommandozeile. Alles, was der Verwalter dazu benötigt, ist der Pfad des Root-Verzeichnisses, eine IP-Adresse und ein logischer LAN-Adapter. Mit diesen Informationen lässt sich ein Container binnen Sekunden aktivieren.

Solaris-Container arbeiten sowohl auf Sparc-Systemen mit Ultrasparc- oder -T1-Prozessor, als auch auf x86- und x86-64-Rechnern. Die Cool-Threads-Systeme wie Suns T2000 sind dabei natürlich besonders interessant. Hier stellt sich ein einzelner Prozessor als 32-Wege-System dar. So kann ein einzelner Server mit passender Container-Konfiguration die Arbeit von mehreren Maschinen übernehmen.

Allerdings muss der Administrator darauf achten, den einzelnen Threads nicht zu viel Arbeit zuzumuten. Der T1 kann zwar 32-Threads simultan abarbeiten, liefert dabei jedoch pro Thread nicht die Performance wie ein x86-, Sparc- oder Power-5-Prozessor. Daher eignet sich der T1 eher für Anwendungen mit simplen Aufgaben.

Im Labor konnte Network Computing einem Sun-Fire-T2000-Server unter die Haube sehen. Der 2-HE-Server integriert duale Netzteile, bis zu vier SAS-Festplatten und vier 1-GBit/s-LAN-Interfaces. Mit 16-Dimm-Bänken kann der T2000 insgesamt 32 GByte RAM aufnehmen. Trotz ausreichenden Platzes im Gehäuse hat sich Sun entschieden, 2,5-Zoll-Enterprise-SAS-Laufwerke anstelle der noch gängigeren 3,5-Zoll-Platten einzusetzen. Wie bei Sun-Servern üblich, verzichtet auch der T2000 auf eine Grafikkarte und eine Tastaturschnittstelle. Stattdessen steuert der Administrator das Gerät über eine RS232-Konsole oder ein administratives LAN-Interface via Telnet oder SSH.

Das Kommandointerface des Bios und der Lights-Out-Management-Konsole erscheint Neulingen ein wenig konfus. Leider arbeiten nach wie vor die drei Konsolenebenen LOM, Bios und Solaris mit einer unterschiedlichen Syntax; das war bei Sun-Servern schon immer so, und früher oder später gewöhnt sich der Systemverwalter daran.

Die Maschine lief nicht lange genug im Labor, als dass aussagekräftige Geschwindigkeitstests damit zu fahren gewesen wären. Laut Messungen der Network-Computing-Kollegen aus den USA lässt sich die Performance eines T1-Threads in etwa mit der Leistung eines einzelnen 500-MHz-Ultrasparc-3-Prozessors vergleichen.

Fazit:
Die Solaris-10-Container liefern eine sehr einfach zu verwaltende VM-Plattform. Der Administrator bleibt dabei zwar an Solaris 10 als Betriebssystem gebunden, erhält im Gegenzug jedoch virtuelle Server ohne Performance-Einbußen durch einen Hypervisor. Für den Betrieb einfacherer VMs ohne großem CPU-Hunger empfiehlt sich der Sun-Fire-T2000-Server. Seine Multithreading-CPU eignet sich sehr gut für Container.

Aber auch auf regulären Intel- oder AMD-Servern läuft Solaris 10 samt Containern sehr zuverlässig und schnell. Network Computing setzt als laborinternen Solaris-Server derzeit einen Celestica A2210 mit zwei Opteron-Prozessoren ein. Administratoren, die das System erst einmal testen möchten, können dies auf bestehender x86-Hardware tun.

HP-Virtual-Server-Environment
Die Unix-Server von HP beherrschen eine ganze Reihe unterschiedlicher Virtualisierungstechniken. Die modernen Integrity-Server – früher unter dem Brand HP-9000 bekannt – arbeiten mit Intel-Itanium-Prozessoren und unterstützen somit eine ganze Reihe von Betriebssystemen. Dazu zählen neben HP-UX und Open-VMS vor allem Windows und Linux. Daher funktioniert eine Reihe der auf x86-Plattformen verfügbaren Virtual-Machine-Manager auch auf dem Itanium. Als kommerzielle Lösung offeriert SW Soft das in Ausgabe 5/6 getestete Virtuozzo für Linux und Windows auch auf der Itanium-Plattform.

Analog zu IBMs »lpars« integriert HP so genannte »vpars« in die größeren Server. Diese Virtualisierung arbeitet auf Prozessorebene und erlaubt einzelnen CPUs, getrennte Systeminstanzen zu betreiben. Allerdings setzen vpars statisch zugewiesene Ressourcen ein.

Das allein genügt HP nicht. Schließlich fehlt unter den aufgezählten Systemen ein vollständiger Hypervisor, der den parallelen Betrieb verschiedener Systeme auf einem Pool aus Memory- und CPU-Ressourcen gestattet. Ursprünglich hatte HP darauf gehofft, Vmware werde eine Itanium-Version des ESX- oder GSX-Servers auf den Markt bringen. Da sich die EMC-Tochter jedoch gegen eine Itanium-Implementierung des Hypervisors entschied, hat HP Teile der Vmware-Technologie lizenziert und daraus ein eigenes Produkt geschmiedet.

Das VSE arbeitet ähnlich wie der Vmware-Server oder Microsoft-Virtual-Server als Hostet-Product. Es setzt auf ein installiertes HP-UX-System auf und kann dann VMs mit Windows, Linux, HP-UX oder Open-VMS betreiben. Network Computing testete das HP-VSE auf einem Integrity-rx4640-Server. Allerdings hat HP das angeforderte Testgerät mit leichter Verspätung geschickt, sodass die Tests des VSE noch andauern und in einer der kommenden Ausgaben ein ausführlicher Bericht folgt. So viel steht jetzt bereits fest: Das HP-VSE installiert sich nicht so mir nichts dir nichts. Der Hypervisor setzt eine Reihe von Systempatches und den »HP Insight Manager« voraus. Dann folgen die verschiedenen Module von dem Hypervisor über das Management GUI bis hin zu einem Tool für die automatisierte Anpassung der VM-Ressourcen.

Fazit:
Unter den Unix-Servern offeriert HP mit den Integrity-Systemen zurzeit die größte Freiheit, was die Servervirtualiserung anbelangt. Neben dem hauseigenen Unix und Linux arbeitet hier auch Windows in vpars oder unter VSE. Anders als bei IBM oder Sun liefert HP das VSE jedoch nicht als festen Bestandteil der Maschine oder des Betriebssystems mit. Der Anwender muss VSE getrennt installieren – und auch getrennt bezahlen.

ast@networkcomputing.de