Angie Lingnau, Fotolia

Was zählt, ist die Praxis, hat sich das Linux-Magazin gedacht und eine Bitte um Kommentare an Mailinglisten und Einzelpersonen geschickt. Das Ergebnis sind Erfahrungen und Performance-Tipps aus dem NFS-Alltag von Sysadmins, darunter auch ein waschechter NFS-4-Anwender.

Provozierende Statements zu NFS heißen: unsicher, langsam, uralt. “Macht fast gar nichts”, sagen die Praktiker, “es kommt auf das Szenario an.” Auf einem internen Dateiserver sei die Authentisierung nicht das wichtigste Feature und die massenhafte Übertragung von 200-KByte-Textdateien erfordere keine besondere Performance. In heterogenen Netzen, so die Admins, kämen sie an NFS schlicht nicht vorbei. Außerdem schätzen sie NFS als einfache, schnelle Lösung. Für hohen Durchsatz auch in Gigabit-Netzwerken könne man ansonsten ja noch einiges tun. Manch einer überleg t sogar die Einführung von NFS 4.

Einfach einfach

“Für ‚alte Hasen’ ist NFS einfach und schnell aufgesetzt, und mit den kleinen Fehlern kann man meist gut leben”, fasst Herbert Wengatz von der GUUG (German Unix User Group) die Situation zusammen. Er beziffert die Zeit, die er dafür braucht, auf weniger als eine Minute. “Je mehr tolle Features ein Filesystem besitzt, umso unhandlicher lässt es sich auch aufsetzen. Profi-Admins tendieren dazu, zu Gunsten einer stabilen Produktion lieber etwas konservativ zu sein. Solange etwas zuverlässig funktioniert, nehmen sie kleine Schwächen oft hin. Lieber so, als Bleeding Edge zu sein und sich mit neuen ‚Features’ herumärgern zu müssen”, erklärt der alte Unix-Hase (Abbildung 1).

Abbildung 1: Herbert Wengatz arbeitet seit 20 Jahren als Unix-Sysadmin in Unternehmen mit teilweise sechsstelliger Mitarbeiterzahl.

An kleinen Schräubchen dreht Bernd Künnen, der bei einer mittelständischen Softwarefirma für Automobil und Maschinenbau arbeitet. Als Systemdesigner gestaltet er die IT-Landschaft und beeinflusst die Implementierung. “An der Datenverarbeitung sind rund 20 Linux- und fünf Windows-Systeme beteiligt”, beschreibt er das Setup. “In der Regel nehmen wir die Default-Einstellungen. Manchmal setzen wir aber gezielt auf UDP, wenn ältere Systeme TCP nicht unterstützen. In anderen Fällen kommt auch mal die Software mit NFS per TCP nicht klar. Ab und zu muss man die Blockgrößen erhöhen, was typischerweise von den Dateigrößen abhängt, die über das Netz müssen. Mit »rsize=8192« und »wsize=8192« haben wir ganz gute Erfahrungen gemacht.”

Durchsatz messen

Konkrete Tests für den Durchsatz machen viele Admins. Benchmarks stehen sie kritisch gegenüber, weil unklar sei, was und wie diese ihre Daten erheben. Stattdessen messen sie wie Wengatz einfach die real benötigte Zeit: “Wir haben eine Reihe von Servern, die auf identischer Hardware aufgesetzt sind und auf denen die gleichen Linuxe laufen. Dann geben wir ein Filesystem einmal unter Samba frei und einmal unter NFS und starten jeweils am anderen Ende die Applikation mit den Testdaten. Bei uns verarbeitete die Applikation ein Datenvolumen von rund 40 GByte. Und dann stoppt man einfach mal die Zeit. Hat den charmanten Vorteil, dass nicht irgendwelche obskuren Benchmarks zum Einsatz kommen. Denn die real laufende Applikation ist letztlich ausschlaggebend.”

Für den Systemadministrator Ralph Mayer steht der Durchsatz nicht an erster Stelle. Bei ihm geht es hauptsächlich um Datenaustausch im SAP-Umfeld. Als Problem sieht er die Firewalls, für die er bei NFS auf eine “sehr unschöne Protokollsammlung inklusive der Diskussion TCP oder UDP” stoße. Mayers Firma betreibt als Dienstleister in Rechenzentren weltweit SAP-Systeme für mittelständische Kunden. Über 1000 Switches, Firewalls und Router verteilen sich dafür über den Globus. “Wir haben einen unglaublichen Zoo an Betriebssystemen und Anwendungen”, fügt er hinzu.

Nicht sicher

Die sich daraus ergebenden Anforderungen an das Netzwerk benennt der IT-Mitarbeiter erstens mit der Abschottung der Systeme voneinander mittels vieler Firewalls. Zweitens benutze fast jeder Kunde private IP-Adressen, was Network Address Translation (NAT) erforderlich macht, und drittens scheide durch die Vielfalt der Plattformen NFS 4 aus. Die SAP-Software, beschreibt Mayer, läuft typischerweise auf einem Arbeitsplatz in der Buchhaltung des Kunden.

Hier fange das Problem für eine Firewall an, führt der Admin aus: “Der Client fragt den Portmapper auf dem Server nach dem Port für den Mount- oder NFS-Daemon. Die Firewall liest die Antwort des Portmappers mit. Wenn die Firewall aber kein NFS versteht, müssten wir alle Ports auf der Firewall freigeben, was auf alle Highports hinausläuft. Da wir nur so wenig wie möglich freigeben, haben wir dann ein Problem.”

Sein Berufskollege Wengatz sieht Sicherheitsprobleme von NFS in der Verschlüsselung. “In einem normalen internen Firmennetzwerk ist dieses Problem im allgemeinen nicht besonders hoch aufgehängt, da man sich innerhalb einer Firma ja meistens vertraut. Etwas anderes sind aber Daten der Buchhaltung, von Ärzten oder Banken. Das sind hochsensible personenbezogene Daten, und die müssen geschützt werden. Dieses Problem kann Tunneling etwa über SSH lösen”, weiß der Unix-Admin. Mit NFS 4 erledigen sich diese Security-Probleme weitgehend, darin sind sich viele Admins einig.

Datenverlust

Schwerwiegender als die Sicherheitsbedenken, meint Wengatz, sei die Gefahr der so genannten Silent Data Corruption bei einem NFS-Server der Version 2 im Gigabit-Ethernet. Auch wenn NFS 3 TCP eingestellt hat, verwendet es nach dem Fallback-Prinzip UDP, wenn sein Partner nur NFS 2 beherrscht. In Kombination mit alten NFS-2-Servern kann das dazu führen, dass NFS ungewollt UDP verwendet. Da das User Datagram Protocol jedoch weder Ankunft noch Reihenfolge fragmentierter Daten prüft, übernimmt diese Aufgabe die Applikation, die auf UDP aufsetzt, hier also NFS.

Wengatz erklärt, wie UDP und Hochgeschwindigkeitsnetz sich in die Quere kommen: “In langsamen Netzen war fehlende Paketkontrolle kaum ein Problem. Im Gigabit-Netzwerk, das stark belastet ist, besteht jedoch die Gefahr, dass eine große Datei von einer später gesendeten quasi überholt wird. NFS verwendet nur eine 16-Bit-Checksumme für fragmentierte Datenpakete. Wenn Pakete im Extremfall die gleiche ID und Checksumme haben, überschreibt der NFS-Server angefangene Datenströme. Das heißt, ich habe plötzlich defekte Dateien im NFS-Filesystem und keiner weiß, warum.”

Gigabit-Tuning

Mit NFS in Gigabit-Netzwerken kennt sich auch René Pfeiffer aus, der hier Tipps für Performance und Troubleshooting gibt (Abbildung 2). Seine typischen NFS-Szenarien sind Fileserver mit Benutzerzugriffen von bis zu 250 Clients, NFS-Server als Backup-Sicherung oder als Backend für virtualisierte Systeme (Abbildung 3). Für höhere Raten als 100 MBit/s bereitet er das Speichersystem, das Netzwerk und den Kernel gezielt vor, etwa mit schnellen Festplattensystemen und den Raid-Kombinationen 1 und 10. Schlechte Erfahrungen machte er mit PCI-Karten in der 32-Bit-Ausführung, weil sie von den Gigabit-Geschwindigkeiten schnell überfordert seien. Gute Erfahrungen bescherten ihm Karten mit Chipsätzen von Intel oder Broadcom. Für hohen Traffic empfiehlt er den Umstieg auf das Polling-Modell der Netzwerktreiber per New API mittels der »NAPI«-Option im Linux-Kernel.

“NAPI muss man sich in Hochleistungsnetzwerken merken”, erklärt der Netzwerktechniker. “Die ersten Linux-Netzwerkkartentreiber haben für jedes eingehende Paket einen Interrupt generiert. Bei hoher Last sind das Tausende Interrupts, die nichts bringen: Der Kern weiß ja eigentlich schon, dass viel Arbeit ansteht. NAPI dagegen erlaubt Datenpakete ohne Interrupts anzunehmen.” Um die Option zu verwenden, muss der Kernel entsprechend kompiliert sein. Ob sie im eigenen System aktiviert ist, verrät das Kommando »grep -i NAPI /boot/config-Kernelplattform«.

Abbildung 2: René Pfeiffer setzt als selbstständiger IT-Dienstleister Systeme auf und unterrichtet an der technischen Fachhochschule Technikum Wien.

Abbildung 3: Sein Testnetz dient Rene Pfeiffer unter anderem für Durchsatz-Messungen von NFS und SMB.

Engpässe analysieren

Feineinstellungen von Rsize, Wsize und Jumbo-Frames machen für Pfeiffer jedoch den Löwenanteil am Leistungsgewinn aus. Er erklärt: “NFS benutzt per Default unter Linux UDP-Pakete und eine Puffergröße von 4096 Byte. Viele erhöhen den Wert auf 8192.” Pfeiffer verweist aber auf die Ethernet-Schicht: “Haben dort die Standard-Frames eine Größe von maximal 1500 Byte, verursacht NFS starke Fragmentierung. Aber bei Gigabit-Ethernet eröffnet sich die Option der so genannten Jumbo-Frames von 9000 Bytes und mehr.”

Bei häufigen Timeouts von Client-Zugriffen rät Pfeiffer, einen Blick auf die eingestellten Nfsd-Prozesse zu werfen. Der »ps«-Befehl gibt Aufschluss über die laufenden NFS-Daemons. Per Default ist deren Anzahl auf 8 bis 16 Prozesse gesetzt, erklärt der Systemadministrator. “Man kann die Anzahl der Threads erhöhen. Unter Debian stellt man sie in der Datei »/etc/default/nfs-kernel-server« mit anschließendem Neustart des NFS-Serverprozesses ein.” Sind andererseits zu viele Nfsd-Prozesse konfiguriert, fällt lediglich mehr RAM-Verbrauch an, da NFS den Platz zur Verwaltung seiner Daemon-Aktivitäten benötigt. “Dieser Nachteil ist oft zu verschmerzen oder ich beseitige das Problem durch Speicherausbau”, so Pfeiffer.

Die oft geführte Beschwerde “NFS hängt schon wieder!” hat nach Pfeiffers Erfahrung nur vordergründig mit dem Dateisystem zu tun. “Ein NFS-Mount mit der Option »soft« gibt der zugreifenden Anwendung bei Netzwerk-Verlust eine Fehlermeldung zurück. Das kann je nach Anwendung zu Datenverlust führen. Daher benutzen Admins üblicherweise die Option »hard«, die den Client mit seiner Zugriffsoperation warten lässt, bis der Server wieder verfügbar ist. So äußern sich dann diese NFS-Hänger”, diagnostiziert der Sysadmin. Wenn sich diese Stockungen häufen, liege das aber am Setup: “Das Problem liegt dann meist am Netzwerk oder am Server. Gute Systeme lassen uns nicht hängen.”

Ein NFS-4-Pionier

Wie auch Pfeiffer kennen viele Admins die Version 4 des Network File System nur von Testservern oder vom Hörensagen. Anders Christoph Neuhaus (Abbildung 4): Auf seinem HA-System mit Terabyte-Raid greifen seit knapp zwei Jahren zehn bis zwölf Clients via NFS 4 zu. Der Informatiker zeigt sich angetan: “Wir hatten mit NFS 3 sehr unschöne Erfahrungen gemacht, sprich Datenverluste und beschädigte Datensätze. Seit dem Einsatz von NFS 4 kommt das nicht mehr vor.” Allerdings sei nicht allein NFS 3 schuld gewesen. Alte Netzwerkhardware und die Mountoption »soft« hätten ebenfalls zu den Aussetzern beigetragen, differenziert Neuhaus.

Der Linux-Magazin-Leser erläutert die Entscheidung für NFS 4: “Wir hatten beschlossen alle Clients auf Linux umzustellen, weil wir eine eigens entwickelte Software nicht mehr für mehrere Betriebssysteme warten wollten. In Centos ist NFS 4 integriert, was ein Grund für meine Entscheidung war. Ich hatte mich vor zwei Jahren zum Systemadministrator für Solaris 10 zertifizieren lassen und war dadurch mit NFS 4 in Berührung gekommen. Da ich durch den Kurs sehr positive Erfahrungen gemacht hatte, machte ich den Versuch”, sagt der gebürtige Schweizer.

Weniger Aufwand

Die Einfachheit von NFS 4 nennt Neuhaus als Motivation: “Mich hat unter Solaris 10 beeindruckt, wie einfach es war, mehrere Dateisysteme miteinander zu verknüpfen und via NFS 4 zu exportieren. Unter NFS 3, jedenfalls mit Red Hat Linux 9, musste man ja noch jede Partition einzeln exportieren und auf den Clients mounten. Bei unseren diversen Datenquellen war das keine schöne Angelegenheit, weil es aufwändig war.”

“Außerdem ist die neue Version viel einfacher zu konfigurieren: In der Firewall der Server den Port 2049 öffnen – fertig, jedenfalls fast. Unter NFS 3 musste ich die verschiedenen Dienste wie Mountd, Lockd oder Statd auf feste Ports trimmen, dazu kamen noch die wesentlich aufwändigeren Sicherheitseinstellungen über TCP-Wrapper in »/etc/hosts.allow« und »/etc/hosts.deny«. Man könnte also sagen, meine Faulheit war mitverantwortlich”, ironisiert sich der Sysadmin, versachlicht aber sofort wieder: “Je mehr Einstellungen ich vornehmen muss, umso eher übersehe ich etwas.”

Weniger angetan zeigt sich der Wahl-Brandenburger von der Linux-Unterstützung der neuen NFS-Version. “Probleme hatte ich zum Beispiel mit unerklärlichen Hängern”, führt der Tüftler aus. “Aber wo ein Wille ist …”

Linux-Probleme

“Manche Clients froren einfach ein, sodass nur noch der Netzschalter half. Als ich aufgeben und zurück auf Version 3 stellen wollte, kam ein rettendes Kernel-Update. Immer noch ist es aber unter Centos 4 nicht möglich, externe Dateisysteme unter dem NFS-4-Pseudofilesystem zu mounten und dann als ein Ganzes zu exportieren. Das liegt daran, dass es in »/etc/exports« die Option »crossmnt« noch nicht gibt. Also musste ich trotzdem, wie bei NFS 3, jedes eingebundene Dateisystem in »/etc/exports« eintragen.Nach mehreren Kernel-Updates exportiert der NFS-4-Server nun Benutzer- und andere Datenverzeichnisse, die auf einer mit DRBD gespiegelten Platte liegen. Der Server ist redundant ausgelegt, wir hatten in den 20 Monaten, die das System mittlerweile läuft, dadurch gerade mal zwei Tage Downtime”, resümiert der Admin.

Doku mit Bug

Mit seinem neuen Wissen will Neuhaus auch die restlichen Linux-Server umstellen. “Zu den Erfahrungen gehört unter anderem, dass in der deutschen Übersetzung etwas Falsches steht”, warnt er. “Ich brauchte ganze zwei Tage, bis ich die Diskrepanz bemerkte. Es hing an dem Dienst »rpc.idmapd«, ohne den der Datenexport mit NFS 4 nicht funktioniert. Die deutsche Übersetzung sagt, den Dienst brauche man nicht [3], das Original sagt das Gegenteil [2].”