filesystems - Sistemas de archivos distribuidos: GridFS vs. GlusterFS vs Ceph vs HekaFS Benchmarks

Question

Actualmente estoy buscando un buen sistema de archivos distribuidos.

Debería:

• ser de código abierto
• ser horizontalmente escalable (replicación y fragmentación)
• no tener un solo punto de falla
• tener una huella relativamente pequeña

Estos son los cuatro candidatos más prometedores en mi opinión:

• GridFS (basado en MongoDB)
• GlusterFS
• Ceph
• HekaFS

El sistema de archivos se usará principalmente para archivos multimedia (imágenes y audio). Hay archivos muy pequeños y de tamaño medio (1 KB - 10 MB). La cantidad de archivos debe ser de varios millones.

¿Hay puntos de referencia en cuanto a rendimiento , carga de la CPU , consumo de memoria y escalabilidad ? ¿Cuáles son sus experiencias al usar estos u otros sistemas de archivos distribuidos?

Answer 1

Después de trabajar con Ceph durante 11 meses, llegué a la conclusión de que realmente apesta, así que sugiero evitarlo. Intenté XtreemFS , RozoFS y QuantcastFS, pero tampoco los encontré lo suficientemente buenos.

Recomiendo sinceramente LizardFS, que es un tenedor de MooseFS ahora propietario . LizardFS ofrece integridad de datos, monitoreo y rendimiento superior con muy pocas dependencias.

Answer 2

No estoy seguro de que tu lista sea correcta. Depende de lo que quiera decir con un sistema de archivos.

Si se refiere a un sistema de archivos que se puede montar en un sistema operativo y que puede usar cualquier aplicación que lea y escriba archivos usando llamadas POSIX, entonces GridFS realmente no califica. Es exactamente cómo MongoDB almacena objetos con formato BSON. Es un sistema de Objetos en lugar de un sistema de Archivo.

Hay un proyecto para hacer que GridFS se pueda montar , pero es un poco extraño porque GridFS no tiene conceptos para cosas como directorios jerárquicos, aunque se permiten rutas. Además, no estoy seguro de cómo se distribuirán las escrituras en gridfs-fusible.

GlusterFS y Ceph son sistemas de archivos montables distribuibles y replicables comparables. Puede leer una comparación entre los dos aquí (y la actualización de comparación ), aunque tenga en cuenta que los puntos de referencia los hace alguien que es un poco parcial. También puedes ver este debate sobre el tema .

En cuanto a HekaFS, es GlusterFS el que está configurado para la computación en la nube, que agrega encriptación y capacidad múltiple, así como también una IU administrativa.

Answer 3

No sé sobre los otros sistemas que publicaste, pero hice una comparación de 3 PHP CMS / Frameworks en el almacenamiento local frente a GlusterFS para ver si funciona mejor en las pruebas del mundo real que los benchmarks sin procesar. Tristemente no.

http://blog.lavoie.sl/2013/12/glusterfs-performance-on-different-frameworks.html

Answer 4

OrangeFS, ¿alguien?

Estoy buscando un HPC DFS y encontré esta discusión aquí: http://forums.gentoo.org/viewtopic-t-901744-start-0.html

Muchos buenos datos y comparaciones :)

Después de hablar, el OP decidió para OrangeFS, citando: "OrangeFS. No admite cuotas ni bloqueos de archivos (aunque todas las operaciones de E / S son atómicas y de esta manera la consistencia se mantiene sin bloqueos). Pero funciona, funciona bien y es estable Además, este no es un sistema general orientado al almacenamiento de archivos, sino HPC dedicado, dirigido a E / S paralelas que incluye compatibilidad con ROMIO. Todas las pruebas se realizaron para la distribución de datos en bandas. A) Sin cuotas. de todos modos, incluso glusterfs admite cuotas no comunes uid / gid, pero las limitaciones de tamaño de directorio son más parecidas a LVM. b) Múltiples servidores activos de metadatos son compatibles y estables. Comparado con el almacenamiento de metadatos dedicado (single node) esto proporciona un rendimiento de + 50% en archivos pequeños y sin diferencias significativas en los grandes c) Excelente rendimiento en grandes fragmentos de datos (dd bs = 1M). Está limitado por una suma de disco duro local (no olvide que cada nodo también participa como un servidor de datos) velocidad y ancho de banda de red disponible. CPU el consumo en tal carga es decente y es aproximadamente del 50% de un solo núcleo en un nodo de cliente y de un 10% de porcentajes en cada uno de los nodos del servidor de datos. d) Rendimiento justo en grandes conjuntos de archivos pequeños. Para la prueba eliminé linux kernel 3.1. Tardó 5 minutos en OrangeFS (con parámetros ajustados) y casi 2 minutos en NFSv4 (sintonizado también) para comparar. La carga de la CPU es de aproximadamente el 50% del núcleo único (por supuesto, se distribuye realmente entre los núcleos) en el cliente y de varios porcentajes en cada nodo. e) Soporte de ROMIO MPI I / O API. Es un delicioso dulce para aplicaciones MPI, lo que permite utilizar las funciones de salida de entrada paralelas PVFS2 / OrangeFS directamente desde las aplicaciones. f) No admite archivos especiales (sockets, fifo, dispositivos de bloque). Por lo tanto, no se puede usar de forma segura como / home y utilizo NFSv4 para esa tarea, lo que proporciona a los usuarios un espacio doméstico pequeño y restringido por cuotas. Aunque la mayoría de los sistemas de archivos distribuidos no admiten archivos especiales de todos modos. "