Xen VM’s auf LVM-Logical Volumes: Konsistente Backups und I/O-Wait im Griff 2

Posted by Chris on April 16, 2008

No Gravatar

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:

Array

Continue reading…