Salut !
Je cherche un moyen d'utiliser la haute disponibilité pour répliquer des fichiers sur plusieurs machines d'un réseau domestique de petite taille (4 machines, mais plus souvent éteinte qu'allumée). L'idée c'est que lorsqu'il y en a au moins 2 d'allumées, certains fichiers de l'une soit immédiatement répliqué sur les autres et évidemment de pouvoir régler la vitesse de transfert entre les machines (certaines pouvant être en wifi, donc avec plus grande latence et plus faible débit).
Le tout de manière transparente (donc sans impacter l'utilisation), qui peut se faire en autant de fois qu'il le faut (le transfert doit pouvoir être interrompu à n'importe quel moment).
Le but étant de maintenir plusieurs copies synchronisées de fichiers sur plusieurs machines. (Evidemment sans passer par un système centralisé de synchronisation du type DropBox, et que la synchronisation se fasse dés que les machines sont disponibles sur le réseau.)
J'ai essayé torrent, en en créant un depuis deluge. Mais ca n'arrive pas à seeder et je ne sais pas quoi mettre comme tracker (j'ai essayé openbittorrent, mais ca ne marche pas).
Qu'en pensez-vous ? Y-a-t-il d'autres solutions ? Par exemple basée sur glusterfs ou lustre ?
Merci
Forum général.cherche-logiciel Réplication données sur réseau local (P2P ?)
25
oct.
2010
# heartbeat + rsync
Posté par NeoX . Évalué à 3.
rsync pour envoyer tes fichiers sur la machine distante
en n'envoyant que les fichiers qui ont changés...
# une solution en 5 lignes de shell
Posté par neologix . Évalué à 1.
L'idée c'est que inotify monitore les modifications faites sur un répertoire, et dès qu'une modification est faite, rsync le synchronise avec les autres noeuds.
Un truc du genre, en shell (non testé) :
#!/bin/sh
DIR_TO_MONITOR="/home/foo"
NODES="toto tata tutu"
REMOTE_PATH=`dirname $DIR_TO_MONITOR`
SYNC_CMD="rsync -aqz --contimeout=3 --timeout=3"
MONITOR_CMD="inotifywait -mr"
$MONITOR_CMD $DIR_TO_MONITOR | while read; do
for node in $NODES; do
$SYNC_CMD $DIR_TO_MONITOR $node:/$REMOTE_PATH
done
done
Bon, c'est juste une illustration (rsync est appelé à chaque événement, tu pourrais lancer une instance par noeud en parallèle, etc), mais ça te donne une idée. Il existe peut-être même déjà des outils qui font ça...
[^] # Re: une solution en 5 lignes de shell
Posté par NeoX . Évalué à 2.
un réseau domestique de petite taille (4 machines, mais plus souvent éteintes qu'allumées)[^] # Re: une solution en 5 lignes de shell
Posté par scullder . Évalué à 2.
J'ai un serveur rsync sur un pc fixe pour sauvegarder le /home de mon portable.
Déjà j'utilise régulièrement une machine virtuelle de 10Go à peu près et à chaque modif, elle est retransférée.
Ensuite en général, le petit serveur patine un peu dans la semoule avant de lancer les transferts, normal sur plus de 200Go de données.
Si on fait un rsync à chaque modification d'un fichier sur 3 ou 4 machines, ça peut marcher mais ça risque d'être long amha.
Si en plus on veut simuler du p2p via rsync, ça risque d'être incroyablement lourd, avec des réactions en chaine qui risquent d'être assez marrantes.
[^] # Re: une solution en 5 lignes de shell
Posté par neologix . Évalué à 1.
Rien n'empêche de pinger le serveur avant, c'est une ligne à ajouter
@scullder:
Il est possible de parser la sortie de inotifywait pour ne mettre à jour que le fichier qui a été modifié
Comme je l'ai dit, ce n'est qu'une proof-of-concept, ça peut largement être optimisé.
D'ailleurs il existe déjà un outil qui fait ça en fait : http://code.google.com/p/lsyncd/. Il est en C, et utilise le couple inotify+rsync.
Maintenant, si tu veux un truc qui tient vraiment la charge, il te reste comme tu l'as dit GlusterFS.
# git ou murder ?
Posté par Mouns (site web personnel) . Évalué à 3.
alors ils ont codé Murder un systeme de distribution P2P basé sur bittorrent.
il y avait eu un article à ce sujet : http://www.korben.info/twitter-bittorrent-murder.html
concernant Murder : http://github.com/lg/murder
# Rsync
Posté par anakin . Évalué à 1.
Je viens de tester murder, bon apparemment cette fois la création du torrent marche (en tout cas le tracker s'annonce bien de manière valide, devait y avoir un truc qui marchait pas avec deluge) et on peut utiliser n'importe quel client torrent existant pour récupérer le fichier du seed initial.
L'idéal serait de combiner la souplesse du torrent (reprise, chaque noeud décide de la bande passante qu'il utilise/fournit, etc.) ainsi que de la possibilité de surveiller un dossier contenant des fichiers à synchroniser.
J'ai vu dans la doc de glusterfs un mode de réplication. Il n'y a plus qu'à...Je vais donc un peu plus me pencher là dessus pour voir.
[^] # Re: Rsync
Posté par NeoX . Évalué à 2.
Merci pour les réponses, effectivement rsync ne sera pas adapté, car quid de la reprise (un transfert peut être interrompu),J'ai jamais eu de soucis avec ca,
justement ca m'a sauvé plus d'une fois quand le FTP ne possede pas de mode resume
de plus ca risque d'être trop lourd si ce sont de gros fichiers pas très adapté pour l'incrémental (images disque, fichiers mailbox).j'ai jamais vu qu'il transferait TOUT le fichier de 10Go quand seulement quelques clusters avaient changés dedans
mais j'ai peut-etre jamais eu le cas
[^] # Re: Rsync
Posté par Guillaume D. . Évalué à 0.
-> pas de problèmes : uniquement ce qui a changé sera transféré.
Mais si tu utilises un système de fichier obsolète type FAT16-32,
-> et bien il se pourrait qu'il re-transfère l'ensemble du fichier, surtout si UTF8 et autre joyeusetées ....
# Torrent
Posté par Grunt . Évalué à 2.
Par contre, faut générer un nouveau torrent chaque fois qu'un fichier est créé ou modifié. Peut-être que si tu régénères régulièrement un torrent pour l'ensemble des dossiers à synchroniser, il sera capable de voir ce qui n'a pas bougé et ne retéléchargera que la différence. À tester.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Torrent
Posté par anakin . Évalué à 2.
Le protocole torrent, c'est pas encore tout à fait la solution ultime qui devrait être entièrement décentralisée (pas de tracker).
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Glusterfs
Posté par anakin . Évalué à 3.
Sinon, j'ai testé GlusterFS, c'est pas mal, ca peut utiliser du NFS derrière en fait pour les montages. La mise en place est relativement simple.
En gros, on déclare un cluster en ajoutant des "bricks", les machines constituant le cluster :
server1:/dossier1
server2:/dossier2
server3:/dossier3
server4:/dossier4
En mode répliqué, chaque dossier va servir au stockage local de la donnée qui sera répliqué.
Donc là, en gros c'est en mode réplication 4 (replica 4). Chaque noeud est aussi un client, donc on monte dessus (dans /mnt/glusterfs par exemple en utilisant comme serveur NFS l'adresse IP du noeud) le dossier dans lequel on écrit les données qui doivent être répliquées. Si on veut juste pouvoir lire à partir d'un noeud, on a pas besoin de monter ce dossier.
La taille disponible pour ce montage NFS sur chaque machine est le min des espaces disque de chaque serveur (comme le RAID 1).
Une donnée écrite dans le /mnt/glusterfs de n'importe quel serveur apparaîtra dans les dossiers /dossier[i] des autres serveurs. (et dans /mnt/glusterfs de chaque serveur si ca a été monté). Mais seule une modification dans /mnt/glusterfs est prise en compte. Les /dossier[i] servent uniquement à lire, en tout cas c'est ce que j'ai constaté.
Donc en fait là, si j'ai bien compris, lorsque je fais un :
cp fichier /mnt/glusterfsle fichier est répliqué de manière transparente et d'un coup sur les autres noeuds.
J'ai testé un cas d'interruption, je copie un truc via cp dans le dossier /mnt/glusterfs sur un serveur. J'interromps une des machines (reboot brutal) vers laquelle les fichiers commencaient à être copiés. Ensuite en redémarrant le noeud, il faut refaire un rebalance (cf man gluster) pour que ca reprenne...ca semble pas mal ;)
Reste à automatiser tout ça (montage auto, démarrage auto, rebalance auto) et ca devrait être bon.
Dommage que le cp soit bloquant, l'idéal aurait été de pouvoir partager un truc existant sans devoir le copier pour le transférer. (comme un dossier de synchro).
[^] # Re: Glusterfs
Posté par NeoX . Évalué à 2.
ou si toutes les machines sont eteintes quand tu crees la donnée sur ton poste
et que tu allumes les machines APRES.
[^] # Re: Glusterfs
Posté par anakin . Évalué à 1.
- Concernant la concurrence en écriture, j'ai pas vraiment pu tester deux noeuds qui modifieraient la même donnée (et donc il faudrait une synchro dans les deux sens, source peut être de conflits).
- Si on allume les machines après, si on fait un rebalance (à la main), les données sont répliquées correctement (si en mode réplication replica N et qu'il y a au moins un multiple de N machines allumées)
Je n'ai que 4 machines (et un de mes portables serveurs est tombés en panne, donc plus que 3) donc je n'ai pu tester que replica 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.