Aus den geplanten zwei Stunden sind beinahe vier Stunden geworden, in denen keiner der Dienste auf unserem Server erreichbar gewesen ist.
Der Grund hierfür war eine vollständige Umstellung der Virtualisierungsplattform. Bisher kam auf der Maschine der VMware Server zum Einsatz, der sich auf Dauer leider als Ressourcenverschwender herausgestellt hat. Obwohl ich zwischenzeitlich schon auf zwei virtuelle Maschinen reduziert hatte und in diesen virtuellen Maschinen verhältnismäßig wenige Dienste laufen, war der Server häufig unter Volllast, Logins auf den Maschinen haben viel zu lange gedauert, manchmal reagierten die virtuellen Maschinen kaum noch. Es wurde also dringend Zeit nach einer Alternative Ausschau zu halten.
Durch meine Arbeit an der Ostfalia Hochschule bin ich auf die Virtualisierungslösung OpenVZ gestossen. OpenVZ ist kein Vollvirtualisierer wie es VMware Server, Parallels oder VirtualBox sind, sondern eine containerbasierte Virtualisierungslösung. Dank dieser anderen Herangehensweise, die einem chroot-Verfahren ziemlich ähnelt, ist der Ressourcenbedarf bei ähnlichen Betriebssystemen ziemlich gering. Als Nachteil erkauft man sich die fehlende Möglichkeit, Fremdsysteme, wie bspw. Windows, auf einem Linux-Server zu installieren. OpenVZ eignet sich also nur dann, wenn ohnehin nur Linux-Varianten zum Einsatz kommen sollen. Da dies in meinem Falle zutrifft, habe ich aber die perfekte Lösung für meine Zwecke gefunden. Wer neben Linuxen noch Windows-Installationen benötigt, sollte einen Blick auf Proxmox Virtual Environment werfen, ein Produkt aus deutschen Landen, welches OpenVZ und eine KVM-Virtualisierung mit libvirt unter einen Hut bringt und das ganze System sogar recht komfortabel über eine webbasierte Konfigurationsoberfläche administrieren lässt. Diese Lösung existiert sowohl als freie als auch als kommerzielle Variante.
Zurück zu OpenVZ. Um OpenVZ zu installieren braucht es nicht sonderlich viel Fachwissen. Auf einem Debian-Etch-basierenden Host genügt es, den passenden OpenVZ-Kernel einzuspielen. Die Kontrollwerkzeuge werden durch entsprechende Abhängigkeiten automatisch installiert. Der Installationsprozess sollte auch dafür sorgen, dass der Kernel beim nächsten Start des Host-Systems automatisch geladen wird.
Das grundlegende Setup ist damit auch schon abgeschlossen. Eine virtuelle Maschine anzulegen ist ziemlich simpel:
vzctl create VM_ID --ostemplate TEMPLATE_NAME --ipadd IPADRESSE --hostname HOSTNAME (-- config CONFIG_NAME)
erzeugt eine neue VM mit der ID VM_ID (ein reiner Zahlenwert), mit dem Betriebssystem aus TEMPLATE_NAME (dazu gleich mehr), mit der IP-adresse IPADRESSE, dem Hostnamen HOSTNAME und optional den Voreinstellungen aus der Datei CONFIG_NAME.
Erklärungsbedürftig sind an dieser Stelle die Werte für die Parameter —ostemplate und —config.
Um ein Betriebssystem in einen OpenVZ-Container zu installieren wird nicht wie man es von einer KVM-Lösung gewöhnt ist mittels eines ISOs das System eingespielt, es wird eine Art Template, also Vorlage verwendet. Diese Templates gibt es zuhauf auf den Unterseiten von OpenVZ, auch die Jungs von Proxmox VE halten einige Templates bereit. Die TAR-GZ-Archive müssen nicht entpackt werden, sie werden einfach in das Template-Verzeichnis von OpenVZ gespeichert und stehen dann dort über den oben genannten Parameter zur Verfügung. Zu beachten ist eigentlich nur, dass der Templatename ohne .tar.gz zu schreiben ist. Auf meinem Debian-Host ist es der Pfad
/var/lib/vz/template/cache
Der Parameter —config dient der Verwendung einer Standardvorlage für einen neuen Container. Da die Konfigurationsdateien von OpenVZ recht schwer verständlich sind, bietet sich das Tool
an. Nach dem Aufruf des Tools wird man nach der Anzahl der auf dem Server gewünschten VMs gefragt. Diese Ausgabe kopiert man dann einfach in eine Datei, welche wiederum im Verzeichnis
gespeichert wird. Der Dateiname muss mit ve beginnen und mit .conf-sample enden, damit er als Vorlage dienen darf. Die Zeichen zwischen diesen Zeichen wiederum werden dem Parameter —config übergeben. Heißt die Datei also ve-16ve.conf-sample muss der Schalter —config 16ve heißen. Am Ende eines solchen Templates ist das Einfügen einer Zeile mit dem Inhalt ONBOOT=“yes” empfehlenswert, damit die VM beim Neustart des Hosts gleich mit gestartet wird.
Nach der in wenigen Sekunden erledigten Erstellung eines neuen Containers müssen noch einige Grundeinstellungen gesetzt werden:
vzctl set VM_ID --nameserver NAMESERVER_IP --userpasswd root:ROOTPW --diskspace nG:mG --save
Der Parameter —diskspace wird mit einem Soft- und einem Hard-Limit angegeben. n und m sind jeweils durch Zahlenwerte zu ersetzen, die auch physikalisch auf der Festplatte des Hosts stattfinden.
Mit einem beherzten
sollte die neu angelegte VM starten und ein paar Meldungen auf dem Bildschirm ausgeben. Mit
meldet man sich direkt in der VM an und kann auch ohne funktionierendes Netzwerk oder SSH in der Maschine arbeiten. Als allererstes sollte man, unabhängig vom verwendeten Template alle Paketlisten und Pakete aktualisieren. Danach kann man wie gewohnt arbeiten, Pakete installieren, etc. Soll die VM angehalten werden, wird auf dem Host der Befehl
aufgerufen. Die VM wird nun sauber heruntergefahren.
Wie mein Freund und Kollege Arne herausgefunden hat, muss man Ubuntu 10.04.1 nach einem Systemupdate noch Manieren beibringen, da sonst das Netzwerk nicht funktioniert. Damit Ubuntu im Container wieder kommunizieren kann, muss folgende Datei samt Inhalt angelegt werden:
/etc/init/openvz.conf
# OpenVZ - Fix init sequence to have OpenVZ working with upstart
description "OpenVZ"
start on startup
task
pre-start script
# mount -t devpts devpts /dev/pts
# mount -t tmpfs varrun /var/run
# mount -t tmpfs varlock /var/lock
mkdir -p /var/run/network
# if [ ! -e /etc/mtab ]; then
# cat /proc/mounts > /etc/mtab
# fi
# touch /var/run/utmp
# chmod 664 /var/run/utmp
# chown root.utmp /var/run/utmp
# if [ "$(find /etc/network/ -name upstart -type f)" ]; then
# chmod -x /etc/network/*/upstart || true
# fi
end script
script
start networking
# initctl emit filesystem --no-wait
# initctl emit local-filesystems --no-wait
# initctl emit virtual-filesystems --no-wait
# init 2
end script
Nach einem Neustart der VM sollte das Netzwerk wieder funktionieren.
Aufgefallen ist mir auch, dass in vielen Templates als Zeitzone Moskau gesetzt ist, was natürlich auch entsprechend des Standorts eures Servers geändert werden sollte.
OpenVZ ist eine unheimlich flexible Lösung, wenn nur Linux-OSe eingesetzt werden sollen. Das Anlegen einer neuen VM ist in wenigen Sekunden geschehen, der Start einer solchen dauert nicht länger. Ein Freund verriet mir, dass auf großen Servern, die im professionellen Webhosting eingesetzt werden, durchaus bis zu 200 solcher virtuellen Container untergebracht werden könne, ohne Performanceeinbußen festzustellen. Aber auch für kleine Unternehmen bietet sich eine solche Lösung an. Mein Server steht im Übrigen bei Hetzner und stemmt jetzt immerhin vier virtuelle Maschinen, in denen schon ein wenig Leben herrscht.
