web-dev-qa-db-fra.com

Empêcher une connexion NFS interrompue de geler le système client

Nous avons un partage NFS 4, partageant un volume entre un certain nombre de serveurs (serveur NFS et clients tous Debian 8). Nous avons récemment rencontré des problèmes où des pannes de réseau gèlaient les systèmes clients.

Nos options NFS étaient minimes, juste rw (et donc les valeurs par défaut hard, fg, etc.).

J'expérimente maintenant avec ces options, mais je n'obtiens pas le comportement que j'attends: rw,soft,bg,retrans=6,timeo=150

(J'ai augmenté les retransmissions pour compenser une partie du risque faible)

La procédure que je suis en train de tester est:

  • Machine de démarrage
  • cd à /mnt/mountpoint
  • Vérifiez la connexion NFS ok
  • cd /
  • tuer le réseau ifdown eth0
  • cd à /mnt/mountpoint
  • ls

À ce stade, la ligne de commande se bloque et je ne peux pas l'interrompre. Après un certain temps, le message 'nfs: server [servername] ne répond pas, chronométré out`, qui semble se répéter une fois par minute (indéfiniment).

Ce que j'aimerais/m'attends à ce que l'opération échoue et que je revienne au contrôle.

S'il vous plaît quelqu'un pourrait-il me dire où je me trompe avec ces paramètres?

(PS: j'ai également essayé de monter avec des autofs, mais j'ai vu un comportement similaire)

Je vous remercie

nfs
22
UpTheCreek

intr devrait vous permettre de reprendre le contrôle lorsque vous appuyez sur ^C, mais généralement pas immédiatement.

   intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the
                  file  operation  and cause it to return EINTR to the calling program.  The default is to not allow file
                  operations to be interrupted.

Comme vous le dites, les attentes sont le problème ici. Les problèmes de réseau peuvent être temporaires, mais l'échec d'une opération est permanent. Par conséquent, la plupart des opérations par défaut sont simplement bloquées jusqu'à la fin de l'opération.

Ceci est la réponse standard, mais en regardant une page de manuel actuelle, je vois ceci:

                  The  intr / nointr mount option is deprecated after ker-
                  nel 2.6.25.  Only SIGKILL can interrupt  a  pending  NFS
                  operation on these kernels, and if specified, this mount
                  option is ignored  to  provide  backwards  compatibility
                  with older kernels.

Donc, il ne me semble pas que ce soit un problème NFS3/NFS4, mais une décision sur le fonctionnement de intr. Vous devriez donc pouvoir KILL le processus, mais cela peut ne pas vous donner beaucoup d'utilité.

Je n'ai pas pu trouver la discussion sur la raison pour laquelle l'option a été supprimée. Pouvez-vous tuer -KILL votre processus?

4
BowlOfRed

Une partie de ma réponse est une opinion, basée sur l'expérience. Là où j'ai des faits, je vais (essayer de m'en souvenir) les relier.

  1. NFS 4 est considéré comme amélioration par rapport aux versions 2 et 3. Cependant, je n'ai pas encore vu de cas d'utilisation solide pour avoir besoin des améliorations. C'est peut-être parce que je vise à exporter des systèmes de fichiers vers des clients Windows avec Samba et vers des clients Unix/Linux avec NFS.
  2. Je ne recommanderais pas soft dans presque toutes les circonstances. Il permet aux données d'être rejetées en cas d'erreur . Je suggère plutôt hard,intr.
  3. Comme vous le faites remarquer, intr n'est pas valide pour NFS 4, mais il semble que ce soit changement de noya plutôt que NFS.
  4. Le NFS Automounter (autofs) fonctionne bien pour mes cas d'utilisation avec les versions NFS 2 et 3, et parvient à protéger mes systèmes clients contre les pannes de serveur en montant les systèmes de fichiers NFS uniquement lorsqu'ils sont requis.

Ma suggestion à vous serait d'envisager de passer de NFS 4 à NFS 3 et de voir si cela aide votre cas d'utilisation particulier. Ne le considérez pas comme un déclassement.

3
roaima