El mejor sistema de archivos distribuido para la granja de almacenamiento de productos básicos de Linux [cerrado]
https://stackoverflow.com/questions/269179
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Tengo una gran cantidad de servidores Intel Linux de repuesto disponibles (cientos) y quiero usarlos para un sistema de archivos distribuido en un entorno de alojamiento web y uso compartido de archivos. Esto no es para una aplicación HPC, por lo que el alto rendimiento no es crítico. El requisito principal es la alta disponibilidad, si un servidor se desconecta, los datos almacenados en sus discos duros aún están disponibles desde otros nodos. Debe ejecutarse sobre TCP / IP y proporcionar permisos de archivo POSIX estándar.
He visto lo siguiente:
-
Lustre ( http://wiki.lustre.org/index.php ? title = Main_Page ): realmente se cierra, pero no proporciona redundancia para los datos en un nodo. Debe hacer que los datos HA se utilicen RAID o DRBD. Compatible con Sun y Open Source, por lo que debería estar disponible por un tiempo
-
gfarm ( http://datafarm.apgrid.org/ ): Parece que proporciona la redundancia pero a costa de complejidad y mantenibilidad. No tan bien soportado como Lustre.
¿Alguien tiene alguna experiencia con estos u otros sistemas que puedan funcionar?
Solución
verifique también GlusterFS
Editar (agosto de 2012): Ceph finalmente se está preparando. Recientemente, los autores formaron Inktank , una compañía independiente para venderle soporte comercial. Según algunas presentaciones, el sistema de archivos compatible con POSIX montable es la capa superior y aún no se ha probado realmente, pero las capas inferiores se están utilizando en producción desde hace algún tiempo.
La parte interesante es la capa RADOS, que presenta un almacenamiento basado en objetos con acceso 'nativo' a través de la biblioteca librados (disponible para varios idiomas) y una API RESP compatible con Amazon S3 . Cualquiera de los dos lo hace más que adecuado para agregar almacenamiento masivo a un servicio web.
Este video es una buena descripción de la filosofía, arquitectura, capacidades y estado actual .
Otros consejos
En mi opinión, el mejor sistema de archivos para Linux es MooseFS, es bastante nuevo, pero tuve la oportunidad de compararlo con Ceph y Luster y digo con seguridad que MooseFS es el mejor.
Gluster está recibiendo mucha prensa en este momento:
Si alguien no te obliga a usarlo, también recomendaría usar cualquier otra cosa que no sea Lustre. Por lo que escuché de otros y lo que también me causó pesadillas durante bastante tiempo es el hecho de que Lustre se descompone fácilmente en todo tipo de situaciones. Y si solo un solo cliente en el sistema se descompone, se pone en un modo interminable do_nothing_loop normalmente mientras mantiene un bloqueo global importante, por lo que la próxima vez que otro cliente intente acceder a la misma información, también se bloqueará. Por lo tanto, a menudo terminas reiniciando todo el clúster, lo que supongo que es algo que tratarías de evitar normalmente;)
Los sistemas de archivos paralelos modernos como FhGFS (http://www.fhgfs.com) son mucho más robustos aquí y también le permiten hacer cosas agradables como ejecutar componentes de servidor y cliente en las mismas máquinas (aunque características de HA incorporadas todavía están en desarrollo, como me dijo alguien de su equipo, pero su implementación será bastante impresionante por lo que he escuchado).
Lustre ha estado trabajando para nosotros. No es perfecto, pero es lo único que hemos probado que no se ha descompuesto por la carga. Todavía recibimos LBUGS de vez en cuando y tratar con sistemas de archivos de 100TB + nunca es fácil, pero el sistema Lustre ha funcionado y ha aumentado tanto el rendimiento como la disponibilidad.
Ceph parece ser una prometedora entrada nueva a la arena. Sin embargo, el sitio afirma que aún no está listo para su uso en producción.
Leí mucho sobre sistemas de archivos distribuidos y creo que FhGFS es el mejor.
Vale la pena intentarlo. Vea más sobre esto en:
