Sincronizar millones de archivos entre dos servidores Linux

Tengo un servidor que exporta un directorio que contiene ~ 7 millones de archivos (en su mayoría imágenes) desde su disco local a clientes de red a través de NFS .

Necesito agregar un segundo por el bien de HA, y mantenerlo sincronizado con el primero con el menor delta entre los dos posible.

La investigación sugiere usar lsyncd u otras soluciones basadas en inotify para esto, pero dada la cantidad de archivos que crean los relojes inotify lleva una eternidad. Lo mismo para rsync .

Otras posibles soluciones parecen ser drdb , o sistemas de archivos de clúster como ceph o glusterfs , pero no tengo experiencia con ellos y no sé cuál sería el más apropiado y haría frente a tantos archivos y aún así proporcionaría un rendimiento decente.

Tenga en cuenta que la actividad se lee principalmente con poca escritura.

Me inclino a sugerir una replicación que sea independiente de los datos, como drbd. La gran cantidad de archivos hará que todo lo que se ejecute a un nivel superior al "almacenamiento en bloque" pase una cantidad excesiva de tiempo caminando por el árbol, como descubrió que usa rsync o crea relojes inotify.

La versión corta de mi historia personal lo respalda: no he usado Ceph, pero estoy bastante seguro de que no está en su objetivo principal de mercado debido a su similitud con Gluster. Sin embargo, he tratado de implementar este tipo de solución con Gluster durante los últimos años. Ha estado funcionando la mayor parte de ese tiempo, a pesar de varias actualizaciones importantes de la versión, pero no he tenido problemas. Si su objetivo es más redundancia que rendimiento, Gluster puede no ser una buena solución. Particularmente si su patrón de uso tiene muchas llamadas stat (), Gluster no funciona muy bien con la replicación. Esto se debe a que las llamadas estadísticas a los volúmenes replicados van a todos los nodos replicados (en realidad "ladrillos", pero probablemente solo va a tener un ladrillo por host). Si tiene una réplica de 2 vías, por ejemplo, cada estadística () de un cliente espera una respuesta de ambos ladrillos para asegurarse de que está utilizando datos actuales. Luego, también tiene la sobrecarga de FUSE y la falta de almacenamiento en caché si está utilizando el sistema de archivos nativo de Gluster para la redundancia (en lugar de usar Gluster como back-end con NFS como protocolo y el automontador para la redundancia, que todavía apesta por la razón stat ()) . Sin embargo, Gluster funciona muy bien con archivos grandes donde puede distribuir datos a través de múltiples servidores; la distribución y distribución de datos funciona bien, ya que para eso es realmente. Y la nueva replicación de tipo RAID10 funciona mejor que los volúmenes replicados directos más antiguos. Pero, según lo que supongo que es su modelo de uso, le aconsejaría que no lo haga. Luego, también tiene la sobrecarga de FUSE y la falta de almacenamiento en caché si está utilizando el sistema de archivos nativo de Gluster para la redundancia (en lugar de usar Gluster como back-end con NFS como protocolo y el automontador para la redundancia, que todavía apesta por la razón stat ()) . Sin embargo, Gluster funciona muy bien con archivos grandes donde puede distribuir datos a través de múltiples servidores; la distribución y distribución de datos funciona bien, ya que para eso es realmente. Y la nueva replicación de tipo RAID10 funciona mejor que los volúmenes replicados directos más antiguos. Pero, según lo que supongo que es su modelo de uso, le aconsejaría que no lo haga. Luego, también tiene la sobrecarga de FUSE y la falta de almacenamiento en caché si está utilizando el sistema de archivos nativo de Gluster para la redundancia (en lugar de usar Gluster como back-end con NFS como protocolo y el automontador para la redundancia, que todavía apesta por la razón stat ()) . Sin embargo, Gluster funciona muy bien con archivos grandes donde puede distribuir datos a través de múltiples servidores; la distribución y distribución de datos funciona bien, ya que para eso es realmente. Y la nueva replicación de tipo RAID10 funciona mejor que los volúmenes replicados directos más antiguos. Pero, según lo que supongo que es su modelo de uso, le aconsejaría que no lo haga. que todavía apesta por la razón stat ()). Sin embargo, Gluster funciona muy bien con archivos grandes donde puede distribuir datos a través de múltiples servidores; la distribución y distribución de datos funciona bien, ya que para eso es realmente. Y la nueva replicación de tipo RAID10 funciona mejor que los volúmenes replicados directos más antiguos. Pero, según lo que supongo que es su modelo de uso, le aconsejaría que no lo haga. que todavía apesta por la razón stat ()). Sin embargo, Gluster funciona muy bien con archivos grandes donde puede distribuir datos a través de múltiples servidores; la distribución y distribución de datos funciona bien, ya que para eso es realmente. Y la nueva replicación de tipo RAID10 funciona mejor que los volúmenes replicados directos más antiguos. Pero, según lo que supongo que es su modelo de uso, le aconsejaría que no lo haga.

Tenga en cuenta que probablemente tendrá que encontrar una manera de tener elecciones maestras entre las máquinas o implementar un bloqueo distribuido. Las soluciones de dispositivos de bloque compartido requieren un sistema de archivos que sea compatible con varios maestros (como GFS), o que solo un nodo monte el sistema de archivos de lectura-escritura. A los sistemas de archivos en general no les gusta cuando los datos se cambian al nivel del dispositivo de bloque debajo de ellos. Eso significa que sus clientes necesitarán saber cuál es el maestro y dirigir las solicitudes de escritura allí. Eso puede resultar ser una gran molestia. Si GFS y toda su infraestructura de soporte es una opción, drbd en modo multimaestro (lo llaman "dual primario") podría funcionar bien. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode para obtener más información al respecto.

Independientemente de la dirección que tome, es probable que descubra que esto sigue siendo un gran problema en tiempo real sin simplemente darle a una compañía SAN un montón de dinero.

He cambiado de rsync a ceph con la ayuda de la configuración de Proxmox VE.

Ahora estoy administrando 14 TB en un clúster con replicación en vivo. Por casi 4 años.