File-Locking bei geclusterten NFS-Servern – so geht's

Bei einem geclusterten NFS-Server ist File-Locking keine leichte Aufgabe. Es lauern viele Stolperfallen, die schlimmstenfalls Datenverluste nach sich ziehen.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht
Lesezeit: 11 Min.
Von
  • Stefan Kania
Inhaltsverzeichnis

Nach dem Erscheinen des Artikels "Linux-HA-NFS-Cluster für v3 und v4" kam von einem Leser die Anmerkung, das Thema File-Locking sei doch zu kurz geraten. Daher nehmen wir es hier noch einmal auf.

Beim NFS-Locking verhalten sich NFSv3 und NFSv4 unterschiedlich. NFSv3 überträgt die Aufgaben auf mehrere Daemons, so auch das File-Locking: Der nfsd stellt die vom Client angeforderten Dateien zwar bereit, beherrscht aber kein Locking der geöffneten Dateien. Der statd überwacht den Zustand einer Verbindung und verwaltet den Status sowohl des Clients als auch des Servers. Über den Network Status Monitor (NSM) sorgt er für einen stets aktuellen Status während der Zugriffszeit des Clients. Der über den lockd bereitgestellte Network Lock Manager (NLM) stellt auf einem NFSv3-Server sicher, dass zwei Clients nicht dieselbe Datei zum Schreiben öffnen. Zusätzlich kann er zusammen mit dem NSM erkennen, wenn ein Client neu bootet, und dann alle Locks des Clients freigeben.

Mehr zu Servern
Stefan Kania

Stefan Kania ist ausgebildeter Informatiker und seit 1997 freiberuflich als Consultant und Trainer tätig. Seine Schwerpunkte liegen in der Implementierung von Samba und LDAP sowie in Schulungen zu beiden Themen.

Die Locks werden dabei immer im Dateisystem des NFS-Servers abgelegt, und zwar in /var/lib/nfs/sm und /var/lib/nfs/sm.back. Darin liegen Dateien, die die IP-Adressen der Clients mit Locks auf dem NFS-Server enthalten. Mehr Information liefert die Manpage zu rpc.statd. Mit dem kleinen Tool flock lässt sich überprüfen, ob die Locks funktionieren.

Immer mehr Wissen. Das digitale Abo für IT und Technik.






Immer mehr Wissen. Das digitale Abo für IT und Technik.