¿Es una buena idea almacenar los volúmenes de Docker en glusterfs?

Actualmente estoy pensando en migrar algunos de nuestros servidores y aplicaciones a un entorno coreOS . Uno de los problemas que veo aquí es la administración de datos persistentes ya que coreOS no maneja los volúmenes de Docker cuando mueve un contenedor a una nueva máquina. Después de algunas investigaciones, encontré glusterFS que afirma ser un sistema de archivos de clúster que podría resolver todos mis problemas.

Mi idea actual es esta: tengo un contenedor glusterFS que se ejecuta como un contenedor privilegiado en cada una de mis máquinas coreOS y expone un almacenamiento /mnt/gluster, por ejemplo. En mi Dockerfiles especifico que todos mis volúmenes deben montarse en esta ruta.

Lo siguiente que consideré fue qué contenedores deberían obtener sus propios volúmenes y cuáles deberían compartir uno. Por ejemplo, cada mysqlcontenedor obtendría su propio volumen, ya que es capaz de manejar la replicación por sí mismo. No quiero perder el tiempo con eso. Los servidores web que sirven al mismo sitio web utilizarían correctamente el mismo volumen para cosas como "imágenes cargadas por el usuario", etc., ya que no pueden replicar esos datos.

¿Alguien ha intentado algo como esto o hay algo que me haya perdido?

— Martín
fuente

He hecho una prueba de concepto con esto y puedo decirle que funciona, pero antes de saltar a Gluster, asegúrese de comprender su perfil de ajuste. Debido a que Gluster es sensible a la latencia del disco (similar a etcd), puede hacer que las aplicaciones sean artificialmente más lentas para garantizar la replicación de los archivos.

— Brian Redbeard

Estamos trabajando en una herramienta que gestiona los volúmenes adjuntos a los contenedores acoplables. Se llama "flocker" y puede ver el repositorio de github aquí: github.com/clusterhq/flocker Actualmente tenemos un backend de almacenamiento para ZFS que utiliza la función de instantánea para facilitar la migración de datos, pero también tenemos planes para otros backends de almacenamiento (como un backend de dispositivo de bloque genérico) No puedo decir si es una buena idea montar volúmenes de docker usando GlusterFS pero puedo responder por el patrón de diseño general, es decir, tener en cuenta el estado generado por un contenedor de docker usando "algo"

— Bino Carlos

Gracias por tu respuesta. Ya vi flocker y parece muy prometedor. ¿Tiene una fecha aproximada para el soporte de coreos o una versión 1.0 lista para producción?

— Martin

He usado glusterfs para volúmenes con OpenStack antes, que tiene una configuración similar a lo que estás haciendo y fue genial.

— Ethode

@Martin Nosotros (trabajo en ClusterHQ) tenemos a Flocker trabajando en CoreOS utilizando Amazon EBS. coreos.com/blog/Flocker-on-CoreOS-Linux

— Stephen Nguyen

Respuestas:

Hemos implementado una configuración similar con Atomic ( http://www.projectatomic.io/ ) en lugar de CoreOS en un sistema de almacenamiento GlusterFS no distribuido replicado con tres conjuntos de réplica-2. Esto funciona muy bien

Sin embargo, debe tener en cuenta algunas características especiales de GlusterFS. Como Brian ya mencionó, Gluster coloca la consistencia y la confiabilidad sobre todo. Los cambios más frecuentes suceden, más replicación está ocurriendo. Esto pone mucho, y quiero decir MUCHA presión sobre su sistema.

Tenga cuidado de que su subsistema IO sea rápido (duh, es almacenamiento), conecte sus nodos Gluster con las conexiones de red más rápidas disponibles. Si solo tiene GBit, ¡agregue! Por último, pero no menos importante, el sistema de almacenamiento debe tener un poder de cálculo serio, Gluster hace muchos cálculos para verificar su estado. Dicho esto, incluso bajo una gran carga, Gluster cumple.

Reconsidere su estrategia MySQL. Gluster realiza la replicación por usted y también proporciona una especie de equilibrio de carga en la entrega. En realidad, podría ser más rápido usar Gluster.

— bjanssen
fuente

El uso de glusterfs dependerá del backend de almacenamiento que esté utilizando. Como sistema de archivos en clúster, está destinado a agrupar el almacenamiento físico para que aparezca como un gran volumen continuo. Esta guía oficial de inicio rápido tiene una buena explicación del proceso.

En el caso de que su configuración utilice dos o más servidores de almacenamiento de back-end separados o algo similar para almacenar todos los volúmenes de la ventana acoplable, el uso de glusterfs u otro sistema de archivos paralelo similar puede ofrecer ventajas de rendimiento significativas. Si este es el caso, también podría considerar usar Lustre , que se usa ampliamente como un sistema de archivos paralelo en la comunidad HPC.

Dicho esto, ajustar, depurar y configurar sistemas de archivos paralelos / en clúster puede ser una tarea que requiere mucho tiempo y requiere mucha experiencia, paciencia y, a veces, la voluntad de reiniciar desde el principio. Sería prudente asegurarse de que los beneficios de rendimiento que ofrece un sistema de archivos paralelo valen la cantidad de esfuerzo requerido para configurarlo y mantenerlo.

— Mate
fuente