Est-il possible d'avoir un dossier de départ hébergé avec NFS?

30

Je prévois de déployer des ordinateurs kiosques et je voudrais leur laisser une petite clé USB comme disque de démarrage, gardant le reste sur un serveur facile à sauvegarder, ala LTSP .

En ce moment, je réfléchis à deux options. Un NFSed / home /, ou une copie locale de ~ / copiée à la connexion, rsynced à la déconnexion.

Mes craintes sont que travailler avec des fichiers puisse devenir trop lent ou que mon réseau soit obstrué .

voyageur
la source
Pourriez-vous remplacer "sûr" par un autre mot moins lié à la sécurité? Peut-être faisable merriam-webster.com/dictionary/feasible ?
Cristian Ciupitu
1
Un léger sentiment de déjà vu. Ce n'est pas exactement la même chose, mais c'est un fil intéressant qu'ils ont là. hardware.slashdot.org/story/09/06/23/1823201/…
voyager

Réponses:

30

J'utilise NFS pour mes répertoires personnels dans notre environnement de production. Il y a quelques astuces.

  1. Ne montez pas sur NFS /home- de cette façon, vous pouvez avoir un utilisateur local qui vous autorise à entrer en cas de panne du serveur NFS. Nous montons à/mnt/nfs/home

  2. Utilisez des montures souples et un délai très court - cela empêchera les processus de se bloquer à jamais.

  3. Utilisez l' automonteur . Cela réduira l'utilisation des ressources et signifie également que vous n'avez pas à vous soucier du redémarrage des services lorsque le serveur NFS démarre s'il tombe en panne pour une raison quelconque.

    auto.master:
      +auto.master
      /mnt/nfs /etc/auto.home --timeout=300
    
    auto.home
       home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
    
  4. Utilisez un système d'authentification unique afin de ne pas rencontrer de problèmes liés aux autorisations. J'ai un serveur OpenLDAP.

Aaron Brown
la source
J'ai toujours trouvé le montage automatique horriblement peu fiable et enclin à se bloquer, surtout si le serveur NFS tombe en panne. Si vous montez sur / mnt / nfs / home, est-ce là que vous définissez le domicile de l'utilisateur dans / etc / passwd?
pjc50
2
Eh bien, utiliser / etc / passwd et NFS pour monter les répertoires personnels est une mauvaise idée, car vous devez garder l'UID et les GID synchronisés - utilisez quelque chose comme OpenLDAP, mais oui, le répertoire personnel de l'utilisateur est défini sur / mnt / nfs / home /Nom d'utilisateur.
Aaron Brown,
@AaronBrown Je suis d'accord que si vous allez mettre $ HOME sur le réseau, vous devez également mettre l'identité et l'authentification des utilisateurs sur le réseau. Quelle que soit la façon dont vous le faites, $ HOME doit être défini quelque part et vous avez indiqué que vous préférez le définir, /mnt/nfs/homemais comment utilisez-vous votre section locale /homependant une panne? Plus précisément, veuillez consulter unix.stackexchange.com/questions/189404/…
JFlo
8

http://www.howtoforge.com a récemment publié un article sur l'utilisation de GlusterFS comme remplacement / alternative NFS, vous voudrez peut-être le vérifier.

http://www.howtoforge.com/creating-an-nfs-like-standalone-storage-server-with-glusterfs-on-debian-lenny

Voici une courte description des raisons pour lesquelles c'est une bonne alternative «faisable» à NFS, à partir de la page du projet GlusterFS http://www.gluster.org/ :

"GlusterFS s'auto-guérit à la volée. Il n'y a pas de fsck. Le backend de stockage est accessible directement en tant que fichiers et dossiers normaux (style NFS). Avec la réplication activée, GlusterFS peut résister aux pannes matérielles."

Plus d'informations peuvent être trouvées dans la documentation du projet.

En outre, une autre bonne chose à propos de l'utilisation de GlusterFS est que si vous avez besoin de plus d'espace sur votre SAN, vous ajoutez simplement une autre brique de stockage (nœud de serveur) et vous êtes en mesure de faire évoluer / augmenter votre stockage en parallèle lorsque cela est nécessaire.

J'espère que cela vous aide ou au moins vous oriente dans la bonne direction!

faultyserver
la source
7

Soyez prudent avec les supports souples! Le montage en douceur d'un système de fichiers NFS signifie que les E / S échoueront après un délai d'attente. Soyez très sûr que c'est ce que vous voulez sur les répertoires personnels des utilisateurs! Je suppose que non. L'utilisation d'un montage dur sur les répertoires personnels en combinaison avec l'option intr semble beaucoup plus sûre ici.

Le disque dur n'expirera pas: les opérations d'E / S seront réessayées indéfiniment. L'option intr permet d'interrompre le processus de montage. Donc, si vous montez l'exportation et rencontrez un échec, le hard-mount verrouillera votre session. L'option intr permettra d'interrompre le montage, donc la combinaison est assez sûre et garantit que vous ne perdrez pas facilement les données d'un utilisateur.

Quoi qu'il en soit, autofs rend tout cela encore plus facile.

wzzrd
la source
1
notez que l' introption de montage a été dépréciée sous linux après le noyau 2.6.2, voir par exemple access.redhat.com/solutions/157873
myrdd
4

La seule chose à noter est que lorsque le serveur NFS est hors service - vos montages gèleront - faire un montage logiciel ne bloquera pas ainsi le "gel" lui-même peut être évité, mais cela ne résoudra pas le problème des répertoires personnels comme sans home répertoire, l'utilisateur est foutu de toute façon.

Même lorsque le serveur NFS se rétablit, à moins que vous ne fassiez quelque chose, le problème de gel restera - vous devrez tuer le processus sur la machine de montage et remonter. La raison en est que lorsque le serveur NFS revient, il en a affecté un autre fsid- vous pouvez donc au moins résoudre ce problème en codant en dur les fsids sur le serveur NFS, par exemple ...

#. Home Directories
/usr/users \
  192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
  192.168.80.0/22(rw,sync,no_root_squash,fsid=1)

#. Scratch Space
/var/ftp/scratch \
  192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
  192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
  172.28.24.151(rw,async,root_squash,fsid=3)

La exports(5)page de manuel déclare ...

fsid=num
          This option forces the filesystem identification portion of the file handle
          and  file attributes used on the wire to be num instead of a number derived
          from the major and minor number of the block device on which the filesystem
          is  mounted.   Any 32 bit number can be used, but it must be unique amongst
          all the exported filesystems.

          This can be useful for NFS failover, to ensure that  both  servers  of  the
          failover  pair use the same NFS file handles for the shared filesystem thus
          avoiding stale file handles after failover.

... Bien que cela indique que tant que les nombres majeurs / mineurs ne changent pas (ce qu'ils ne font généralement pas, sauf lorsque vous exportez des volumes SAN / multichemin, où cela peut changer), j'ai constaté que nous 'ai complètement éliminé le problème - par exemple, si le serveur NFS revient - la connexion a été rétablie rapidement - je ne sais toujours pas vraiment pourquoi cela a fait une différence pour des appareils tels que /dev/sdaX par exemple.

Je dois maintenant souligner que mon argument est en grande partie anecdotique - cela n'a en fait aucun sens pourquoi il a résolu le problème, mais il "semble" l'avoir corrigé - d'une manière ou d'une autre - il y a probablement d'autres variables en jeu ici que j'ai pas encore découvert. =)

Xerxès
la source
Êtes-vous sûr de ce fsid "aléatoire" utilisé par le serveur?
Cristian Ciupitu
Salut Cristian - J'ai essayé d'expliquer ci-dessus - mais je ne peux pas expliquer complètement le comportement par rapport à la description de la page de manuel du drapeau. L'avez-vous essayé et vu autrement?
Xerxes
4

Quelques conseils généraux qui s'appliqueront quel que soit le système de fichiers réseau que vous adoptez: de nombreux programmes mettent en cache les données dans le répertoire personnel de l'utilisateur, ce qui fait généralement plus de mal que de bien lorsque le répertoire personnel est accessible via un réseau.

De nos jours, vous pouvez dire à de nombreux programmes de stocker leurs caches ailleurs (par exemple, sur un disque local) en définissant la XDG_CACHE_HOMEvariable d'environnement dans un script de connexion. Beaucoup de programmes (par exemple, Firefox) nécessitent toujours une configuration manuelle, cependant, vous devrez probablement faire un travail supplémentaire pour les identifier et les configurer de manière uniforme pour tous vos utilisateurs.

Sam Morris
la source
+1 J'ai rencontré des problèmes de performances avec les répertoires personnels de Google Chrome et NFS. corrigé en déplaçant les répertoires de travail de Chrome vers le système local, puis en plaçant un lien symbolique depuis le répertoire principal NFS (où Chrome s'attend à trouver les répertoires), vers le répertoire local. Il y a peut-être une meilleure façon de faire ce que j'ai fait, mais cela a résolu le problème pour moi.
Bryan
Bryan (9 mars) a laissé une bonne réponse partielle, cependant, je veux développer cette question. Veuillez faire ... Merci .. Comment avez-vous déplacé les répertoires de travail vers la machine locale et placé les liens symboliques.
Jason
Regardez également l' XDG_RUNTIME_DIRemplacement de la base de données Dconf décrit à: developer.gnome.org/dconf/unstable/dconf-overview.html
JKnight
3

Beaucoup d'endroits où j'ai travaillé utilisent des répertoires personnels montés NFS. Il n'y a généralement pas une énorme différence de performances (et les utilisateurs de kiosques sont probablement un peu moins exigeants que les développeurs qui savent comment contacter leur informaticien local). Un problème que j'ai vu est ce qui se passe lorsque je suis connecté à un bureau Gnome et que le serveur NFS disparaît pour une raison quelconque. Les choses ne réagissent vraiment pas.

kbyrd
la source
2

J'utilise une maison NFSed et cela fonctionne bien. mais vous devez vous assurer que le réseau est suffisamment rapide et qu'il ne sera jamais en panne.

cd1
la source
2

Sur une base pratique, NFS fonctionne bien pour le répertoire personnel s'il existe un réseau commuté de 100 Mbits ou mieux. Pour plus de 10 à 20 kiosques, le serveur doit avoir une connectivité gigabit. Vous ne gagnerez pas de concours de performances, mais des choses comme Firefox et Open Office fonctionneront bien.

La copie dans le répertoire personnel sera une douleur majeure en termes de retards de connexion (sur un réseau de 100 Mbits qui est au maximum de 12 Mo / s. Un répertoire personnel de 100 Mo est proche de 10 secondes.) Rsync vous lancera la synchronisation du cache du navigateur Web ... 10 minutes et 500 fichiers blessés.

Alexandre Carmel-Veilleux
la source
1

Jetez un oeil à cachefilesd . Je ne l'ai pas utilisé moi-même, mais cela semble prometteur.

Le démon cachefilesd gère les fichiers de mise en cache et le répertoire utilisés par les systèmes de fichiers réseau tels que AFS et NFS pour effectuer une mise en cache persistante sur le disque local.

N'oubliez pas non plus de régler les paramètres rsize et wsize et d'utiliser des trames Jumbo si possible.

Cristian Ciupitu
la source
J'ai essayé cachefilesd pendant plusieurs années mais j'ai abandonné en raison de toute l'instabilité qu'il a apportée. YMMV
JFlo