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:

Backups mit Snapshots von LVM

Einen Snapshot eines logical volumes zu erstellen ist simpel. Man muss nur zuvor darauf achten, dass das Kernel-Modul “dm_snapshot” geladen ist, ansonsten funktioniert das Ganze nicht:

modprobe dm_snapshot lvcreate --snapshot --name=snap_myvol -L 200M /dev/VolGroup0/myvol

Hier haben wir soeben einen Snapshot des logischen Volumes “myvol” kreiert. Der Snapshot liegt immer in der gleichen Volume Group wie das Original. In diesem Beispiel hat der Snapshot ca. 200MB zur Verfügung. Dies ist etwas kompliziert zu erklären: Der Snapshot an sich ist so gross wie das Original, wenn man ihn verwendet, ein Backup zu ziehen. D.h. wenn das Original 5GB gross ist, ist der Snapshot auch so gross. Was bedeuten nun die 200MB? Sie sind der Maximalwert der Änderungen, die am Original vorgenommen werden können in der Zeit in welcher wir den Snapshot benutzen. Deshalb braucht man viel weniger Platz als im Original, da man nur den Delta (die Veränderung) berücksichtigen muss. Man muss sich also immer überlegen, wieviel sich im Original in welcher Zeit ändert. Wenn man für den Backup vom Snapshot 10 Minuten benötigt und es sich beim Original um die Daten eines DNS-Servers handelt, dürften sogar 5 MB genügen.

Einbinden von logischen volumes in Xen-DomU’s

So sieht ein Beispiel der Einbindung von verschiedenen logischen Datenträgern in einer Xen-Konfigurationdatei aus:

name = "vm_test"
uuid = "d43cc47c-4e49-5999-369d-3a5ccccf43c2"
maxmem = 2048
memory = 1700
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ "type=vnc,vncunused=1" ]
disk = [ "phy:/dev/VolGroup1/vm_serv,xvda,w",
         "phy:/dev/VolGroup0/data,xvdb1,w",
         "phy:/dev/VolGroup2/backup,xvdb2,w",
         "phy:/dev/VolGroup1/export_home,xvdd1,w" ]
vif = [ "mac=00:16:33:bb:ff:44,bridge=xenbr0" ]

Man beachte, dass ich hier einerseits ein unformatiertes logical volume als Grundlage der Serverinstallation selbst verwende (repräsentiert Disk xvda) und andererseits bereits formatierte Filesysteme auf logical volumes einbinde (repräsentiert beispielsweise die Partition xvdb2). Man kann ungefähr die Möglichkeiten erahnen, die Xen einem damit bietet. Übrigens lassen sich Volumes auch per Label- oder UUID-Definition einbinden. Dies ist zum Beispiel ganz nützlich, wenn man eine externe HD verwendet, welche ja nicht immer dieselbe /dev-Zuweisung erhält:

 [ "phy:/dev/disk/by-label/extern_backup,xvdd1,w" ]