Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.
OpenVZ erstellt mehrere isolierte Container für Betriebssysteme. Dazu werden alle Prozesse dieser Betriebssysteme in einem einzigen Kernel verarbeitet. Die Betriebssysteme in den Containern sind dennoch weitgehend unabhängig voneinander und können beispielsweise unabhängig voneinander heruntergefahren werden. Sie verfügen außerdem jeweils über ihr eigenes Root-Konto.
Im Vergleich zu Virtuellen Maschinen von VMware oder zu Paravirtualisierungen wie Xen bietet OpenVZ weniger Auswahl an Betriebssystemen: sowohl der Host als auch die Gäste müssen unter Linux laufen, nur die Linux-Distributionen können sich unterscheiden. Andererseits bietet OpenVZ bessere Leistungsfähigkeit, Skalierbarkeit, dynamische Ressourcenverwaltung und einfachere Administration an. Der Virtualisierungsaufwand oder Overhead durch OpenVZ ist vernachlässigbar gering.[2]
OpenVZ wurde im Jahr 2005 aus dem kommerziellen Virtuozzo heraus von dessen Hersteller als Open Source eingeführt.[3]
OpenVZ besteht aus Erweiterungen des Kernels und Werkzeugen auf Benutzerebene.[4]
Kernel
Der OpenVZ-Kernel ist ein modifizierter Linux-Kernel, der den Begriff Virtual Environment (VE) einführt. Der Kernel gewährleistet die Funktionalität von Virtualisierung, Isolierung, Ressourcenverwaltung und Checkpointing.
Virtualisierung und Isolierung
Jedes VE ist eine separate Einheit, die vom Standpunkt ihres Besitzers wie ein physischer Server aussieht. Das bedeutet, jedes VE hat unter anderem eigene
Jedes VE hat den Benutzer „root“ sowie auch andere Benutzer und Gruppen.
Prozessbaum
Ein VE kann nur eigene Prozesse sehen, die standardmäßig von init stammen. PIDs (Prozess-IDs) sind virtualisiert, so dass z. B. PID von init in jedem VE gleich 1 ist.
Netzwerk
Virtuelles Netzwerkgerät ermöglicht einem VE, eine eigene IP-Adresse zu haben, sowie ein Set von Netzwerkfiltern (iptables) und Routingtabellen.
Devices
Falls nötig, kann für ein VE ein Zugang zu realen Geräten wie Netzwerk-Schnittstellen, seriellen Ports, Festplatten-Partitionen usw. gewährleistet werden.
IPC-Objekte
Gemeinsam genutzter Speicher, Semaphore, Nachrichten
Ressourcenverwaltung
Weil alle VEs denselben Kernel nutzen, spielt die Ressourcenverwaltung die wichtigste Rolle. Tatsächlich muss jedes VE im Rahmen der zugewiesenen Ressourcengrenzen bleiben und darf nicht die anderen VEs beeinflussen. Genau das ist die Kompetenz der Ressourcenverwaltung.
Die OpenVZ-Ressourcenverwaltung besteht aus drei Subsystemen: Zwei-Ebenen-Festplattenquota, CPU-Planer und User Beancounters. Alle diese Ressourcen lassen sich im laufenden Betrieb ändern, es ist dafür kein Neustart nötig. Soll einem VE beispielsweise mehr RAM zugewiesen werden, können die entsprechenden Parameter „on the fly“ geändert werden. Bei VM-basierten Virtualisierungslösungen ist dies nicht ohne weiteres möglich.
Zwei-Ebenen-Festplattenquota
Die erste Ebene ist die pro-VE Festplattenquota, die zweite Ebene ist die standardmäßige UNIX-Festplattenquota pro Benutzer und pro Gruppe innerhalb eines VEs.
Um mehr Festplattenplatz zu einem VE zuzuweisen, braucht man nur die entsprechende Festplattenquota zu vergrößern.
Auf der ersten Ebene entscheidet der Planer, welches VE den CPU-Takt erhält. Das wird entsprechend dem per-VE cpuunits-Wert gemacht. Auf der zweiten Ebene entscheidet der standardmäßige Linux-Planer, welcher Prozess in ausgewähltem VE den CPU-Takt bekommen soll. Dabei werden wie immer die Standard-Linux-Prioritäten von Prozessen usw. benutzt.
Der OpenVZ-Administrator kann verschiedene Werte von cpuunits für verschiedene VEs definieren. In diesem Fall wird CPU-Zeit proportional laut den angegebenen Werten der VEs verteilt.
Außerdem steht die Möglichkeit zur Verfügung, die CPU-Zeit zu limitieren. D. h., man kann z. B. 10 % der CPU-Zeit einem VE zuweisen.
User Beancounters
Die User Beancounters sind ein Set von pro-VE-Ressourcenzählern, Limits und Garantien. Es gibt etwa 20 Parameter, die sorgfältig ausgewählt werden müssen, um alle Aspekte der VE-Funktionalität zu berücksichtigen.
Damit darf jedes einzelne VE nur die zugewiesenen Ressourcen nutzen und keinen Einfluss auf das Hostsystem oder andere VEs haben.
Die kontrollierten Ressourcen sind RAM und verschiedene in-kernel-Objekte wie IPC shared memory segments, network buffers usw. Jede Ressource kann man in /proc/user_beancounters anschauen. Hier werden 5 Werte für jeden einzelnen Parameter angezeigt: Aktuelle Auslastung, maximale Auslastung, Soft-Limit, Hard-Limit und fail counter.
Die Bedeutungen von Soft-Limit und Hard-Limit sind verschieden und hängen von Parametern ab. Generell gilt: wenn irgendeine Ressource das Limit überschreitet, wird der entsprechende fail counter erhöht. So kann der Besitzer des VEs, falls irgendein Problem im VE auftritt, die Ausgabe von /proc/user_beancounters analysieren und mögliche Ursachen ausfindig machen.
Checkpointing und Live-Migration
Live-Migration und Checkpointing sind Funktionen, die von OpenVZ Mitte April 2006 veröffentlicht wurden. Sie ermöglichen, ein VE von einem physischen Server auf den anderen zu migrieren, ohne dabei das VE stoppen/neu starten zu müssen. Der Vorgang ist als Checkpointing bekannt, und die Hauptidee besteht darin, ein VE einzufrieren und alle Prozesse in eine Datei zu speichern. Diese Datei kann dann auf eine andere Maschine übertragen und alle Prozesse können dort wiederhergestellt werden. Die ganze Übertragung des VEs nimmt nur einige Sekunden in Anspruch und verursacht damit keine Downtime, sondern nur eine leichte Verzögerung.
Die Tatsache, dass jeder Teil des VE-Status, wie z. B. geöffnete Netzwerkverbindungen, gespeichert wird, macht den ganzen Migrationsprozess für den Benutzer völlig transparent. Während des Verschiebens des VEs kann z. B. eine Transaktion mit einer Datenbank laufen, die viel Zeit benötigt. In diesem Fall merkt der Benutzer nicht, dass die Datenbank schon auf einem anderen Server läuft.
Dieses Merkmal ermöglicht, Szenarien wie das Upgrade eines Servers ohne Neustart durchzuführen. Wenn eine Datenbank oder andere Applikation in einem VE mehr RAM oder CPU-Ressourcen braucht, kann man einfach eine andere, bessere Maschine kaufen, dieses VE live darauf migrieren und dann die entsprechenden Limits vergrößern. Wenn es z. B. nötig ist, zusätzliches RAM hinzuzufügen, kann man alle VEs auf einen anderen Server migrieren, das Upgrade auf der Maschine durchführen und dann alle VEs zurück migrieren.
Werkzeuge auf Benutzerebene
OpenVZ hat sowohl Kommandozeilen-Werkzeuge für die Verwaltung von VEs (vzctl), als auch Werkzeuge für die Verwaltung von Applikationen in VEs (vzpkg).
vzctl
vzctl ist ein einfaches high-level Kommandozeilen-Werkzeug für die Verwaltung von VEs.
Dieser Befehl erzeugt ein neues VE, das eine numerische ID, ein angegebenes OS-Template (eine Linux-Distribution) und die Ressourcen, die in der angegebenen Konfigurationsdatei spezifiziert sind, hat. Die beiden Parameter --ostemplate und --config sind optional. Die Hauptkonfigurationsdatei enthält Standardwerte für beide.
vzctl start VEID
Startet das angegebene VE. Das Starten bedeutet das Erzeugen eines Virtual Environment im Kernel, Initialisieren von allen Ressourcenverwaltungsparametern und Starten des VEs /sbin/init in diesem Umfeld.
vzctl stop VEID
Stoppt das angegebene VE. Ein VE kann auch mit Hilfe von eigenen /sbin/halt oder /sbin/reboot -Befehlen gestoppt oder neu gestartet werden.
vzctl exec VEID <command>
Startet den Befehl <command> im angegebenen VE. Um beispielsweise alle Prozesse im VE 102 anzeigen zu lassen, kann man vzctl exec 102 ps ax nutzen.
vzctl enter VEID
Öffnet die VE-Shell. Das ist nützlich, wenn z. B. sshd nicht gestartet ist und das Problem untersucht werden soll.
vzctl set VEID --parameter <value> […] [--save]
Setzt den angegebenen Parameter für das VE. Hier können verschiedene Parameter benutzt werden; um z. B. eine IP-Adresse zu einem VE hinzuzufügen, geben Sie vzctl set VEID --ipadd x.x.x.x --save ein. Um die Festplattenquota für das VE festzulegen, verwenden Sie vzctl set VEID --diskspace soft:hard --save. Um das Kernel-RAM-Soft-Limit und -Hard-Limit für VE zu (re)definieren, müssen Sie den Befehl so starten: vzctl set VEID --kmemsize barrier:limit --save
vzlist
vzlist zeigt die Liste der VEs an.
vzlist [ -a ]
Dieser Befehl zeigt den Zustand und den Ressourcenverbrauch der VEs an
VEID NPROC STATUS IP_ADDR HOSTNAME
110 21 running 192.168.0.1 dns
111 0 stopped 192.168.0.21 www
Templates und vzpkg
Templates sind vorgefertigte Images, die zum Erzeugen von VEs benutzt werden. Ein Template ist ein Set von Paketen, und ein Template-Cache ist ein Tar-Archiv einer chroot-Umgebung, in der alle Pakete installiert sind. Während der Ausführung von vzctl create wird das Tar-Archiv entpackt. Diese Technik ermöglicht, ein VE in wenigen Sekunden zu erzeugen.
Die Entwickler stellen Template-Caches für die gebräuchlichsten Linux-Distributionen auf der Projekt-Webseite zum Download zur Verfügung.
vzpkg ist ein Satz von Werkzeugen, mit dem das Erzeugen eines Template-Caches wesentlich vereinfacht wird. Es unterstützt rpm- und yum-basierende Repositories. Um ein Template, z. B. Fedora Core 5, zu erstellen, braucht man ein Set von (yum-)Repositories, in denen sich FC5-Pakete befinden, und auch ein Set von Paketen, die installiert werden müssen. Zusätzlich, falls es nötig ist, ein Template anzupassen, stehen auch pre- und postinstall-Skripte zur Verfügung. Alle oben dargestellten Parameter (Repositories, Paketlisten, Skripte, GPG keys usw.) werden als Template-Metadaten dargestellt. Mit Hilfe von Template-Metadaten kann der Template-Cache automatisch erstellt werden. Man braucht nur den vzpkgcache Befehl zu starten. Dabei werden alle angegebenen Pakete auf den Server hochgeladen und in ein temporäres VE installiert. Danach wird das entsprechende Tar-Archiv erzeugt.
Es ist auch möglich, Template-Caches für nicht RPM-basierende Distributionen zu erstellen.
Die wichtigsten Eigenschaften von OpenVZ
Skalierbarkeit
OpenVZ benutzt das Ein-Kernel-Modell und ist deswegen wie der Linux-Kernel 2.6 skalierbar. Es unterstützt somit die Nutzung von bis zu 64 CPUs und 64 GB RAM. Eine einzelne VE kann auf das komplette Hostsystem skaliert werden, d. h. alle CPUs und das gesamte RAM des Hostsystems nutzen. Diese Vorgehensweise virtualisiert die Hardware des VEs: Das in der VE laufende Betriebssystem greift nicht mehr direkt auf die physische Hardware des Hostsystems zu, sondern nutzt die Schnittstellen von OpenVZ. Auf diese Weise ist es möglich, einen Server zur Laufzeit zu migrieren, um gestiegene Ressourcen zu nutzen oder um Hardware-Ausfälle des Hostsystems zu kompensieren.
Dichte
Auf dem Server mit OpenVZ können hunderte von Virtual Environments laufen, ihre Zahl ist hauptsächlich durch den vorhandenen RAM und die CPU-Leistung begrenzt.
Massenverwaltung
Der Administrator des OpenVZ-Servers kann auf Prozesse und Dateien von allen VEs zugreifen. Das erleichtert die Massenverwaltung vieler Server, Sicherheitsupdates in den VEs können durch ein einfaches Skript geschehen. Das ist ein Vorteil gegenüber Virtualisierungslösungen wie VMware oder Xen, die für jede virtuelle Maschine ein manuelles Update erfordern.
Einsatzszenarien
Die folgenden Einsatzszenarien sind für alle Virtualisierungstechnologien gemeinsam. Der Hauptunterschied von Virtualisierungen auf Betriebssystem-Ebene besteht darin, dass der Virtualisierungsaufwand sehr gering ist. Genau das macht solche Szenarien sehr attraktiv.
Sicherheit
Es ist möglich, verschiedene Netzwerkdienste wie Apache, Mailserver, DNS-Server usw. in verschiedenen VEs laufen zu lassen. Falls ein Eindringling eine Sicherheitslücke in einem dieser Dienste findet und in das System eindringt, kann er zunächst nur diesen Dienst beschädigen, weil alle anderen sich in separaten VEs befinden. Damit wird die gesamte Sicherheit des Systems erhöht, wenn die Netzwerkdienste zuvor zusammen auf einem physischen System ausgeführt wurden und es dem Eindringling nicht gelingt, in OpenVZ selbst eine Sicherheitslücke zu finden. Die Sicherheit wird verringert, wenn die Netzwerkdienste vorher auf physisch getrennten Systemen ausgeführt wurden.
Server-Konsolidierung
Heutzutage ist die Mehrzahl der Server wenig ausgelastet. Mit Hilfe von OpenVZ können solche Maschinen beim Migrieren in Virtual Environments konsolidiert werden. Die Ersparnisse liegen beim Platz im Rack, Strom und dem Verwaltungsaufwand.
Hosting
Zweifellos ist die Virtualisierung auf Betriebssystem-Ebene eine einzigartige Möglichkeit für Hoster, sehr günstige VEs anzubieten. Man muss beachten, dass jedes VE Root-Zugang hat, so dass ein Besitzer eines VEs verschiedene Applikationen (re)installieren und auch Dinge wie iptables (Firewall-Regeln) konfigurieren kann.
Entwicklung und Test
Entwickler und Tester brauchen gewöhnlich einen Zugang zu verschiedenen Linux-Systemen. Dabei wird es erforderlich, diese jederzeit komplett neu installieren zu können. Mit OpenVZ hat man alle verschiedenen Systeme auf demselben Server, und Operationen wie das Erstellen von VEs nimmt nur etwa eine Minute in Anspruch. Es ist auch sehr einfach, ein VE zu klonen. Dafür muss man nur den VE-Bereich und die Konfigurationsdatei kopieren.
Bildungseinrichtungen
Jeder Schüler kann ein eigenes VE haben. Es ist möglich, mit verschiedenen Linux-Distributionen zu arbeiten. Ein neues VE kann in nur einer Minute erstellt werden.
Thin-Client-Systeme
Es können mehrere Application-Server in VEs realisiert werden. Auf diese kann jeweils via Thin-Clients zugegriffen werden. Die verschiedenen Application-Server sind bezüglich Ressourcen durch die OpenVZ Mechanismen gegeneinander geschützt. Zudem können verschiedene Distributionen auf diesen parallel zur Verfügung gestellt werden.
