Die vierte Version: NFSv4

In der vierten Auflage wurde das komplette Protokoll umgekrempelt. Während Version 3 eher ein Bugfix war, kann man Version 4 als Redesign mit den Erfahrungen aus den alten Versionen verstehen. Alle einzelnen Dienste wurden im zentralen Programm NFS zusammengefasst. Das NFSv4-Protokoll benötigt auch kein »rpcbind« mehr, weil es fest den Port »2049/tcp« nutzt. Damit können endlich auch alle Firewall-Administratoren aufatmen. In Version 4 ist der Client allein für das Locking zuständig, sodass der »lockd« und »rpc.statd« entfallen. Allein der »rpc.mountd« bleibt übrig, der aber nur auf dem Server lokal zum Einsatz kommt.

Der Server gibt jedem Datei-Handle, das ein Client anfordert, auch eine »nfsv4leasetime« mit. Diese Zeit hat der Client die Datei zur exklusiven Nutzung und der Server sperrt den Zugriff durch andere. Wenn der Client die Daten länger braucht, muss er dies dem Server innerhalb dieser Zeitspanne mitteilen. Vorgabe sind in den meisten Distributionen 90 Sekunden. Mit diesem Trick braucht der Server keine Statusdaten mehr lokal mitzuführen. Welche Dateien gerade von welchem Client in Benutzung sind, kann er im RAM protokollieren. Diese Daten müssen einen Serverabsturz nicht überleben. Nach einem Neustart wartet der Server einfach die »nfsv4gracetime« ab, bevor er Clients den Zugriff auf Daten erlaubt. Innerhalb dieser Zeitspanne haben Clients die Chance, ihre Ansprüche auf Daten anzumelden. Oft ist dieser Parameter ebenfalls auf 90 Sekunden gesetzt, sodass alle Clients ihre Ansprüche durchsetzen können.

Abbildung 1: Nutzt eine Applikation Daten, spricht der NFS-Client mit dem NFS-Server, der sie aus seinem Dateisystem ausliefert.

Grundsätzlich kann man diese Änderung in Version 4 als Verschiebung der Verantwortung für die Locks vom Server hin zum Client verstehen. Der Client ist jetzt für die Sicherung seiner Ansprüche auf die exklusive Nutzung von Daten zuständig. Der Server setzt die Wünsche der Clients nur noch um.

Abbildung 2: Architekturskizze von pNFS: Die Clients holen sich nur noch die Metadaten vom zentralen Server, die Daten selbst aber von den Storage-Servern.

Hochverfügbares NFS

Diese Änderung macht auch das Design eines NFSv4-Server-Clusters wesentlich einfacher. Beim Failover des Dienstes von einem aktiven zu einem Backup-Server müssen keine Statusdaten mehr repliziert werden. Der neue Server wartet einfach auf die Meldungen der Clients. Es bleibt eine Aufgabe des Admins, für die »nfsv4leasetime« und die »nfsv4gracetime« geeignete Werte zu finden. Sind sie zu hoch, können die Clients eine zu lange Zeit nach dem Failover nicht auf ihre Daten zugreifen. Wird die Zeit zu kurz gewählt, müssen die Clients unnötig oft ihre Ansprüche erneuern, was zu erhöhtem Arbeitsaufwand und Netzwerk-Traffic führt.

Typischerweise setzt man die Kernel-Parameter auf 10 Sekunden:

echo "10" > /proc/fs/nfsd/nfsv4gracetime
echo "10" > /proc/fs/nfsd/nfsv4leasetime

Diese Parameter können in den neuen Versionen der Cluster-Software beziehungsweise des Agenten, der für den NFS-Server zuständig ist, konfiguriert werden.