¿Es GlusterFS una buena elección para mantener sincronizados los servidores web?


9

Tengo 2 servidores web, con la posibilidad de tener que agregar más servidores en el camino. En este momento mantengo estos servidores sincronizados usando lsyncd + csync2. Funciona bien en cuanto al rendimiento porque todos los archivos están en ambos servidores (no se requiere acceso a la red para abrir archivos localmente), pero no tan bien en otros casos.

Un ejemplo de esto es si elimino un archivo en el servidor 1 e inmediatamente carga un nuevo archivo en el servidor 1 que tiene el mismo nombre. Mientras tanto, el archivo se eliminaría del servidor 2, lo que provocaría que el archivo recién cargado en el servidor 1 se elimine cuando el servidor 2 envíe el evento de eliminación al servidor 1 para completar el "círculo de actualización".

No puedo evitar pensar que debe haber una mejor manera de mantener los servidores sincronizados. He estado mirando GlusterFS y veo que se desaconseja una configuración en la que todos los archivos se replican en todos los servidores. Sin embargo, estoy ejecutando sistemas CMS como Drupal en estos servidores. Tales sistemas CMS a menudo abren bastantes archivos, y me preocupa que demasiado tráfico de red para obtener estos archivos disminuya las solicitudes.

¿Sería una idea considerar reemplazar lsyncd + csync2 con GlusterFS configurado para replicar todos los archivos en todos los nodos, o es una mala idea?


2
Puedo entender mal su problema aquí, pero ¿por qué no usar el almacenamiento de red compartido entre servidores?
mveroone

1
@Kwaio: me gustaría "reflejar" todos los servidores web (tanto scripts como contenido cargado por el usuario) ya que esto evitará el tiempo de inactividad si algo sale mal con el servidor que aloja el almacenamiento compartido. En otras palabras, no quiero confiar en una configuración en la que todos los servidores web vuelvan a depender de un único almacenamiento de archivos.
sbrattla

Entonces, ¿por qué no un clúster de almacenamiento de red de alta disponibilidad?
mveroone

Claro, pero ¿qué implica eso? ¿Hardware?
sbrattla

No soy un especialista, pero eso significa tener su almacenamiento de red reflejado en una arquitectura maestro-esclavo en 2 clústeres, y un sistema que cambia en caso de una falla del maestro. La mayoría de los proveedores de dispositivos de almacenamiento en red tienen soluciones para eso, incluso si pudiera construirlo usted mismo con dispositivos Linux, lo que requeriría mucho desarrollo.
mveroone

Respuestas:


2

BitTorrent Sync puede hacer el trabajo por usted. Lo estoy usando para mantener los archivos sincronizados entre algunos servidores internos en mi casa y está haciendo el trabajo maravillosamente. Otra cosa en la que tendrá que pensar es en la base de datos de back-end cuando su aplicación utiliza un CMS. Asegúrese de que esté ocurriendo la replicación MySQL, o algo por el estilo.


Eso es interesante. ¿Cómo trata BitTorrent Sync con los conflictos? Digamos que tengo 5 servidores web, y un archivo se actualiza en el servidor A. Luego, 2 segundos después, el mismo archivo se actualiza en el servidor C antes de que el cambio en A llegue a C. ¿El software tiene algoritmos para configurar qué servidor gana en estos casos?
sbrattla

Tengo entendido que BitTorrent Sync comparará la fecha / hora de modificación en ambas copias y solo mantendrá la última, lo que podría ser ideal o perjudicial para el caso de uso.
whiskykilo

1

Gluster resolvería el problema que tiene porque puede retener los bloqueos, propagar cambios: eliminar el archivo en todos los demás nodos, pero puede agregar latencia adicional que puede ser un problema para un servidor web. La siguiente alternativa es DRBD + OCFS2 o GFS, pero eso es probablemente más complejo, ya que con Gluster está utilizando el sistema de archivos subyacente: no funciona en el nivel de bloque, por lo que si los servidores no están sincronizados, no es demasiado difícil de solucionar, los archivos pueden no se corrompa tan fácilmente debido a cerebros partidos, etc.

Lo estamos utilizando para un servidor de correo y es bastante lento para directorios con muchos archivos. Definitivamente debe probar todo antes de implementar. Actualmente estoy probando el montaje NFS porque funciona mejor para archivos pequeños.


1

GlusterFS es difícil de implementar. Para los datos web, el nivel de sincronización de archivos como Unison es mucho más fácil de implementar y mantener.

DRBD es una solución perfecta para mantener la sincronización de datos a nivel de bloque. Pero debe formatearlos a un formato especial como OCFS2 o algo similar.


GlusterFS no es como DRBD: no funciona a nivel de bloque, sino a nivel de archivo. Pero entiendo que el unísono es más fácil de desplegar.
Jure1873

-3

¿Por qué no usas una herramienta como títere ? Escriba una vez en una fuente y una vez listo, despliéguelo en los objetivos con "títere" o mcolletive. Está bien documentado Y puede agregar servidores fácilmente más tarde si es necesario.

También puede confiar en las herramientas que utilizan inotify, como lsyncd, que funcionan a nivel del núcleo. Observa los cambios en una carpeta y activa una sincronización. Pero si una herramienta dedicada a la sincronización de archivos en un clúster como csync2 no es suficiente, no sé qué será.

Solo para estar seguro, ¿las modificaciones ocurren también en el servidor 2 o solo en el servidor 1?


3
Votación negativa: Puppet no es una buena forma de mantener los archivos sincronizados entre servidores. Sin embargo, es una herramienta brillante para administrar la configuración del servidor .
Craig Watson

Las modificaciones pueden ocurrir en cualquier servidor, ya que participan en una configuración de carga equilibrada. Los usuarios pueden subir archivos a cualquier servidor y, en consecuencia, ese archivo debería estar disponible en todos los servidores ya que el tráfico se distribuye entre los servidores.
sbrattla

1
Bueno, en este caso títere no es lo que quieres (pero aún así, @Craig Watson, un archivo es un archivo, configuración o HTML, sigue siendo un archivo). Dudo que GlusterFS esté listo para la producción, por lo que si realmente desea algo seguro, será mejor que use un servidor NFS con alta disponibilidad.
Rosco
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.