Bisher werden die Virtuellen Maschinen Images üblicherweise via NFS in einem gemeinsamen Ordner bereitgestellt. Es gab mal die Überlegung diesen Export via SquashFS/NBD zu machen, aber der Aufwand das SquashFS nach jeder Änderung neu zu generieren, schien nicht sehr attraktiv und zudem wenig praktikabel. Stattdessen wurde nun das Ganze via Network Blockdevice ohne den Umweg via Filesystem realisiert: Dabei wird die Blockdevice-Datei wie eine normale Filesystemimage-Datei angesprochen, dabei ist es völlig egal, wie die Datei intern aufgebaut ist.

Im getesteten Setup erfolgt der NBD-Export (via nbd-server) einfach auf jedes einzelne VMDK, das damit als Blockdevice-Datei interpretiert wird. Auf der Client-Seite wird ein NBD-Device ganz normal per nbd-client erzeugt, was eine typische Device-Datei (/dev/nbdN) ergibt. Dieses Block-Device wird dann aber eben nicht gemountet, sondern direkt angesprochen. Am einfachsten zeigt ein Link, der das VMDK (, VDI, …) repräsentiert, einfach auf die Datei des Blockdevices, z.B. /dev/nbd7/ … Andere Blockdevices (DNBD2, iSCSI) sollten sich ebenso eignen, wurden aber noch nicht getestet.

In einem generellen, weiteren Schritt, könnte dann auch überlegt werden, dass “Diffing” (Wegschreiben der Session-Unterschiede) über dieses Blockdevice (zumindest NBD kennt ein COW) zu realisieren, statt es beispielsweise in einen RW-NFS-Share zu machen. Das sollte insbesondere bei Maschinen mit relativ wenig RAM und dem Redo auf NFS die Sache deutlich vereinfachen. Dann würde man aber das Image nicht non-persistent sondern persistent nutzen.

Die ganze Aktion sollte das NFS erheblich entlasten. Der Netzwerktraffic wird sich nicht wesentlich verändern, auch wenn das Caching auf dem Client bei wiederholten Blöcken was ausmachen sollte. Die Performance scheint sich zu verbessern, wie folgende sehr grobe Messungen zeigten. Diese erfolgten später am Abend, damit das Netz schon relativ leer war. Eine Geschwindigkeitsmessung wurde mit drei verschiedenen Servern gemacht:

• NBD A: Neuere Dell-Servermaschine mit 24 GByte RAM, 10 Gbit/s Netz, Hardware-Raid auf zwei SAS (nicht super fix), OS: Scientific Linux 5.4 (2.6.18er Kernel)
• NBD B: Sechs Jahre alte SUN V20z mit 8 GByte RAM, 2 Gbit/s Netz, Software-Raid über zwei ältere SCSI-320-Platten, OS: Debian 6 (2.6.32 Kernel)
• SUN-Server (24+GByte, …, 10 GBit/s Netz), OS: Aktuelles Solaris auf ZFS

Im ersten Test war kein Server direkt im Netz des Clients, im zweiten Fall nur der NBD B. Dabei ging es dann aber trotzdem noch über einen Stapel von Switches.

Die Messung erfolgte immer beim dritten Start in der gleichen Konfiguration zum Ausschluss von Caching-Unterschieden auf einem Dual-AMD-Turion, der 3+ Jahre alt ist, 4 GByte RAM hatte und via Gigabit ans Netz angeschlossen ist:

NBD A – 1.15 Min
NBD B – 1.35 Min
NFS – 1.46 Min

Die Messungen wurden auf einer neueren Maschine (ca. 1 Jahr alt, Intel E5300 CPU, 4 GByte RAM, Gigabit Netzwerkanschluss) wiederholt:

NBD A – 1.02 Min
NBD B – 1.05 Min
NFS – 2.02 Min

Im ersten (optimalen) Fall wurden 30 Sekunden (~70% der Standardstartzeit) Einsparung erreicht. Interessant im zweiten Setup war, dass hier NFS und NBD fast um den Faktor zwei auseinanderliegen, sich NBD auf dem alten und dem neuen Server aber kaum unterschieden. Schwer zu bestimmen ist hier der Einfluss von Netzwerk und Maschinenperformance. Die beiden Rechner standen in verschiedenen Teilnetzen mit etwas unterschiedlicher dahinterliegender Infrastruktur, die aber mindestens 1 Gigabit bereitstellt.

Derzeit wird an der Unterstützung diverser aktueller Distributionen im OpenSLX gearbeitet. Die OpenSuSE 11.4, Ubuntu 11.4 und LinuxMint 10 sind derzeit weitgehend angepasst. Zusätzlich soll die Fedora-Reihe aufgenommen werden, an einer Einbindung der Fedora-15 wird im Moment gearbeitet. Alle Änderungen erfolgen derzeit im Stable-Branch, der mit
git clone git://git.openslx.org/openslx/core.git openslx ausgecheckt werden kann.