Sistema de archivos de almacenamiento distribuido: ¿cuál / hay un producto listo para usar?

Con Hadoop y CouchDB en todos los blogs y noticias relacionadas, ¿qué es un almacenamiento (motor) tolerante a fallas distribuidas que realmente funciona?

• CouchDB en realidad no tiene ninguna función de distribución incorporada, que yo sepa, simplemente falta el pegamento para distribuir automáticamente las entradas o incluso bases de datos completas.
• Hadoop parece ser muy utilizado, al menos tiene buena prensa, pero aún tiene un único punto de falla: el NameNode. Además, solo se puede montar a través de FUSE, entiendo que HDFS no es realmente el objetivo principal de Hadoop
• GlusterFS tiene un concepto de nada compartido, pero últimamente leí varias publicaciones que me llevan a la opinión de que no es tan estable
• Lustre también tiene un único punto de falla, ya que utiliza un servidor de metadatos dedicado
• Ceph parece ser el jugador elegido, pero la página de inicio dice que todavía está en sus etapas alfa.

Entonces, la pregunta es qué sistema de archivos distribuido tiene el siguiente conjunto de características (sin un orden particular):

• Compatible con POSIX
• Fácil adición / eliminación de nodos
• concepto de nada compartido
• se ejecuta en hardware barato (procesadores de clase AMD Geode o VIA Eden)
• autenticación / autorización incorporada
• un sistema de archivos de red (me gustaría poder montarlo simultáneamente en diferentes hosts)

Agradable tener:

• archivos localmente accesibles: puedo bajar un nodo y montar la partición con un sistema de archivos local estándar (ext3 / xfs / lo que sea ...) y aún acceder a los archivos

Estoy no en busca de aplicaciones alojadas, más bien algo que me permitirá tomar decir 10GB de cada una de nuestras cajas de hardware y tener esa almacenamiento disponible en nuestra red, fácilmente montable en una multitud de los ejércitos.

Creo que tendrá que abandonar el requisito POSIX, muy pocos sistemas implementan eso; de hecho, incluso NFS no lo hace realmente (piense en bloqueos, etc.) y eso no tiene redundancia.

Cualquier sistema que use replicación sincrónica será glacialmente lento; cualquier sistema que tenga replicación asincrónica (o "consistencia eventual") violará las reglas POSIX y no se comportará como un sistema de archivos "convencional".

No puedo hablar con el resto, pero parece estar confundido entre un 'motor de almacenamiento distribuido' y un 'sistema de archivos distribuido'. No son lo mismo, no deben confundirse con lo mismo, y nunca serán lo mismo. Un sistema de archivos es una forma de realizar un seguimiento de dónde se encuentran las cosas en un disco duro. Un motor de almacenamiento como hadoop es una forma de realizar un seguimiento de una porción de datos identificados por una clave. Conceptualmente, no hay mucha diferencia. El problema es que un sistema de archivos es una dependencia de un motor de almacenamiento ... después de todo, necesita una forma de escribir en un dispositivo de bloque, ¿no?

Aparte de eso, puedo hablar sobre el uso de ocfs2 como un sistema de archivos distribuido en un entorno de producción. Si no desea los detalles arenosos, deje de leer después de esta línea: es genial, pero puede significar más tiempo de inactividad de lo que cree.

Hemos estado ejecutando ocfs2 en un entorno de producción durante los últimos años. Está bien, pero no es genial para muchas aplicaciones. Realmente debería considerar sus requisitos y descubrir cuáles son: es posible que tenga mucha más libertad para las fallas de lo que pensaba que tenía.

Como ejemplo, ocfs2 tiene un diario para cada máquina en el clúster que va a montar la partición. Entonces, supongamos que tiene cuatro máquinas web, y cuando crea esa partición usando mkfs.ocfs2, especifica que habrá seis máquinas en total para tener algo de espacio para crecer. Cada uno de esos diarios ocupa espacio, lo que reduce la cantidad de datos que puede almacenar en los discos. Ahora, supongamos que necesita escalar a siete máquinas. En esa situación, debes eliminar todoclúster (es decir, desmontar todas las particiones ocfs2) y usar la utilidad tunefs.ocfs2 para crear un diario adicional, siempre que haya espacio disponible. Entonces, y solo entonces, puede agregar la séptima máquina al clúster (lo que requiere que distribuya un archivo de texto al resto del clúster a menos que esté utilizando una utilidad), vuelva a poner todo en marcha y luego monte la partición en los siete maquinas.

¿Ves lo que quiero decir? Se supone que es alta disponibilidad, lo que se supone que significa 'siempre en línea', pero justo ahí tienes un montón de tiempo de inactividad ... y Dios no permita que estés abarrotado de espacio en disco. NO QUIERES ver qué sucede cuando abarrotas ocfs2.

Tenga en cuenta que evms, que solía ser la forma "preferida" de administrar clústeres ocfs2, ha seguido el camino del pájaro dodo en favor de clvmd y lvm2. (Y buen viaje a evms.) Además, los latidos del corazón rápidamente se convertirán en un proyecto zombie a favor de la pila de openais / marcapasos. (Aparte: al realizar la configuración inicial del clúster para ocfs2, puede especificar 'pcmk' como motor del clúster en lugar de latido. No, esto no está documentado).

Por lo que vale, hemos vuelto a nfs administrados por marcapasos, porque los pocos segundos de tiempo de inactividad o unos pocos paquetes tcp caídos a medida que el marcapasos migra un recurso compartido nfs a otra máquina es trivial en comparación con la cantidad de tiempo de inactividad que estábamos viendo para el básico operaciones de almacenamiento compartido como agregar máquinas cuando se usa ocfs2.

Puedo estar malinterpretando sus requisitos, pero ¿ha mirado en http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Solo para arrojar mis € 0.02 aquí: ¿no puede OpenAFS hacer lo que quiere?

Echa un vistazo a chirp http://www.cse.nd.edu/~ccl/software/chirp/ y loro http://www.cse.nd.edu/~ccl/software/parrot/

¿Qué tal Xtreemfs ? La versión 1.4 (noviembre de 2012) se considera calidad de producción.

Es compatible con POSIX y tiene una excelente tolerancia automática a fallas.

Lustre permite múltiples almacenes de metadatos en configuración activa / pasiva para redundancia, por lo que no hay un solo punto de falla.

También vale la pena mirar OCFS2.

Tenga en cuenta que eliminar el requisito de acceso múltiple simultáneo a la red hace posible cambiar a algo como iSCSI o incluso cifs o nfs. La desventaja es que tiene que 'dividir' piezas de su uberArray en mordidas para cada servidor que necesita espacio.

A menos que sea para fines académicos / de desarrollo, este tipo de cosas deben abordarse comenzando con los requisitos generales para el proyecto. La mayoría de los sistemas de archivos distribuidos no son lo suficientemente maduros para una implementación seria, por ejemplo, ¿qué hacer si todo se descompone? Si es para fines académicos / de desarrollo, entonces esto es realmente algo bueno, ya que podría aprender mucho y corregir muchos errores.

El comentario que cuestiona si realmente necesita la semántica POSIX es un buen comienzo. La semántica del "sistema de archivos" que no es POSIX puede ser mucho más flexible y conducir a sistemas mucho más confiables.

Si se trata de una aplicación heredada, realmente me pregunto por qué un sistema de archivos distribuido moderno podría considerarse la mejor solución.

No me malinterpreten, estos son juguetes increíblemente divertidos. Simplemente no quisiera ser responsable de una solución interdependiente compleja que no se usa comúnmente y que sería muy difícil de solucionar cuando se descomponga.

¿Realmente necesita absolutamente la semántica POSIX? La vida se vuelve mucho más fácil si puedes usar un almacén de datos personalizado. Tenemos un almacén de datos escrito internamente que es efectivamente un gran almacén de valores clave distribuido. Guarda un archivo en él y recupera un token. Si desea recuperar el archivo, dele el token que recibió anteriormente. Se distribuye, no se comparte, los datos se replican tres veces, los nodos se pueden agregar y eliminar a voluntad, tanto los servidores de almacenamiento como los servidores de control.

Lustre también tiene un único punto de falla, ya que utiliza un servidor de metadatos dedicado

Lustre está diseñado para admitir la conmutación por error y un MDS / MDT / OSS puede tener una serie de direcciones con las que puede contactarse, los latidos pueden usarse para migrar el servicio.

Tenga en cuenta que algunas versiones recientes han tenido problemas en los que el desmontaje parece funcionar, pero todavía hay datos en el disco, sin embargo, la protección de doble montaje debería haber ayudado (aparte de los problemas interesantes que ha tenido) ...

Le recomiendo que use MooseFS (sistema de archivos distribuidos en red tolerante a fallas, escalado horizontal ). Es compatible con POSIX y desde la versión 1.6, MooseFS ofrece una autenticación / autorización simple, similar a NFS. Consulte también los requisitos de hardware .