Sistema de archivos distribuido geográficamente con localidad preferida

Estoy creando una aplicación que necesita distribuir un servidor de archivos estándar en algunos sitios a través de una WAN. Básicamente, cada sitio necesita escribir muchos archivos misceláneos de diferentes tamaños (algunos en el rango de los 100 MB, pero la mayoría pequeños), y la aplicación está escrita de tal manera que las colisiones no son un problema. Me gustaría tener un sistema configurado que cumpla con los siguientes requisitos:

1. Cada sitio puede almacenar archivos en un "espacio de nombres" compartido. Es decir, todos los archivos aparecerían en el mismo sistema de archivos.
2. Cada sitio no enviará datos a través de la WAN a menos que sea necesario. Es decir, habría almacenamiento local en cada lado de la WAN que se "fusionaría" en el mismo sistema de archivos lógico.
3. Linux y Gratis ($$$) es un Plus

Básicamente, algo así como un recurso compartido NFS central cumpliría la mayoría de los requisitos, sin embargo, no permitiría que los datos escritos localmente permanezcan locales. Todos los datos de los lados remotos de la WAN se copiarían localmente todo el tiempo.

He examinado Lustre y he realizado algunas pruebas exitosas con él, sin embargo, parece distribuir archivos de manera bastante uniforme en el almacenamiento distribuido. He revisado la documentación y no he encontrado nada que automáticamente "prefiera" el almacenamiento local sobre el almacenamiento remoto. Incluso algo que fuera con el almacenamiento de latencia más bajo estaría bien. Funcionaría la mayor parte del tiempo, lo que cumpliría los requisitos de esta aplicación.

Algunas respuestas a algunas preguntas formuladas a continuación:

• Nodos de servidor: 2 o 3 para comenzar. Cada servidor tendría docenas de clientes de lectura / escritura simultáneos conectados.
• La topología WAN es de malla completa y confiable. (corporación grande, el costo no es tan limitante como la burocracia)
• Conmutación por error del cliente: en realidad no había pensado en hacer que la conmutación por error de los clientes (principalmente porque nuestra aplicación actual no hace esto en un solo sitio). Supuse que la respuesta práctica es que se espera que los servidores en cada sitio distribuido geográficamente sean puntos únicos de fallas para los clientes que atienden. Sin embargo, si está pensando en algo específico aquí, creo que sería bastante pertinente para la discusión.
• Roll-my-own: he pensado en rsync / unison, sin embargo, necesitaría un poco de lógica sofisticada para hacer que la parte "dinámica" de este trabajo funcione a la perfección. Es decir, el archivo parece ser local, pero solo se recupera a pedido.
• MS-DFS: Ciertamente parece ser algo que debería considerar. Mi principal problema podría ser no estar seguro acerca de la configuración / confiabilidad / rendimiento del servidor NFS en Windows, ya que muchos de los clientes que se conectan son clientes NFS.

Lástima el requisito de Linux. Esto es exactamente lo que hace Windows DFS. Desde 2003 R2, también lo hace a nivel de bloque.

Algunas preguntas:

• ¿Cuántos nodos de "servidor" estás pensando en participar en esto?

• ¿Cómo es la topología de conectividad WAN: concentrador y radio, malla completa? ¿Qué tan confiable es?

• ¿Espera que los clientes conmuten por error a un servidor geográficamente no local en caso de que el servidor local falle?

Windows DFS-R ciertamente sería lo que está buscando, aunque con algunos costos de licencia potencialmente altos.

Usted dice que las colisiones no son un problema y que no necesita un administrador de bloqueo distribuido, por lo que puede hacer esto con herramientas de usuario como rsync o Unison y simplemente exportar el corpus de archivos resultante con NFS a los clientes locales. Es feo, y tendrías que manejar unir algún tipo de sistema para manejar la generación de una topología de replicación y ejecutar las herramientas de usuario, pero sin duda sería barato a medida que aumenta el costo de la licencia.

¿Has considerado AFS ?

Andrew File System (AFS) es un sistema de archivos distribuido en red que utiliza un conjunto de servidores confiables para presentar un espacio homogéneo de nombre de archivo transparente para la ubicación a todas las estaciones de trabajo del cliente.

Según tengo entendido, la mayor parte del desarrollo reciente ha estado detrás del proyecto OpenAFS .

No puedo pretender estar lo suficientemente familiarizado con el proyecto para saber si la función de "localidad preferida" está disponible, pero de lo contrario, parece una buena opción.

¿Has mirado las piscinas OST en Luster?

No será automático, pero con los grupos de OST puede asignar directorios / archivos a OST / OSS específicos, básicamente una asignación de almacenamiento basada en políticas, en lugar de la operación por turnos / bandas predeterminada en OST.

Por lo tanto, puede configurar un directorio por sitio y asignar ese directorio a los OST locales para ese sitio, que dirigirá todas las E / S a los OST locales. Seguirá siendo un espacio de nombres global.

Se está trabajando mucho para mejorar el Lustre a través de las conexiones WAN (servidores de almacenamiento en caché locales y cosas por el estilo), pero todo está en desarrollo pesado AFAIK.

Tal vez NFS pero con Cachefs en los servidores de aplicaciones logrará su parte de su objetivo. Según tengo entendido, todo lo escrito aún irá al servidor central, pero al menos las lecturas podrían terminar en caché localmente. Potencialmente, esto podría quitar mucho retraso de las lecturas dependiendo de sus patrones de uso.

Además, vale la pena analizar mabye UnionFS. Con esto, creo que cada ubicación sería una exportación NFS, y luego podría usar UnionFS en cada ubicación para que eso y todos los demás montajes NFS de la ubicación aparezcan como un sistema de archivos. Sin embargo, no tengo experiencia con esto.

Puede buscar DRBD para replicar los discos. http://www.drbd.org/ . Esta es una solución de alta disponibilidad de Linux que acaba de llegar al kernel.

Sin embargo, esto tiene algunas limitaciones:

1. Solo se pueden configurar dos nodos
2. WAN podría ser demasiado poco confiable para mantener DRBD robusto.

Si quiere que sea simple, eche un vistazo a rsync, resuelve muchos problemas y puede ser programado.

Verifique los chironfs .

Tal vez pueda hacer lo que quiera, en función del sistema de archivos.

Btsync es otra solución con la que he tenido una buena experiencia. Utiliza el protocolo BitTorrent para transferir los archivos, por lo que cuantos más servidores tenga, más rápido será la sincronización de nuevos archivos.

A diferencia de la solución basada en rsync, detecta cuándo cambia el nombre de los archivos / carpetas y los renombra en todos los nodos en lugar de eliminar / copiar.

Los clientes de btsync pueden compartir las carpetas en una red local.

El único inconveniente que encontré (en comparación con MS DFS) es que no detectará una copia de archivo local. En su lugar, lo interpretará como un archivo nuevo que se cargará a todos los pares.

Hasta ahora, btsync parece ser la mejor solución de sincronización y puede instalarse en dispositivos Windows, Linux, Android y ARM (por ejemplo, NAS)