Quel est le meilleur moyen de garder plusieurs serveurs Linux synchronisés?

Question

J'ai plusieurs endroits différents dans une zone assez large, chacun avec un serveur Linux stockant les données de l'entreprise. Ces données changent chaque jour de différentes manières à chaque endroit différent. J'ai besoin d'un moyen de garder ces données à jour et synchronisées entre tous ces endroits.

Par exemple :

Dans un endroit, quelqu'un place un ensemble d'images sur son serveur local. Dans un autre endroit, quelqu'un d'autre place un groupe de documents sur son serveur local. Un troisième endroit ajoute une poignée d'images et de documents à son serveur. Dans deux autres endroits, aucune modification n'est apportée à leurs serveurs locaux. Le lendemain matin, j'ai besoin que les serveurs des cinq endroits aient toutes ces images et tous ces documents.

Mon premier réflexe est d'utiliser rsync et un cron job pour synchroniser pendant la nuit (de 1h à 6h environ), lorsque aucun des débits dans nos endroits n'est utilisé. Il me semble qu'il serait préférable d'avoir un serveur comme serveur "central", qui récupère d'abord tous les fichiers des autres serveurs. Ensuite, il enverrait ces modifications à chaque serveur distant ? Ou y a-t-il une autre manière, meilleure, d'effectuer cette fonction ?

Answer 1

La manière dont je le fais (sur les boîtes Debian/Ubuntu):

• Utilisez dpkg --get-selections pour obtenir vos paquets installés
• Utilisez dpkg --set-selections pour installer ces paquets à partir de la liste créée
• Utilisez une solution de contrôle de source pour gérer les fichiers de configuration. J'utilise git de manière centralisée, mais subversion pourrait être utilisé tout aussi facilement.

Answer 2

À ma connaissance, rsync est votre meilleur choix, il prend en charge les mises à jour partielles de fichiers parmi une variété d'autres fonctionnalités. Une fois configuré, il est très fiable. Vous pouvez même configurer le cron avec des fichiers journaux horodatés pour suivre ce qui est mis à jour à chaque exécution.

Answer 3

Une alternative si rsync n'est pas la meilleure solution pour vous est Unison. Unison fonctionne sous Windows et possède des fonctionnalités pour gérer les changements des deux côtés (sans nécessairement avoir à choisir un serveur comme étant le principal, comme vous l'avez suggéré).

En fonction de la complexité de la tâche, l'un ou l'autre pourrait fonctionner.

Answer 4

Une chose que vous pourriez (théoriquement) faire est de créer un script en utilisant Python ou quelque chose et la fonctionnalité du noyau inotify (à travers le package pyinotify, par exemple).

Vous pouvez exécuter le script, qui s'inscrit pour recevoir des événements sur certains répertoires. Votre script pourrait alors surveiller les répertoires, puis mettre à jour tous les autres serveurs lorsque des changements se produisent sur chacun.

Par exemple, si quelqu'un télécharge spreadsheet.doc sur le serveur, le script le voit instantanément; si le document n'est pas modifié ou supprimé dans, disons, 5 minutes, le script pourrait le copier sur les autres serveurs (par exemple, via rsync)

Un système comme celui-ci pourrait théoriquement mettre en œuvre une sorte de 'réplication de système de fichiers' limitée d'une machine à une autre. Une idée assez intéressante, mais vous auriez probablement à le coder vous-même.

Answer 5

Je ne sais pas à quel point cela est pratique, mais un système de contrôle de source pourrait fonctionner ici. À un moment donné (peut-être toutes les heures?) pendant la journée, une tâche cron exécute un commit, et pendant la nuit, chaque machine effectue un checkout. Vous pourriez rencontrer des problèmes avec un long commit qui n'est pas terminé lorsque qu'un checkout doit être exécuté, et essentiellement la même chose pourrait être faite avec rsync.

Je suppose ce que je pense, c'est qu'un serveur central rendrait votre opération de synchronisation plus facile - les conflits peuvent être gérés une fois sur le serveur central, puis poussés vers les autres machines.