# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Autofs y automount para servir nfs


Algunos de los pros de automount/autofs frente a montar sistemas de ficheros de forma estática es su dinamismo y simplicidad. Si utilizamos automount para servir nfs podemos conseguir que el export NFS únicamente esté montado cuando realmente es necesario, reduciendo la posibilidad de corrupción del sistema de ficheros. Si es un filesystem con pocos accesos también es útil no tenerlo montado de forma permanente y establecer un timeout.

En la parte práctica, nfs con automount es muy útil para servir las /home de usuarios, pudiendo el usuario tener un mismo directorio home centralizado para varias máquinas, también para repositorios de software compartido, etc. Vamos a ver el ejemplo más sencillo de servir un directorio por nfs y automount en unas máquinas CentOS:

Requisitos

Necesitaremos estos dos paquetes:

# yum install nfs-utils autofs

Disponer de una NAS o servidor NFS con un export configurado (IP 192.168.1.144), por ejemplo:

# more /etc/exports
/repo *(rw)

Configuración automount en los clientes

El fichero de configuración principal es /etc/auto.master, en el cual se especifican los mapeos, puntos de montaje y parámetros de configuración. Muchas veces, por limpieza y tener mejor estructuración, los parámetros y puntos de montaje se especifican en ficheros aparte (/etc/auto.misc o el que queramos).

Nosotros queremos por un lado, mapear el directorio local /export con el sistema de ficheros NFS. De momento establecemos esta configuración en auto.master (Tenéis ejemplos en el fichero así como comentarios de ayuda):

/export        /etc/auto_repo

Y en el fichero /etc/auto_repo especificamos punto de montaje, flags del filesystem y el export NFS:

repo	-fstype=nfs,rw,nosuid	192.168.1.144:/repo

Iniciamos servicios autofs y nfs:

/etc/init.d/nfs start && /etc/init.d/autofs start

Vemos los puntos de montaje actuales:

# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
/dev/sda5            1008M   34M  924M   4% /home

Entramos en /export/repo y volvemos a revisar los puntos de montaje, aparece automáticamente el export NFS:

Nota: con automount tienes que saber el path directo, no puedes usar [TAB]

# cd /export/repo
[root@server1 repo]# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
192.168.1.144:/repo   7,7G  963M  6,4G  13% /export/repo

Una vez pasado el timeout especificado el punto de montaje quedaría desmontado automáticamente. Este es el ejemplo más básico de automount y autofs, podríamos llegar a montar vía export todas las home de usuario, Autofs + LDAP y otras configuraciones más complejas. De momento esta es la idea básica sobre la que podéis comenzar a trabajar. Os dejo unos enlaces recomendados para aprender más sobre autofs:

  1. Automount y autofs en es.tldp.org
  2. Automounter examples en www.linux-consulting.com

NetApp y rsync: mkstemp failed: File too large (27)


Este problema ha surgido en una cabina NetApp mientras realizaba una copia de seguridad vía rsync contra un volumen montado por NFS. El problema es que la copia tenía un tamaño considerable y sobre todo una cantidad muy elevada de ficheros. Tras un rato realizando el rsync sin problemas comenzaron a saltar errores tal que:

rsync: mkstemp "xxxxxxxxxxx" failed: File too large (27)
rsync: mkstemp "xxxxxxxxxxx" failed: File too large (27)
rsync: mkstemp "xxxxxxxxxxx" failed: File too large (27)
rsync: mkstemp "xxxxxxxxxxx" failed: File too large (27)

Revisando los logs de la cabina (syslog) efectivamente vemos que el origen del problema es en la configuración de la directiva maxdirsize limit del volumen:

Wed Jul 27 11:36:06 CEST [ems.engine.inputSuppress:warning]: Event 'wafl.dir.size.max' suppressed 1455 times since Tue Jul 26 20:21:47 CEST 2011.
Wed Jul 27 11:36:06 CEST [wafl.dir.size.max:warning]: Directory /vol/xxxx reached the maxdirsize limit. Reduce the number of files or use the vol options command to increase this limit.

Así que la solución es sencilla, aumentamos el valor para ese volumen y solucionado:

filer*>  vol options mi_volumen maxdirsize 125000

Storage: diferencias entre NAS, SAN y DAS


NAS (Network Attached Storage), SAN (storage area network) y DAS (Direct Attached Storage) son tres modos de almacenamiento muy utilizados en la actualidad y que conviene saber diferenciar para conocer en que momento nos puede ser de utilidad uno u otro.Conocer el significado de sus siglas ya nos puede dar una idea de cada uno, no obstante vamos a ver de forma directa y clara lo que es cada uno de ellos.

NAS (Network Attached Storage)

Este modo de almacenamiento se caracteriza por servir de soporte para el compartimiento de datos dentro de una red a través del protocolo TCP-IP y basandose en sistemas de ficheros remotos como NFS (Network File System) o CIFS (Common Internet File System). Los equipos conectados a la NAS piden los datos (ficheros) de forma remota a la unidad NAS a través de uno de estos dos protocolos y se almacenan en la propia máquina local.

SAN (Storage Area Network)

La principal diferencia entre una NAS y una SAN es que la SAN sirve los datos a bajo nivel a través de protocolos SCSI con tecnologías como fibre channel o iSCSI. Los equipos conectados a la SAN no solicitan los ficheros sino que como están conectados a bajo nivel solicitan el bloque concreto de un determinado disco. La máquina local conectada a una SAN verá el disco/compartición de la SAN como si fuera un disco/sistema de archivos local en lugar de uno remoto.

DAS (Direct Attached Storage)

Finalmente el modo de almacenamiento DAS utiliza la misma forma de comunicación que SAN, a través de protocolos SCSI,SAS y Fibre Channel, aunque en este caso se conecta directamente al servidor a través de un “host bus adapter” (HBA). Las peticiones de datos al igual que en SAN se hacen directamente al sistema de ficheros.

Esta es una pequeña explicación de las diferencias a grandes rasgos entre NAS, SAN y DAS. Lecturas recomendadas para ampliar información en Wikipedia:

Montar una unidad NFS en una máquina virtual Virtuozzo


Para poder disponer de un sistema de ficheros NFS en una máquina virtual en Parallels Virtuozzo, lo primero que debemos hacer es activar nfs desde el nodo Hardware para la máquina virtual:

vzctl set 111 --features nfs:on --save

En este caso 111 es el ID de la máquina virtual a activar. Una vez realizado, ya debería figurar nfs como sistema de ficheros soportado en la máquina virtual:

# grep nfs /proc/filesystems
nodev	nfs

Instalamos todo lo necesario para que funcione NFS en la máquina virtual (en este caso RHEL, CentOS o Fedora):

yum install nfs-utils nfs-utils-lib

Arrancamos nfs:

/etc/init.d/rpcbind start
/etc/init.d/nfs start

Configuramos para que arranque al inicio:

chkconfig --level 3 nfs on
chkconfig  --level 3 rpcbind on

Ya deberíamos poder montar una unidad NFS sin problemas, ya sea directamente con el comando mount o desde el fichero /etc/fstab.

mount -t nfs 192.168.0.1:/compartido /mnt/compartido

Y un ejemplo en fstab:

192.168.0.1:/compartido /mnt/compartido nfs rw 	0 0

NFS: mount: wrong fs type, bad option, bad superblock on X missing codepage or helper program, or other error


En caso de encontrar el siguiente error al tratar de montar un sistema de ficheros NFS:

NFS: mount: wrong fs type, bad option, bad superblock on X missing codepage or helper program, or other error

Verificad que tenéis instalados los nfs-utils:

nfs-utils.i586 : NFS utilities and supporting clients and daemons for the kernel NFS server

Para instalarlo en sistemas RedHat, CentOS, Fedora, etc:

yum install nfs-utils.i586

Después iniciáis nfs:

/etc/init.d/nfs start

Y os aseguráis que rpc.bind está corriendo, sino al tratar de arrancar NFS recibiréis el siguiente error (por pantalla o en los logs):

Cannot register service: RPC: Timed out
: unable to register (statd, 1, udp).

Para arrancar rpcbind:

service rpcbind start

Cómo montar un sistema de ficheros NFS (Cliente Linux)


El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Wikipedia

Vamos a suponer que tenemos montado un servidor con comparticiones NFS (otro día explicaré detalladamente como se monta un servidor NFS). En el caso de querer conectarnos a ese sistema de ficheros desde un equipo remoto (cliente), tendremos que hacerlo del siguiente modo:

mount host:/comparticion /punto/de/montaje

En el ejemplo encontramos:

  • Host: IP o FQDN del servidor que está compartiendo vía NFS
  • /compartición: Ruta que comparte el servidor NFS
  • /punto/de/montaje: Lugar en el que queremos montar la compartición NFS (Punto de montaje)

Un ejemplo real podría ser:

$ mkdir /mnt/compartido
$ mount 192.168.0.199:/home/compartido /mnt/compartido

Una vez realizado, si hacemos un df veremos que efectivamente la unidad ha sido montada satisfactoriamente, y tenemos acceso a ella a través de /mnt/compartido. Para que esto se mantenga tras el reinicio de la máquina, hemos de incluir la línea correspondiente en el fichero /etc/fstab. Por ejemplo, para el ejemplo anterior añadiríamos una línea similar a lo que sigue.

La estructura de la línea es la siguiente:

<server>:</path/of/dir> </local/mnt/point> nfs <options> 0 0

Y en nuestro ejemplo (con opcion de read-write, lectura escritura):

192.168.0.199:/home/compartido /mnt/compartido nfs rw 0 0

Recomiendo no obstante revisar la documentación de Red-Hat pues detallan de forma extensa y muy buena todas las opciones disponibles.

Próximamente montaremos un servidor NFS desde cero.