Cela dépend beaucoup du travail à accomplir.
Pourquoi avez-vous besoin de la mise en miroir de fichiers. Voulez-vous mettre à jour quelque chose comme un site Web ou un référentiel de contenu où il est généralement correct de le mettre à jour périodiquement. Ou avez-vous besoin d'une synchronisation des données en temps réel?
Pour une mise en miroir asynchrone périodique des fichiers, il suffit généralement d'avoir une zone de transit dans laquelle vous téléchargez toutes vos données. Et d'où vous le distribuez aux serveurs. Dans votre cas - avec deux serveurs - vous pouvez créer un partage de fichiers intermédiaire sur srv1 à l'endroit où vous transférez les données (via FTP, NFS, DAV, SFTP, etc.) et ensuite avoir une cronjob rsync les fichiers dans les répertoires "live" de srv1 et srv2. Dans ce cas, la façon la plus simple d'utiliser rsync est de générer une paire de clés ssh que vous utiliserez pour les transferts de données et qui est autorisée sur tous les serveurs de votre cluster.
Exemple:
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/
=====
Cela devrait vous donner une idée de base. Bien sûr, vous voudrez encapsuler les appels rsync dans certains scripts et implémenter un verrouillage approprié afin qu'il ne s'exécute pas deux fois au cas où la synchronisation prend plus de 5 minutes, etc. De plus, il va sans dire qu'une zone de transfert n'est pas obligatoire. Vous pourriez aussi bien synchroniser srv1: production avec srv2: production directement. Juste que srv2 peut afficher des données jusqu'à 5 minutes plus anciennes que celles de srv1. Ce qui pourrait être un problème, selon l'équilibre entre les deux.
Une autre façon de distribuer des fichiers de manière asynchrone consiste à les empaqueter en rpm ou dans votre cas, des fichiers deb. Mettez-les dans un référentiel central et faites-les installer / mettre à jour via quelque chose comme cfengine, monkey ou une solution basée sur un bus de messages bricolage. Cela a le bel effet secondaire de la gestion des versions des données déployées, mais ne convient qu'aux petites quantités de données que vous produisez et déployez vous-même (comme les versions de votre propre logiciel). Vous ne voudriez pas distribuer des To de données avec cela et il n'est pas non plus adapté pour refléter du contenu qui change à une fréquence élevée, comme toutes les deux minutes environ.
Si vous devez répliquer des données en temps quasi réel mais pas nécessairement synchrones au lieu d'appeler un cron de temps en temps, vous pouvez utiliser une méthode basée sur inotify comme l'incron déjà mentionné pour appeler vos scripts de synchronisation. Une autre possibilité est d'utiliser Gamin (qui utilise également inotify s'il est présent dans le noyau) et d'écrire votre propre petit démon de synchronisation. Last but not least, si tous les fichiers sont téléchargés sur un serveur via par exemple SFTP, vous pouvez vérifier si votre serveur SFTP vous permet de définir des hooks qui sont appelés après certains événements, comme le téléchargement de fichiers. De cette façon, vous pouvez demander à votre serveur de déclencher votre script de synchronisation chaque fois que de nouvelles données sont téléchargées.
Si vous avez besoin d'une mise en miroir synchrone en temps réel des données, un système de fichiers de cluster peut être en ordre. DRDB a déjà été nommé. Il est très agréable pour la réplication au niveau du bloc et souvent utilisé pour les configurations MySQL hautement disponibles. Vous pourriez également vouloir jeter un œil à GFS2, OCFS2, Luster et GlusterFS. Bien que Luster et GlusterFS ne soient pas vraiment adaptés à une configuration à deux serveurs.