![Sincronización de archivos en tiempo real entre servidores con cientos de miles de archivos pequeños](https://rvso.com/image/697005/Sincronizaci%C3%B3n%20de%20archivos%20en%20tiempo%20real%20entre%20servidores%20con%20cientos%20de%20miles%20de%20archivos%20peque%C3%B1os.png)
Me he dado la tarea de crear dos servidores CentOS 7 donde no solo se replicarán las bases de datos sino también los archivos. Ahora mi problema es que probablemente habrá cientos de miles de archivos, si no un millón, con una amplia variedad de tamaños, desde unos pocos Kbytes hasta ~1 Gbyte.
he leído sobre
- incrión
- lysncd
- anexo git
- QuirónFS
Ahora deseo preguntarte tus experiencias sobre cualquiera de estos si lo has estado usando o lo estás usando actualmente. ¿Cómo va el rendimiento con los cambios de archivos con respecto a copias y eliminaciones? Tengo mucho miedo de usar rsync porque mi experiencia es que no es muy rápido con muchos archivos pequeños, por lo tanto, no puedo usarlo para una replicación de archivos en tiempo real. ¿O me equivoco? Por favor, demuéstrame que estoy equivocado. :)
¿O tal vez necesitaré un tercer y un cuarto servidor como servidores de archivos? En caso afirmativo, la pregunta sigue siendo: ¿Cómo replicar los archivos entre los dos servidores en tiempo real?
¡Salud!
Respuesta1
Si sus servidores están en la misma LAN, entonces un sistema de archivos en clúster (es decir, GlusterFS) o una solución de almacenamiento compartido (es decir, a través de NFS) debería ser la mejor opción.
Si sus servidores están en una ubicación diferente y solo tienen conectividad WAN, la solución anterior no funcionará bien. En este caso, ysi solo necesita replicación unidireccional(es decir, del servidor activo al de respaldo), lsyncd
es una buena solución. Otra solución es csync2
. Finalmente, otra posibilidad es usar DRBD + DRBD Proxy
(tenga en cuenta que su componente proxy es un complemento comercial).
Finalmente, si sus servidores solo tienen conectividad WAN ynecesitas replicación bidireccional(es decir, ambos servidores están activos al mismo tiempo), básicamente no existe una solución mágica. Enumeraré algunas posibilidades, pero estoy lejos de recomendar una configuración similar:
unison
con su complemento en tiempo realpsync
, que escribí exactamente para resolver un problema similar (pero tenga en cuenta que tiene su propia idiosincrasia y proporcionosin soportepara ello)syncthing
con su complemento en tiempo real (pero tiene limitaciones importantes, es decir, no conserva las ACL ni el propietario/grupo del archivo)
Respuesta2
Utilizo el sistema de archivos ZFS y aprovecho su replicación a nivel de bloque usando el marco de envío/recepción de zfs.
Utilizo un script útil llamadosincoidepara realizar una sincronización regular de los sistemas de archivos en intervalos de 15 segundos a cada hora o diariamente, según los requisitos.
La replicación a nivel de bloque será más limpia y precisa que rsync para el conjunto de datos del que habla.
Respuesta3
Según mi experiencia, los sistemas de archivos distribuidos proporcionan mecanismos de replicación sencillos para las aplicaciones. Sin embargo, sufren de un mal rendimiento, especialmente cuando los directorios se vuelven muy grandes con demasiados archivos pequeños. Esto es de esperarse ya que necesitan lidiar con el bloqueo/acceso compartido desde múltiples ubicaciones/máquinas.
Las formas similares a Rsync proporcionan, en algunos casos, una replicación aceptable con cierto retraso. No afectan el rendimiento de la aplicación mientras se lee/escribe la carpeta replicada.
Creo que una mejor solución es proporcionar almacenamiento compartido (cuando sea asequible) accesible desde un servidor. Otro servidor en espera está listo para montar la carpeta compartida cuando el primero deja de funcionar. No es necesario replicar ningún dato entre servidores.
Respuesta4
Saludos por las ideas. Los revisé y probé todos y me quedo con lsyncd.
Razones:
- Instalación extremadamente fácil
- Configuración extremadamente fácil
- Admite replicación unidireccional y bidireccional