Open Source im professionellen Einsatz

Netzwerkblockgeräte in neuen Missionen

Block-Spirale

Dirk von Suchodoletz , Thorsten Zitterell

Versorgt ein Server zum Beispiel Thin Clients mit einem Read-only-Dateisystem, muss er das nicht unbedingt mit NFS oder Samba tun. Für viele Aufgaben reichen Remote-Blockdevices, die kräftig an der Performance- und Effizienz-Spirale drehen.

Einen Fileserver hat praktisch jede Firma oder Organisation. Dennoch verschwenden viele Plattenplatz durch redundante Datenhaltung: Meist steckt in allen Arbeitsplatzrechnern noch eine eigene Festplatte, obwohl das installierte Betriebssystem und die eingesetzten Applikationen unternehmens- oder abteilungsweit identisch sind. Zentrale Datenverwaltung (teils auch unter dem Modebegriff Speichervirtualisierung bekannt) führt hier zu festplattenlosen Rechnern, die je nach Anwendung Thin, Fat oder Diskless Clients heißen.

Server und Netz belastet

Das Konzept setzt schnelle und zuverlässige Netzwerke sowie durchsatzstarke Server voraus. Klassische Implementierungen mit einem Netzwerk-Dateisystem belasten Server und Netz aber unnötig: Wann immer der Server Dateisysteme verbreitet, an denen die Clients nichts ändern, eröffnen sich wirksame Optimierungsmöglichkeiten mit Hilfe von Netzwerk-Blockgeräten (siehe Kasten "Motivation"). Diese verzichten darauf, Schreib- und Leseoperationen der Clients zu koordinieren. Die Geschwindigkeitsvorteile gelten für jeden Read-only-Fileserver, egal ob CD-Server, Dokumentenarchiv oder Server für Diskless Clients.

Motivation
Ausgangspunkt für die im Artikel beschriebene Suche nach einem schnellen und die Netzwerk-Bandbreite schonenden Root-Filesystem fürs LAN war ein Rechnerpool aus 60 Linux Diskless Clients an der Uni Freiburg (Abbildung 1), der drei Jahre produktiv lief. Abbildung 1: Die Rechner dieses Lehrpools an der Uni Freiburg arbeiten als Diskless Clients. Damit sie beim Booten das Netz nicht unnötig belasten, haben die Autoren in die Trickkiste gegriffen und beispielsweise das Netzwerk-Filesystem durch Remote-Blockdevices ersetzt. Die bisherige Umgebung, die in den drei Lehrpools zum Einsatz kam, arbeitete mit zwei NFS-Servern und erledigte die Setup- und Konfigurationsaufgaben beim Runlevel-Start der Clients. Bis ein Benutzer unter KDE eingeloggt war, holte jeder Client bis zu 350 MByte vom Server, was mindestens eine Minute dauerte. Die Ressourcen des Servers und die Nerven der Nutzer stießen spätestens an ihre Grenzen, wenn gleichzeitig 15 Maschinen hochfuhren. Die Autoren konterten mit einer systematischen Suche nach Optimierungsmöglichkeiten, ohne dabei die Hardware ihrer Server und des Uni-Netzwerks anzutasten. Als wichtiger Faktor stellte sich das Bootverfahren der Clients heraus. So weit sinnvoll verlegten die Autoren Konfigurationsschritte in die Initial RAM-Disk und parallelisierten sie. Zudem untersuchten sie alternative Netzwerk-Filesystemen und Netzwerk-Blockgeräte mit geeigneten Dateisystemen. Zusammen verringern beide Maßnahmen die übertragene Datenmenge von 350 MByte auf weniger als 50 MByte. Die Zeit für das Booten reduzierte sich fast auf die Hälfte. Zukunftsmusik: Diskless Notebook per WLAN Mit der günstiger werdenden Notebook-Hardware und zunehmenden Bandbreiten in Funk-LANs denken die Betreiber an neue Möglichkeiten des Pool-Betriebs. So könnten sie vielleicht mittelfristig wartungsarme mobile Pools schaffen, die sich für Ad-hoc-Lösungen wie flexible Seminarräume, Schulungsumgebungen oder Konferenzterminals eignen.

Motivation

Ausgangspunkt für die im Artikel beschriebene Suche nach einem schnellen und die Netzwerk-Bandbreite schonenden Root-Filesystem fürs LAN war ein Rechnerpool aus 60 Linux Diskless Clients an der Uni Freiburg (Abbildung 1), der drei Jahre produktiv lief.

Abbildung 1: Die Rechner dieses Lehrpools an der Uni Freiburg arbeiten als Diskless Clients. Damit sie beim Booten das Netz nicht unnötig belasten, haben die Autoren in die Trickkiste gegriffen und beispielsweise das Netzwerk-Filesystem durch Remote-Blockdevices ersetzt.

Die bisherige Umgebung, die in den drei Lehrpools zum Einsatz kam, arbeitete mit zwei NFS-Servern und erledigte die Setup- und Konfigurationsaufgaben beim Runlevel-Start der Clients. Bis ein Benutzer unter KDE eingeloggt war, holte jeder Client bis zu 350 MByte vom Server, was mindestens eine Minute dauerte. Die Ressourcen des Servers und die Nerven der Nutzer stießen spätestens an ihre Grenzen, wenn gleichzeitig 15 Maschinen hochfuhren. Die Autoren konterten mit einer systematischen Suche nach Optimierungsmöglichkeiten, ohne dabei die Hardware ihrer Server und des Uni-Netzwerks anzutasten.

Als wichtiger Faktor stellte sich das Bootverfahren der Clients heraus. So weit sinnvoll verlegten die Autoren Konfigurationsschritte in die Initial RAM-Disk und parallelisierten sie. Zudem untersuchten sie alternative Netzwerk-Filesystemen und Netzwerk-Blockgeräte mit geeigneten Dateisystemen. Zusammen verringern beide Maßnahmen die übertragene Datenmenge von 350 MByte auf weniger als 50 MByte. Die Zeit für das Booten reduzierte sich fast auf die Hälfte.

Zukunftsmusik: Diskless Notebook per WLAN

Mit der günstiger werdenden Notebook-Hardware und zunehmenden Bandbreiten in Funk-LANs denken die Betreiber an neue Möglichkeiten des Pool-Betriebs. So könnten sie vielleicht mittelfristig wartungsarme mobile Pools schaffen, die sich für Ad-hoc-Lösungen wie flexible Seminarräume, Schulungsumgebungen oder Konferenzterminals eignen.

Traditionelles NFS

Für den Linux-Kernel ist es unerheblich, wo er sein Root-Filesystem findet: auf der lokalen Festplatte, einem SCSI-Raid, Flash-Device oder auf einem fernen Server im Netz. Für Letzteren nutzt Linux üblicherweise das Netzwerk-Dateisystem NFS. Es ist weit verbreitet, einfach zu konfigurieren und seit Jahren Bestandteil des Kernels. Sein Alter merkt man NFS jedoch an: Bis einschließlich Version 3 existiert kein ernst zu nehmendes Sicherheitskonzept. Der Server verlässt sich blind auf die User-Authentifizierung am Client und unterscheidet Clients nur anhand ihrer IP-Adresse. Bei NFS heißt eine Freigabe Export, zu definieren auf dem Server in der Datei »/etc/exports«:

/home  10.8.4.0/255.255.255.0(rw,async)
/home         *.mydomain.site(rw,async)

Das Beispiel exportiert die Homeverzeichnisse aller Benutzer für alle Maschinen im Subnetz 10.8.4.0 mit der Netzmaske 255.255.255.0 sowie für alle Rechner, deren IP-Adresse - rückwärts aufgelöst - Namen aus der Domain »mydomain.site« liefert.

Die in Klammern stehenden Optionen legen fest, dass Clients auf die Freigabe schreiben dürfen, der Benutzer Root bleibt jedoch davon ausgenommen. Das Schlüsselwort »async« fordert für alle Schreibvorgänge eine sofortige Bestätigung an, ohne dass der Client wartet, bis der Server diese Aktion abgeschlossen hat. Das beschleunigt das Schreiben auf Kosten der Datensicherheit.

Dass NFS per Default dem Client-Systemadministrator keinen privilegierten Zugriff gewährt, ist für Angreifer nur eine minimale Hürde. Nichts hindert sie daran, die passenden Benutzer-IDs anzunehmen und sich damit in interessanten Verzeichnissen zu bewegen.