ConHadoopysofádbEn todos los blogs y noticias relacionadas, ¿qué es un almacenamiento (motor) distribuido tolerante a fallas que realmente funciona?
- CouchDB en realidad no tiene ninguna función de distribución incorporada; hasta donde yo sé, simplemente falta el pegamento para distribuir automáticamente 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 en realidad el objetivo principal de Hadoop.
- GlusterFSTiene un concepto de nada compartido, pero últimamente leí varias publicaciones que me llevan a la opinión de que no es tan estable.
- Lustretambién tiene un único punto de falla ya que utiliza un servidor de metadatos dedicado
- cefParece ser el reproductor elegido, pero la página de inicio indica que todavía se encuentra en su etapa alfa.
Entonces la pregunta es qué sistema de archivos distribuido tiene el siguiente conjunto de características (sin orden en particular):
- compatible con POSIX
- fácil adición/eliminación de nodos
- concepto de nada compartido
- se ejecuta en hardware económico (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 accesibles localmente: puedo desactivar un nodo, montar la partición con un sistema de archivos local estándar (ext3/xfs/lo que sea...) y seguir accediendo a los archivos.
SoynoEstoy buscando aplicaciones alojadas, más bien algo que me permita tomar, digamos, 10 GB de cada una de nuestras cajas de hardware y tener ese almacenamiento disponible en nuestra red, fácilmente montable en una multitud de hosts.
Respuesta1
Creo que tendrás que abandonar el requisito POSIX, muy pocos sistemas lo implementan; de hecho, ni siquiera NFS realmente lo hace (piense en bloqueos, etc.) y eso no tiene redundancia.
Cualquier sistema que utilice replicación sincrónica será tremendamente 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".
Respuesta2
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 la misma cosa 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 cantidad 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 todo eso, yopoderHable sobre el uso de ocfs2 como un sistema de archivos distribuido en un entorno de producción. Si no desea conocer detalles importantes, deje de leer después de esta línea: es genial, pero puede significar más tiempo de inactividad del que cree.
Hemos estado ejecutando ocfs2 en un entorno de producción durante los últimos años. Está bien, pero no es excelente para muchas aplicaciones. Realmente debería analizar sus requisitos y descubrir cuáles son; es posible que descubra que tiene mucha más libertad para fallas de lo que pensaba.
Como ejemplo, ocfs2 tiene un diario para cada máquina del clúster que montará la partición. Entonces, digamos 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 espacio para crecer. Cada uno de esos diarios ocupa espacio, lo que reduce la cantidad de datos que puede almacenar en los discos. Ahora, digamos que necesita escalar a siete máquinas. En esa situación, necesitas eliminar elcompletocluster (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 sólo entonces, podrá 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é usando una utilidad), recuperar todo y luego montar la partición en las siete. máquinas.
¿Ves lo que quiero decir? Se supone que es alta disponibilidad, lo que se supone que significa "siempre en línea", pero ahí mismo tienes un montón de tiempo de inactividad... y Dios no quiera que estés lleno de espacio en el disco. NO quieres ver lo que sucede cuando llenas a 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 adiós a los evms). Además, heartbeat se convertirá rápidamente en un proyecto zombie a favor de la pila openais/pacemaker. (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 si sirve de algo, hemos vuelto a nfs administrado por pacemaker, porque los pocos segundos de tiempo de inactividad o algunos paquetes tcp descartados cuando pacemaker migra un recurso compartido de nfs a otra máquina es trivial en comparación con la cantidad de tiempo de inactividad que estábamos viendo para básico Operaciones de almacenamiento compartido como agregar máquinas cuando se usa ocfs2.
Respuesta3
Puede que no entienda bien sus requisitos, pero ¿ha miradohttp://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems
Respuesta4
Echa un vistazo al chirridohttp://www.cse.nd.edu/~ccl/software/chirp/y lorohttp://www.cse.nd.edu/~ccl/software/parrot/