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.

Der OpenSLX-Server ist neben dem Netzwerk eine der wichtigen Komponenten, die über die Performance des Gesamtsystems mitbestimmen. Hierzu mal längere Messungen unternommen, siehe auch den Beitrag zu NFS vs. NBD. Das Testsetup bestand aus zwei Räumen mit jeweils 17 Maschinen, die auf zwei große (mit 10 Gbit/s verbundenen) Switches verteilt waren. An einem Switch hing an vier Ports der Server im Bonding. Alles lief mit NFSv3, da NFSv4 noch nicht im Stage3 unterstützt ist. Die Maschinen booteten jeweils blockweise 17 gemeinsam, da über einen Hardware-Video-Switch gesteuert (mit einem Software-Video-Switch ist das nur bedingt möglich, da während des BIOS und PXE-Laufs keine Interaktion besteht). Der Server selbst war mit 16 Cores, 48 GByte und SCSI-RAID großzügig dimensioniert.
Insgesamt ergaben sich folgende Ergebnisse für die Bootzeiten der Clients in ein Ubuntu 10.04:

Im Test handelte es sich beim abgesetzten Raum um einen Pool, an dem 14 Geräte an einem gemeinsamen Gigabit-Switch hingen, der mit einem Gigabit-Uplink an einen der beiden vorne genannten Switches verbunden war. Die NFS-Last wurde durch find /usr -name -exec cat {} >/dev/nulll\; erzeugt. Leider scheint dieses Verfahren nicht wirklich realistische Ergebnisse zu liefern, ebensowenig wie tar -cf /dev/null /usr, da im Vergleich zu anderen Verfahren die Bandbreitenanforderung kleiner bleibt.
Auf dem Server entstand während der gesamten Tests eine maximale Last von 3.X – also weit unter der möglichen Kapazität. Die Spitzentransferrate beim Booten eines Pools mit und ohne Belastung lag bei 250 bzw. 270 MByte/s. Die Differenz hier ist sicherlich eher der Messungenauigkeit geschuldet und zeigt, dass eine bestehende Last (erzeugt duch einen gleichzeitigen Aufruf des oben genannten find ...) auf dem Server keinen besonderen Einfluss hatte, was sich aus den obigen Zahlen auch ablesen lässt. Während des find .. Laufs in einem bzw. beiden der Pools lag die max. Ausgangsleistung des Servers bei 150 bzw. 210 MByte/s. Insgesamt lag die Spitzenausgangsleistung bei 270 MByte/s (theoretische Höchstleistung wäre mit 450 MByte/s zu veranschlagen). Dabei machte es kein Unterschied, ob das NFS-Verzeichnis vom RAID oder aus einem TEMPFS ausgeliefert wurde. Auch fielen durchaus stärker schwankende Empfangsleistungen der Clients auf, die zwischen 800 KByte/s bis 2.8 MByte/s lagen. Dabei spielte die Last auf dem Server keine wirkliche Rolle. Auch hier müsste man sich die Messverfahren nochmal genau ansehen …
Der nächste interessante Test wäre der Vergleich des in die Jahre gekommenen NFSv3 mit dem aktuellen NFSv4, das schon länger im Kernel verfügbar ist. Letzteres soll performanter sein. Derzeit besteht jedoch noch das Problem, dass es sich im Stage3 noch nicht mounten lässt (siehe Ticket).

Wenn mehrere verschiedene Systeme (unterschiedliche Distros, Versionen oder Exports) angeboten werden, will man evtl. das default-mäßig startende System ändern. Dieses geht durch slxsettings set pxe-default-menu-entry='suse-11.3-clone::nfs' (hier ist das Vendor-OS “suse-11.3-clone” in seiner Export-Variante “nfs” als im Menü vorselektiert eingestellt worden).
Ebenso lässt sich das Timeout bis der Default-Eintrag gebootet wird auf diesem Wege anpassen: slxsettings set pxe-timeout='50'. Weitere für das PXE-Menü auf dieser Weise festlegbare Variablen sind: pxe-passwd, pxe-title oder pxe-totaltimeout. Das Theme kann mit der Variablen syslinux-theme eingestellt werden (Voraussetzung ist natürlich, dass ein solches vorher angelegt wurde).

Wieder mal ein Test gemacht mit einem luxuriösen Server und ganz ordentlichen Clients. Der Server bietet 16 CPU Cores und verfügt über 48 GByte Speicher und ist als SLX- sowie Homeverzeichnisserver im Einsatz. Der Server hängt mit 4 Gigabit-Netzwerkinterfaces der Intel-Server-Bauart mittels Bonding-Interface am Switch (3COM Gigabit). Dabei passierte während der Tests im Bereich der Homeverzeichnisse nichts. NFS lief mit insgesamt 64 Threads (bei maximal 32 Clients).
Der Server ist ein aktuelles Debian mit 2.6.32 Kernel, die Clients ein Ubuntu-LTS-10.04.01. Bootzeit eines einzelnen Clients sowohl mit NFSv3 als auch mit SuashFS/NBD lag bei 18 Sekunden von der PXE-Menüauswahl bis zum Login-Screen (KDM auf Xorg/Intel). Wenn 16 Clients gleichzeitig per NFS booteten stieg die Zeit auf 22 Sekunden bei NBD sogar auf 24 Sekunden.
Folgende Dinge waren zu beobachten:

• Die maximale Transferleistung ausgehend auf dem Server war 1.9 Gbit/s
• Maximal wurden 1.8 Gbit/s beim gleichzeitigen NFS-Boot von 16 Clients gemessen
• Der gleichzeitige Start von 16 Clients mittels SquashFS/NBD erbrachte maximal 680 Mbit/s
• Das lineare Lesen des Blockdevices auf den Clients time dd if=/dev/nbd0 of=/dev/null erbrachte ein maximales Transfervolumen serverseitig ausgehend von 1.75 Gbit/s

Insgesamt scheint also im beschriebenen Setup das NBD die Kapazität des Netzes so gut wie nicht auszunutzen. Auch das Lesen von nur einem Client nach der beschriebenen Methode brachte die Peakleistung auf gerade 1/10 der Leistung. Im gesamten NBD-Setup machte es keinen Unterschied, ob der auszuliefernde SquashFS-Container auf der Festplatte (RAID) oder im RAM lag.
Ebenfalls fiel eine start schwankende Transferleistung auf: Das Maximum empfangener Pakete lag bei 100 Mbit/s das Minimum fiel bis unter 10 MBit/s bei insgesamt hoher Volatilität. Dabei wurde nicht weiter untersucht, ob das durch TCP-Parameter (Window-Size, ACKs, …) verursacht wurde oder ein Problem des NBD-Servers war. Von der Server- und Client-Leistung her sollte es keine Einschränkungen gegeben haben.
Das wirft nochmal ein anderes Licht auf den NBD (zumindest im vorliegenden Setup).
NFS lässt sich auch aus einem TEMPFS heraus exportieren, man muss es aber mit einer ID versehen (“fsid=1234″). Es braucht jedoch bedeutend mehr Platz (ca. 5:2 bezogen auf SquashFS).