Das Titelthema im ADMIN 04/14 "Vernetzt speichern" sind Netzwerkdateisysteme, etwa Samba 4, verteilter Storage mit Ceph & GlusterFS und der Unix-Klassiker ... (mehr)

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021