Forum général.cherche-logiciel Réplication données sur réseau local (P2P ?)

Posté par  .
Étiquettes : aucune
0
25
oct.
2010
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

  • # heartbeat + rsync

    Posté par  . Évalué à 3.

    heartbeat pour detecter que la machine en face est en marche

    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  . Évalué à 1.

    Soit tu pars sur une solution à base de système de fichier distribué, soit, si ton système n'est pas critique, je pense qu'on peut faire un truc utilisable avec à base d'inotify et rsync.
    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  . Évalué à 2.

      sauf que dans son cas il risque d'avoir plein de message d'erreur de RSYNC car il utilise
      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  . Évalué à 2.

      rsync ne va pas scanner tous les répertoires sur la machine client et hôte pour faire sa synchronisation ? Si oui ça risque de prendre pas mal de temps.
      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  . Évalué à 1.

        @NeoX:
        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  (site web personnel) . Évalué à 3.

    twitter utilisait GIT jusqu'à que cela ne suffise plus du fait du nombre important de machine.
    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  . Évalué à 1.

    Merci pour les réponses, effectivement rsync ne sera pas adapté, car quid de la reprise (un transfert peut être interrompu), 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).

    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  . É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  . Évalué à 0.

        si tu travailles avec des systèmes de fichiers linux type ext2-3-4 btrfs,
        -> 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  . Évalué à 2.

    Suffit d'installer le paquet "bittorrent" (sous debian) et t'as le tracker "bttrack", "btmakemetafile" pour créer un torrent et le client "btdownloadheadless" pour seeder.

    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  . Évalué à 2.

      Oui c'est ce que j'ai obtenu avec Murder, effectivement il faudrait générer un torrent pour un dossier. Alors après je ne sais pas si quand le fichier est modifié c'est répercuté, et à quel niveau. (par exemple ajout d'un fichier, modification d'un fichier existant, etc.). En plus il faudrait le régénérer pour chaque noeud susceptible de mettre des fichiers.
      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  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Glusterfs

    Posté par  . Évalué à 3.

    OpenAFS, j'ai pas encore eu le temps de regarder.
    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/glusterfs
    le 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  . Évalué à 2.

      il se passe quoi si deux machines modifie le meme dossier en meme temps ?

      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  . Évalué à 1.

        Alors, d'après ce que j'ai compris :

        - 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.