Abbildung 1: Die virtuelle Umgebung lässt die Vorteile von NFS 4 nicht richtig zur Geltung kommen, zeigt aber, dass die höhere Sicherheit durch zusätzliche Verschlüsselung ihren Preis hat, der mit der Münze Performance zu bezahlen ist. Läuft derselbe Benchmark – Iozone – in einem realen Netz, kann sich NFS 4 kleine Vorteile beim Schreiben erkämpfen. Noch größere Unterschiede offenbaren sich bei einem realen Workload.

Hält NFS 4, was die Entwickler versprechen? Was kosten die neuen Features an Performance? Das klären Benchmarks, die die Versionen und Konfigurationsvarianten gegeneinander ausspielen.

Lohnt der Umstieg auf NFS 4? Auf der Hand liegt der Sicherheitsvorteil der möglichen Kerberos-Authentifizierung und -Verschlüsselung, Was aber kostet das an Performance? Welchen Schub entfalten die Optimierungsbemühungen der Entwickler, die ja gerade in Netzen mit höherer Latenz einen merklichen Performancegewinn versprechen? Das Linux-Magazin hat nachgemessen.

Mit einzelnen Benchmarks und unter verschiedenen Netzwerkbedingungen testeten wir in unserem Labor unterschiedliche NFS-Setups. Mit Ubuntu als der ursprünglich gewählten Linux-Distribution ließ sich allerdings selbst mit erheblichem Zeiteinsatz keine Kombination von NFS mit Kerberos zum Laufen bewegen (siehe Kasten “Stolpersteine”). Deshalb wichen die Tester zeitweise in eine virtuelle Umgebung unter Fedora aus.

Sicherheit kostet

Die geringsten Unterschiede zwischen den NFS-Versionen und -Spielarten ergaben sich bei den Messungen mit Iozone [1] in der virtuellen Umgebung. Dort waren zum einen die verfügbaren Ressourcen limitiert – im vorliegenden Setup teilten sich der virtuelle NFS-Server und sein Client einen Single-CPU-Host -, zum anderen sind die Netzwerkzugriffe tatsächlich Speicheroperationen, die sich anders verhalten als ein reales LAN. Schließlich maßen die Tester drittens nur sequenzielle Lese- und Schreiboperationen, die der Fileserver nicht weiter optimieren konnte.

NFS 3 und 4 liegen hier gleichauf, die Differenzen bewegen sich im Bereich eines Prozents. Die sicherste NFS-Variante, die mit Kerberos nicht nur authentifiziert, sondern auch verschlüsselt, fällt erwartungsgemäß deutlich zurück (Abbildung 1, links). Der Security-Overhead verursacht ein Minus zwischen 15 (schreibend) und 30 Prozent (lesend).

Anders sieht sie Sache in einem realen Netzwerk aus. Für diesen Versuch lief der gleiche Benchmark auf einem Netzwerkvolume, das der Client von einem potenten Server mit Diskarray via Gigabit-Ethernet gemountet hatte (siehe Kasten “So haben wir getestet”). Unverschlüsseltes NFS 4 brachte es hier lesend und schreibend auf jeweils knapp 60 MByte/s und hatte zumindest beim Schreiben auch deutlich die Nase vor seinem Vorgänger (15 bis 20 Prozent plus).

Beide NFS-Varianten waren sogar eine Spur schneller als die lokale Platte des Clients, stand ihnen doch auf dem Server eine performante Raid-1-LUN zur Verfügung, auf der auch kein Betriebssystem dazwischenfunkte, und die Host-Anbindung mit Ultra-Wide-SCSI war außerdem deutlich schneller als Parallel-ATA beim Client. Diese Faktoren können den Netzwerk-Malus offenbar mehr als kompensieren (Abbildung 3).

So haben wir getestet

NFS 4 trat gegen die lokale Platte und seinen Vorgänger NFS 3 unter anderem auf realer Hardware an. Dafür stand das Servermodell Proserv II der Firma Exus Data zur Verfügung (Abbildung 2 oben). Das Mainboard mit Intel-Chipsatz ist mit zwei Quad-Core-Xeon 5400 CPUs (3,16 GHz) und 16 GByte RAM bestückt. Für die Netzwerkanbindung gibt es zwei Gigabit-Ethernet-Schnittstellen. Abbildung 2: Die Hardware für die NFS-Benchmarks: Oben der Server von Exus Data, unten das Transtec-Raid. Zwei interne SATA-Platten, die der integrierte Controller auch spiegeln kann, nehmen das Betriebssystem auf. Die Daten-Platten der Testkonfiguration befinden sich in einem Transtec 6100 SATA Premium Raid (Abbildung 2, unten), ausgestattet mit zwölf Serial-ATA-Disks, einem 320-UW-SCSI-Controller für die Anbindung des Hosts und 512 MByte Cache. Für die Benchmarks richtete das Team ein 100 GByte großes Volume auf einer Raid-1-LUN, formatiert mit Ext 3 ein. Als Betriebssystem verwendet der NFS-Server die Server-Edition von Ubuntu 8.04.1 mit einem Kernel 2.6.24-19. Passend dazu lief der NFS-Client, ein Standard-PC, unter der Ubuntu-Desktop-Unterrelease 8.0.4.1 mit demselben Kernel. Für den Vergleich des kerberesierten NFS mit der nicht verschlüsselten Variante und seinem Vorgänger mussten die Tester einen anderen Weg einschlagen (siehe Text). Auch kam es hier weniger auf die absoluten Messwerte als auf deren Verhältnis zueinander an. Sie richteten NFS-Server und Client als virtuelle Maschinen mit Hilfe von KVM ein. Der Host war ein älterer Dell Optiplex unter Fedora Core 9, der jeder VM 1 GByte RAM anbieten konnte.

Praxistest

Ein synthetischer Benchmark wie das hier verwendetet Iozone vermittelt dennoch nur eine annähernde Vorstellung von der Realität, denn die gemessenen reinrassigen Lese- und Schreiboperationen kommen in der Praxis so nicht vor. Alle Effekte, die sich aus der Mischung und Abfolge der Filesystem-Aktionen in der Praxis ergeben, fallen dabei unter den Tisch. Optimierungsbemühungen der Fileserver-Software müssen ins Leere greifen, wenn sich lediglich eine einzige Operation fortwährend wiederholt. Zwar ergibt sich der Vorteil, dass sich einzelne Einflüsse so leichter isolieren und getrennt bewerten lassen – den aber erkauft man mit dem Nachteil, dass die einfache Addition der separierten Einflüsse nicht die praxisgerechte Summe ergibt.

Gerade die Wechselwirkungen sollten bei einem Benchmark, der einen typischen Funktionsmix absolviert, besser zur Geltung kommen. Die Wahl fiel auf Dbench [2], eine kleine Benchmarksuite aus der Feder des bekannten Samba-Entwicklers Andrew Tridgell.

Vorbild für Dbench ist die kommerzielle Windows-Software Netbench, die sich in ihrer Welt als Quasi-Standard etabliert hatte, aber nur für wenige nutzbar war. Das liegt nicht nur an Lizenzbestimmungen, sondern auch an der Tatsache, dass man für einen Netbench-Lauf 60 bis 150 Windows-PC plus gut ausgebautem Server in einem schnellen Netz benötigt und zudem in der Lage sein muss, diese Umgebung zentral zu dirigieren.

Weil Open-Source-Entwicklern derart ausgestattete Labore nicht allzu oft offenstehen, entschloss sich Tridgell ein “Netbench for the Masses” zu schreiben. Entstanden ist ein Triumvirat: Dbench emuliert die Filesystem-Operationen, die ein realer Netbench-Lauf in einem Filesystem einmal ausgelöst hat. Sie wurden aufgezeichnet und lassen sich nun wieder einspielen, wobei die Anzahl der jeweils beteiligten User skalierbar ist. Dbench gibt den daraus resultierenden I/O-Durchsatz aus, der sicherlich als absoluter Wert weniger informativ ist, aber durchaus für Vergleiche zwischen Systemen oder verschiedenen Nutzerzahlen taugt.

Dbench führt selbst keine Netzwerkoperationen aus. (Die sind natürlich trotzdem im Spiel, wenn man den Benchmark – wie hier – auf ein Netzwerkvolume ansetzt.) Wer nur die Netzwerkseite untersuchen möchte, für den gibt es dafür das Dbench-Pendant Tbench, das ausschließlich den Netzwerkverkehr eines Windows-Fileservers nachstellt. Beides zusammen bietet das Tool SMB Torture, ein Stresstester für Samba-Server.

Abbildung 3: Das neuere NFS ist stets deutlich schneller, geht aber anscheinend eher in die Knie.

Fazit

In einem geswitchten100-MBit-LAN zeigte sich deutlich, dass NFS 4 durchaus in Sachen Geschwindigkeit punkten kann, und zwar gerade in einem praxisnahen Setup, wo offenbar die Optimierungen der neuen NFS-Version greifen. Unverschlüsselt war es meist gut doppelt so schnell wie sein Vorgänger (Abbildung 2). Allerdings schwindet dieser Vorteil bei sehr großen Benutzerzahlen auf dem NFS-Server wieder merklich.

/export *(rw,fsid=0,no_subtree_check,sync)

/export/Verzeichnis *(rw,nohide,insecure,no_subtree_check,async)

mount -t nfs4 myhost:/ /mnt

/home host.beispiel.com(rw)
/home host.beispiel.com (rw)