Table of Contents
Translate this page
VHFFSFSSync
Présentation
VHFFSFSSync est un outil de réplication de filesystem via TCP/IP écrit en langage C.
Concrètement, il s'agit d'un serveur maitre pouvant accepter 0 à n clients esclaves. Un daemon côté serveur surveille un répertoire particulier qui est considéré comme le référentiel / le maître. Il informe les daemons clients / esclaves de toutes les modifications survenant dans ce répertoire afin qu'ils puissent les rejouer sur leurs machines respectives. On obtient ainsi une solution de mirroring unidirectionnelle s'approchant d'une réplication en temps réel, la réplication étant commencée au plus tôt sur les clients et réduite au strict minimum (seules les modifications sont rejouées, à la manière d'un rsync, mais sans le coût inhérent à la détection des différences).
Fonctionnement
Le daemon maître, nommé vhffsfssync_master, ne fait pas de polling : il est informé directement des modifications effectuées dans le répertoire grâce à inotify. En conséquence, VHFFSFSSync n'est utilisable qu'avec un kernel Linux > 2.6.13.
Par défaut, seules l'arborescence et les données (création/modification/suppression de fichier/dossier/liens symboliques) sont répliquées, mais il est également possible de répliquer les permissions Unix (owner, group et mode) ainsi que les dates (mtime seulement) avec l'option --preserve
.
Cette option implique toutefois que le daemon client, nommé vhffsfssync_slave, tourne en tant qu'utilisateur root.
La communication entre les clients et le serveur s'effectue purement en TCP/IP, sur un unique port statique (par défaut : le port 4567) et peut donc facilement traverser un firewall.
De plus, le client intègre une fonction de limitation du débit via l'option --limit-rate
.
Enfin, il est possible de compiler une variante du client nommée vhffsfssync_check, qui n'effectue aucune opération de réplication mais se contente d'écrire sur la sortie standard la liste des fichiers non synchronisés.
Téléchargement
Il est recommandé d'utiliser la toute dernière version provenant du master du dépôt Git de VHFFS :
# Recuperation des sources du produit git clone "git://git.tuxfamily.org/gitroot/vhffs4/vhffs.git vhffs" cd vhffs/vhffs-fssync # Les instructions de compilation sont consignées de manière concise dans le fichier HOWTOCOMPILEANDRUN cat HOWTOCOMPILEANDRUN
Mise en place
Prenons l'exemple suivant : on souhaite mettre en place une réplication du contenu du répertoire /data/iso/BSD de la machine tom (sous Debian) vers le répertoire /data de la machine jerry (sous Fedora). Cette différence de système ne pose pas de problème en soi. En revanche, il est préférable que le serveur et le client VHFFSFSSync soient à la même version/révision.
Côté serveur
Sur tom, on veillera donc à lancer la commande suivante :
./vhffsfssync_master --foreground --pidfile=/var/run/vhffsfssync_master-data-iso-BSD.pid --port=5678 /data/iso/BSD
Détails des arguments :
- l'option
--foreground
nous permettra de garder le daemon en avant-plan et donc de disposer de ses éventuels messages d'erreur, ce qui s'avère pratique pour sa première mise en place. - Le port 5678 a été choisi au hasard pour cet exemple.
- On indique le chemin d'un fichier pid, ce qui facilitera l'arrêt du daemon ultérieurement.
- Enfin, le dernier argument stipule le répertoire à mettre à surveiller pour réplication.
Il est recommandé de lancer le daemon en tant qu'utilisateur root, celui-ci se chrootant ensuite dans ce dossier ; dans le cas contraire, vous obtiendrez le message suivant :
cannot chroot() to /data/iso/BSD: Operation not permitted
Ceci n'empêche toutefois pas le daemon de fonctionner. Enfin, vhffsfssync_master affiche “Ready” : voilà pour la partie serveur
Côté client
Sur jerry, on crée le dossier de destination :
mkdir /data
Cela nous évitera de rencontrer le message d'erreur suivant :
cannot chdir() to /data: No such file or directory
On lancera le client en tant qu'utilisateur root pour les mêmes raisons que pour le serveur.
On détermine ensuite l'adresse IP qui sera contactée par le client ; en effet, à l'heure où ce document est rédigé, vhffsfssync_master prend en paramètre une adresse IP, pas un nom DNS :
host -t A tom
tom.domaine.local has address 192.168.0.2
./vhffsfssync_slave --foreground --preserve --pidfile=/var/run/vhffsfssync_slave-data.pid 192.168.0.2:5678 /data
Il est alors intéressant à ce moment-là de regarder l'utilisation qui est faite de la bande passante entre les deux serveurs : vhffsfssync effectue une première réplication complète, ce qui prend un peu de temps et pas mal de bande passante.
Voir l'option --limit-rate
pour contrôler cet aspect-là.
Il est également intéressant de comparer les arborescences sur les deux serveurs pour s'assurer qu'elles sont désormais identiques à tout niveau : noms de fichiers, données, permissions, mtime, …
Amusez-vous ensuite à effectuer des modifications côté serveurs (touch, chmod, chown, chgrp, mv, cp, …) et à les retrouver quasi-instantanément côté client. Une autre expérience intéressante consiste à suivre le travail de vhffsfssync à l'aide de l'utilitaire strace :
strace -f -p $(pgrep vhffs)
Après vous être assuré que tout était ok, vous pouvez automatiser le démarrage de ces daemons sans l'option --foreground
À noter que les problématiques relatives au packaging et aux scripts d'init.d ne sont pas abordées ici, car elles ne différent pas de celles accompagnant les autres daemons Unix.
Possibilités en termes d'architectures
TODO : lister ce qu'il est possible de réaliser avec plusieurs daemons maîtres / esclaves.