Nach einer Auszeit meines Linux-Experiments auf dem iMac 24 von ca. 5 Monaten hatte ich endgültig genug vom OSX. Einfache Aufgaben wie “schnell ein Mail schreiben” u.ä. dauerten unter dem Strich einfach länger auf Mac als auf Linux (und sogar Win XP). Ich bin auch nicht bereit, für simple Progrämmchen Unsummen auszugeben, nur damit ich mit meinem “coolen” Mac endlich richtig arbeiten kann. Deshalb installierte ich also Fedora 9, neugierig, was die inzwischen zahlreich vorhandenen Updates verbessert haben. Tatsächlich lag am Jahresanfang einiges noch im Argen, wenn man den ersten Artikel anschaut. Mittlerweile sind wir jedoch bei Kernel 2.6.25 und zwei problematische Teile funktionieren nun tatsächlich besser:
Seit meinem Erfahrungsbericht vom letzten Jahr haben sich einige der Stromspareinstellungen geändert und einige Tricks sind dazugekommen. Als erstes meine aktuelle /etc/rc.local Datei:
# Div. Stromsparer:
echo 5 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/kernel/nmi_watchdog
# Achtung, 30000 = 5 Minuten Datenverlust, wenn die geaenderten Daten
# kleiner sind als der Festplattenpuffer
echo 30000 > /proc/sys/vm/dirty_writeback_centisecs
# Nach 4*5=20 Sekunden wird die Festplatte ausgeschaltet
# Achtung, dies schraenkt im Gegenzug die Lebensdauer der Platte etwas ein
hdparm -B 16 -S 4 /dev/sda
# Stromsparmodus fuer alle USB-Geraete:
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
# Div. Stromsparmodi:
echo 1 > /sys/module/snd_hda_intel/parameters/power_save
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
###iwpriv wlan0 set_power 7 # original 5, but 1 is from lesswatts.org
# Besserer Weg, die iwl-Treiber in den Stromsparmodus zu wechseln:
echo 7 > /sys/bus/pci/drivers/iwl4965/0000:03:00.0/power_level
ethtool -s eth0 wol d
# Lebensverlaengerung der Batterie, wenn sie am Strom haengt (sie sollte
# immer zwischen 40% und 85% sein):
# Als Alternative den Startthreshold auf 81% setzen (wenn andere Anzeigen
# Probleme damit haben, z.B. gkrellm)
echo 85 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh
##echo 81 > /sys/devices/platform/smapi/BAT0/start_charge_thresh
echo 30 > /sys/devices/platform/smapi/BAT0/start_charge_thresh
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:
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:
Chris on 
Hans Harald on 
Janu on