Dipende molto dal lavoro a portata di mano.
Perché hai bisogno del mirroring dei file. Vuoi aggiornare qualcosa come un sito Web o un repository di contenuti dove di solito va bene aggiornarlo periodicamente. O hai bisogno della sincronizzazione in tempo reale dei dati?
Per il mirroring periodico asincrono dei file, in genere è sufficiente disporre di un'area di gestione temporanea in cui caricare tutti i dati. E da dove lo distribuisci ai server. Nel tuo caso - con due server - potresti creare una condivisione file di gestione temporanea su srv1 dove trasferisci i dati (tramite FTP, NFS, DAV, SFTP, ecc.) E quindi avere un cronjob sincronizzare i file nelle directory "live" di srv1 e srv2. Il modo più semplice di usare rsync in quel caso è generare una coppia di chiavi ssh che userete per i trasferimenti di dati e che è autorizzata su tutti i server del cluster.
Esempio:
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/
=====
Questo dovrebbe darti un'idea di base. Naturalmente vorrai racchiudere le chiamate rsync in alcuni script e implementare un blocco adeguato in modo che non venga eseguito due volte nel caso in cui la sincronizzazione impieghi più di 5 minuti, ecc. Inoltre, è ovvio che un'area di gestione temporanea non è obbligatoria. Potresti anche sincronizzare srv1: production con srv2: production direttamente. Solo che srv2 potrebbe mostrare dati fino a 5 minuti più vecchi di quelli di srv1. Quale potrebbe essere un problema, a seconda di come si bilancia tra i due.
Un altro modo per distribuire i file in modo asincrono è comprimerli come rpm o nei file deb del caso. Mettili in un repository centrale e installali / aggiorna tramite qualcosa come cfengine, monkey o qualche soluzione basata su bus di messaggi fai da te. Ciò ha il piacevole effetto collaterale del controllo delle versioni dei dati distribuiti, ma è adatto solo per piccole quantità di dati prodotti e distribuiti dall'utente (come le versioni del proprio software). Non vorrai distribuire TB di dati con questo e inoltre non è adatto per il mirroring di contenuti che cambiano ad alta frequenza, come ogni altro minuto.
Se hai bisogno di replicare i dati quasi in tempo reale ma non necessariamente in modo sincrono invece di chiamare un cron ogni tanto puoi usare un metodo basato su inotify come l'incron già menzionato per chiamare i tuoi script di sincronizzazione. Un'altra possibilità è usare Gamin (che usa anche inotify se presente nel kernel) e scrivere il proprio piccolo demone di sincronizzazione. Ultimo ma non meno importante, se tutti i file vengono caricati su un server tramite ad esempio SFTP, è possibile verificare se il server SFTP consente di definire hook che vengono chiamati dopo determinati eventi, come il caricamento di file. In questo modo potresti dire al tuo server di attivare lo script di sincronizzazione ogni volta che vengono caricati nuovi dati.
Se è necessario il mirroring sincrono in tempo reale dei dati, un file system del cluster potrebbe essere in ordine. DRDB è già stato nominato. È molto utile per la replica a livello di blocco e spesso utilizzato per configurazioni MySQL ad alta disponibilità. Potresti anche dare un'occhiata a GFS2, OCFS2, Lustre e GlusterFS. Sebbene Lustre e GlusterFS non siano realmente adatti per una configurazione a due server.