27 votos

Opciones para sincronizar de manera eficiente 1 millón de archivos con servidores remotos?

En una empresa en la que trabajo tenemos una cosa que se llama "listas de reproducción", que son pequeños archivos de ~100-300 bytes cada uno. Hay alrededor de un millón de ellos. Alrededor de 100.000 de ellos se cambian cada hora. Estas listas de reproducción necesitan ser cargados a 10 otros servidores remotos en diferentes continentes, cada hora y tiene que suceder rápido, en menos de 2 minutos lo ideal. Es muy importante que los archivos que se eliminan en el maestro también se eliminan en todas las réplicas. Actualmente uso Linux para nuestra infraestructura.

Estaba pensando, tratando de rsync con la opción-W para copiar archivos completos sin comparar contenidos. Yo no lo he probado aún, pero tal vez las personas que tienen más experiencia con rsync podría decirme si es una opción viable?

Qué otras opciones que vale la pena considerar?

Actualización: he elegido la lsyncd opción como la respuesta, pero sólo porque era la más popular. Otras alternativas sugeridas son también válidas en su propia manera.

39voto

faker Puntos 11270

Desde el instante las actualizaciones también son aceptables, puede utilizar lsyncd.
Mira directorios (inotify) y rsync cambios a los esclavos.
En el inicio se va a hacer un completo rsync, por lo que tomará algún tiempo, pero después de que sólo se transmiten los cambios.
Recursiva viendo de directorios es posible, si un servidor esclavo es por la sincronización se volverá a intentar hasta que regresa.

Si esto es todo en un solo directorio (o una lista estática de directorios), usted podría también utilizar incron.
El inconveniente que hay es que no permite recursiva viendo de carpetas y que necesita para implementar la sincronización de la funcionalidad del mismo.

11voto

Priyan R Puntos 687

Considere el uso de un sistema de ficheros distribuido, tales como GlusterFS. Está diseñado con la replicación y el paralelismo en la mente, GlusterFS puede ampliar hasta 10 servidores mucho más suavemente que los ad-hoc de soluciones que involucran inotify y rsync.

Para este caso de uso, se podría construir un 10-servidor de GlusterFS volumen de 10 réplicas (es decir, 1 de réplica/ladrillo por servidor), por lo que cada réplica sería un reflejo exacto de cada réplica en el volumen. GlusterFS sería propaga automáticamente las actualizaciones de sistema de ficheros a todas las réplicas.

Los clientes en cada lugar se pondría en contacto con su servidor local, por lo que el acceso de lectura a los archivos sería rápido. La pregunta clave es si la latencia de escritura podrían estar aceptablemente bajo. La única manera de responder que es intentarlo.

8voto

Sven Puntos 51980

Dudo rsync trabajaría para esto en la forma normal, debido a que el escaneo de un millón de archivos y su comparación con el sistema remoto 10 veces llevaría mucho tiempo. Me gustaría tratar de implementar un sistema con algo como inotify que mantiene una lista de archivos modificados y los empuja a los servidores remotos (si estos cambios no se registran en otra forma, de todos modos). Puede utilizar esta lista para identificar rápidamente los archivos necesarios para ser transferido - tal vez incluso con rsync (o mejor 10 en paralelo instancias de ella).

Edit: Con un poco de trabajo, usted puede incluso utilizar este inotify/log reloj enfoque para copiar los archivos tan pronto como la modificación sucede.

5voto

Brad Puntos 3206

Algunas alternativas:

  • Insertar un trabajo en RabbitMQ o Gearman forma asincrónica ir y eliminar (o añadir) en el mismo archivo en todos los servidores remotos siempre que eliminar o agregar un archivo en el servidor principal.
  • Almacenar los archivos en una base de datos y el uso de la replicación para mantener los servidores remotos en modo de sincronización.
  • Si usted tiene ZFS puede utilizar ZFS, replicación.
  • Algunos SANs han de replicación de archivos. No tengo idea de si esto puede ser usado a través de Internet.

4voto

neovatar Puntos 156

Este parece ser un ideal de libro de cuentos de caso de uso para MongoDB y tal vez GridFS. Dado que los archivos son relativamente pequeñas, MongoDB por sí solo debería ser suficiente, aunque puede ser conveniente el uso de la GridFS de la API.

MongoDB es una base de datos nosql y GridFS es un archivo de almacenamiento de construir en la parte superior de la misma. MongoDB tiene un montón de opciones para la replicación y la fragmentación, por lo que debe escala muy bien en su caso de uso.

En tu caso, es probable que comience con un conjunto de réplicas que consiste en que el maestro se encuentra en su centro de datos principal (tal vez un segundo, en caso de que quieras conmutación por error en el mismo lugar) y el diez "esclavos" de distribución en todo el mundo. Luego de hacer las pruebas de carga para comprobar si el rendimiento de la escritura es suficiente y comprobar los tiempos de replicación a sus nodos. Si usted necesita más rendimiento, podrían convertir la instalación en un sharded uno (principalmente para distribuir la carga de escritura a más servidores). MongoDB ha sido diseñado con la ampliación de enorme configuraciones con "barato" de hardware, así que usted puede lanzar en un lote de bajo costo de los servidores para mejorar el rendimiento.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: