Est-il possible d'avoir un dossier de départ hébergé avec NFS?
Je prévois de déployer des ordinateurs kiosques et je voudrais leur laisser une petite clé USB comme disque de démarrage, en 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é à la connexion, rsynced à la déconnexion.
Mes craintes sont que travailler avec des fichiers puisse devenir trop lent, ou mon réseau pourrait devenir obstrué .
J'utilise NFS pour mes répertoires personnels dans notre environnement de production. Il y a quelques astuces.
Ne montez pas NFS sur
/home- de cette façon, vous pouvez avoir un utilisateur local qui vous permet en cas de panne du serveur NFS. Nous montons à/mnt/nfs/homeUtilisez des supports souples et un délai très court - cela empêchera les processus de se bloquer à jamais.
Utilisez le automounter . 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:/homeUtilisez un système d'authentification unique afin de ne pas rencontrer de problèmes liés aux autorisations. J'ai un serveur OpenLDAP.
Soyez prudent avec les supports souples! Le montage en douceur d'un système de fichiers NFS signifie IO échouera après un délai d'expiration. Soyez très sûr que c'est ce que vous voulez sur les répertoires personnels des utilisateurs! Je suppose que vous ne le faites pas. Utiliser un montage dur sur les répertoires personnels en combinaison avec l'option intr sont beaucoup plus sûrs ici.
Le disque dur n'expirera pas: IO 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 montage dur se 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.
HowtoForge a publié un article intitulé Création d'un serveur de stockage autonome de type NFS avec GlusterFS sur Debian Lenny , vous voudrez peut-être le vérifier.
Voici une courte description de pourquoi c'est une bonne alternative "faisable" à NFS, à partir de la page du projet GlusterFS :
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 quand il y a est besoin.
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 demander à de nombreux programmes de stocker leurs caches ailleurs (par exemple, sur un disque local) en définissant le XDG_CACHE_HOME variable 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.
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 vissé 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 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 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 page de manuel exports(5) indique ...
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 - c'est-à-dire, si le serveur NFS revient - la connexion a été restaurée 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. =)
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.
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.
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.
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.