2010-07-08 6 views
9

Estoy tratando de encontrar la forma adecuada de manejar datos obsoletos en el cliente NFS. Considere siguiente escenario: montajeAsegúrese de que el estado del archivo en el cliente esté sincronizado con el servidor NFS

  • Dos servidores misma NFS almacenamiento compartido con el número de archivos
  • aplicación cliente en 1 servidor elimina algunos archivos de aplicación Cliente
  • el 2 de servidor intenta acceder a los archivos borrados y falla con: añejo Manejador de archivo NFS (nada extraño, se espera error)

(También puede ser útil saber que las opciones de montaje de caché son bastante altas en ambos servidores por razones de rendimiento).

Lo que estoy tratando de entender es:

  • ¿Existe un método fiable para comprobar, ese archivo está presente? En el escenario anterior, lstat en el archivo devuelve éxito y la aplicación falla solo después de intentar mover el archivo.
  • ¿Cómo puedo sincronizar manualmente los contenidos del directorio en el cliente con el servidor?
  • Algunos consejos generales sobre cómo escribir código de gestión de archivos confiable en caso de NFS?

Gracias.

Respuesta

11
  • ¿Existe un método fiable para comprobar, ese archivo está presente? En el escenario anterior, lstat en el archivo devuelve éxito y la aplicación falla solo después de intentar mover el archivo.

Eso es normal comportamiento de NFS.

  • ¿Cómo puedo sincronizar manualmente el contenido del directorio en el cliente con el servidor?

Eso es imposible hacerlo de forma manual, ya que NFS se hace pasar por un sistema de archivos compatible con POSIX normal.

me han tratado una vez al código de cierre()/open() en un intento de mitigar de alguna manera los efectos de la caché del cliente NFS. En mi caso, necesitaba leer la información escrita en el archivo en otro servidor. Pero incluso el truco de reapertura tuvo un efecto casi nulo. Y no puedo agregar fdatasync() al lado de la escritura, ya que eso reduce la velocidad de toda la aplicación.

Mi experiencia con NFS hasta la fecha es que nada se puede hacer. En rutas de código críticas simplemente codifiqué para volver a intentar las operaciones de archivo que devuelven ESTALE.

  • Algunos consejos generales sobre cómo escribir código de gestión de archivos fiable en caso de NFS?

Mod yo abajo todo lo que quiera, pero si sus clientes quieren fiabilidad entonces no deberían utilizar NFS.

Mi empresa, por ejemplo, anuncia el uso del sistema de archivos distribuido adecuado (omito deliberadamente la marca) si el cliente quiere fiabilidad. Nuestro software central no está garantizado para ejecutarse en NFS y no admitimos dichas configuraciones. Pero en nuestro caso, realmente necesitamos las garantías de que tan pronto como los datos se escriben en FS, se vuelven accesibles en todos los otros nodos.

Coherencia en NFS se puede lograr, pero a costa de rendimiento, haciendo NFS apenas utilizable. (Verifique sus opciones de montaje.) NFS almacena en caché como un loco para ocultar el hecho de que es un sistema de archivos de servidor. Para que todas las operaciones sean coherentes, el cliente NFS debería ir al servidor NFS de forma síncrona para cada pequeña operación, sin pasar por la memoria caché local. Y eso nunca sería rápido.

Pero ya que estamos hablando aquí de Linux, se puede aconsejar a los clientes del software para evaluar los sistemas de archivos de clúster disponibles. P.ej. RedHat ahora oficialmente es compatible con GFS. He oído hablar de personas que usan CodaFS, pero no tienen información sobre él.

+0

Gracias. Has confirmado la mayoría de mis propios resultados de investigación de NFS. Supongo que codificaré un montón de comprobaciones ESTALE, porque no tenemos planes de migrar a otro tipo de almacenamiento.No aceptaré esta respuesta por el momento, espero que alguien presente más información sobre el tema. – begray

4

Se podría probar el '' noac '' opción de montaje

desde NFS hombre:

Además de prevenir el cliente de atributos de archivo de almacenamiento en caché, la aplicación noac fuerzas opción escribe a convertirse en síncrono para que el local cambie a un archivo se vuelva visible en el servidor inmediatamente. De esta forma, otros clientes pueden detectar rápidamente escrituras recientes cuando comprueban los atributos del archivo .

El uso de la opción noac proporciona una mayor coherencia de caché entre NFS clientes que acceden a los mismos archivos, pero Extrae una penalización de rendimiento significativa . Como tal, se recomienda el uso juicioso del bloqueo de archivos .

Puede tener dos soportes, uno para los datos críticos que cambian rápidamente que necesita sincronizar y otro para otros datos.

Además, mira en NFS locking and its limitations.

En cuanto a los consejos generales:

Una forma de truncar un archivo que se lee simultáneamente desde varios hosts es escribir el contenido en un archivo temporal y luego rename ese archivo a la ubicación final.

En el mismo sistema de archivos esta operación debe ser atómica.

+0

Bueno, eso trae una buena idea: publicar la pregunta a serverfault. Los desarrolladores no tienen forma de influir en NFS programmatically (soluciones temporales en el mejor de los casos), mientras que los administradores tienen que lidiar con NFS y las aplicaciones que se ejecutan en la parte superior con más frecuencia. En consecuencia, estos últimos tienen más experiencia y pueden dar más sugerencias. – Dummy00001

+0

El artículo de bloqueo de NFS vinculado se ha ido, ¿tiene un reemplazo? –

1

que he tenido éxito en hacer ls -l en el directorio que contiene el archivo.

Cuestiones relacionadas