Depende mucho del trabajo en cuestión.
¿Por qué necesitas duplicar archivos? ¿Desea actualizar algo como un sitio web o un repositorio de contenido donde generalmente está bien actualizar periódicamente? ¿O necesita sincronización de datos en tiempo real?
Para la duplicación asíncrona periódica de archivos, generalmente es suficiente tener un Área de ensayo en la que cargue todos sus datos. Y desde donde lo distribuyes a los Servidores. En su caso, con dos servidores, puede crear un recurso compartido de archivos provisional en srv1 a donde transfiere los datos (a través de FTP, NFS, DAV, SFTP, etc.) y luego hacer que un cronjob rsync los archivos a los directorios "en vivo" de srv1 y srv2. La forma más fácil de usar rsync en ese caso es generar un par de claves ssh que usará para las transferencias de datos y que está autorizado en todos los servidores de su clúster.
Ejemplo:
srv1:/data/staging/ <= is where you upload your data
srv1:/data/production/ <= is where your servers get their production data from
srv2:/data/production/
srv1$ cat /etc/cron.d/syncdata.cron
=====
*/5 * * * * syncuser rsync -a --delete /data/staging/ /data/production/
*/5 * * * * syncuser rsync -az --delete -e ssh /data/staging/ srv2:/data/production/
=====
Esto debería darte una idea básica. Por supuesto, desearía ajustar las llamadas rsync en algunos scripts e implementar un bloqueo adecuado para que no se ejecute dos veces en caso de que la sincronización tarde más de 5 minutos, etc. Además, no hace falta decir que un área de preparación no es obligatoria. También podría sincronizar srv1: producción a srv2: producción directamente. Solo que srv2 podría mostrar datos que son hasta 5 minutos más antiguos que los de srv1. Lo que podría ser un problema, dependiendo de cómo se equilibre entre los dos.
Otra forma de distribuir archivos asincrónicamente es empaquetarlos como rpm o, en su caso, archivos deb. Póngalos en un repositorio central y haga que se instalen / actualicen a través de algo como cfengine, monkey o alguna solución basada en el bus de mensajes de bricolaje. Esto tiene el agradable efecto secundario de versionar los datos desplegados, pero solo es adecuado para pequeñas cantidades de datos que usted produce y despliega (como las versiones de su propio software). No querría distribuir TB de datos con esto y tampoco es adecuado para reflejar el contenido que cambia con una frecuencia alta, como cada dos minutos más o menos.
Si necesita replicar datos casi en tiempo real pero no necesariamente sincrónico en lugar de llamar a un cron de vez en cuando, puede usar algún método basado en inotify como el incron ya mencionado para llamar a sus scripts de sincronización. Otra posibilidad es usar Gamin (que también usa inotify si está presente en el Kernel) y escribir su propio pequeño demonio de sincronización. Por último, pero no menos importante, si todos los archivos se cargan en un servidor a través de, por ejemplo, SFTP, puede verificar si su servidor SFTP le permite definir enlaces que se invocan después de ciertos eventos, como la carga de archivos. De esa manera, podría decirle a su servidor que active su script de sincronización cada vez que se carguen nuevos datos.
Si necesita un reflejo síncrono de datos en tiempo real, un sistema de archivos del clúster podría estar en orden. DRDB ya ha sido nombrado. Es muy bueno para la replicación en el nivel de bloque y a menudo se usa para configuraciones de MySQL de alta disponibilidad. También es posible que desee echar un vistazo a GFS2, OCFS2, Lustre y GlusterFS. Aunque Luster y GlusterFS no son realmente adecuados para una configuración de dos servidores.