Linux @ Home

Da ich im Moment sehnlichst auf den Fedora 9 Release warte, bleibt mir etwas Zeit, endlich die Bilder unserer neuen Mitbewohnerin hochzuladen. Darf ich vorstellen? Chihiro, die K(r)atze. Wir haben sie im Januar aus dem Tierheim geholt. Ihre Geschicht ist so kurz wie tragisch: Sie wurde mit mehrfach gebrochenem Schwanz (der heute am Ende etwas krumm ist) unter einer Brücke an der Reuss gefunden, wo sie sich gerne mal von den einheimischen Fischern den einen oder anderen Brocken erbettelte…
Heute hat sie sich gut bei uns eingelebt. Sie ist keine Schmusekatze und beweist dies gerne mal mit ihren sehr scharfen Krallen. Zuneigung gibt’s nur, wenn sie es will, oder wir uns zu konzentrieren versuchen, beispielsweise an der Computertastatur.

Ein paar Fotos genügen eigentlich schon, um ihre Lieblingsbeschäftigung ungefähr wiederzugeben:

Continue reading…

Als nächsten Schritt in der vollständigen Migration aller Services auf virtuelle Server mit Xen wollte ich wegkommen von den unhandlichen Image-Dateien, welche niemals konsistent gesichert werden können und auch keine schnellen Zugriffszeiten bieten. Nach kurzem Überlegen und bestätigt durch Erfahrungen anderer Admins gab es einen einfachen Weg: LVM der Logical Volume Manager von Linux eignet sich dafür bestens. Der Hauptgrund war erst, dass man sogenannte “Snapshots” von einem aktiven logischen Volume machen kann. Dieser Snapshot ist quasi statisch und repräsentiert somit einen konsistenten und permanenten Zustand der Daten zum Zeitpunkt der Erstellung dieses Snapshots. Dadurch wird das Erstellen von konsistenten Backups sehr erleichtert. Wie sich zeigte, löste der Umstieg auf LVM aber auch noch ein anderes altbekanntes Problemchen…

Das I/O-Wait Problem wird entschärft

In all den Jahren meines beruflichen und privaten Umgangs mit Computersystemen war es immer wieder dieser Flaschenhals, der die größten Performanceprobleme machte: I/O Wait: Der Prozessor wartet auf den Festplattencontroller, bis dieser seine Lese- oder Schreiboperation vollständig abgeschlossen hat.

Auch für meinen Backupserver (Backups via NFS und rsync) hiess das immer wieder Warten mit bis zu 90% I/O Wait, was den Server praktisch unbrauchbar macht für weitere Tätigkeiten. Mit den VM’s auf LVM fiel mir nun auf, dass die DomU’s zwar auch bis zu 100% I/O Wait haben, dass aber das Wirtssystem indessen keinen bis ganz wenig I/O Wait aufweist. Vermutlich liegt dies daran, dass die DomU gar nicht direkt auf die Hardware zugreift (obwohl im Endeffekt dieselben Backups auf dieselbe externe USB-Disk geschrieben wird bei mir). Auch die Geschwindigkeit, in der diese bis 20GB grossen Backups geschrieben sind, scheint mir subjektiv nicht viel kleiner zu sein als zuvor.

Ich bin kein Kernelspezialist und kann daher nur vermuten, dass die I/O-Wait-Last deswegen geringer ist, weil der Dual-Core in diesem Setup besser zur Geltung kommt, da die VM gezwungenermassen nur auf einem Kern läuft (je nach Konfiguration natürlich) und das Wirts-Betriebssystem nach wie vor 1-2 Kerne zur Verfügung hat (je nach Last). Man möge mich bitte aufklären, falls es andere Gründe sind, die zum besseren I/O-Wait-Verhalten führen.

Mir scheint fast, als sei Virtualisierung so etwas wie der Stein der Weisen, wenn es um die Gleichzeitigkeit von lese- und schreibintensiven Operation und anderen Services auf einer einzigen Maschine geht.

Auf dem Bild ist zu sehen, dass der Xen-Wirt (oberer Teil) nur sehr wenig I/O-Wait aufweist, während die VM (unterer Teil) praktisch nur noch I/O-Wait hat:

Continue reading…

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"