Klassische Virtualisierung à la Vmware beruht auf der softwareseitigen Emulation von Standardhardware in virtuellen Maschinen. Eine interessante Alternative dazu ist Containervirtualisierung. ZDNet zeigt ihre Möglichkeiten und Grenzen auf.
Virtualisierung wird heute vorwiegend als Vollvirtualisierung oder Paravirtualisierung betrieben. Bei einer Vollvirtualisierung wird mittels Software ein kompletter Computer emuliert. Dazu gehört vor allem die Emulation von Hardwarekomponenten, etwa Netzwerkkarte oder SCSI-Controller. Dies ermöglicht die Verwendung eines unmodifizierten Gastbetriebssystems in einer virtuellen Maschine und zeichnet sich vor allem durch hohe Flexibilität aus, da jedes beliebige Betriebssystem in einer virtuellen Maschine gestartet werden kann.
Ein großer Nachteil der Vollvirtualisierung ist, dass durch die Emulation der Hardware einiges an Performance verloren geht. Der Verlust kann bei Netzwerk- und Festplatten-I/O bis zu 50 Prozent betragen, je nach Unterstützungslevel des jeweiligen Prozessors für Virtualisierung.
Ein Ansatz, diesen großen Verlust an Performance wieder wettzumachen, ist Paravirtualisierung. Sie emuliert keine Hardwarekomponenten, sondern ersetzt die Hardwaretreiber des Gastbetriebssystems einfach durch Treiber, die nicht mit der Hardware, sondern mit dem Hypervisor der Virtualisierungssoftware interagieren. Damit wird der Performancenachteil einer Vollvirtualisierung zwar drastisch reduziert, es muss aber eine speziell angepasste Version des Gastbetriebssystems in der virtuellen Maschine installiert werden.
Moderne Linux-Betriebssysteme wie Suse 10 oder Fedora 6 bieten heute bereits optional eine Installation mit paravirtualisiertem Kernel. Für Windows ist diese Paravirtualisierung erst mit Longhorn angekündigt. Die Open-Source-Virtualisierungslösung Xen in der aktuellen Version 3.0 setzt daher bei Linux auf Paravirtualisierung und bei Windows auf Vollvirtualisierung.
Als dritte Alternative bietet sich Containervirtualisierung an. Hier gibt es für Linux zum Beispiel Vserver[1] als Open-Source-Projekt. Kommerziell bietet Swsoft[2] die Software Virtuozzo für Linux und Windows an. Containervirtualisierung beruht auf einem völlig anderen Ansatz als Voll- oder Paravirtualisierung. Hier wird gar keine virtuelle Maschine emuliert, sondern ein Layer zwischen Betriebssystemkern und den APIs gelegt, der alle relevanten APIs abfängt und auf dieser Ebene virtualisiert. Das bedeutet zunächst einmal, dass keine Cross-Plattform-Virtualisierung möglich ist.
Ein Container entspricht einer virtuellen Maschine bei Voll- und Paravirtualisierung. Jeder Container wird unter demselben Betriebssystem wie der Hostcomputer betrieben. Es ist nicht möglich, den Hostcomputer unter Windows zu betreiben und einen Container unter Linux oder einer anderen Windows-Version.
 |
| Bild 1: Laut Device Manager fehlen Windows im Container einige Komponenten, um überhaupt starten zu können. |
Ein Container wird nicht tatsächlich gebootet, sondern nur aktiviert oder deaktiviert. Ein Container kann auch gar nicht gebootet werden, da die dafür nötige Hardware im Container fehlt (Bild 1). Programme, die in einem Container gestartet werden, starten als ganz normaler Prozess im Hostbetriebssystem und sind dort mit derselben Prozessnummer sichtbar (Bild 2).
 |
| Bild 2: Sowohl in der Hostmaschine (XP Style) als auch in der Gastmaschine (Classic Style) sind die Prozesse sichtbar. |
Der API-Virtualisierungslayer sorgt dafür, dass alle Prozesse eines Containers in einer "privaten" Umgebung laufen, das heißt, mit einer eigenen Platte, einer eigenen Netzwerkkarte und so weiter. Im Falle von Windows gibt es zudem für jeden Container eine eigene Registry.
Der Benutzer, der sich in einen Container einloggt, hat genau wie bei Voll- und Paravirtualisierung das Gefühl, er besäße einen eigenen Computer. Nur an Kleinigkeiten ist der Unterschied zu merken. Im Falle von Windows wird er nach einem Pagefile ebenso vergeblich suchen wie nach den Dateien für eine Registry. Auch der Diskmanager zeigt erst gar keine physikalischen Platten an.
Trotz der fehlendenden Cross-Plattform-Virtualisierung schneidet die Containervirtualisierung im Vergleich alles andere als schlecht ab. Zunächst einmal fällt sehr viel Memory-Overhead weg. Dadurch, dass kein komplett neues Betriebssystem gebootet werden muss, ergibt sich insbesondere bei Windows ein großer Speichervorteil. Typischerweise benötigt jeder Windows-Container 80 bis 120 MByte RAM, je nachdem, welche Dienste in der Containermaschine gestartet werden. Die Zuteilung der Systemressourcen ist tatsächlich dynamisch. Plattenplatz, verfügbarer Hauptspeicher und Prozessorleistung können im laufenden Betrieb einer Containermaschine verändert werden, ohne dass diese neu gestartet werden muss. Dies ist ein nicht zu unterschätzender Vorteil gegenüber Voll- und Paravirtualisierung.
Grundsätzlich teilen sich bei einer Containervirtualisierung alle Containermaschinen die gesamten Ressourcen. Besitzt der Hostcomputer 4 GByte RAM, 1 TByte Festplattenspeicher und vier Prozessoren, so stehen diese kompletten Ressourcen allen Containermaschinen jederzeit zur Verfügung.
Diese Ressourcen werden von der Virtualisierungssoftware lediglich "quotiert", so dass eine Containermaschine nicht beispielsweise 95 Prozent des freien Plattenplatzes verwenden kann. Dies erlaubt eine unter Voll- oder Paravirtualisierung unerreichte Flexibilität.
Allerdings gibt es auch Einschränkungen. Updates und Servicepacks können in der Regel nicht für jeden Container einzeln zur Verfügung gestellt werden, sondern werden zentral auf der Hostmaschine eingespielt. Man muss sich also entscheiden, ob man ein Update oder Servicepack für alle Containermaschinen einspielt - oder für gar keine.
Natürlich gibt es keine Regel ohne Ausnahme. Updates, die nur solche Dateien verändern, die nicht direkt mit dem Kernel interagieren und selbst keinen neuen Kernel mitbringen, können auch einzeln in jeden Container eingespielt werden. Dies ist relativ wichtig, wenn man in einer Containermaschine eine Software betreibt, die mit einem bestimmten Update oder Servicepack nicht kompatibel ist. Schaut man sich beispielsweise die mindestens wöchentlich erscheinenden Updates von Microsoft an, so lässt sich nicht ohne weiteres vor dem Update erkennen, ob dieses global in der Hostmaschine oder einzeln in jeden Container installiert werden kann.
Zu guter Letzt muss erwähnt werden, dass bestimmte Updates von der Virtualisierungssoftware unterstützt werden müssen. Dazu gehört unter anderem der Internet Explorer 7. Für regelmäßige Updates ist eine umfangreiche Testumgebung daher unerlässlich. Containervirtualisierung ist eine höchst interessante Alternative, wenn Virtualisierung mit identischem Betriebssystem gefragt ist. Containermaschinen sind von virtuellen Maschinen für den Benutzer so gut wie nicht zu unterscheiden. Dabei ist die technische Realisierung nicht einmal ansatzweise vergleichbar.
Containervirtualisierung wird heute hauptsächlich bei Hostern eingesetzt, die ihren Kunden eigene virtuelle Server unter Linux und Windows zur Verfügung stellen, damit der Kunde eigene Administrator- beziehungsweise Root-Rechte hat.
Doch auch im Intranet-Rechenzentrum kann Containervirtualisierung interessant sein. Grundsätzlich ist es nicht erforderlich, mehrere Serveranwendungen in verschiedenen Containermaschinen zu installieren, wenn die Containermaschinen ohnehin unter identischem Betriebssystem laufen müssen.
In der Praxis können jedoch oftmals zwei Serveranwendungen nicht auf der gleichen Maschine installiert werden, oder es ist aus Performancegründen sinnvoll, unterschiedliche Betriebssystemkonfigurationen für zwei Serveranwendungen zu verwenden. Dann kann eine Containervirtualisierung natürlich sehr hilfreich sein.
Ein anderer Grund für Containervirtualisierung im Intranet ist natürlich Flexibilität beim Serverumzug. Containermaschinen können mindestens genauso flexibel ohne Neuinstallation auf einen anderen Server umgezogen werden wie virtuelle Maschinen. In der Regel muss sogar weniger Datenvolumen transportiert werden.
Hauptvorteil einer Containervirtualisierung ist die Möglichkeit, alle Ressourcen (etwa Hauptspeicher, Prozessorleistung und Plattenplatz) dynamisch den einzelnen Containermaschinen zur Verfügung stellen zu können, ohne dass diese neu gestartet werden müssen.
Selbiges ist bei der heutigen Hypervisortechnologie bei Voll- und Paravirtualisierung nicht möglich. Da keine Hardware emuliert werden muss, entfällt zudem jeder Performanceverlust, der mit dieser Emulation verbunden ist.
Kopfzerbrechen können jedoch Updates, Service Packs und andere Betriebssystemveränderungen bereiten. Hier ist die Voll- und Paravirtualisierung im Vorteil, da jede virtuelle Maschine eine komplett eigene Betriebssystemkopie hat und nicht mit einer anderen virtuellen Maschine in Konflikt geraten kann.
Insgesamt kann gesagt werden, dass bei Virtualisierung mit identischen Betriebssystemen die Containervirtualisierung in der Regel die bessere Alternative ist, da sie sehr viel sparsamer mit Ressourcen umgeht und somit effektiv mehr Rechen- und I/O-Leistung für die eigentlichen Aufgaben zur Verfügung steht.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/