☰

NFS-veralteter Datei-Handle nach Neustarts des NFS-Servers: Warum passiert das und wie geht die Industrie damit um?

tag-icon • tag-icon nfs fstab
NFS-veralteter Datei-Handle nach Neustarts des NFS-Servers: Warum passiert das und wie geht die Industrie damit um?

Dieses Problem hat mich verrückt gemacht.

Ich habe einen NFS-Server mit NFS-Freigaben, die auf verschiedenen Clients gemountet sind. Wenn ich den NFS-Server jedoch neu starten muss, erhalte ich ausnahmslos eine Reihe von „Stale File Handle“-Fehlern bei den Mounts auf allen meinen Clients, was mich dazu zwingt, meine NFS-Freigaben auf den Clients manuell zu demontieren und erneut zu mounten.

Ich habe meine Exporte auf meinem NFS-Server überprüft cat /etc/exportsund übergebe für jeden NFS-Export über Neustarts hinweg dieselbe FID.

Meine Fragen:

  1. Wie geht die Industrie mit diesem Problem um? Ich kann mir kaum vorstellen, dass Systemadministratoren jeden Client manuell aushängen/neu einhängen oder einfach alle verbundenen Clients en masse neu starten. Oder wird das wirklich so gehandhabt? (Abgesehen von der Standardangabe „Wir haben nie Ausfallzeiten und müssen NFS-Server nie neu starten.“)
  2. Warum passiert das? Liegt es daran, dass der NFS-Server Dateihandles neu berechnet, die bei Neustarts möglicherweise nicht gleich sind, obwohl die FSID dieselbe ist?
  3. Gibt es etwas, das ich in meiner Mount-Konfiguration besser machen sollte, um dies zu verhindern?

/etc/fstab:

[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0

Prodieser Beitraghardwurde vorgeschlagen, Mount - Optionen hinzuzufügen intr, aber das scheint keinen Unterschied gemacht zu haben.

  1. Wenn alles andere fehlschlägt, sollte ich dann einfach auf die Verwendung eines Bash-Skripts zurückgreifen, um das Mount/Verzeichnis auf einen Fehler aufgrund einer veralteten Datei zu überwachen und einen Umount/Mount-Zyklus ausführen zu lassen?

Dank im Voraus.

-Drehmomentschlüssel

Antwort1

Sie verwenden NFS Version 3, die neben dem NFS-Hauptdienst auf Port 2049 mehrere Hilfsdienste benötigt. Einer davon ist rpc.statd, der eine Schlüsselrolle beim Erkennen von Neustarts und beim Wiederherstellen/Löschen von NFS-Sperren nach einem Neustart spielt.

Diese Hilfsdienste können sich in zufälligen Ports befinden und werden durch Kontaktaufnahme mit dem RPC-Port-Mapper ( rpcbindin modernen Linux-Versionen normalerweise ein Prozess mit dem Namen) entdeckt. In modernen Netzwerken mit Firewalls kann ein solches Verhalten die Dinge erschweren: Auch wenn Sie sie nach einem Neustart in deterministisch aussehenden Ports finden, werden sie möglicherweise ganz anderen Portnummern zugewiesen, wenn Sie die NFS-Dienste neu starten.

Glücklicherweise können Sie auf vielen modernen Unix-ähnlichen Systemen die Portnummern des NFS-Sperrmanagers (früher rpc.lockd, heutzutage normalerweise im Kernel implementiert) sperren rpc.statdund rpc.mountd. Dies ist wichtig, wenn Sie NFSv3 einigermaßen zuverlässig durch Firewalls bringen möchten.

Für RHEL und verwandte Distributionen können Sie die NFS-Hilfsportnummern sperren, indem Sie die folgenden Zeilen hinzufügen /etc/sysconfig/network:

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047

Für Debian und verwandte Distributionen können Sie folgende Zeile hinzufügen /etc/modprobe.d/nfs.conf:

options lockd nlm_udpport=4045 nlm_tcpport=4045

... und diese Zeile in /etc/default/nfs-common:

STATDOPTS="-p 4046"

... und diese Zeile in /etc/default/nfs-kernel-server:

RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here

(Sie können bei Bedarf andere Portnummern verwenden, aber 4045 ist der Standardport für den NFSv3-Sperrmanager in Solaris und in HP-UX 11.31 fest codiert.)

Das NFSv3-Protokoll birgt jedoch noch eine weitere Tücke. Obwohl Sie eine NFS-Freigabe erfolgreich nur mit IP-Adressen mounten können, verwendet das NFSv3-Sperrprotokoll intern Hostnamen. Sowohl Client als auch Server müssen sich unter den richtigen Namen kennen, sonst funktionieren die NFS-Dateisperre und die Sperrwiederherstellung nach einem Neustart nicht. Und der „richtige Name“ für jedes System ist der von gemeldete Name uname -n.

Wenn also auf dem Server bzw. auf dem Client uname -nzurückgegeben wird , sollten Sie sicherstellen, dass diese genauen Namen in die IP-Adressen aufgelöst werden, die die Hosts für NFS verwenden müssen. Mit anderen Worten: Der Server muss in der Lage sein, den Client über den Namen zu kontaktieren und umgekehrt.server.exampleclient.examplerpc.statdclient.example

Wenn Sie dies nicht tun, scheint zunächst alles reibungslos zu funktionieren. Beim Neustart an einem der beiden Enden können jedoch diese Stale file handleFehler auftreten.

Antwort2

Zusätzlich zu der hervorragenden Antwort von @telcoM möchte ich zwei weitere mögliche Lösungen vorschlagen:

  • mounten Sie nfs mit der noacOption (beachten Sie, dass diesWillekann zu einem Leistungsverlust führen, wenn die Ausgabe lsauf einem großen Verzeichnis oder statauf vielen Dateien erfolgt)

  • verwenden Sie NFS v4.1 (v4.0 hatte einige Fehler, die zu einer „veralteten Dateibehandlung“ führten; wählen Sie daher unbedingt das v4.1-Protokoll aus).

verwandte Informationen