¿Es factible tener una carpeta de inicio alojada con NFS?

Estoy planeando implementar algunas computadoras de kiosco y me gustaría dejarlas con un pequeño pendrive como disco de arranque, manteniendo el resto en un servidor fácil de respaldar, al igual que LTSP .

En este momento estoy pensando en dos opciones. Un NFSed / home /, o una copia local de ~ / copiado al iniciar sesión, sincronizado al cerrar sesión.

Me temo que trabajar con archivos puede ser demasiado lento o que mi red se obstruya .

Uso NFS para mis directorios de inicio en nuestro entorno de producción. Hay un par de trucos.

1. No monte en NFS /home: de esa manera puede tener un usuario local que le permita entrar en caso de que el servidor NFS se caiga. Montamos a/mnt/nfs/home

2. Use montajes suaves y un tiempo de espera muy corto: esto evitará que los procesos se bloqueen para siempre.

3. Usa el automontador . Esto mantendrá bajo el uso de recursos y también significa que no tiene que preocuparse por reiniciar los servicios cuando se abre el servidor NFS si se cae por alguna razón.

   auto.master:
     +auto.master
     /mnt/nfs /etc/auto.home --timeout=300
   
   auto.home
      home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
   

4. Use un sistema de inicio de sesión único para no tener problemas relacionados con los permisos. Tengo un servidor OpenLDAP.

http://www.howtoforge.com recientemente publicó un artículo sobre el uso de GlusterFS como un reemplazo / alternativa de NFS, puede consultarlo.

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

Aquí hay una breve descripción de por qué es una buena alternativa 'factible' a NFS, desde la página del proyecto GlusterFS http://www.gluster.org/ :

"GlusterFS se cura automáticamente sobre la marcha. No hay fsck. Se puede acceder al backend de almacenamiento directamente como archivos y carpetas normales (estilo NFS). Con la replicación habilitada, GlusterFS puede soportar fallas de hardware".

Se puede encontrar más información en la documentación del proyecto.

Además, otra cosa interesante sobre el uso de GlusterFS es que si necesita más espacio en su SAN, simplemente agrega otro ladrillo de almacenamiento (nodo de servidor) y puede escalar / aumentar su almacenamiento en paralelo cuando sea necesario.

¡Espero que esto ayude o al menos ayude a orientarte en la dirección correcta!

¡Ten cuidado con las monturas suaves! El montaje suave de un sistema de archivos NFS significa que IO fallará después de un tiempo de espera. ¡Asegúrese de que eso es lo que desea en los directorios principales de los usuarios! Supongo que no. El uso de un montaje rígido en directorios de inicio en combinación con la opción intr se siente mucho más seguro aquí.

Hard no agota el tiempo de espera: las operaciones de IO se volverán a intentar indefinidamente. La opción intr permite interrumpir el proceso de montaje. Entonces, si monta la exportación y experimenta una falla, el montaje duro bloqueará su sesión. La opción intr permitirá interrumpir el montaje, por lo que la combinación es bastante segura y garantiza que no perderá fácilmente los datos de un usuario.

De todos modos, autofs hace que todo sea aún más fácil.

Una cosa a tener en cuenta es que cuando el servidor NFS está apagado, sus montajes se congelarán, hacer un montaje suave no bloqueará, por lo que se puede evitar el "congelamiento" en sí mismo, sin embargo, eso no solucionará el problema de los directorios de inicio como si no hubiera un inicio directorio, el usuario está jodido de todos modos.

Incluso cuando el servidor NFS se recupere, a menos que haga algo al respecto, el problema de congelación continuará: tendrá que matar el proceso en la máquina de montaje y volver a montar. La razón de esto es que cuando el servidor NFS vuelve a funcionar, le asigna un diferente fsid, por lo que al menos puede solucionar este problema codificando los fsids en el servidor NFS, por ejemplo ...

#. 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)página del manual dice ...

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.

... Si bien eso indica que siempre que los números mayores / menores no cambien (lo que generalmente no cambian, excepto cuando se exportan volúmenes SAN / multirrutas, donde pueden cambiar), descubrí que He eliminado completamente el problema, es decir, si el servidor NFS regresa, la conexión se ha restablecido rápidamente, todavía no sé por qué esto ha marcado una diferencia para dispositivos como, /dev/sdaXpor ejemplo.

Ahora debería señalar que mi argumento es en gran medida anecdótico: en realidad no tiene sentido por qué ha solucionado el problema, pero "parece" haberlo solucionado, de alguna manera, probablemente hay otras variables en juego aquí que he Aún no descubierto. =)

Algunos consejos generales que se aplicarán sin importar qué sistema de archivos de red adopte: muchos programas almacenan datos en el directorio de inicio del usuario, lo que generalmente hace más daño que bien cuando se accede al directorio de inicio a través de una red.

En estos días, puede indicar a muchos programas que almacenen sus cachés en otro lugar (por ejemplo, en un disco local) configurando la XDG_CACHE_HOMEvariable de entorno en un script de inicio de sesión. Sin embargo, muchos programas (p. Ej., Firefox) aún requieren configuración manual, por lo que probablemente tendrá que hacer un trabajo adicional para identificarlos y configurarlos de manera uniforme para todos sus usuarios.

Muchos de los lugares en los que he trabajado utilizan directorios de inicio montados en NFS. Por lo general, no hay una gran diferencia en el rendimiento (y los usuarios de quioscos probablemente sean un poco menos exigentes que los desarrolladores que saben cómo comunicarse con su chico de TI local). Un problema que he visto es lo que sucede cuando estoy conectado a un escritorio Gnome y el servidor NFS desaparece por cualquier motivo. Las cosas se vuelven realmente insensibles.

Yo uso una casa NFSed y funciona bien. pero debe asegurarse de que la red sea lo suficientemente rápida y que nunca se caiga.

Sobre una base práctica, NFS funciona bien para el directorio de inicio si hay una red conmutada de 100mbit o mejor. Para más de 10-20 quioscos, el servidor debe tener conectividad gigabit. No ganará concursos de rendimiento, pero cosas como Firefox y Open Office funcionarán bien.

Copiar en el directorio de inicio será un gran problema en términos de demoras en el inicio de sesión (en una red de 100 mbits que tiene un máximo de 12 MB / s. Un directorio de inicio de 100 MB está cerca de 10 segundos). minutos y 500 archivos duelen.

Echa un vistazo a cachefilesd . No lo he usado yo mismo, pero parece prometedor.

El demonio cachefilesd gestiona los archivos y el directorio de almacenamiento en caché que utilizan los sistemas de archivos de red como AFS y NFS para realizar el almacenamiento en caché persistente en el disco local.

Además, no olvide ajustar los parámetros rsize y wsize y use marcos jumbo si es posible.