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.
- Stefan Kania
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.
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.