Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 3
Virtualisierung im Vergleich
Linux Virtual Server
Das Projekt Linux Virtual Server (VServer) kann leicht verwechselt werden mit dem ebenfalls »Linux Virtual Server« genannten Projekt, das in gewisser Weise die Umkehrung der Virtualisierung darstellt: Es fasst mehrere reale Server zu einem hochverfügbaren, lastverteilenden Cluster zusammen.
VServer virtualisiert das Betriebssystem, aber nicht die Hardware. Das bedeutet, es läuft ein Kernel (Linux mit VServer-Patch), und dieser stellt eine (beliebige) Anzahl von virtuellen Umgebungen (Virtual Private Servers, VPS) bereit. Jede dieser VPS fühlt sich wie ein separater Rechner an. Das System arbeitet mit »Sicherheitskontexten« (Security Contexts), was als »weiches Partitionierungskonzept« bezeichnet wird.
VServer wurde übrigens von Jacques Gélinas initiiert, dem Autor von Linuxconf, einem umfassenden Programm zur Konfiguration von Linux-Systemen. Auch wenn Linuxconf letztlich untergegangen ist, dürfte es anderen Programmen dieser Art wesentliche Impulse gegeben haben. Nachdem Gélinas keine Zeit mehr für VServer übrig hatte, wurde das Projekt von anderen weitergeführt.
Aus der Sicht eines VPS kann man nur an wenigen Punkten die Virtualisierung erkennen. Die Isolation der VPS gegeneinander soll sicher genug sein, so dass man diese VPS als Hosting-Angebote für Webpräsenzen verwenden kann. Jede VPS kann Prozesse und Dienste ausführen, die unabhängig von allen anderen VPS sind. Die meisten Dienste sollen sich unverändert einsetzen lassen, bei manchen sind jedoch kleine Anpassungen nötig.
In jedem VPS startet eim Prinzip ein Standard-Linuxsystem mit den üblichen Init-Skripten. Auch die Benutzer sind für jeden VPS separat definiert. Es gibt in jedem VPS einen Root-Benutzer, der jedoch wie auch die anderen User keinen Zugriff auf den Hostrechner oder andere VPS hat. Software kann installiert, deinstalliert und konfiguriert werden, wie in einem normalen System.
Bei VServer ist die Isolation zwischen den Gastsystemen untereinander und zwischen Gast und Host nicht perfekt. So ist es nötig (zumindest wenn man Quotas verwenden will), Dateien mit einer Kontext-ID zu markieren. Das geschieht für den Anwender unmerklich, ist aber dennoch seltsam. Mounts in einem VServer sind wegen des globalen Namensraums für Dateisysteme in anderen sichtbar. Mounts des Hostsystems dürften über /proc/mounts in jedem Gastsystem zu sehen sein. Durch die Verwendung von privaten Namensräumen, die in neueren Linux-Kerneln zur Verfügung stehen, soll dieser Punkt verbessert werden.
Die Isolation zwischen den Gästen scheint eine Art chroot zu verwenden. Zusätzlich werden verschiedene Informationen des Kernels virtualisiert, darunter die Systemlaufzeit, Host- und Domainname, Rechnertyp und Kernel-Version, verfügbarer Speicher und Festplattenplatz. Eines der Ziele des Projekts ist, die benötigten Ressourcen zu minimieren, vermutlich für den Zweck, möglichst viele VServer auf einem realen Rechner unterzubringen. So lassen sich Dateien, die in den VPS gemeinsam genutzt und normalerweise nicht geändert werden, als Hardlinks anlegen. Dadurch soll ein VPS mit nur 40 bis 100 MB Festplattenplatz auskommen, wobei die Paketdatenbank den größten Teil davon ausmacht. In Xen ist das schwer realisierbar (eine Xen-VM könnte ihr Dateisystem readonly über NFS mounten, aber die Performance würde wahrscheinlich leiden).
Geräte werden von VServer nicht virtualisiert. Daher darf das Verzeichnis /dev auch nur eine minimale Menge von Einträgen enthalten, denn über eine Device-Datei wäre dem Gastsystem der Zugriff auf das Gerät möglich.
VServer bietet keine vollständige Virtualisierung der Netzwerkkarte und kann daher auch keine Netfilter-Regeln in den Gastsystemen anwenden. Auch hier ist die Isolation nicht perfekt. Root kann in einem VPS eine Option setzen, die es ihm ermöglicht, den gesamten Traffic des Hosts und aller VPS zu sniffen. Eine bessere Virtualisierung des Netzwerkstacks ist unter dem Namen ngnet in Arbeit.
VServer verfügt auch über eine Ressourcenverwaltung, die jedoch erst teilweise implementiert ist. Sie steuert die Menge der Ressourcen, die jedem VPS zur Verfügung steht. Dies sind neben CPU-Leistung, RAM und Festplattenplatz auch die Anzahl der Prozesse. Alle Limits sind optional und einige sind noch nicht oder unvollständig vorhanden.
VServer bietet kein Checkpointing, doch wenn das Dateisystem auf einen anderen Rechner gespiegelt wird, sei es mit rsync, DRBD oder anderen Methoden, kann ein VPS blitzschnell auf dem anderen System wieder gestartet werden. Ein echtes Failover ist das natürlich nicht. Insbesondere verliert der VPS alle Verbindungen zu anderen Rechnern.
FreeVPS
FreeVPS ist ein früher Fork von Linux Virtual Server, der einige von dessen Nachteilen überwinden soll. FreeVPS ist nur für Red Hat Enterprise Linux und dessen Clones verfügbar. Der einzige unterstützte Kernel der 2.6er-Reihe dürfte 2.6.9 sein.
Gegenüber VServer führt FreeVPS private Disk-Namespaces ein, die zu einer vollständigen Isolation der Dateisysteme der Gäste führen sollen. Ein Mount innerhalb eines VPS ist damit nur noch in diesem sichtbar. Die zweite große Änderung ist die Virtualisierung des Netzwerk-Stacks, die auch in diesem Bereich für eine gute Isolation sorgt und die Anwendung von Netfilter usw. möglich macht.
Näher habe ich mir FreeVPS nicht angesehen. Die Features, die es VServer derzeit voraushat, sind auch bei VServer in Arbeit, so dass das Projekt eine fragliche Zukunft hat.
