Das Netzwerkdateisystem ist die zentrale Komponente jedes Fileservers. Das richtige auszuwählen und sich das nötige Know-how anzueignen, ist für jeden Admin eine große Aufgabe. Der Schwerpunkt dieser Ausgabe assistiert ihm in der Startphase.

Fast jedes Netzwerk beherbergt einen Fileserver, der einen Großteil aller täglich anfallenden Daten zentral verwaltet. Die Vorteile liegen auf der Hand: Anwender müssen nicht aufwändig die Dateien zwischen ihren Rechnern hin- und herkopieren und sich auch nicht sorgen, dass ihre Festplatte überläuft. Doch jeder hochgezüchtete Server-Bolide mit Terabytes Speicherkapazität ist nur soviel wert wie die Methoden, mit denen er seine Daten bereitstellt.

Netzwerkdateisysteme sorgen für den reibungslosen Austausch aller Dateien zwischen Fileserver und Clients. So einfach das Prinzip klingen mag, die Probleme sind so vielfältig wie schwer zu lösen. Bekannten Klippen, die ein Netzwerk-Filestem umschiffen sollte, sind gleichzeitige Zugriffe auf dieselben Daten, Netzwerkausfälle und die Verteilung von Daten auf mehrere Server rund um den Globus.

Ein alte Meister und der Fensterputzer

Der älteste und bekannteste Vertreter dieser Gattung ist das Network File System (NFS), das die Firma Sun im Jahr 1984 entwickelte. Und noch immer ist NFS aus den meisten Netzwerken nicht wegzudenken, obwohl es Sicherheitsrisiken birgt und modernere Dateisysteme Features bieten, von denen NFS nur träumen kann. Doch die Entwicklung an NFS steht nicht still und Version 4 bereits auf der Startrampe. Der Artikel ab Seite 36 erklärt die Grundlagen des Network File System und der zugrunde liegenden RPC-Dienste.

In heterogenen Windows/Unix-Netzwerken ist es allerdings sinnvoller, auf das ebenfalls sehr verbreitete SMB-Protokoll zu setzen. Obwohl SMB der Windows-Welt entstammt, gibt es mit Samba eine Implementierung für Linux, die jeden NT-Server auf die Plätze verweist. Mit SMB (oder Common Internet Filesystem, CIFS, wie Microsoft es seit einiger Zeit nennt) lassen sich nicht nur Verzeichnisse exportieren, sondern auch Druck- und andere Dienste teilen.

Offenbar kennt sogar Microsoft nicht alle Details seines hauseigenen Protokolls: Selbst die Microsoft-interne Dokumentation zu SMB weist erhebliche Lücken auf. Im Artikel ab Seite 48 beschreibt ein Mitglied das Samba-Teams ausführlich, wie SMB funktioniert und gibt einen Ausblick auf die Samba-Suite in Version 4.

Für die Großen

Wer große Fileserver in verteilten Umgebungen benötigt, wird mit NFS nicht glücklich. Es ist hauptsächlich für den Einsatz in kleinen und mittelgroßen LANs geeignet. Aufgrund seiner Sicherheitsschwächen ist ein Betrieb über das Internet nicht empfehlenswert. Einige Hersteller haben daher Erweiterungen hinzugefügt, die das NFS-Protokoll um neue Sicherheitsfunktionen aufstocken.

Sollen mehrere Fileserver-Netze über das Internet angebunden werden, wird das Andrew Filesystem (AFS) interessant. Das von IBM im Jahr 2000 als Open Source veröffentlichte Dateisystem verteilt Daten innerhalb großer Netzwerke. Entsprechend komplex ist die Installation und Konfiguration dieses Boliden.

Auf einem AFS-Server laufen gut ein Dutzend Prozesse, die ausschließlich den Fileserver-Funktionen dienen. Das mag auch der Grund sein, warum AFS nicht sehr verbreitet ist. Wer sich allerdings die Mühe gemacht hat das Filesystem aufzusetzen, wird reich belohnt.

AFS hat für fast jede Problemstellung eine passende Lösung. Es verwendet Kerberos zur Authentifizierung, ermöglicht redundante Datenhaltung und die transparente Verteilung von Dateien auf Servern unabhängig von deren Standort. Der Artikel ab Seite 42 zeigt, was AFS kann und was Admins alles beachten müssen.

Harte Zahlen

Um ein Gefühl für die Geschwindigkeit der vorgestellten Protokolle zu vermitteln, hat die Linux-Magazin-Redaktion einige Benchmarks mit NFS und Samba durchgeführt. AFS befindet sich nicht unter den Kandidaten, da es sich mit NFS und Samba funktional nicht vergleichen lässt. AFS kommt zumeist in Umgebungen zum Einsatz, in denen NFS und SMB gar nicht infrage kämen.

Überhaupt ist davor zu warnen den Durchsatz eines Dateisystems als einziges oder primäres Kriterium für den Einsatz heranzuziehen. Die Geschwindigkeit eines Netzwerkdateisystems hängt sehr stark von seinem Einsatzgebiet ab. Wer etwa ein heterogenes Netzwerk betreibt, mit Windows-, Unix- und gar MacOS-X-Clients, der wird wohl kaum auf NFS setzen. Samba ist dort die richtige Wahl.

Bonnie, Iozone und Kernel

Gleichwohl bestimmt natürlich die Dimensionierung der Fileserver-Hardware die erreichbare Geschwindigkeit des Dateisystems direkt mit. Es gilt etwa zu entscheiden, wie schnell das Festplattensystem sein muss. Dafür liefert der Festplatten-Benchmarks Bonnie [1] auf einem leistungsstarken Server in Abbildung 1 wichtige Anhaltspunkte. Für die Bewertung zogen die Tester die Transferraten beim blockweisen Schreiben und Lesen heran. Im zweiten Schritt kam Iozone [2] zum Einsatz; zusätzlich kopierten das Testlabor die Quellen des Kernel 2.6.9 einmal im ausgepackten Zustand rekursiv mit »cp -r« und dann als unkomprimiertes Tar-Archiv.

Die Messwerte von Iozone mussten jedoch unberücksichtigt bleiben, die Ergebnisse enthielten zum Teil abstruse Messwerte im Bereich von 300 MByte/s, die sich jeglichem Erklärungsversuch entzogen. Der Kasten “So haben wir getestet” beschreibt die eingesetzte Hard- und Software. NFS hatten die Tester über Yast auf dem Suse Linux Enterprise Server 9 eingerichtet und mit den Standardoptionen gemountet. Zur besseren Vergleichbarkeit wurden auch an der Samba-Konfiguration keine Modifikationen vorgenommen, da je nach Einsatzzweck völlig verschiedene Optimierungen sinnvoll sind.

Uhrenvergleich

Alle Tests liefen zunächst mit einem einzelnen und dann auf zwei synchron arbeitenden Clients. Die Synchronisierung der beiden, den Server parallel stressenden Clients erfolgte über einen Timeserver, die Benchmarks selbst starteten dann per »at«-Job.

Die Synchronisation über die Systemzeit garantiert zwar keine harte Synchronität, reichte für den Test jedoch aus: Über die gesamte Testlaufzeit traten gerade einmal Laufzeitunterschiede von rund einem Prozent auf. Die nahezu gleichen Transferraten mit einem und zwei Clients in Abbildung 2 zeigen, dass bei synchronem Lauf zweier Clients die Performance offenbar vom Caching des Netzwerkdateisystems profitiert.

Abbildung 1: Bereits bei synchronem Datenaustausch mit zwei Clients bricht die Transferrate von NFS deutlich ein. Samba reagiert hier elastischer.

Abbildung 2: Viele kleine Dateien kopieren ist die Killer-Applikation für NFS und Samba. Jede Datei erzeugt erheblichen Overhead im Protokoll, bei den gemessenen 60 000 Dateien des Kernel 2.6.9 summiert sich das.

Maxiproblem: Minidateien

Auffällig ist der eklatante Leistungseinbruch bei vielen kleinen Dateien. Das liegt daran, dass die Server für jede Datei einzeln die Freigaben prüfen und neue Handles verteilen müssen. So schickt beispielweise NFS 13 Pakete zwischen Client und Server hin und her, bevor es den Inhalt einer Datei überhaupt übertragen kann. Das bedeutet für jede einzelne Datei 13 Mal Paketlaufzeit plus weitere Laufzeit in den Protokoll-Stacks. Dies führt auch zu erheblichem Protokoll-Overhead: Zum Austausch einer 1 KByte kleinen Datei per NFS wurden in einer Stichprobe mehr als 3 KByte Daten übertragen.

Bei über 60 000 Dateien des Kernel 2.6.9 summieren sich Overhead und die Wartezeit auf Antwortpakete zu einem erheblichem Wert. Bei großen Dateien laufen die Daten nach einem anfänglichen Handshake dagegen praktisch ohne Overhead übers Netz. Zudem werden die Dateien sequentiell und nicht fragmentiert übertragen, sodass der Server die volle Leistung seines Plattensystems ausschöpfen kann.

Fazit

Insgesamt kann NFS bei der Geschwindigkeit punkten. Gerade bei großen Dateien liegt das ältere der beiden Netzwerkdateisysteme haushoch vor seinem Konkurrenten. Dennoch hat auch Samba seine Vorteile, selbst bei zwei Clients bleibt die Transferrate während eines Bonnie-Durchlaufs nahezu gleich. Mit kleinen Dateien haben jedoch beide Kandidaten ernste Probleme – Transferraten von unter 1 MByte/s sind schlicht indiskutabel, wenn das Speichersystem des Servers lokal über 40 MByte/s liefern kann.

So haben wir getestet

Um beim Performance-Test von Netzwerk-Dateisystemen sinnvolle und aussagekräftige Messwerte zu erhalten, gilt es, sowohl beim Server als auch bei den Clients einige typische Flaschenhälse zu beseitigen. Zunächst einmal ist ein herkömmliches Ethernet mit einer Brutto-Datenrate von 100 MBit/s kaum geeignet, implementationsspezifische Vor- oder Nachteile eines speziellen Dateisystems aufzudecken. Die Tester installierten deshalb ein Gigabit-Ethernet. Der Server Delfin Silent-LX von Leo [3] besaß bereits einen Gigabit-Ethernet-Port On-Board und ein vorinstalliertes Linux, die drei Delfin-Clients Euros-LX rüsteten die Tester mit je einer Level-One-Netzwerkkarte mit Realtek-8169-Chip aus und verbanden die Rechner über einen 24-Port-Tiger-Switch 8624T von SMC. Weitere Geräte waren nicht mit dem Testnetz verbunden. Drei Clients und ein Server Die Konfiguration der Clients ist der gängiger Client-PCs ebenbürdig: Das Mainboard Asrock K7S41GX besitzt wie viele Micro-ATX-Mainboards lediglich zwei PCI-Slots und ist mit einem AMD Sempron 2300+ (1583 MHz) und 256 MByte RAM bestückt. Zusammen mit DVD-ROM, einer 40-GByte-Platte und vorinstalliertem Linux kostet ein Gerät rund 350 Euro. Das Plattensystem des Servers wurde so dimensioniert, dass es die maximale Transferrate des Netzwerks in jedem Fall übertrifft. Zum Einsatz kam daher ein SCSI-Raid-5 mit Intels SRCU42L U320-SCSI-Controller und drei Fujitsu MAP3367NP U320-SCSI-Festplatten mit 10 000 U/min und 8 MByte Cache. Für ausreichend Reserve bei der Rechenleistung sorgte ein Pentium 4 mit 3 GHz auf dem Intel Server-Board SE7210TP1-E mit 512 MByte RAM. Zusammen mit einem Silentmaxx-Gehäuse und einem 16-fach DVD-ROM verkauft Leo den Delfin-Server für rund 1850 Euro. Das bei Anlieferung vorinstallierte White Box Linux ersetzten die Tester durch einen Suse Linux Enterprise Server 9, das Red-Hat-System der Clients wich entsprechend einem Suse Linux Professional 9.1, jeweils in der Standardinstallation. Die Tester verschalteten die On-Board vorhandenen 100-MBit/s-Netzwerkkarten aller Rechner zu einem separaten Steuernetz. Das enthielt auch den Nameserver und das Standard-Gateway für etwaige Internet-Verbindungen. Damit stand das Gigabit-Netz exklusiv für das Datenaufkommen der Netzwerk-Dateisystemen zur Verfügung. Der durch Fremdzugriffe auf die Testmaschinen verursachte Traffic ging somit nicht in die Ergebnisse der Bechmarks ein. Abbildung 3: Damit sich nicht das Netzwerk als Flaschenhals erweist, wurden nur die drei Clients (Mitte) über einen Tiger-Gigabit-Switch von SMC (rechts, oberhalb des Monitors) mit dem Server (links) verbunden.