In einem meiner Systeme stecken 2 SATA2-Festplatten mit je 750 GB Speicherplatz. Das Betriebssystem ist SLES11 und hauptsächlich befinden sich dort Xen4-DomU’s. Die Gäste stellen Webserver, Mailserver und andere Systemdienste bereit. Bisher war es so, dass ich einen Teil der ersten Platte mit LVM genutzt habe. Die zweite Platte war für Backups und andere Dinge in Verwendung. Die Performance war in Ordnung, aber auch nicht überragend.

Um diese Situation zu verbessern, hab ich mich im Internet auf die Suche gemacht. Es galt, ohne neue Hardware auszukommen (bei Mietservern unverschämt teuer) und ohne den Server komplett umzukrempeln, wie es z.B. bei einem neu konfigurierten Software-RAID der Fall wäre. Ich bin fündig geworden! Die Lösung funktioniert in meiner Umgebung wunderbar, ist aber grundsätzlich auch problemlos woanders verwendbar:

Das Geheimnis liegt im LVM verborgen. Statt weiterhin nur ein einziges Physical Volume (PV) zu verwenden, in dem die Volume Group (VG) und ihre Logical Volumes (LV) liegen, habe ich einen Teil der zweiten Festplatte zur bereits bestehenden VG hinzugefügt. Das ist erst mal nichts Neues, sondern bei LVM üblich.

Neu für mich war allerdings beim Kommando “lvcreate“, das zum Anlegen neuer Logical Volumes verwendet wird, der Parameter “-i 2“. Dieser Parameter gibt an, auf wie viele Physical Volumes das zu erzeugende Logical Volume aufgeteilt werden soll. In diesem Fall auf 2 PV’s. Auf ganz bequeme Art schaffen wir somit ein Software-RAID-0 für dieses LV. Wichtig ist aber, dass alle PV’s einer VG unbedingt auf separaten Platten liegen müssen, da es sonst zu Performance-Einbußen kommt.

Die Festplatten-Geschwindigkeit meines Xen-Gastes, den ich zum Testen verwendet habe, ist massiv gestiegen.

Hier die Ausgaben von hdparm zu den Lesegeschwindigkeiten:

(“/dev/xvdb” liegt auf einem einzigen PV, “/dev/xvdc” liegt auf 2 PV’s)

3x hintereinander “hdparm -Tt /dev/xvdb” (ALT)

/dev/xvdb:
Timing cached reads:   18416 MB in  1.99 seconds = 9251.71 MB/sec
Timing buffered disk reads:  280 MB in  3.00 seconds =  93.29 MB/sec

/dev/xvdb:
Timing cached reads:   18144 MB in  1.99 seconds = 9114.75 MB/sec
Timing buffered disk reads:  274 MB in  3.00 seconds =  91.24 MB/sec

/dev/xvdb:
Timing cached reads:   17474 MB in  1.99 seconds = 8778.24 MB/sec
Timing buffered disk reads:  276 MB in  3.02 seconds =  91.45 MB/sec

3x hintereinander “hdparm -Tt /dev/xvdc” (NEU)

/dev/xvdc:
Timing cached reads:   17672 MB in  1.98 seconds = 8909.50 MB/sec
Timing buffered disk reads:  552 MB in  3.01 seconds = 183.52 MB/sec

/dev/xvdc:
Timing cached reads:   17226 MB in  1.99 seconds = 8651.80 MB/sec
Timing buffered disk reads:  560 MB in  3.01 seconds = 186.18 MB/sec

/dev/xvdc:
Timing cached reads:   18446 MB in  1.99 seconds = 9267.25 MB/sec
Timing buffered disk reads:  550 MB in  3.02 seconds = 182.30 MB/sec

Und hier noch das “dd”-Kommando bei der Erzeugung von ca. 4 GB großen Dateien:

ALT:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 51.6753 s, 79.3 MB/s

real    0m51.682s
user    0m0.556s
sys     0m10.405s

NEU:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 26.8236 s, 153 MB/s

real    0m26.813s
user    0m0.512s
sys     0m8.845s

Na, wenn das nichts ist… ich find’s großartig! :-)

Die genaue Fehlermeldung war “Error: Device 0 (vif) could not be connected. Hotplug scripts not working.“. In der Datei “/var/log/xen/xen-hotplug.log” war außerdem zu lesen: “/etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected".

Anscheinend ist an der entsprechenden Stelle im genannten Skript nun eine Variable leer, die eigentlich gefüllt sein sollte. Das Ergebnis ist nun jedoch ungültig, woraufhin das Skript auf die Nase fällt. Bis Novell ein Update zur Verfügung stellt, um den Fehler zu beheben (ich hoffe, dass Novell die Lösung beisteuert) kann man sich mit einem Workaround helfen, der darin besteht, die Zeilen 24 und 25 im Skript "/etc/xen/scripts/xen-hotplug-cleanup" anzupassen:

aus:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ]
&& [ "${path_array[1]}” = “vbd” ]; then

wird:

if [ x$(xenstore-read "$vm_dev" 2>/dev/null) != "x" ]
&& [ x"${path_array[1]}" = "xvbd" ]; then

Damit sollte das Problem umgangen werden können. Bisher funktioniert's bei mir ohne Probleme.

UPDATE (20.07.2010):

Meine Xen-Umgebung lief in den letzten Tagen ziemlich wackelig. Das Starten von domU's war möglich, wenn ich allerdings eine der Instanzen stoppen oder neu starten musste, befand sie sich für ca. eine Minute im "paused"-Zustand und brach dann ab. Die Meldung war (wie gehabt) "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".

Ich habe Foren durchsucht, Manuals gelesen und diverse Mailinglisten umgegraben, doch zunächst schien nichts zu helfen, was auch immer ich versuchte.

Nun habe ich endlich das Problem für mich isoliert und "vorerst" behoben. SLES11SP1 nutzt in der Standardauslieferung für Xen das Kernelpaket "kernel-xen-2.6.32.12-0.7.1". Damit lief alles reibungslos. Dann kam vor einigen Tagen ein Kernel-Patch heraus, Version "kernel-xen-2.6.32.13-0.4.1". Und hiermit fing - wie anfangs bereits vermutet - der ganze Ärger an. Ich habe mittlerweile die Version wieder auf den Originalzustand zurück gedreht und schon funktioniert alles wieder reibungslos. Ich hatte war vor ein paar Tagen schon probiert, den Kernel zurück zu drehen, doch ich hatte auf meinem Server noch ein weiteres Problem, dass mit dem Booten von Software-RAID-Partitionen zusammen hing. Das konnte ich beheben, indem ich "mkinitrd-2.5.10-4.6.1" installierte. Ich glaube aber nicht, dass es sich hierbei um ein grundsätzliches Problem handelt... aber wer weiß. :-)

Zunächst ist es hierzu erforderlich, die VMDK-Dateien mit dem beim VMware-Server beigelegten Tool “vmware-vdiskmanager” zu konvertieren. Ich hatte die Software allerdings nicht mehr installiert, wollte aber auf das Tool nicht verzichten. Da ich noch das RPM-Paket “VMware-server-2.0.2-203138.x86_64.rpm” vorliegen hatte, habe ich einfach Folgendes gemacht:

1. Anlegen eines neuen Ordners (“/tmp/vmware”)
2. Öffnen des RPM-Pakets im Midnight Commander (“mc”)
3. Öffnen der enthaltenen Datei “CONTENTS.cpio”
4. Kopieren der folgenden darin enthaltenen Dateien nach “/tmp/vmware”:
   usr/bin/vmware-vdiskmanager
   usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8
   usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8

Danach kann man “/tmp/vmware/vmware-vdiskmanager” nutzen, als wäre der komplette Server installiert.