Virtualisierung ist nicht gleich Virtualisierung. Es gibt verschiedene Konzepte, Projekte und Produkte mit jeweils eigenen Stärken und Schwächen. Wer sie genau kennt, kann das beste Verfahren für seine Bedürfnisse auswählen. Allen gemeinsam ist: Die CPUs bekommen mehr zu tun.

Mit ungenutzten CPU-Zyklen lassen sich nicht nur Außerirdische suchen wie bei SETI@Home. Wo ein Rechner allein das Leistungsvermögen einer modernen CPU nicht auszuschöpft, da können sich mehrere bedienen. Viele virtuelle Server auf wenigen physischen Hosts ermöglichen dabei neben der besseren Auslastung der Ressourcen oft auch eine Konsolidierung der Systemlandschaft.

En vogue

Virtualisierung ist derzeit zwar ein Megatrend – aber kein neuer Gedanke. Spätestens seit Einführung der Programmiersprache Java ist jeder schon mal einer virtuellen Maschine begegnet. Vorher gab es bereits das P-System von UCSD-Pascal, eine der ersten virtuellen Maschinen für Pascal.

Genauso alt ist Virtualisierung auf Betriebssystemebene. Die erste virtuelle Maschine war IBMs VM/CMS aus den späten 60er Jahren. Unter dem Namen Z/VM ist diese Technik nach wie vor aktuell, erlaubt sie es doch, Linux effizient auf den Z-Series-Servern von IBM einzusetzen [19].

Virtuelle Maschinen

Eine virtuelle Maschine emuliert eine Ausführungsumgebung, das heißt, dass sie die Schnittstellen dieser Umgebung nachahmt. Eine Simulation würde außerdem alle internen Zustände dieser Umgebung darstellen.

In der Programmiersprache Java spricht man von einer Java Virtual Machine (JVM) als Emulation einer hypothetischen Maschine gemäß einer Spezifikation [16]. Die internen Zustände sind für den Anwender dabei nicht von Bedeutung. Die JVM agiert als ein virtueller Prozessor mit virtueller Ausführungsumgebung.

Das Gleiche lässt sich auch mit einem ganzen Rechnersystem machen. Typischerweise wird diese Aufgabe nicht komplett durch Hardware gelöst, sondern erfordert eine unterstützende Softwarekomponente – eine Art rudimentäres Betriebssystem -, die man dann als Virtual Machine Monitor (VMM) oder Hypervisor bezeichnet (Abbildung 1). Allerdings muss die Hardware, insbesondere natürlich die CPU, einige Anforderungen erfüllen [1].

VMware [2] und Virtual PC beziehungsweise Virtual Server [3] ermöglichen diese Form der Virtualisierung auf der x86-Architektur. Allerdings erfüllen die Intel- und AMD-Prozessoren derzeit noch nicht alle Anforderungen, um eine effiziente Virtualisierung zu ermöglichen [1]. Dazu wäre es notwendig, dass jede Maschineninstruktion, die einen Zugriff auf Ressourcen des Rechnersystems ermöglicht, einen Software-Interrupt auslöst, wenn sie in einem nicht-privilegierten Modus des Prozessors ausgeführt wird [17]. Erst Intels Vanderpool- [4] und AMDs Pacifica-Prozessoren [5] werden diese Möglichkeit effizient bereitstellen. Derzeit müssen Produkte wie VMware oder Virtual PC dagegen einige Umwege gehen, die die Performance teilweise stark beeinträchtigen.

Auch Xen [6] ist eine Hypervisortechnik, die allerdings ohne Vanderpool- oder Pacifica-Prozessoren noch eine Anpassung des Gastbetriebssystems erfordert. Aus diesem Grunde spricht man hier auch von Para-Virtualisierung. Letztlich zeichnen sich die volle und die Para-Virtualisierung dadurch aus, dass sie eine vollständige Ausführungsumgebung entsprechend einem physikalischen Rechnersystem zur Verfügung stellen. Daher ist es in diesem Fall auch notwendig, dass in der virtuellen Maschine wiederum ein eigenständiger Betriebssystemkern abläuft. Dabei darf der Gast auch einen vollkommen anderen Kern verwenden, als ihn sein Wirtssystem benutzt.

Die Kerne von Wirts- und Gastsystem können aber auch identisch sein. In diesem Fall wäre es grob betrachtet eigentlich unsinnig, den Weg über eine virtuelle Maschine zu gehen, denn schließlich stellt der Virtual Machine Monitor eine Ausführungsumgebung bereit, die bereits das Wirtssystem bietet.

Bei genauerer Betrachtung kann es allerdings sehr wohl gute Gründe dafür geben, genau dies zu tun. Beispielsweise kann es sinnvoll sein, mehrere physische Rechnersysteme auf einem leistungsfähigen zusammenzufassen und auf diese Weise Kosten und Administrationsaufwand zu sparen.

Es ist sehr wichtig, bereits im Vorfeld die Ziele der angestrebten Virtualisierung zu erfassen. Die auszubalancierenden Kriterien sind Sicherheit, Performanz, Kosten und Komplexität. Einen Überblick über die unterschiedlichen Virtualisierungsansätze gibt [7].

Ziele definieren

Geht es um die Bereitstellung homogener, aber abgetrennter virtueller Ausführungsumgebungen, so kann der Ansatz der vollen Virtualisierung sehr gut weiterhelfen. Auch bei unterschiedlichen physischen Wirtssystemen besteht die Möglichkeit, die virtuellen Maschinen dennoch gleich zu gestalten. Damit lassen sich die Gastsysteme beliebig und teilweise sogar dynamisch über einen Pool von physischen Systemen verschieben, sofern Voraussetzungen wie zum Beispiel ein SAN erfüllt sind.

Gleichzeitig ist durch Over-Committment, also ein mehrfaches Verplanen physischer Ressourcen in den virtuellen Maschinen, ein Einsparungseffekt zu erzielen. Dazu müssen allerdings die Lastprofile zueinander passen: Spitzen mehrerer virtueller Systeme dürfen nicht gleichzeitig auftreten.

Das Wirtssystem und seine Gäste wie auch die Gastsysteme untereinander sind strukturell voneinander vollständig entkoppelt – ein wichtiger Sicherheitsaspekt. Alle benutzen lediglich dieselbe CPU. Dabei ist es egal, ob das Wirtssystem ein eigenständiger Virtual Machine Monitor ist – wie etwa VMware ESX -, auf dem als Gastsysteme Linux, FreeBSD oder Windows laufen, oder ob die virtuelle Maschine ein vollständiges Wirtssystem voraussetzt, etwa wie Microsofts Virtual PC (Abbildung 2).

Die Komplexität des zweiten Szenarios ist aber eher hoch, weil zur Verwaltung der Gastsysteme noch eine weitere Softwarekomponente für die Virtualisierung hinzukommt. Die Ausführungsgeschwindigkeit unprivilegierter Maschinen-Instruktionen eines virtuellen Systems ist bei vollständiger Virtualisierung theoretisch identisch mit der einer nativen Umgebung, obwohl die derzeitigen Intel- und AMD-Prozessoren noch leistungsmindernde Anpassungen erfordern.

Bei der Leistung der virtuellen Peripherie kann es allerdings große Unterschiede geben. Hier sind im Einzelfall genaue Untersuchungen erforderlich, ob das gewünschte Virtualisierungsziel überhaupt erreichbar ist.

Abbildung 1: Virtuelle Maschine mit einem Virtual Machine Monitor. Ein konkretes Beispiel für diesen Aufbau ist VMware ESX.

Abbildung 2: Virtuelle Maschine mit vollständigem Wirtsbetriebssystem. So arbeitet zum Beispiel VMware Workstation.

Virtuelle Server

Erzwingen die Anforderungen keine vollständige Virtualisierung, sondern geht es hauptsächlich um eine sichere Kapselung von Anwendungen und Diensten und darf der Betriebssystemkern für Gäste und Wirt identisch sein, dann kommen virtuelle Serverumgebungen oder Betriebssystempartitionen in Betracht. Wenn ein Betriebssystemkern über die Möglichkeit verfügt, die Menge der Prozesse, das Dateisystem sowie alle weiteren Ressourcen derart aufzuteilen, dass sich Prozesse unterschiedlicher Partitionen nicht gegenseitig beeinflussen und auch die Ressourcen der anderen Partition nicht erreichen, dann lassen sich diese Partitionen beinahe wie eigenständige physische Server betreiben. (Abbildung 3).

Abbildung 3: Partitionierung des Betriebssystems. Das ist die Technik von Linux Vserver und OpenVZ, der Jails in FreeBSD oder der Zonen in Solaris.

Die Vorteile der Partitionierung sind: Weniger Latenz und Overhead gegenüber virtuellen Maschinen, bei denen mehrere Kerne neben- und übereinander arbeiten und Daten mehrfach gepuffert und umkopiert werden. Genau wie bei virtuellen Maschinen ist hier auf das Lastprofil der Dienste und Applikationen in den Partitionen zu achten. Der Performanceverlust gegenüber einer nativen Umgebung ist zwar vernachlässigbar, doch eine Kapazitätsplanung muss auch hier erfolgen. Ein Over-Committment ist nicht grenzenlos möglich.

Wenn also Aktivitätsträger (Threads) nicht mehr nur in traditionellen Prozessen gekapselt sind, sondern darüber hinaus genau einer Partition zugeordnet werden, können Root-Prozesse der Partition A die Prozesse der Partition B weder sehen noch beeinflussen. Gleiches gilt für das Dateisystem. Bekommt die Partition A einen Teilbaum ab »/A« exklusiv zugeordnet und die Partition B einen Teilbaum ab »/B«, dann sind hier auch die Rechte des übermächtigen Root-Users gut kanalisiert. Natürlich muss der Admin auch alle anderen Ressourcen entsprechend zuteilen, zum Beispiel die Netzwerkinterfaces. Ein direkter Hardwarezugriff ist dabei sicher auszuschließen. Ein Zugriff auf »/dev/kmem« oder »/dev/sda« darf ausschließlich den Root-Prozessen einer bestimmten Partition erlaubt sein.

Jail House

Eine recht frühe Realisierung dieses Konzepts findet sich in den so genannten Jails von FreeBSD [13]. Jails erweitern den unter Unix bekannten Ansatz einer Chroot-Umgebung um die Partitionierung des Prozessraums und der Netzwerkinfrastruktur. Dabei sind für Prozesse in einer Jails-Umgebung keine Aktionen mehr möglich, die das gesamte System betreffen. Aus einem Jail heraus kann man zum Beispiel keine Kernelmodule laden, keine Dateisysteme montieren, Gerätedateien erzeugen oder das System rebooten.

Für den Linux-Kern gibt es die Projekte Linux Vserver [8] sowie OpenVZ [9] mit seiner kommerziellen Variante Virtuozzo [10]. Auch Sun hat ab der Solaris-Version 10 mit den so genannten Zonen [11] ein technisch vergleichbares Produkt. Es gelten prinzipiell die gleichen Beschränkungen wie bei den Jails in FreeBSD. Für Linux gehen Linux Vserver (siehe Artikel in diesem Heft-Schwerpunkt) und OpenVZ unterschiedliche technische Wege, auch ihre Userlevel-Werkzeuge sind verschieden.

Linux Vserver

Bislang gehört noch keins der Projekte Linux Vserver und OpenVZ zum offiziellen Bestandteil des Linux-Kerns. Allerdings sind die Modifikationen in beiden bereits recht weit fortgeschritten und stabil. Beide unternehmen deshalb auch Anstrengungen, um die Zustimmung der Kernelentwickler zu bekommen. Es wäre schön, wenn dieser Prozess dazu führte, dass zwar die zur Virtualisierung notwendigen Dinge in die Codebasis des Kerns einfließen, aber projektspezifische Anteile weiterhin getrennt blieben.

Linux Vserver ist das derzeit am weitesten verbreitete Projekt. Es baut auf den im aktuellen Linux-Kern enthaltenen Mechanismen auf, et- wa Posix-Capabilities für Prozesse [15], Namespaces, den Resource-Limits und den Extended Attributes für das Dateisystem. Dies reicht aber für die genannten Anforderungen noch nicht aus. Die Vserver-Patches fügen daher die so genannten Prozesskontexte ein und ermöglichen eine begrenzte Bindung der Prozesse an Netzwerkadressen.

Neben diesen wichtigen Erweiterungen kommt noch eine Rechtebegrenzung für alle Prozesse eines Kontextes mit Hilfe der Posix-Capabilities hinzu, außerdem die Möglichkeit, Dateien einem Kontext zuzuordnen. Im praktischen Einsatz sind Dinge wie kontextbezogenes Accounting und Scheduling gefragt, die auch zu einem großen Teil abgedeckt werden. Darüber hinaus gibt es mit den Userlevel-Tools Util-Vserver einen überaus nützlichen Werkzeugkasten.

OpenVZ

Obwohl das kommerzielle Virtuozzo von SWsoft schon lange angeboten wird, ist der Open-Source-Ableger OpenVZ erst seit ein paar Monaten verfügbar. OpenVZ stellt die Modifikationen am Linux-Kern und einige Userlevel-Werkzeuge bereit. Virtuozzo bietet kommerziellen Kunden eine ganze Management-Suite mit einer Management Console (VZMC) sowie einem Web-basierten Control Center. Professionellen Hostern offeriert SWsoft mit HSPcomplete eine Komplettlösung von der Beauftragung und Bereitstellung bis zur Abrechnung.

OpenVZ führt ähnlich wie Linux Vserver Kontexte ein, um eine Isolation der Prozesse durchzusetzen. Die Netzwerkvirtualisierung erfolgt jedoch ohne Alias-Interfaces, sodass jeder VS seine eigene Firewall einsetzen darf. Die Steuerung des Ressourcenverbrauchs eines VS erfolgt über so genannte User-Beancounter mit feinerer Granularität. Andererseits fehlen derzeit Instrumente für die Vereinheitlichung der VS-Dateisysteme, wie sie mit Copy-on-Write-Link-Breaking in Linux Vserver möglich sind.

Solaris Zones

Solaris Zones sind Bestandteil der Solaris-10-Container. Sun hat recht lange Erfahrung mit der Partitionierung größerer Unix-Systeme. Für die E10000-Maschinen hatten die Amerikaner schon 1996 die Möglichkeit zur statischen Partitionierung eingeführt. Doch waren die Partitionen quasi-autarke Maschinen mit je einem eigenen Betriebssystemkern. Die unmittelbare Vorstufe der jetzigen Container war dagegen der Resource Manager, der bereits in Solaris 9 einfloss. Damit konnte der Admin Prozesse erstmals Pools zuordnen, deren Ressourcenverbrauch sich steuern ließ.

Eine Isolation der Ausführungsumgebungen war damit jedoch noch nicht gegeben. Das ist erst mit den Zonen möglich. Zonen und andere Solaris-eigene Instrumente zur Ressourcenkontrolle, etwa die so genannten Projekte, sind außerdem untereinander kombinierbar.

Die zugrunde liegende Technik ist Linux Vserver und OpenVZ sehr ähnlich. Es findet eine Partitionierung des einen Betriebssystemkerns statt. Für die Installation und Administration der Zonen gibt es mit »zoneadm« und »zonecfg« mächtige Werkzeuge. Loopback-Mounts können die Zonen vereinheitlichen, sie sind allerdings nicht so effizient wie das Copy-on-Write-Link-Breaking oder gar Union-FS [18]. (jcb)