Existe-t-il un moyen de mettre en miroir deux serveurs sur Ubuntu?

Je me demandais s'il était possible de mettre en miroir deux serveurs, comme si vous pouviez télécharger des fichiers sur un serveur et qu'ils poussaient vers l'autre serveur, etc. Je suis plus curieux de mettre en miroir des fichiers, il n'a pas à refléter la gestion des packages et configuration (Mais ce serait cool aussi!)

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.

Fondamentalement, vous avez 3 possibilités:

1. Laissez votre application pousser les fichiers vers les deux serveurs.
2. Réplication asynchrone, par exemple rsync toutes les 15 minutes (ou moins) avec un travail cron
3. Réplication synchrone au niveau du système de fichiers (par exemple GlusterFS ) ou au niveau du périphérique de bloc (par exemple DRBD ). Si vous utilisez la réplication au niveau du périphérique de bloc, vous avez besoin d'un système de fichiers qui prend en charge le verrouillage distribué (par exemple OCFS2 ou GFS2 ) si vous souhaitez avoir un accès r / w aux fichiers des deux serveurs en même temps.

cron + rsync = répertoires / fichiers en miroir

Selon votre cas d'utilisation spécifique - Vous pouvez utiliser quelque chose de similaire à DRBD http://www.drbd.org/

Si vous essayez de créer une solution de sauvegarde ici (ce que j'ai personnellement fait dans à peu près la même configuration), soyez prudent. Il existe de nombreux types différents contre lesquels vous devez effectuer une sauvegarde, l'un des (sans doute le plus important) étant la suppression d'accès - tout système de réplication en direct ne fera que répliquer la suppression et ne fournir aucune sécurité. Pour cette réplication quotidienne fonctionne, mais est une réponse assez faible. Essayez RSnapshot.

Unison pourrait bien fonctionner pour vous, mais je n'ai aucune expérience personnelle.

Exécuter Rsync dans les deux sens avec les drapeaux aproprate peut fonctionner, mais il a le problème plutôt délicat de gérer les fichiers supprimés, sans manipulation spéciale, il restaure simplement les fichiers, ce qui est bien si vous ne supprimez jamais rien comme moi, mais un peu pauvre sinon. Il fait également des choses étranges si un fichier est déplacé.

Quoi que vous fassiez, si une situation peut survenir où des fichiers peuvent être modifiés simultanément aux deux extrémités, vous avez un problème. l'unisson est la seule solution que je connaisse qui puisse gérer cela même de manière satisfaisante.

Si c'est unidirectionnel (je veux dire, toujours d'un serveur à un autre serveur, mais pas vice versa), vous pouvez l'utiliser incron. C'est comme cron mais basé sur les événements du système de fichiers.

Chaque fois qu'un fichier est créé ou modifié, il déclenchera une scp ou une rsync vers l'autre serveur.

Bi-directionnel a le problème des boucles :).

cela dépend de vos besoins ... j'ai une configuration très "bon marché et facile" pour les serveurs web en cluster.

j'ai simplement un "serveur de fichiers" (NFS) où tous les serveurs web montent les répertoires suivants:

/etc/apache/sites-enabled
/etc/apache2/sites-avaliable
/var/www

mort simple et fonctionnel

clonezilla peut également regarder qui utilise rsync