Sincronización bidireccional en tiempo real del árbol de archivos grandes entre dos servidores linux distantes

21

Por árbol de archivos grande me refiero a unos 200k archivos, y creciendo todo el tiempo. Sin embargo, se cambia un número relativamente pequeño de archivos en una hora determinada.

Por bidireccional quiero decir que los cambios pueden ocurrir en cualquiera de los servidores y necesitan ser empujados al otro, por lo que rsync no parece apropiado.

Por distante quiero decir que los servidores están en centros de datos, pero geográficamente remotos entre sí. Actualmente solo hay 2 servidores, pero eso puede expandirse con el tiempo.

En tiempo real, está bien que haya una pequeña latencia entre la sincronización, pero ejecutar un cron cada 1-2 minutos no parece correcto, ya que una fracción muy pequeña de archivos puede cambiar en una hora determinada, y mucho menos minutos.

EDITAR : Esto se ejecuta en VPS, por lo que podría estar limitado en los tipos de cosas a nivel de kernel que puedo hacer. Además, los VPS no son ricos en recursos, por lo que evitaría las soluciones que requieren mucha memoria RAM (como Gluster?).

¿Cuál es el enfoque mejor / más "aceptado" para hacer esto? Parece que sería una necesidad común, pero todavía no he podido encontrar un enfoque generalmente aceptado, lo cual fue sorprendente. (Estoy buscando la seguridad de las masas. :)

Me he encontrado con lsyncd para activar una sincronización en el nivel de cambio del sistema de archivos. Eso parece inteligente, aunque no es muy común, y estoy un poco confundido por los diversos enfoques de lsyncd. Solo está usando lsyncd con rsync, pero parece que esto podría ser frágil para la bidireccionalidad ya que rsync no tiene una noción de memoria (por ejemplo, para saber si un archivo eliminado en A debe eliminarse en B o si es un archivo nuevo en B eso debería copiarse a A). lipsync parece ser solo una implementación lsyncd + rsync, ¿verdad?

Luego está usando lsyncd con csync2 , así: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Me estoy inclinando hacia este enfoque, pero csync2 es un poco peculiar, aunque hice una prueba exitosa. Me preocupa sobre todo que no haya podido encontrar mucha confirmación comunitaria de este método.

A la gente aquí parece gustarle mucho Unison, pero parece que ya no está en desarrollo activo y no está claro que tenga un activador automático como lsyncd.

He visto mencionar a Gluster , pero ¿quizás exagere para lo que necesito?

ACTUALIZACIÓN: fyi- Terminé yendo con la solución original que mencioné: lsyncd + csync2. Parece que funciona bastante bien, y me gusta el enfoque arquitectónico de tener los servidores unidos de manera muy flexible, de modo que cada servidor pueda funcionar de manera indefinida por sí mismo, independientemente de la calidad del enlace entre ellos.

dlo
fuente
¿Qué tipo de cambios necesitas manejar? Por ejemplo, creación, eliminación, modificación.
sciurus
Además, ¿esperas conflictos? ¿Podría modificarse el mismo archivo en ambos servidores?
sciurus
Todos los cambios: creación, eliminación, modificación. Existe la posibilidad de conflictos, pero deberían ser raros. No me importaría si simplemente recibo una alerta sobre un conflicto que luego tengo que resolver manualmente.
dlo

Respuestas:

5

DRBD en modo Dual-primario con un Proxy es una opción.

quanta
fuente
El Proxy parece no ser de código abierto ni gratuito, ¿verdad? No estoy seguro de entender la consecuencia de no tener un Proxy en modo asíncrono: durante un tiempo de inactividad extendido, si no hay Proxy, ¿el búfer de salida [pequeño?] Podría llenarse y perderíamos la sincronización? ¿Es difícil recuperarse de eso?
dlo
Vea mi respuesta arriba. No creo que el proxy sea lo que necesitas. Incluso durante un pequeño tiempo de inactividad, el drbd-meta-device marcará los bloques "sucios" y los transferirá después de que la conexión vuelva a funcionar. Creo que la principal diferencia entre el proxy y el modo asíncrono es que el modo asíncrono usa un búfer máximo de algunos MB. Después de eso, se sincroniza antes de volver a llenar el búfer. El proxy permite de manera propagable un búfer más grande (necesario si tiene una latencia grande o puede escribir mucho más rápido de forma local que remota).
Nils
2

En lugar de sincronizar, ¿por qué no compartir el mismo sistema de archivos a través de NFS?

Bart B
fuente
2
NFS es horrible, simplemente horrible. Cualquier cosa sería mejor que NFS
AliGibbs
2
Uno de los puntos principales de la configuración de varios servidores es la conmutación por error / redundancia. Por lo tanto, un servidor debe poder continuar sin el otro.
dlo
Debería haber mencionado eso en su pregunta entonces: ¡no es necesario votar por una respuesta perfectamente razonable!
Bart B
para tu información, no lo rechacé, alguien más lo hizo. Pero sí, debería haber mencionado eso para empezar.
dlo
@Bart: Bueno, él mencionó que hay acceso concurrente en dos sitios distantes. Entonces, incluso si instala HA-NFS, sería una mala solución, ya que un lado sufriría latencia durante el acceso NFS. Y tampoco voté en contra. Pero he sido administrador de NFS el tiempo suficiente para admitir AliGibbs. : - /
Nils
2

La implementación de un sistema de archivos distribuido probablemente sea mejor que piratear esto junto con herramientas y scripts, especialmente si el grupo de servidores crecerá. También podrá manejar mejor un nodo caído.

No creo que Gluster (o AFS) sea excesivo en absoluto.


fuente
Gluster requiere 1GB de ram? gluster.com/community/documentation/index.php/… ... También estoy en un VPS, así que no estoy seguro de hacer cambios en el nivel de kernel que AFS pueda requerir. Pero estoy empezando a ver que un fs distribuido adecuado es el mejor camino.
dlo
Sí, lo siento, no entendí antes que estabas usando hosts VPS. Las huellas de memoria de Gluster, tanto del servidor como del cliente, no son pequeñas y pueden crecer considerablemente. DRBD suena más apropiado.
AFS es el camino a seguir.
Anthony Giorgio
2

En su caso, recomendaría una combinación de DRBD en modo dual-primario y gfs u ocfs.

El inconveniente de DRBD en dual-primary es que se ejecutará en modo sincrónico. Pero la velocidad de escritura no parece ser importante aquí, ¿verdad?

Una alternativa a DRBD podría ser un Soft-Raid1 que usa muchos (2+) objetivos iSCSI, pero preferiría DRBD con dos nodos.

Nils
fuente
1
El modo síncrono sería malo: no lo necesito y no quisiera socavar el rendimiento ya que los servidores están conectados a través de una WAN en todos los continentes. Pero, ¿no puedes tener doble primario en modo asíncrono?
dlo
Actualmente estoy usando DRBD 8.3.5: allí debe estar en modo de sincronización ("C") para acceder al modo primario dual. No tengo experiencia personal con el proxy DRBD, pero parece ser similar al Veritas Volume Replicator, pero esto no es adecuado, ya que desea acceso de escritura en ambos lados. El modo de sincronización en el nivel de bloque puede no ser tan malo como crees, tal vez gfs y / u ocfs pueden escribir en el búfer.
Nils
Acabo de consultar un artículo alemán que compara GFS2 y OCFS2. A partir de eso, al menos OCFS2 parece admitir el acceso al sistema de archivos con búfer. Se recomienda GFS2 en ese artículo ya que es más antiguo. Consulte la documentación de RedHat en GFS2 para obtener detalles sobre GFS2 (también utiliza el almacenamiento en búfer), pero debe usar diferentes directorios para escrituras concurrentes para obtener el mejor rendimiento.
Nils
0

Como se demostró anteriormente, hay muchas soluciones disponibles, cada una con sus ventajas y desventajas.

Creo que consideraría colocar todo el árbol bajo control de versiones ( Subversion , por ejemplo) y registrar / actualizar periódicamente desde ambos servidores en trabajos cron.

Paul Preziosi
fuente
0

Habiendo terminado una búsqueda con respecto a lo mismo, voy con el brillo. Sin embargo, no he hecho ni encontrado pruebas de rendimiento.

cbaltatescu
fuente