Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 3
Virtualisierung im Vergleich
OpenVZ
OpenVZ ist die freie Basis der kommerziellen Lösung »Virtuozzo« von SWsoft. Es virtualisiert das Betriebssystem, aber nicht die Hardware. Das bedeutet, es läuft ein Kernel (Linux mit OpenVZ-Patch), und dieser stellt eine (beliebige) Anzahl von virtuellen Umgebungen (Virtual Environments, VEs) bereit. Jede dieser VEs fühlt sich wie ein separater Rechner an. Nur an wenigen Punkten, wenn überhaupt, kann man die Virtualisierung erkennen. Die Isolation der VEs gegeneinander soll sicher genug sein, dass man diese VEs als Hosting-Angebote für Webpräsenzen verwenden kann. Jede VE kann Prozesse und Dienste ausführen, die unabhängig von allen anderen VEs sind. In der VE startet eim Prinzip ein Standard-Linuxsystem mit den üblichen Init-Skripten. Auch die Benutzer sind für jede VE separat definiert. Es gibt in jeder VE einen Root-Benutzer, der jedoch wie auch die anderen User keinen Zugriff auf den Hostrechner oder andere VEs hat. Software kann wie in einem normalen System installiert, deinstalliert und konfiguriert werden.
Prozesse einer VE in OpenVZ sind normale Prozesse des Hostsystems. Sie können auf jedem Prozessor des Hostsystems laufen, womit alle Prozessoren ausgenutzt werden können. Das Dateisystem einer VE ist ein Unterverzeichnis auf dem Host-System, so wie es auch bei einem chroot der Fall wäre. Nur ist bei OpenVZ eine stärkere Isolation gegeben als bei chroot. Da der Host auf alle Dateien des Gastes Zugriff hat, ist der Dateiaustausch zwischen Host und Gast unproblematisch und der vorhandene Plattenplatz lässt sich besser ausnutzen, da keine separaten Partitionen angelegt werden müssen.
Das Netzwerk wird von OpenVZ weitgehend virtualisiert. Jede VE kann eine oder mehrere IP-Adressen haben. Dabei ist jede VE ist von anderen VEs und dem physischen Netz isoliert. Dies schafft Privatsphäre, da es nicht möglich ist, den Traffic einer anderen VE oder des Hosts mit Sniffern mitzuhören. Innerhalb der VEs ist es möglich, Routing und Firewall-Regeln einzurichten, die nur für diese einzelne VE gelten.
OpenVZ verfügt auch über recht weitreichende Ressourcenverwaltung. Sie steuert die Menge der Ressourcen, die jeder VE zur Verfügung steht. Dies sind neben CPU-Leistung, RAM und Festplattenplatz auch die »User Beancounter«, mit denen rund zwanzig Parameter einstellbar sind, darunter Speicher, Shared Memory und die Anzahl der Prozesse. Soweit ich sehe, ist das Setzen der Limits optional; da ich plane, 2-4 virtuelle Maschinen einzusetzen, auf denen sich keine fremden Benutzer tummeln, könnte ich darauf verzichten. Wenn man Disk-Quotas nutzen will, sollte man laut FAQ des Projekts ext3 einsetzen, da dies mit XFS nicht möglich sei.
Seit April 2006 besitzt OpenVZ auch die Fähigkeit für »Checkpointing und Live-Migration«. Mit Hilfe des Tools »vzmigrate« sollen sich VEs ohne Unterbrechungszeit zwischen Hosts migrieren lassen. Rechner, die mit der migrierten VE verbunden sind (z.B. Clients), sollen von der Migration abgesehen von einer kurzen Unterbrechung nichts mitbekommen.
Bei der Installation ist es sicherlich wiederum die einfachste Methode, Pakete seiner Distribution einzusetzen, sofern vorhanden. Ist das nicht der Fall, dann kann man, wenn man Fedora oder Red Hat einsetzt, auf fertige Kernels von OpenVZ setzen. Ansonsten kann man eine Patch herunterladen und ihn auf seinen eigenen Kernel anwenden. Eine brauchbare Anleitung ist vorhanden.
Ein Problem mit OpenVZ ist, dass die stabile Version auf dem alten Kernel 2.6.9 beruht. Alles neuere ist offiziell »Beta«. Es wird auch nicht jede Version unterstützt. Es gibt Patches für Kernel 2.6.16 und seit kurzem auch für 2.6.18. Sollte man aus unerfindlichen Gründen 2.6.17 benötigen, hat man Pech gehabt.
Der Host wird bei OpenVZ auch als »Hardware Node« bezeichnet. Auf diesem läuft der mit OpenVZ gepatchte Kernel. SELinux muss deaktiviert sein, damit OpenVZ richtig funktionieren kann. Der Hardware Node sollte nur eine minimale Installation besitzen, die dem Installationstyp »Server« bei vielen Linux-Distributionen ungefähr entspricht. Es wird empfohlen, für die VEs eine eigene Partition einzurichten, die unter /vz gemountet wird. Das Hostsystem sollte mit 2-4 GB für das Root-Dateisystem und dem Doppelten des RAMs als Swap auskommen. Ist der Kernel gebootet, kann mit
/sbin/service vz start
OpenVZ gestartet werden, wobei die benötigten Kernelmodule geladen werden. (Die Befehlszeile ist für Fedora und kann unter anderen Distributionen anders lauten).
Eines fehlt noch: Die Einrichtung der VEs. Diese erfolgt mit sogenannten »Templates«. Ein solches Template ist leicht herzustellen. Der aufwendigste Schritt ist dabei, das Dateisystem der VE zu erstellen. Das kann mit verschiedenen Tools erledigt werden, die spezifisch für die jeweilige Distribution sind. Notfalls macht man eine minimale Installation des Gastsystems auf einem realen Rechner, erstellt ein Tar-Archiv des Dateisystems und entpackt es auf dem Host. Für verschiedene Distributionen gibt es Anleitungen zur möglichen Vorgehensweise. Die Erstellung eines Templates kann von 10 Minuten bis einigen Stunden in Anspruch nehmen. Ist es aber einmal erstellt, so lassen sich VEs, die auf diesem Template beruhen, binnen zwei Minuten aufsetzen. Dies lässt sich auch als Skript erledigen, um Dutzende oder Hunderte von VEs auf einmal zu erstellen.
Allerdings bietet OpenVZ im Download-Bereich bereits fertige Templates im Umfang von ca. 40 bis 100 MB zum Download an. Mit solch einem vorgefertigten Template reduziert sich das Starten eines neuen VEs im Wesentlichen auf drei Kommandos vzctl create, vzctl set --ipadd und vzctl start und ist in einer Minute erledigt.
