Im Rahmen meiner RHCE-Ausbildung hatte ich das erste Mal die Gelegenheit, Xen-Installationen für den “professionellen” Einsatz einzurichten. Die überraschend gute Performance auch bei mehreren Instanzen auf einem einzelnen Rechner hat mich sehr beeindruckt. Diese Performance erreicht man indes nur, wenn die virtuellen Maschinen “paravirtualisiert” sind, also dann wenn nicht nur das Wirts- sondern auch das Gastsystem einen Xen-angepassten Kernel verwendet, der gegenseitig kompatibel ist.
Mein Spieltrieb für zu Hause war geweckt. Nach und nach migrierte ich also alle Services themenorientiert auf vier verschiedene sog. DomU’s (unprivilegierte Domains = virtuelle Maschine = Gastsystem, alles austauschbare Begriffe) unter einem CentOS 5.1 Wirts-Server. Dazu benötigt man unter den Redhat Derivaten folgende Komponenten: Xen-Kernel, libvirtd und xend. Dank yum reicht eigentlich ein “yum install kernel-xen” und man hat im Handumdrehen alle notwendigen Werkzeuge für die Virtualisierung zur Hand.

Nach anfänglichen Abhängigkeitsproblemen zwischen den VM’s (oder besser Anfängerfehler, denn das der DNS-Server als erster gestartet werden sollte, müßte mir klar gewesen sein…) kann ich bestätigen, dass die Virtualisierung auch für den kleinen Server im Keller zu Hause durchaus Sinn machen kann. Ich kann nichts über komplexere Applikationen wie Oracle u.ä. sagen aber die Antwortzeiten von LDAP, DHCP, DNS, FTP etc. sind praktisch identisch zu ihren Pendants direkt auf physischen Servern. Auch netzwerktechnisch gesehen ist die Antwortzeit (Ping-Messung) identisch zu einem klassischen Server.

Den Overhead durch die Verwaltung von 4 gleichzeitig laufenden virtuellen Maschinen kann ich indes nur schätzen resp. beobachten. Im Leerlauf sind es zur Zeit nicht mehr als 5-15% des Wirtsystems, die verbraucht werden. Durch die Erweiterung von 2 auf 4 oder gar 6 GB Arbeitsspeicher erhoffe ich mir einen weiteren Leistungsgewinn, da die Resourcen im Moment doch etwas knapp zu sein scheinen, vor allem der Wirt selber hätte etwas mehr Arbeitsspeicher verdient. Die durch den Einsatz des Xen-Kernels fehlende CPU-Geschwindigkeitsregelung (das cpu-ondemand Kernelmodul gibt’s noch nicht für den Xen-Kernel) wird mehr als aufgehoben durch die Tatsache, dass bei mir der 2. Server nicht mehr ständig laufen muss (naja, zumindest sobald ich mir für das Backup resp. NFS/SMB auch eine Lösung geschnitzt habe).
Eine Live-Migration der Server bei einem Ausfall habe ich noch nicht getestet, sobald beide Server RAM-technisch aufgerüstet sind, werde ich dies aber vermutlich in Angriff nehmen. Eine gewisse Flexibilität ist sowieso gegeben, wenn man z.B. wöchentlich die virtuellen Disk-Imagedateien sichert und diese auf einen zweiten Server transferiert. Dann muss im Falle eines Ausfalls des ersten Servers dort nur noch die virtuelle Maschine gestartet werden und schon ist der Service (z.B. FTP) wieder einsatzbereit, ganz ohne weitere Eingriffe in DNS oder DHCP. Dies alleine bedeutet schon einen enormen Fortschritt an Unabhängigkeit im Vergleich zu Server-gebundenen Diensten oder klassischen Failover-Lösungen, da der Server an sich nur noch aus einer Disk-Imagedatei und der Xen-Konfigurationsdatei besteht.

Fazit

Abgsehen vom Aufwand, die VM’s einzurichten, empfinde ich den Serverbetrieb nun als ziemlich aufgeräumt und elegant. Habe ich irgendwo ein Problem, kann ich es auf die betreffende VM eingrenzen. Und auch der Aufwand für die Einrichtung der VM’s lässt sich in engen Grenzen halten, wenn man die Installation mit Kickstart-Konfigurationen, DHCP-vergebenen Adressen sowie mit Netzwerk-Images weitgehend automatisiert.

Hier noch ein Beispiel des virt-install Aufrufes für eine solche automatische Installation. Wenn man das grafische Werkzeug virt-manager zur Einrichtung einer DomU nimmt, geschieht im Hintergrund so ziemlich dasselbe wie hier von Hand:

virt-install --paravirt --name=another_vm --location=http://installserver/centos5_1
--keymap=de_CH --extra-args=ks=http://192.168.1.4/inst/vm_stuff/ks/another_vm.cfg
--ram=512 --vcpus=1 --vnc --file=/vm/xen/images/another_vm.img --file-size=8
--accelerate --mac="00:18:ef:dd:aa:cc"

Als ich mein neues Notebook mit Linux beglücken wollte, stand die Frage des “wie” im Vordergrund. Das Gerät hat nämlich kein eingebautes CD/DVD-ROM, und das als Zubehör mit einer Art Dockingstation verkaufte Gerät ist sauteuer.

Für’s erste begnügte ich mich damit, mein externes USB-Laufwerk zu nehmen, die Festplatte daraus zu entfernen und ein älteres CD-ROM-Laufwerk daran anzuschliessen. Das ganze sah sehr abenteuerlich aus, musste aber nur solange laufen, bis die Installation gelungen war.

Eine elegantere Möglichkeit bietet die Installation über’s Netzwerk. Dazu gibt es ebenfalls schon genügend howto’s. Aber eine wirklich funktionierende Konfiguration hinzubekommen, ist nicht ganz trivial, denn die eingesetzten divergieren sehr

Für mich tat’s ein Standardsetup mit dem Fedorapackage “tftp-server” (ein absolut simpler und unsicherer FTP-Client speziell für dieses Einsatzgebiet) und “dhcp” (der DHCP-Server, der auf die BOOTP-Anfragen der Netzwerkkarten antworten soll). Mit der Installation vom “tftp-server” wird direkt das Verzeichnis /tftpboot/linux-install eingerichtet, welches den pxe-Bootloader pxeboot.0 enthält. Dorthin muss man dann auch folgende Dateien von der Fedora-Installations-DVD aus dem Verzeichnis images/pxeboot kopieren: initrd.img und vmlinuz. Dann muss man noch eine Datei default im /tftpboot/linux-install/pxelinux.cfg (ja das ist wirklich ein Verzeichnis, keine Datei) erstellen. Diese sieht so aus:

default linux
timeout 5

label linux
    kernel vmlinuz
    append initrd=initrd.img  ramdisk_size=8192 method=http://192.168.0.6/inst/fedora8 ip=dhcp

Damit ist auch schon die Installationsmethode angegeben. Hier kann natürlich auch eine der anderen Methoden (NFS, FTP, CDROM) verwendet werden oder die Option kann ganz weggelassen werden, dann wird man während dem Installationsprozess nach einer Methode gefragt.

Was man nun auch noch von Hand machen muss, ist: den DHCP-Server als BOOTP-Server konfigurieren. Dies war der schwierigste Teil, da in keiner Anleitung ein funktionierendes Beispiel zu finden war. In einem Forum wurde ich fündig. Und so sieht sie also aus, die funktionierende dhcpd.conf:

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
allow bootp;
allow booting;
next-server 192.168.0.6;
ddns-update-style none;

option routers 192.168.0.1;

option domain-name-servers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "bootynet";

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.254;
default-lease-time 14400;
max-lease-time 172800;
}

host client1 {
hardware ethernet 00:16:D3:C2:FE:91;
fixed-address 192.168.0.254;
option host-name "client1";
filename "linux-install/pxelinux.0";
}

host client2 {
hardware ethernet 00:18:F3:2D:F8:3B;
fixed-address 192.168.0.253;
option host-name "client2";
filename "linux-install/pxelinux.0";
}

Auch wenn im Netz ein Router DHCP-Services anbietet, funktioniert diese Methode. Solange der Router nicht auch auf BOOTP-Anfragen antwortet, gibt es keinen Konflikt.

Es gibt übrigens auch ein Redhat-Tool “system-config-netboot”, welches die Erstellung von Diskless Clients oder Netzwerkinstallations-Servern erleichtern soll. Ich habe es aber noch nicht getestet. Diskless Clients sind zwar toll, aber da PXE (noch) nicht wirklich via WLAN möglich ist, sehe ich noch kein Einsatzgebiet dafür bei mir zu Hause.