Das Distributed Network Block Device 3 (DNBD3) setzt die Tradition von OpenSLX fort, spezielle Blockdevices für die effiziente Bereitstellung des Rootfilesystems für die OpenSLX-Clients zu entwickeln. DNBD3 wurde im Rahmen einer Masterarbeit von Johann Latocha am Lehrstuhl für Kommunikationssysteme erstellt. Dabei handelt es sich um eine komplette Neuentwicklung, die versucht die Vorteile des NBD und des zuvor entwickelten DNBD2 in einem Ansatz zu vereinen. Zusätzlich sollten folgende Ziele erreicht werden:

• Server mit Caching- und Proxy-Funktion
• Maximale Performance bei 1-Gbit/s-Ethernet
• Ausfallsicherheit durch redundante Server
• Load Balancing durch geeignete Metriken
• Intelligentes Readahead
• Vereinfachte Administration

Eine ausführliche Anleitung und weitere Dokumentation können von der Entwicklungs- und Dokumentationsseite bezogen werden. Das Blockdevice ist komplett funktionsfähig und läuft bereits in ersten Testinstallationen in Freiburg. Zum Ausprobieren (vorher sind vermutlich noch einige Pakete zum Kompilieren zu ergänzen):
git clone git://git.openslx.org/dnbd3.git
# Debian-basierte
apt-get install cmake build-essential linux-headers-generic libglib2.0-dev
# RPM-basierte
yum|zypper install cmake glib2-devel

cd dnbd3/
mkdir build
cd build/
cmake..
make
sudo make install
Die Konfigurationsdatei des Servers befindet sich in /etc/dnbd3-server.conf.example und hat folgenden Aufbau:

[Ein selbst gewählter Name]
file=/pfad/zum/image
servers=ip1;ip2;ip3...
vid=VersionID
rid=ReleaseID

Sowohl die VersionID als auch die ReleaseID müssen ganzen Zahlen und größer 0 sein. Zusätzlich darf die VersionID nur ein einziges mal vorkommen. Die installierte Konfigurationsdatei beinhaltet einige Beispiele.

Nach der Konfiguration kann der DNBD Server gestartet werden:
dnbd3-server
Durch einen erneuten Start des Servers mit dem Schalter -s kann eine laufende Instanz wieder beendet werden. Weitere Informationen und Möglichkeiten können aus der eingebauten Hilfe entnommen werden.

Pünktlich zum Erscheinen des aktuellen Ubuntu 12.04 erfolgte ein Update des OpenSLX-Basissystems. Damit kann auf dem gewohnten Weg des Clonens und Exportierens die neue Distribution bereitgestellt werden. Wie üblich gab es einige Änderungen im Startprozess von Ubuntu, die entsprechende Anpassungen erforderten. Das Bootsplash-Plugin kann ohne Probleme direkt übernommen werden.

Mit der Änderung bei den neueren Linux-Kernels und den Distributionen (Ubuntu und andere haben beispielsweise auf Plymouth umgestellt, SuSE macht immer noch ein eigenes Ding, was zwar am besten aussieht, aber einen aufwändigen Kernel-Patch erfordert) wurde es notwendig den alten Splashy-basierten Bootsplash abzulösen. Das Bootsplash-Plugin setzt nun auch Plymouth ein, da dieses der derzeitige Standard zu sein scheint. Für Theme-Anpassungen, die dann im nächsten Schritt für den Login-Manager eine Rolle spielen, sind folgende Dinge zu beachten:

• In der Vorlage kdm installieren, da gdm nicht mehr unterstützt wird. Dieser muss nun über gconf konfiguriert werden und nicht mehr über eine einfache Konfigurationsdatei, wie bei den früheren Versionen.
• Das Vorlagensystem muss erneut geclont werden, damit die entsprechenden Ergänzungen übernommen werden.
• Aus den vorgenannten Gründen muss nun die Variable desktop::manager auf kdm gesetzt werden.
• Am Ende müssen wie gewohnt noch der Export und der slxconfig-demuxer ablaufen.

Der Pool Video Switch (PVS) ist ein Werkzeug zur Display- und Tastatur/Maussteuerung von Linux-Rechnern zum Einsatz in Schulungsumgebungen, die beispielsweise auf einer OpenSLX-Basis laufen. Mit der aktuellen Version geht nun auch eine sinnvolle Nutzung von Tablet-Devices (beispielsweise ein angepasstes WeTab mit Linux als Basis) als PVS-Steuerkonsole. Mit einem solchen Gerät ist ein mobiler Einsatz möglich, setzt aber eine ausreichende WLAN-Anbindung in das Netz des Rechner-Pools voraus.

Nach dem die Überlegung wegen des relativ hohen Aufwands verworfen wurde, die VMware VMDKs per NBD/SquashFS gemeinsam zu exportieren – hier müsste nach jeder Änderung das SquashFS neu generiert und das Blockdevice neu exportiert werden – wurde nochmal ein Blick auf die Container selbst gerichtet. Das Tool vmware-vdiskmanager kennt den VMDK-Typ 5 (optimized for streaming), welches deutlich kleinere (d.h. komprimiertere) Images erstellt. So wurde aus einem 14 GByte Windows 7 Image eine 7 GByte Datei nach der Konvertierung (Reduktion auf 50%, müsste mit weiteren Images überprüft werden). Der Aufruf hierfür lautet:
vmware-vdiskmanager -r source-image.vmdk -t 5 compressed-image.vmdk
Der Vorgang brauchte jedoch seine Zeit, im Beispiel übers Netz zehn Minuten.

Ein Streaming-Image brauchte zum Starten geringfügig weniger Zeit und transferierte dabei ca. 1/4 bis 1/3 weniger Daten. Nach zehn Minuten waren dieses 1.2 GByte vom Server für das komprimierte und 1.8 GByte für das unkomprimierte Windows 7 Image. Der Upstream lag im Testbeispiel mit ca. 30-50 MByte deutlich darunter.