Login
Login-Name Passwort


 
Newsletter
Werbung

So, 26. November 2006, 00:00

OpenVZ: »Weniger Overhead als Xen«

Interview mit Kir (Kirill) Kolyshkin

Am Rande der LinuxWorld Expo in Köln sprach Pro-Linux mit dem Entwicklungsleiter von OpenVZ, Kir Kolyshkin. Dabei demonstrierte er einige Features, um zu zeigen, wie es in einer virtuellen Umgebung (Virtual Environment, VE) aussieht, und führte auch Checkpoint und Restore, die Grundlage der Live-Migration, vor.

Kir Kolyshkin

Hans-Joachim Baader (hjb)

Kir Kolyshkin

Pro-Linux: Ich bin bereits mit den Grundlagen von OpenVZ vertraut und habe diese auch unseren Lesern in diesem Artikel erläutert, so dass wir uns diesen Punkt sparen können. Was zeichnet OpenVZ im Unterschied zu Xen aus?

Kir Kolyshkin: Zum einen haben wir durch die Betriebssystem-Virtualisierung weniger Overhead als Xen. Je nach Anwendung liegt er um 1%. Zum anderen nutzen wir die Ressourcen des Hosts besser. Es gibt nur einen Kernel, daher ist jeder Prozess in einer VE [Virtual Environment, also das Gastsystem, Anm. d. Red.] auch ein Prozess im Hostsystem. Ich demonstriere das am Init-Prozess. Rufen wir ps ax in der VE auf, sehen wir einen Init-Prozess mit PID 1.

ve:~# ps ax
 PID TTY STAT TIME COMMAND
    1 ? Ss 0:00 init [2]
 9993 ? Ss 0:00 /sbin/syslogd
 9999 ? Ss 0:00 /sbin/klogd -x
10045 ? Ss 0:00 /usr/sbin/exim4 -bd -q30m
10063 ? Ss 0:00 /usr/sbin/sshd
10117 ? Ss 0:00 sshd: root@pts/0
10119 pts/0 Ss 0:00 -bash
10082 ? Ss 0:00 /usr/sbin/atd
10089 ? Ss 0:00 /usr/sbin/cron
 7592 pts/0 R+ 0:00 ps ax

Auf dem Host aufgerufen, zeigt ps ax den Init-Prozess des Hosts mit PID 1 und die Initprozesse aller definierten VEs mit ganz anderen PIDs.

host:~# ps ax | grep init
    1 ? Ss 0:00 init [2]
 6200 ? Ss 0:00 init [2]

Diese PID-Virtualisierung war u.a. für die Live-Migration nötig, denn eine VE, die auf einen anderen Rechner migriert wird, kann dort wegen möglicher Konflikte nicht die gleichen PIDs bekommen. Aus Sicht der VE ändern sich die PIDs natürlich nicht. Und das ist nur ein Teil. Auch /proc, /sys, Interprozess-Kommunikation (IPC) mit Shared Memory, Semaphoren und Message Queues und die Netzwerkschnittstellen sind virtualisiert.

Pro-Linux: Was bringt OpenVZ in der gerade gestern veröffentlichten neuen Version Neues?

Kir Kolyshkin: Live-Migration, eine neue Art virtueller Ethernet-Schnittstellen und Kernel 2.6.9.

Live-Migration bedeutet, einen Checkpoint des VE zu erstellen. Das ist eine Datei, die den Zustand des VE enthält. Diese Datei kann, zusammen mit dem Dateibaum des VE, auf einen anderen Server kopiert werden, wo dann das VE wieder gestartet wird.

Das Kopieren kann mit rsync erfolgen, oder man hält zwei Dateisysteme mit DRBD synchron, oder man nutzt ein Netzwerk-Device gemeinsam. Diesen Fall, dass das Dateisystem automatisch synchron ist, kann man leicht mit einer Migration auf dem lokalen Rechner simulieren. Mache ich hier beispielsweise checkpoint, dann dauert das 0,7s. Man sieht, wie in der VE hier, mit der ich mit VNC verbunden bin, das Display einfriert. Die VE ist suspendiert. Ein anschließendes Restore dauert 1,5s. Eine Live-Migration kann also in wenigen Sekunden ablaufen und die Clients der VE bekommen nichts davon mit, weil die Netzverbindungen mit migriert werden. Sie nehmen nur eine kurze Verzögerung wahr.

Haben die Rechner kein synchrones Dateisystem, kann man das Tool vzmigrate benutzen, das im Prinzip folgendes macht. Es ruft rsync auf, was ein Weilchen dauern kann. In dieser Zeit läuft die VE aber weiter. Danach wird die VE suspendiert und nochmal rsync aufgerufen. Dieses rsync sollte schnell gehen. Dann wird die Statusdatei kopiert und die VE auf dem Zielrechner aufgeweckt.

Neu ist auch der virtuelle Netzwerkstack für jede VE. Es gab vorher schon virtuelle Schnittstellen, mit denen man aber keine Broadcasts und Multicasts machen konnte. Und zwar deshalb, weil diese Devices keine Mac-Adresse hatten. Der Host fungiert als Router.

Mit dem neuen Device veth wird der Host als Bridge konfiguriert und die Beschränkungen sind aufgehoben. Der Nachteil ist eine geringere Performance (wenn auch nur wenig) und der Verlust der Sicherheit. VEs können durch Zuweisung von beliebigen IP-Adressen den Traffic der anderen VEs und des Hosts mithören. Hoster werden also bei den alten venet-Devices bleiben. Die neuen veth-Devices sind nur für vertrauenswürdige Umgebungen gedacht.

Ferner beruht die stabile Version auf Kernel 2.6.9 (RHEL 4), vorher war es 2.6.8.

Pro-Linux: Ist das nicht arg konservativ? Wie kann da neuere Hardware unterstützt werden?

Kir Kolyshkin: Die Kunden verlangen extreme Stabilität, deswegen verwenden wir den extrem zuverlässigen Red Hat-Kernel. Neue Hardware ist kein Problem, da Red Hat auch neue Treiber in diesen zurückportiert hat. Außerdem ist die Entwicklerversion von OpenVZ für Kernel 2.6.16 und 2.6.18 verfügbar.

Pro-Linux: Für welche Kernel-Version wird die nächste stabile Version gemacht?

Kir Kolyshkin: Da gibt es noch keine Pläne.

Pro-Linux: Live-Migration erfordert ja, dass beide beteiligten Rechner noch funktionieren. Was ist, wenn einer ausfällt? Kann man Hochverfügbarkeit mit OpenVZ machen?

Kir Kolyshkin: Ich weiß nur, dass die Entwickler bei Thomas-Krenn.com da etwas mit Heartbeat implementiert haben. Im Wiki gibt es weitere Informationen dazu.

Pro-Linux: OpenVZ läuft auf x86 und x86_64. Welche weiteren Portierungen gibt es?

Kir Kolyshkin: Eine Portierung auf PPC ist fertig. Eine auf SPARC ist in Entwicklung. Nur etwa 5% des OpenVZ-Codes sind hardwareabhängig.

Pro-Linux: Wie sieht die Firmenstruktur bei SWSoft/OpenVZ aus?

Kir Kolyshkin: SWSoft, die Firma, die auf Basis von OpenVZ das proprietäre Produkt Virtuozzo entwickelt, hat den Hauptsitz in den USA, die Entwicklung wird aber überwiegend von einem Team in Moskau gemacht. Nur wenige Leute arbeiten vollzeit an OpenVZ. Ich zum Beispiel als Projektmanager von OpenVZ arbeite die ganze Zeit nur an OpenVZ. SWSoft tritt lediglich als Sponsor auf und ich habe freie Hand in dem Projekt. Die meisten anderen Entwickler arbeiten einen Teil ihrer Zeit an Virtuozzo und einen Teil an OpenVZ.

Pro-Linux: Wie die Virtualisierung in den Linux-Kernel integriert wird, ist ja noch in der Diskussion. Sind aber nicht schon Patches von OpenVZ auch in den offiziellen Kernel eingeflossen?

Kir Kolyshkin: Ja, im Einzelnen sind die Virtualisierung des IPC-Namespaces und von utsname (also dem Hostnamen) in den Kernel eingeflossen. Die PID-Virtualisierung wird für die Integration vorbereitet. Unsere Beancounters, die übrigens auf sechs Jahre alte Ideen von Alan Cox zurückgehen, habe ich gerade in einer neuen Version an die Kernel-Liste geschickt. Diese Implementation könnte in Kernel 2.6.20 erscheinen. Man kann sie als eine stark erweiterte Version von rlimit, also den vorhandenen Prozess-Limits, sehen. Es gibt natürlich einen Performance-Overhead, wenn sie aktiviert sind, aber der ist nicht allzu groß. Man kann die Limits dynamisch ändern, wie man es braucht, und vor allem auch die aktuelle Ressourcen-Nutzung sehen.

Pro-Linux: Vielen Dank für die vielen Informationen!

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung