Tabla de contenidos
El montaje de un filesystem NFS no tiene ningún secreto pero, a veces, el servicio no funciona como lo debería hacer.
En este artículo explicaré los errores que me he ido encontrando con el servicio de NFS, durante la administración profesional de entornos Linux.
Error de NFS – server XXX not responding, timed out
Recientemente he tenido una incidencia con un servidor de NFS de preproducción en el que durante unos segundos el cliente de NFS perdía la conectividad, afectando a una aplicación muy sensible o, traduciéndolo de otra manera, mal desarrollada:
May 10 06:02:07 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:07 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:08 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:09 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:11 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:11 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:13 servidor2 kernel: nfs: server servidor1 not responding, timed out
May 10 06:02:15 servidor2 kernel: nfs: server servidor1 not responding, timed outPara solucionarlo, aumenté el timeout en el que el cliente de NFS va a seguir intentando acceder al servidor antes de dar el error, consiguiendo que el proceso de la aplicación quede bloqueado o interrumpido por IO hasta que reciba respuesta del sistema operativo. Las opciones de montaje configuradas en el /etc/fstab han sido:
ServidorNFS:/FS_SERVIDOR_NFS /PUNTO_DE_MONTAJE nfs vers=4,timeo=60,retrans=60,rw,intr,suid 0 0Destacar los parámetros timeo=60 y retrans=60.
- timeo: Es el tiempo en decenas de segundos que el cliente de NFS espera antes de realizar un nuevo intento.
- retrans: Es el número de reintentos que el cliente de NFS hace para conectarse al servidor.
El motivo de este problema se debió a que el servidor de NFS es un servidor virtual de VMWare (preproducción) que quedaba congelado unos segundos cuando se realizaba un snapshot para la copia de seguridad diaria. Como vemos, las horas coinciden con las de los mensajes de error.
El cliente de NFS era un RedHat 7.3 y el servidor un RedHat 6.5.
RPC: fragment too large
En este caso me encontré con que el servicio de NFS había dejado de funcionar puntualmente y luego se recuperó solo sin que tuviese que hacer nada.
[[email protected] ~]# dmesg |tail
RPC: fragment too large: 1090519040
RPC: fragment too large: 469762048
RPC: fragment too large: 1247096314
RPC: fragment too large: 369295616
RPC: fragment too large: 1224736768
RPC: fragment too large: 1404416
RPC: fragment too large: 1986359923
RPC: fragment too large: 870215
RPC: fragment too large: 1701738089
RPC: fragment too large: 2130706432
[[email protected] ~]#
En el lado del cliente NFS, al ejecutar un simple df -h la salida del comando se quedaba bloqueada permanentemente sin mostrar ninguna información.
Causa del problema
En este caso la tarjeta de red que estaba dando el servicio había perdido link. El servicio se recuperó automáticamente, gracias a la configuración del bonding.
Sin embargo, este problema puede tener otra causa derivada de una reducción de la memoria del servidor NFS.
Cuando arranca el sistema operativo, el parámetro max_block_size, se calcula automáticamente en función de la memoria que tiene el servidor.
[[email protected] ~]# cat /proc/fs/nfsd/max_block_size
524288
[[email protected] ~]#
En base a este valor, los clientes NFS pueden leer y escribir en los filesystems compartidos con este tamaño de bloque máximo.
Ahora bien, si se reduce la memoria del servidor NFS y el tamaño de bloque máximo es menor al que hay configurado en los clientes NFS, obtendremos el error RPC: fragment too large.
Lo que tenemos que hacer si disminuimos la memoria del servidor NFS, es volver a montar los filesystems en los clientes para que vuelvan a adquirir los nuevos valores de rsize y wsize (tamaños de bloque de lectura y escritura).
mount.nfs: Protocol not supported
No nada como empezar la jornada laboral con una serie de filesystems NFS desmontados sin saber por qué. Pero, tirando del hilo, vemos que el equipo de comunicaciones ha cerrado las comunicaciones de los puertos NFS v3 así que, decido montarlo como NFS v4 modificando el fichero /etc/fstab de la siguiente manera:
10.48.40.30:/usr/sap/trans_RIX /usr/sap/trans_RIX nfs vers=4,rw,soft,intr,timeo=14 0 0
Pero, para mi sorpresa, el filesystem no monta, dando el siguiente error:
[[email protected] ~]# mount /usr/sap/trans_RIX
mount.nfs: Protocol not supported
[[email protected] ~]#Solución
Tras estar un rato investigando, me doy cuenta de que en el servidor de NFS, alguien había deshabilitado el protocolo NFS v4, lo vuelvo a habilitar y reinicio el servicio de NFS:
[[email protected] ~]# grep RPCNFSDARGS /etc/sysconfig/nfs
#RPCNFSDARGS="-N 2 -N 3"
#RPCNFSDARGS="-N 4"
[[email protected] ~]#Luego, reinicio el servidor de NFS:
service nfs restartY monto el filesystem desde el cliente, esta vez, sin problemas (mount /usr/sap/trans_RIX).
kernel: nfsd: peername failed (err 107)
El equipo de aplicaciones me comentaba que, de vez en cuando y de manera aleatoria, la aplicación sufría una breve desconexión y no sabían el motivo. Resulta que esta aplicación utiliza un filesystem NFS ubicado en un servidor de NFS que ha ido creciendo con el tiempo y, cada vez más, compartía más filesystems con más servidores.
Revisando el log del sistema operativo (/var/log/messages), aparecían de manera puntual, los siguientes mensajes de error de NFS:
May 22 19:01:33 lensnax1 kernel: nfsd: peername failed (err 107)!
May 22 19:02:07 lensnax1 kernel: nfsd: peername failed (err 107)!
May 22 19:02:07 lensnax1 kernel: nfsd: peername failed (err 107)!
May 22 19:02:07 lensnax1 kernel: nfsd: peername failed (err 107)!
May 22 19:02:07 lensnax1 kernel: nfsd: peername failed (err 107)!
May 22 19:02:07 lensnax1 kernel: nfsd: peername failed (err 107)!Las horas coincidían con las desconexiones sufridas por la aplicación.
Origen del problema
Por lo visto, como el servicio de NFS ha ido creciendo, de vez en cuando, los diferentes clientes de NFS realizaban operaciones de lectura y escritura simultáneamente y se llenaba el buffer de memoria TCP del servidor NFS, causando los errores comentados anteriormente.
Revisando el problema en la WEB de RedHat, encontré este enlace https://access.redhat.com/solutions/63171, que decía que este error puede deberse a:
- Problemas de red
- Alto tráfico de red
- Problemas en el servidor de NFS
En mi caso, el problema estaba en el servidor NFS.
Solución
Para solucionarlo, modifqué los siguientes parámetros del kernel (RedHat 6 – /etc/sysctl.conf):
Valores originales del fichero sysctl.com
net.core.wmem_max = 124928
net.core.rmem_max = 124928
net.core.wmem_default = 124928
net.core.rmem_default = 124928
net.core.netdev_max_backlog = 1000Nuevos valores
net.core.wmem_max = 1048576
net.core.rmem_max = 4194304
net.core.wmem_default = 1048576
net.core.rmem_default = 4194304
net.core.netdev_max_backlog = 3000rmem y wmem es el tamaño en bytes de los bufferes de memoria para o escribir (wmem) y enviar (rmem) paquetes TCP, mientras que netdev es el número máximo de paquetes TCP que pueden encolarse antes de ser procesados.
Después de este cambio, ya no he vuelto a volver a ver estos mensajes de error.
Stale file handle
Me he encontrado con un servidor que no podía acceder un filesystem por NFS, pero este mismo FS sí que estaba accesible por otros cuatro servidores diferentes.
El error que daba era el siguiente:
[[email protected] ~]# ls -la /mnt/nas/jtc_pre/pscp
ls: cannot access /mnt/nas/jtc_pre/pscp: Stale file handle
[[email protected] ~]#Por mi parte he intentado varias cosas para tratar de solucionarlo pero ninguna de ellas ha funcionado:
- Desmontar y volver a montar el FS:
umount -f /mnt/nas/jtc_pre/pscp
mount /mnt/nas/jtc_pre/pscp- Eliminar la caché de filesystems y volver a montar el FS:
# To free pagecache
echo 1 > /proc/sys/vm/drop_caches # To free dentries and inodes
echo 2 > /proc/sys/vm/drop_caches # To free pagecache, dentries and inodes
echo 3 > /proc/sys/vm/drop_caches- Reiniciar el servidor de NFS
Solución
Este FS se estaba montando con NFSv4 en las opciones de fstab. Lo que he hecho ha sido montarlo manualmente con NFSv3 y ha funcionado. Desconozco el motivo. Probablemente se deba a algún bug de NFS4.
[[email protected]~]# mount -t nfs -o vers=3,rw,suid,soft,intr,timeo=300,retrans=5 lcttnat1:/serveis/dades/PRE/NAS01/857_pre_psp/pscp_pre /mnt/nas/jtc_pre/pscp
[[email protected] ~]# ls -la /mnt/nas/jtc_pre/pscp
total 5860
drwxrwxr-x 26 pscp_pre pscp_pre 4096 Dec 15 16:34 .
drwxr-xr-x 4 root root 46 Dec 4 10:00 ..
drwxrwx--- 4 pscp_pre pscp_pre 4096 Apr 28 2010 customizedProfiles
drwxrwx--- 2 pscp_pre pscp_pre 4096 Jun 1 2016 dogcTemplates
