automount nfs: paramètres de délai d'expiration autofs pour les serveurs non fiables - comment éviter le blocage?

18

J'utilise un petit serveur pour notre colocation. Il s'agit principalement d'un serveur de fichiers avec des services supplémentaires. Les clients sont des machines Linux (principalement Ubuntu, mais aussi quelques autres Distros) et quelques Mac (-Book) entre les deux (mais ils ne sont pas importants pour la question). Le serveur exécute Ubuntu 11.10 (Oneiric Ocelot) «Server Edition», le système à partir duquel je fais ma configuration et mes tests exécute la version 11.10 «Desktop Edition». Nous avons exécuté nos partages avec Samba (que nous connaissons mieux) pendant un certain temps, puis nous migrons vers NFS (car nous n'avons pas d'utilisateurs Windows sur le LAN et nous voulons l'essayer) et jusqu'à présent, tout fonctionne bien .

Maintenant, je veux configurer le montage automatique avec autofs pour lisser les choses (jusqu'à présent, tout le monde monte les partages manuellement en cas de besoin). Le montage automatique semble également fonctionner. Le problème est que notre "serveur" ne fonctionne pas 24h / 24 et 7j / 7 pour économiser de l'énergie (si quelqu'un a besoin de trucs du serveur, il l'allume et l'éteint ensuite, donc il ne fonctionne que quelques heures par jour). Mais depuis la configuration automatique, les clients raccrochent souvent lorsque le serveur n'est pas en cours d'exécution.

  • Je peux très bien démarrer tous les clients, même lorsque le serveur ne fonctionne pas.

  • Mais quand je veux afficher un répertoire (dans terminal ou nautilus), qui contient des liens symboliques vers un partage sous /nfsalors que le serveur n'est pas en cours d'exécution, il se bloque pendant au moins deux minutes (car les autofs ne peuvent pas se connecter au serveur mais restent essayer, je suppose).

    • Y a-t-il un moyen d'éviter cela? Pour que le montage soit retardé jusqu'à ce qu'un changement dans le répertoire ou jusqu'à ce que le contenu de ce répertoire soit accessible? Pas lorsque vous "regardez" un lien vers un partage sous /nfs? Je pense que non, mais peut-être est-il possible de ne pas essayer d'y accéder aussi longtemps? Et donnez-moi juste un répertoire vide ou un "ne peut pas trouver / se connecter à ce répertoire" ou quelque chose comme ça.
  • Lorsque le serveur fonctionne, tout fonctionne bien.

  • Mais lorsque le serveur est arrêté, avant qu'un partage ne soit démonté, les outils (comme dfou ll) se bloquent (en supposant qu'ils pensent que le partage est toujours activé mais que le serveur ne répond plus).

    • Existe-t-il un moyen de démonter automatiquement les partages lorsque la connexion est perdue?
  • De plus, les clients ne s'arrêteront pas ou ne redémarreront pas lorsque le serveur est arrêté et qu'ils ont toujours des partages montés. Ils pendent (à l'infini, comme il semble) pour " tuer les processus restants " et rien ne semble se produire.

Je pense que tout se résume à des valeurs de timeout soignées pour le montage et le démontage. Et peut-être pour supprimer tous les partages lorsque la connexion au serveur est perdue.

Ma question est donc la suivante: comment gérer cela? Et en bonus: existe-t-il un bon moyen de se connecter à l'intérieur /nfssans avoir besoin de monter les vrais partages (une option autofs ou peut-être en utilisant un pseudo FS pour /nfslequel il est remplacé lorsque le montage se produit ou quelque chose comme ça)?

Ma configuration

Le paramètre NFS est assez basique mais nous a bien servi jusqu'à présent (en utilisant NFSv4 ):

/ etc / default / nfs-common

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=YES
NEED_GSSD=

/etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

/ etc / exports

/srv/   192.168.0.0/24(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0)

Sous la racine d'exportation, /srvnous avons obtenu deux répertoires avec bind:

/ etc / fstab (serveur)

...
/shared/shared/      /srv/shared/      none    bind  0 0
/home/Upload/        /srv/upload/      none    bind  0 0

Le 1er est principalement en lecture seule (mais j'applique cela à travers les attributs de fichier et la propriété au lieu des paramètres NFS) et le 2ème est rw pour tous. Remarque: Ils n'ont aucune entrée supplémentaire dans / etc / exports , leur montage séparément fonctionne cependant.

Côté client, ils sont installés /etc/fstabet montés manuellement selon les besoins ( mortonc'est le nom du serveur et ça se résout très bien).

/ etc / fstab (client)

morton:/shared  /nfs/shared nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0
morton:/upload  /nfs/upload nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0

Pour la configuration automatique, j'ai supprimé les entrées des /etc/fstabclients et mis en place le reste comme ceci:

/etc/auto.master

/nfs    /etc/auto.nfs

J'ai d'abord attaché l'exécutable fourni /etc/auto.net(vous pouvez le consulter ici ) mais il ne montera rien automatiquement pour moi. Ensuite, j'écris un /etc/auto.nfsbasé sur certains HowTos que j'ai trouvés en ligne:

/etc/auto.nfs

shared  -fstype=nfs4  morton:/shared
upload  -fstype=nfs4  morton:/upload

Et cela fonctionne un peu ... Ou fonctionnerait si le serveur fonctionnait 24/7. Nous obtenons donc les blocages lorsqu'un client démarre sans que le serveur ne fonctionne ou lorsque le serveur tombe en panne alors qu'il partage où il est toujours connecté.

Brutus
la source

Réponses:

2

En utilisant n'importe quel système de montage, vous voulez éviter les situations où Nautilus répertorie le répertoire contenant un montage qui peut ou non être monté. Donc, avec autofs, ne créez pas de montages dans, par exemple, / nfs. Si vous le faites, lorsque vous utilisez Nautilus pour répertorier le «système de fichiers», il essaiera de créer les montages qui devraient exister dans / nfs, et si ces tentatives de montage échouent, il faut quelques minutes pour abandonner.

J'ai donc changé auto.master pour créer les montages dans / nfs / mnt.

Cela a résolu le problème pour moi. Je reçois seulement un long délai si j'essaie de lister le contenu de / nfs / mnt, ce que je peux facilement éviter.

Tim Passingham
la source
20

Montez le partage NFS sur les clients en utilisant les options de montage "bg, intr, hard".

Le plus important dans votre cas est "bg" pour le fond - qui indique au système de ne pas bloquer lorsque le serveur n'est pas disponible.

"intr" pour interrruptable - vous pouvez donc tuer les supports suspendus sur le client avec la commande kill.

"dur" est l'opposé de "doux". La différence est que "hard" continuera d'essayer sans fin tandis que "soft" annulera exponentiellement ses tentatives lorsque le serveur n'est pas disponible.

Nils
la source
Merci pour la réponse. Je ne peux pas tester pour le moment car je ne suis pas chez moi, mais après avoir cherché à obtenir la page de manuel (à nouveau), j'ai d'autres questions: hardet les bgsons sont contre-intuitifs pour moi au début. Je veux que la monture ne réessaye pas et ne revienne pas immédiatement si elle échoue? intrsemble correct mais ne semble plus fonctionner: " L'option de montage intr / nointr est déconseillée après le noyau 2.6.25. Seul SIGKILL peut interrompre une opération NFS en attente sur ces noyaux, et si spécifié, cette option de montage est ignorée pour assurer la compatibilité descendante avec des noyaux plus anciens. "?
Brutus
2
Hard réessayera sans fin - bg ne bloquera PAS si le montage n'est pas possible pour le moment. Le résultat sera qu'il est monté lorsqu'il est disponible, mais toutes les autres opérations continueront. INTR semble être par défaut maintenant - ce qui est génial. Au début, vous deviez redémarrer le client suspendu si votre serveur NFS était mort ...
Nils
Je viens de le tester, mais l'ajout hard,bgde ne /etc/auto.mastersemble rien changer. Un time ls -l ~(mon répertoire utilisateur contient un lien symbolique vers /nfs/upload) prend toujours plus de deux minutes, lorsque le serveur n'est pas en cours d'exécution.
Brutus
Avez-vous redémarré les autofs? Seuls les changements de sous-carte se propageront sans redémarrage des autofs.
Nils
J'ai fait:sudo reload autofs && sudo restart autofs
Brutus le
7

J'ai joué un peu plus avec certaines des options de la page de manuel. Tous bg,hard, bg,soft, fg,hardet fg,softdonne - moi de revenir deux fois de plus menuets.

retrans=1,retry=0Cependant, le réglage (combiné à l'un des éléments ci-dessus) me donne un temps d'environ trois secondes. Assez décent. Bien que je ne sois pas sûr de ce que signifie chaque combinaison. Va creuser plus loin.

Je suis également tombé sur les options autofs MOUNT_WAITet UMOUNT_WAIT. Je n'ai pas pu obtenir de résultats différents avec eux mais je vais continuer d'essayer. Semble également un bon moyen d'utiliser l'option "NFS" (plus de tentatives, etc.) plus sécurisée mais des temps de retour rapides pour les autofs, ou non?

Brutus
la source
1
Il semble également y avoir d'autres options, comme rsize=32768,wsize=32768,noatimeindiqué ici: techrepublic.com/blog/opensource/…
Ehtesh Choudhury
-1

Pour configurer un système de fichiers NFS pour qu'il se monte automatiquement à chaque démarrage de votre système Red Hat Linux, vous devez ajouter une entrée pour ce système de fichiers NFS dans le fichier / etc / fstab. Le fichier / etc / fstab contient des informations sur tous les différents types de systèmes de fichiers montés (et disponibles à monter) pour votre système Red Hat Linux. EX:: nfs Le correspond au nom d'hôte, à l'adresse IP ou au nom de domaine complet du serveur exportant le système de fichiers. Est le chemin d'accès au répertoire exporté. Le spécifie où sur le système de fichiers local pour monter le répertoire exporté. Ce point de montage doit exister avant la lecture de / etc / fstab ou le montage échouera La zone spécifie les options de montage pour le système de fichiers. Par exemple, si la zone d'options indique rw, suid, le système de fichiers exporté sera monté en lecture-écriture et l'utilisateur et le groupid définis par le serveur seront utilisés. Notez que les parenthèses ne doivent pas être utilisées ici

M.Zaman
la source