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


21

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.

Options Notre NFS étaient minimes, juste rw(et donc les valeurs par défaut hard, fgetc.).

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: serveur [nom_serveur] ne répond pas, a expiré», 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


3
Je ne recommanderais soften aucun cas. Il permet d' éliminer les données en cas d'erreur . Au lieu de cela, je suggère hard,intr.
roaima

2
@roaima - Merci. Cette opinion semble être très répandue sur le Web :) Le problème est que la situation actuelle avec laquelle nous sommes hardest tout aussi mauvaise pour nous (les systèmes meurent et restent morts jusqu'au redémarrage). intrn'est pas pris en charge dans NFS4 selon l'homme.
UpTheCreek

2
(Correction, il semble que intrcela soit pris en charge par NFS4, mais pas par les noyaux> 2.6.25)
UpTheCreek

Je pense que ce qui diffère des réponses «standard», c'est que vous changez le répertoire de travail actuel en point de montage. Obtenez-vous le même comportement sans cd, mais à la place ls /mnt/mountpoint? Il est possible qu'après l' lséchec, votre shell tente d'effectuer des opérations sur le système de fichiers dépendant de PWD. (Pire encore, si vous avez été assez idiot pour mettre .votre $PATH)
Toby Speight

Réponses:


4

intrdevrait vous permettre de reprendre le contrôle lorsque vous frappez ^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 intrfonctionnement. Vous devriez donc pouvoir suivre KILLle processus, mais cela ne vous donnera peut-être pas 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?


Merci, mais selon l'homme intrest pris en charge par nfs 2/3 mais pas 4.
UpTheCreek

@UpTheCreek, je ne comprends pas pourquoi ce serait. Je n'ai pas de système Debian ici mais il est explicitement mentionné comme disponible. L'as tu essayé? "intr Cela permettra d'interrompre les opérations NFS4 (sur les supports durs) en attendant une réponse du serveur."
BowlOfRed

2
Ouais, je l'ai essayé, et ça n'a pas semblé avoir d'effet. L'homme dit qu'il est ignoré dans les versions récentes du noyau.
UpTheCreek

Il n'est pas possible de TUER un processus car l'ensemble du système se bloque. D'après mon expérience, aucune commande ne peut être émise. (Bien qu'il puisse être possible de SSH dans une telle machine gelée dans certains cas.)
MountainX pour Monica Cellio

3

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 une 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 softdans presque aucune circonstance. Il permet d' éliminer les données en cas d'erreur . Au lieu de cela, je suggère hard,intr.
  3. Comme vous le faites remarquer, ce intrn'est pas valable pour NFS 4, mais il semble que ce soit un changement de noyau plutôt qu'un changement 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 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.


1
Merci, mais je ne suis pas en mesure de passer à NFS3, et même si j'étais, comme vous le dites, intrn'est pas pris en charge sur les versions récentes du noyau.
UpTheCreek

2
Ah oui, on dirait qu'il intr est pris en charge dans NFS4 (il est répertorié dans les deux seules options 2/3 et les 4 seules options dans man, ce qui est un peu déroutant), mais tout simplement pas pris en charge dans les versions récentes du noyau.
UpTheCreek

1
"Je ne recommanderais jamais le soft en aucune circonstance" - vraiment? Dans mon cas, j'ai un serveur Web occupé qui monte un répertoire d'images. Si l'hôte d'images tombe en panne et que nous utilisons hard, tout le site Web tombe en panne. Si nous utilisons soft, nous pourrions éventuellement obtenir quelques images cassées (bien que notre système de mise en cache atténue cela presque complètement). Le risque d' softautoriser la corruption de fichiers n'est pas vraiment un gros problème. Je préfère de loin avoir un fichier image corrompu qu'un site en panne!
Doug McLean

1
@DougMcLean ayant également été dans une situation similaire (ferme Web occupée, serveurs d'images, NFS ...) je dirais que c'est un cas un peu spécialisé. Si mes serveurs d'images avaient été aussi peu fiables, je soupçonne que j'aurais bien pu me contenter d' softune solution acceptable. Réponse modifiée de "jamais" à "presque jamais". Merci!
roaima

1
Si ma mémoire est correcte, ce problème de gel du système était également présent dans NFS v3.
MountainX pour Monica Cellio
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.