Ce problème m'a rendu fou.

J'ai un serveur NFS avec des partages NFS montés sur divers clients. Cependant, chaque fois que je dois redémarrer le serveur NFS, je me retrouve invariablement avec un tas d'erreurs "Stale file handle" sur les montages sur tous mes clients, ce qui m'oblige à démonter et remonter manuellement mes partages NFS sur les clients.

J'ai vérifié mes exportations sur mon serveur NFS cat /etc/exportset je transmets le même fsid pour chaque exportation NFS lors des redémarrages.

Mes questions:

  1. Comment l'industrie gère-t-elle ce problème? J'ai du mal à imaginer des administrateurs système entrer et démonter/remonter manuellement chaque client ou simplement redémarrer en masse les clients connectés. Ou est-ce vraiment ainsi que cela est géré? (En dehors de la norme, "Nous n'avons jamais de temps d'arrêt et nous n'avons jamais à redémarrer les serveurs NFS.")
  2. Pourquoi cela arrive-t-il? Est-ce parce que, même si le fsid peut être le même, le serveur NFS recalcule les descripteurs de fichiers qui peuvent ne pas être les mêmes d'un redémarrage à l'autre ?
  3. Y a-t-il quelque chose que je devrais améliorer dans ma configuration de montage pour éviter cela ?

/etc/fstab:

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

Par cet article , il a été suggéré d'ajouter hardet de intrmonter des options, mais cela ne semble pas avoir fait de différence.

  1. Si tout le reste échoue, dois-je simplement revenir à l'utilisation d'un script bash pour surveiller le montage/répertoire à la recherche d'une erreur de fichier obsolète et lui faire effectuer un cycle de montage/montage ?

Merci d'avance.

-Clé dynamométrique

answer

Vous utilisez NFS version 3, qui nécessite plusieurs services d'assistance en plus du service NFS principal sur le port 2049. L'un d'entre eux est rpc.statd, qui joue un rôle clé dans la détection des redémarrages et la récupération/effacement des verrous NFS après un redémarrage.

Ces services d'assistance peuvent être situés dans des ports aléatoires, et ils sont découverts en contactant le mappeur de port RPC (généralement un processus nommé rpcbindsur les Linux modernes). Dans les réseaux modernes dotés de pare-feu, un tel comportement peut rendre les choses difficiles : même si vous pouvez les trouver dans des ports d'apparence déterministe après un redémarrage, ils peuvent être attribués à des numéros de port assez différents si/quand vous redémarrez les services NFS.

Heureusement, sur de nombreux systèmes modernes de type Unix, vous pouvez verrouiller les numéros de port du gestionnaire de verrouillage NFS (historiquement rpc.lockd, de nos jours généralement implémenté dans le noyau), rpc.statdet rpc.mountd. Ceci est essentiel si vous souhaitez faire passer NFSv3 à travers des pare-feu avec une quelconque fiabilité.

Pour RHEL et les distributions associées, vous pouvez verrouiller les numéros de port d'assistance NFS en ajoutant ces lignes dans/etc/sysconfig/network :

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

Pour Debian et les distributions associées, vous pouvez ajouter cette ligne à /etc/modprobe.d/nfs.conf:

options lockd nlm_udpport=4045 nlm_tcpport=4045

... et cette ligne en /etc/default/nfs-common:

STATDOPTS="-p 4046"

... et cette ligne en /etc/default/nfs-kernel-server:

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

(Vous pouvez utiliser différents numéros de port si vous le souhaitez, mais 4045 est le port par défaut pour le gestionnaire de verrouillage NFSv3 dans Solaris et codé en dur pour le même dans HP-UX 11.31.)


Mais il y a un autre écueil dans le protocole NFSv3. Bien que vous puissiez monter avec succès un partage NFS en utilisant uniquement des adresses IP, le protocole de verrouillage NFSv3 utilise en interne des noms d'hôte. Le client et le serveur doivent tous deux se connaître sous les noms corrects, sinon le verrouillage du fichier NFS et la récupération du verrouillage après un redémarrage ne fonctionneront pas. Et le "nom correct" pour chaque système est le nom rapporté par uname -n.

Ainsi, si les uname -nretours sont respectivement server.examplesur le serveur et client.examplesur le client, vous devez vous assurer que ces noms exacts seront résolus en adresses IP que les hôtes doivent utiliser pour NFS. En d'autres termes, le serveur doit pouvoir contacter le client en rpc.statdutilisant le nom client.exampleet vice versa.

Si vous ne le faites pas, tout peut sembler bien fonctionner au début... mais lorsque l'une ou l'autre des extrémités redémarre, vous pouvez obtenir ces Stale file handleerreurs.

En plus de l'excellente réponse de @telcoM, je voudrais suggérer deux autres solutions possibles :

  • monter nfs avec l' noacoption de (méfiez - vous que cela va causer une perte de performance lors de l' émission lssur le grand répertoire ou statsur de nombreux fichiers)

  • utilisez NFS v4.1 (la v4.0 avait quelques bogues conduisant à une "gestion des fichiers obsolètes", alors assurez-vous de sélectionner le protocole v4.1).