☰

Manejo de archivos obsoletos de NFS después de reiniciar el servidor NFS: ¿por qué sucede esto y cómo lo maneja la industria?

tag-icon • tag-icon nfs fstab
Manejo de archivos obsoletos de NFS después de reiniciar el servidor NFS: ¿por qué sucede esto y cómo lo maneja la industria?

Este problema me ha estado volviendo loco.

Tengo un servidor NFS con recursos compartidos NFS montados en varios clientes. Sin embargo, cada vez que tengo que reiniciar el servidor NFS, invariablemente termino con un montón de errores de "control de archivos obsoletos" en los montajes de todos mis clientes, lo que me obliga a desmontar y volver a montar manualmente mis recursos compartidos NFS en los clientes.

He verificado mis exportaciones en mi servidor NFS cat /etc/exportsy estoy pasando el mismo fsid para cada exportación NFS durante los reinicios.

Mis preguntas:

  1. ¿Cómo maneja la industria este problema? Me cuesta imaginar que los administradores de sistemas entren y desmonten/remonten manualmente cada cliente o simplemente reinicien los clientes conectados en masa. ¿O es realmente así como se maneja esto? (Aparte del estándar, "Nunca tenemos un tiempo de inactividad y nunca tenemos que reiniciar los servidores NFS").
  2. ¿Por qué pasó esto? ¿Esto se debe a que, aunque el fsid puede ser el mismo, el servidor NFS vuelve a calcular los identificadores de archivos que pueden no ser los mismos entre los reinicios?
  3. ¿Hay algo que debería hacer mejor en mi configuración de montaje para evitar esto?

/etc/fstab:

[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0

Poresta publicación, se sugirió agregar hardy intrmontar opciones, pero eso no parece haber hecho ninguna diferencia.

  1. Si todo lo demás falla, ¿debería recurrir a un script bash para monitorear el montaje/directorio en busca de un error de archivo obsoleto y hacer que realice un ciclo de montaje/desmontaje?

Gracias de antemano.

-Llave de torsión

Respuesta1

Está utilizando NFS versión 3, que necesita varios servicios auxiliares además del servicio NFS principal en el puerto 2049. Uno de ellos es rpc.statd, que tiene un papel clave en la detección de reinicios y la recuperación/limpieza de bloqueos de NFS después de un reinicio.

Estos servicios auxiliares pueden estar ubicados en puertos aleatorios y se descubren contactando al asignador de puertos RPC (generalmente un proceso denominado rpcbinden Linux modernos). En las redes modernas con firewalls, este comportamiento puede dificultar las cosas: aunque puede encontrarlos en puertos de aspecto determinista después de un reinicio, es posible que se asignen a números de puerto bastante diferentes si reinicia los servicios NFS.

Afortunadamente, en muchos sistemas modernos tipo Unix, puedes bloquear los números de puerto del administrador de bloqueo NFS (históricamente rpc.lockd, hoy en día generalmente implementado en el kernel) rpc.statdy rpc.mountd. Esto es esencial si desea pasar NFSv3 a través de firewalls con algún tipo de confiabilidad.

Para RHEL y distribuciones relacionadas, puede bloquear los números de puerto auxiliares de NFS agregando estas líneas en /etc/sysconfig/network:

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047

Para Debian y distribuciones relacionadas, puede agregar esta línea a /etc/modprobe.d/nfs.conf:

options lockd nlm_udpport=4045 nlm_tcpport=4045

... y esta línea en /etc/default/nfs-common:

STATDOPTS="-p 4046"

... y esta línea en /etc/default/nfs-kernel-server:

RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here

(Puede usar números de puerto diferentes si lo desea, pero 4045 es el puerto predeterminado para el administrador de bloqueo NFSv3 en Solaris y está codificado para el mismo en HP-UX 11.31).

Pero hay otro problema en el protocolo NFSv3. Aunque puede montar con éxito un recurso compartido NFS utilizando solo direcciones IP, el protocolo de bloqueo NFSv3 utiliza internamente nombres de host. Tanto el cliente como el servidor deben conocerse por los nombres correctos; de lo contrario, el bloqueo del archivo NFS y la recuperación del bloqueo después de un reinicio no funcionarán. Y el "nombre correcto" para cada sistema es el nombre informado por uname -n.

Entonces, si uname -nregresa server.exampleen el servidor y respectivamente client.exampleen el cliente, entonces debe asegurarse de que esos nombres exactos se resuelvan en las direcciones IP que los hosts deben usar para NFS. En otras palabras, el servidor debe poder contactar al cliente rpc.statdusando el nombre client.exampley viceversa.

Si no lo hace, puede parecer que todo funciona bien al principio... pero cuando cualquiera de los extremos reinicia, es posible que obtenga esos Stale file handleerrores.

Respuesta2

Además de la excelente respuesta de @telcoM, me gustaría sugerir otras dos posibles soluciones:

  • montar nfs con la noacopción (cuidado que estovoluntadcausar una pérdida de rendimiento al publicar lsen un directorio grande o staten muchos archivos)

  • utilice NFS v4.1 (v4.0 tenía algunos errores que provocaban un "manejo de archivos obsoleto", así que asegúrese de seleccionar el protocolo v4.1).

información relacionada