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?
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.
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.
fuente