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 deNFS.
Necesito agregar un segundo por el bien de HA y mantenerlo sincronizado con el primero con la menor diferencia posible entre los dos.
La investigación sugiere utilizarlsyncdu otroinotificarsoluciones basadas en para esto, pero dada la cantidad de archivos que crean elinotificarLos relojes tardan una eternidad. Lo mismo parasincronización.
Otras posibles soluciones parecen serdrbd, o gruposistemas de archivoscomocefoglusterfs, pero no tengo experiencia con ellos y no sé cuál sería más apropiado y manejaría bien tantos archivos y aún así proporcionaría un rendimiento decente.
Tenga en cuenta que la actividad se lee principalmente y se escribe poca.
Respuesta1
Me inclino a sugerir una replicación que sea independiente de los datos, como drbd. La gran cantidad de archivos hará que cualquier cosa que se ejecute en un nivel superior al "almacenamiento en bloque" pase una cantidad excesiva de tiempo recorriendo el árbol, como lo descubrió al usar rsync o crear 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 principal objetivo de mercado debido a su similitud con Gluster. Sin embargo, he estado intentando implementar este tipo de solución con Gluster durante los últimos años. Ha estado funcionando la mayor parte de ese tiempo, aunque hubo varias actualizaciones de versión importantes, pero he tenido un sinfín de problemas. Si su objetivo es más la redundancia que el rendimiento, es posible que Gluster no sea una buena solución. Particularmente si su patrón de uso tiene muchas llamadas a stat(), a Gluster no le va muy bien con la replicación. Esto se debe a que las llamadas de estadísticas a volúmenes replicados van a todos los nodos replicados (en realidad, "ladrillos", pero probablemente solo tendrá un ladrillo por host). Si tiene una réplica bidireccional, por ejemplo, cada stat() de un cliente espera una respuesta de ambos bloques 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 gluster para redundancia (en lugar de usar Gluster como backend con NFS como protocolo y montador automático para redundancia, lo cual aún apesta por la razón stat()) . Sin embargo, a Gluster le va muy bien con archivos grandes donde se pueden distribuir datos en varios servidores; La división y distribución de datos funciona bien, ya que para eso sirve. Y la replicación de tipo RAID10 más nueva funciona mejor que los volúmenes replicados directamente más antiguos. Pero, según lo que supongo que es su modelo de uso, lo desaconsejaría.
Tenga en cuenta que probablemente tendrá que encontrar una manera de realizar elecciones maestras entre las máquinas o implementar un bloqueo distribuido. Las soluciones de dispositivo de bloque compartido requieren un sistema de archivos que sea compatible con múltiples maestros (como GFS), o requiere que solo un nodo monte el sistema de archivos de lectura y escritura. A los sistemas de archivos en general no les gusta que los datos se cambien en el nivel del dispositivo de bloque debajo de ellos. Eso significa que sus clientes deberán poder saber cuál es el maestro y dirigir las solicitudes de escritura allí. Esto puede resultar una gran molestia. Si GFS y toda su infraestructura de soporte es una opción, drbd en modo multimaestro (lo llaman "primario dual") podría funcionar bien. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-modepara obtener más información al respecto.
Independientemente de la dirección que tome, es probable que descubra que esto sigue siendo bastante complicado de hacer en tiempo real sin simplemente darle a una empresa SAN una gran cantidad de dinero.
Respuesta2
Pasé de rsync a ceph con la ayuda de la configuración de Proxmox VE.
Ahora administro 14 TB en un clúster con replicación en vivo. Durante casi 4 años.