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.

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).

Es gibt ein neues Tool in testfähigem Zustand am Start, den Pool Video Switch. Das ist ein Open Source Projekt als freie Alternative zu kommerziellen Hardware- und Softwareprodukten. Einige Hintergrundinfo zu Ideen oder auch von einem gehaltenen Vortrag.

Herunterladen kann man sich das Projekt derzeit lediglich mittels SVN, erst wenn eine gewisse Stabilität zur Verfügung steht, wird es auch Pakete geben:

svn co http://svn.openslx.org/svn/pvs

Benötigt werden die VNC-Libraries und einige Gnome/Gtk-Entwicklungspakete. Anschließend ruft man das übliche

configure

und

make

auf. Hier sieht man dann auch, welche Pakete noch fehlen; die man dann nachinstallieren sollte.

Installiert sein sollte auch das x11vnc Paket. Darauf basiert derzeit die VNC-Verbindung für das Monitoring der Clients. Es ist aber geplant, hier auch Alternativen zuzulassen.

Der poolVSClient läuft auf jedem Teilnehmerrechner und braucht eine Kon-
fig im Homeverzeichnis des Users:

• Konfigverzeichnis .pvs anlegen
• Darin eine Datei clientfile anlegen, die so aussieht:

  start:name-konsolen-rechner
  client-name
  end:name-konsolen-rechner

• Datei .allow anlegen mit einer “1″ drin
• Das Skript irgendwo hinlegen und dem poolVSClient dieses beim Aufruf mitgeben

Der poolVS ist die Steuerkonsole. Diese sollte auf einer separaten Maschine laufen oder in einem zweiten X-Server auf der Dozentenmaschine. Die Clients melden sich automatisch bei korrekter Konfig (name-konsolen-rechner ist die Maschine auf der poolVS läuft) an der Steuerkonsole an und können von dort aus bedient werden. Wenn alles glatt geht, schafft man es, auf die Clients per VNC zuzugreifen, sie zu sperren und Botschaften abzusetzen

Feedback ist willkommen!