Journal Répliquer des fichiers sur n machines via bittorrent

Posté par  . Licence CC By‑SA.
Étiquettes :
38
22
sept.
2011

Bonjour à tous.

Confronté pour mon boulot à la problématique consistant à répliquer une arborescence de fichiers sur un grand nombre de machines réparties sur des sites géographiques différents et ce en un minimum de temps, j'ai d'abord eu recours à rsync. C'est pratique, on contrôle finement son utilisation de la bande passante mais lancer n copies en parallèle à partir d'un serveur, ça charge beaucoup ce dernier et, au final, la réalisation de toutes les copies prend pas mal de temps. On peut finasser en créant n sources de référence sur des sites à grosse bande passante mais ça représente alors un joli boulot de planification.

Je me suis alors demandé si les techniques de transfert décentralisées (comprendre "peer to peer") ne constitueraient pas une solution plus élégante. Ce journal entend vous fournir une piste à creuser, assortie en prime d'un petit mode opératoire. Ce dernier (extrêmement rudimentaire, mais c'est une base de travail) repose sur l'utilisation de murder, un petit outil Python créé par les employés de Twitter pour mettre à jour leur armada de serveurs. Cet utilitaire s'appuie sur le client Bittorrent Bittornado (écrit lui aussi en Python). Pour ceux qui voudraient en savoir plus, une présentation d'une vingtaine de minutes est disponible sur le net et détaille le fonctionnement de cet outil, couplé chez Twitter à Capistrano, un système de déploiement d'applications écrit lui en Ruby.

Voici le mode opératoire (je n'ai rien inventé : je me suis contenté de reprendre ce qui était mentionné dans une diapo particulière de la présentation évoquée plus haut. Comme vous allez le voir, c'est tout bête.)

  • Postulat 1 : vous disposez de N machines sur lesquelles pouvez prendre la main. Une de ces machines contient une arborescence de référence à propager sur les autres.
  • Postulat 2 : un interpréteur Python est présent sur toutes ces machines.

  • Postulat 3 : vous avez la main sur tout système de filtrage réseau présent entre vos machines pour aménager les règles de filtrage gênantes, le cas échéant.

  • Commencez par récupérer murder via git puis déposez-le sur chaque machine dans un dossier donné (ici : /toto).
    git clone https://github.com/lg/murder.git

  • Sur la machine source, on crée le fichier torrent /tmp/acopier.torrent correspondant au dossier /tmp/arepliquer à répliquer vers les autres machines.
    python /toto/murder/dist/murder_make_torrent.py /tmp/arepliquer <nom ou IP du tracker>:8998 /tmp/acopier.torrent

  • Toujours sur la machine source, on lance ensuite le tracker (serveur HTTP ultra-rudimentaire) :
    python /toto/murder/dist/murder_tracker.py &

  • On se met en mode diffusion.
    python /toto/murder/dist/murder_client.py seed /tmp/acopier.torrent /tmp/arepliquer <nom ou IP de la machine courante>

  • On copie le fichier .torrent sur les autres machines (dans /tmp pour cet exemple).

  • Sur les autres machines, on lance le chargement. Le dossier de destination peut exister et être partiellement rempli. Seuls les blocs à mettre à jour transiteront sur le réseau.
    python /toto/murder/dist/murder_client.py peer /tmp/acopier.torrent /tmp/arepliquer <nom ou IP de la machine courante>

Quand les machines cibles sont à jour, le process Python se termine et affiche Done and done. Quand toutes les machines sont à jour, on peut arrêter les 2 process Python lancés sur la première machine.

Il faut savoir que, contrairement à un rsync, seul le contenu des fichiers est répliqué. Si vous visez à obtenir non seulement un contenu mais aussi des attributs identiques, un coup de rsync final pourra se révéler utile.

Dernier détail : la maîtrise de la bande passante. Vous pouvez tenter de jouer sur les options par défaut du client bittorrent, qu'on trouve dans murder/dist/BitTornado/download_bt1.py. Ce sont les valeurs max_upload_rate et max_download_rate que vous modifierez pour commencer.

Voilà. Je crois que ça mérite d'être creusé. Ça démontrera en outre aux décideurs pressés perméables à l'argumentaire partisan de d'industrie du divertissement que "le peer to peer", ça n'est pas réservé aux "méchants pirates" et qu'au fond, un outil n'est ni bon ni mauvais en lui-même. C'est ce qu'on en fait qui peut être sujet à controverse.

  • # Le P2P

    Posté par  . Évalué à 2.

    "le peer to peer", ça n'est pas réservé aux "méchants pirates"

    Déjà en France, si tu parles de "pair à pair" ça fait moins méchant pirate :)

    C'est une très bonne idée. Je m'étais déjà fait la réflexion une fois dans une entreprise ou j'étais, pour les postes bureautiques.

    Tous les documents étaient sur des serveurs. On se retrouvait donc avec des postes bureautiques ayant des disques de 80 Go utilisés à 10 %.

    Réserver un espace sur ces disques pour l'utiliser comme cache, puis mettre en place une réplication P2P automatique entre les postes aurait permis d'avoir une meilleur accessibilité aux documents et une redondance, toujours bienvenue comme sauvegarde supplémentaire.

    Après cela pose des problèmes de gestion des versions de documents. Mais à la limite, avec une nomenclature stricte et horodatée des noms de fichiers et en se basant sur leur date de modification on peut s'en sortir.

    • [^] # Re: Le P2P

      Posté par  (site web personnel) . Évalué à 3.

      bittorrent est déjà utilisé dans la réplication des OS pour les noeuds de calcul de clusters et de grilles de calcul.

    • [^] # Re: Le P2P

      Posté par  (site web personnel) . Évalué à 1.

      Etant donné que ça fait vachement d'espace par rapport à un serveur, on pourrait imaginer un système à la Time Machine d'Apple, mais décentralisé.

      There is no spoon...

      • [^] # Re: Le P2P

        Posté par  . Évalué à 1.

        Déjà utiliser en prod avec le serveur/client historique (les méthodes sont sensiblement les même) pour déployer un client "lourd" (2Go) de datacenter en datacenter.

        L'ancienne méthode utilisant des rsync dev local => datacenters n fois
        1er seed, même vitesse, ensuite on démultiplie par le nombre de seed (chaque serveur avait sa propre bande passante dédier)

        Bref on passe d'un déploiement en 1 semaine à 24h, (pour le premier transfert en fait, les suivants se faisant à 10mo/s c'est la réception qui fait goulot d'étranglement).

    • [^] # Re: Le P2P

      Posté par  (Mastodon) . Évalué à 2.

      C'est une très bonne idée. Je m'étais déjà fait la réflexion une fois dans une entreprise ou j'étais, pour les postes bureautiques.

      Tous les documents étaient sur des serveurs. On se retrouvait donc avec des postes bureautiques ayant des disques de 80 Go utilisés à 10 %.

      En bureautique le princpial point bloquant c'est la confidentialité. Ce n'est pas parce que tel document est visible par telle personne à tel niveau hiérarchique de tel département qu'elle doit l'être pour tout le monde. Alors ce serait sûrement ingérable même avec du chiffrement.

  • # murder, vraiment ?

    Posté par  . Évalué à 7.

    rien que le nom m'amuse.

    • [^] # Re: murder, vraiment ?

      Posté par  . Évalué à 7.

      Moi, je pense que la vérité est ailleurs...

    • [^] # Re: murder, vraiment ?

      Posté par  . Évalué à 10.

      Ça doit être un logiciel crée par Hans Reiser.

      Désolé.

    • [^] # Re: murder, vraiment ?

      Posté par  . Évalué à 6.

      Un murder, c'est un groupe de corbeaux.
      Effectivement, c'est pas le sens le plus connu, mais comme twitter a pour mascotte un piaf, ca colle bien en fait.

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: murder, vraiment ?

        Posté par  . Évalué à 2.

        Ta traduction est confirmée par l'image d'une nuée de corbeau à 3min de la vidéo de présentation :)

        • [^] # Re: murder, vraiment ?

          Posté par  . Évalué à 2.

          Elle surtout confirmée par l'auteur dans la présentation (si c'est celle a laquelle je pense), je le savais pas non plus avant de regarder des conf sur murder ;-)

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

  • # mtree plutôt que rsync

    Posté par  (site web personnel) . Évalué à 10.

    Si vous visez à obtenir non seulement un contenu mais aussi des attributs identiques, un coup de rsync final pourra se révéler utile.

    À mon avis c'est probablement plus efficace de créer un fichier ATRIBUTS contenant les dits attributs en utilisant mtree puis lorsque ce fichier ATTRIBUTS a été transmis sur tous les nœuds, de répliquer les attributs grâce à un second appel à mtree.

    Ensuite l'idée de faite un P2P pour tout répliquer semble séduisante mais présente l'inconvénient (a priori) qu'elle ne tient pas compte de la topologie du réseau. Disons pour simplifier que chaque site géographique est un réseau en étoile centré sur un hub (la passerelle) et que les hub sont ensuite interconnectés entre eux via internet. C'est alors probablement plus efficace de synchroniser premièrement les hubs (par exemple avec ta solution ou une réplication avec rsync ou unison en arbre, cf. infra) puis de répliquer localement chaque hub sur les autres membres du LAN. La méthode pour la dernière étape est optimale à cause de la topologie du réseau.

    Réplication en arbre disons que tes hubs s'appellent h[0], h[1], h[10] h[11] etc. On réplique h[0] sur h[1], puis en parralèle h[0] sur h[10] et h[1] sur h[11], puis en parallèle h[0] sur [100], h[1] sur h[101], h[10] sur h[110] et h[11] sur h[111] et ainsi de suite.

    • [^] # Re: mtree plutôt que rsync

      Posté par  (site web personnel) . Évalué à 7.

      Le P2P a l'avantage de gérer les pannes. Si un hub parent tombe mais que tu as une liaison de secours (ou qu'un de tes frères a déjà fini la réplication), tu peux toujours aller demander à quelqu'un d'autre.

      Ensuite, peut-être qu'on peut s'amuser à configurer les clients bittorent pour favoriser une réplication en arbre (par exemple en attribuant des priorités aux peers).

  • # Pour mémoire

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    elk42 : les limites du p2p
    elk42 : 15 mecs des 4 coins du monde bloqués comme toi à 67.8% d'un fichier et qui comme > toi attendent qu'un mec se connecte avec le fichier entier
    elk42 : finalement le p2p c'est un peu l'internationale de la loose

    Sinon, y a CodaFS aussi pour faire ce genre de trucs, notamment la réplication entre serveurs.

    • [^] # Re: Pour mémoire

      Posté par  . Évalué à 2.

      elk42 : les limites du p2p
      elk42 : 15 mecs des 4 coins du monde bloqués comme toi à 67.8% d'un fichier et qui comme > toi attendent qu'un mec se connecte avec le fichier entier
      elk42 : finalement le p2p c'est un peu l'internationale de la loose

      Ah ça aussi si tu lances le téléchargement d'un fichier qui a peu de sources faut pas s'étonner... Évidemment il se peut que le mec en question ne remette plus jamais à disposition le fichier on se retrouve avec un fichier tronqué sur le réseau. Le bon coté c'est qu'il va disparaître de lui même car les 15 gus baisés vont l'effacer...

      Ça arrive pas tant que ça, et jamais sur des fichiers qui ont un réel intérêt.

      • [^] # Re: Pour mémoire

        Posté par  (site web personnel) . Évalué à 7.

        On parle ici de déployer sur son parc. Il y a toujours une machine sur le réseau P2P, le serveur.

        Le P2P sur un réseau local, au sien d'un cluster, c'est une très bonne idée.

    • [^] # Re: Pour mémoire

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      J'aime bien me faire moinsser pour avoir cité bashfr !
      Sinon, pour CodaFS, y a personne qui plussoie ?

  • # Bittorrent sans tracker

    Posté par  (site web personnel) . Évalué à 3.

    J'ai lu rapidement http://tanguy.ortolo.eu/blog/article26/publier-torrent qui permet de se passer du tracker si tu connais au moins une IP fiable qui a une copie du fichier complet.
    Ca pourrait simplifier ton truc.

  • # Et pourquoi pas passer par DHT

    Posté par  (Mastodon) . Évalué à 3.

    Il doit aussi y avoir moyen de se passer du tracker : http://tanguy.ortolo.eu/blog/article26/ à condition que le client Bittornado le supporte…

    • [^] # Re: Et pourquoi pas passer par DHT

      Posté par  . Évalué à 3.

      Larry Gadea, de chez Twitter, explique dans la vidéo (allez à 15:25) que je cite dans le journal pourquoi, en interne chez Twitter, ils ont fait l'impasse sur l'option DHT afin de grapiller quelques précieuses secondes dans leurs transferts. Cela explique pourquoi, par défaut, murder ne prend pas en charge cette option. Cela-dit, étant donné que cet outil (dont le nom a été choisi car il signifie "vol de corbeaux/corneilles" en plus de "meurtre") s'appuie sur un client Bittorrent générique, peut-être suffit-il de modifier ça dans la config du Bittornado embarqué avec murder.
      (...) Vérifications faites, la version de Bittornado embarquée avec murder est peut-être épurée car un "grep -i dht" ne renvoie rien. :)

  • # Facebook et Bittorent

    Posté par  . Évalué à 7.

    FaceBook utilise le P2P pour diffuser au mieux les majs sur tous leurs serveurs.
    Cette vidéo à ce sujet est très intéressante :
    http://www.youtube.com/watch?v=T-Xr_PJdNmQ

  • # bittorent c cool

    Posté par  . Évalué à 4.

    Je me sens moins seul au monde ..
    J'ai eu l'occasion de mettre en place une diffusion par bittorent d'une dizaine de gigas sur 600 machines en environnement pro , et c'est vrai que pour moi , c'était la seule façon d'y arriver ...
    Et au final, ca fonctionne très bien.

    J'ai utilisé un tracker rivettracker et un client Enhanced CTorrent.
    J'ajoute que ce client permet de controler le débit par pairs, c'est assez pratique .
    J'ai fait mes scripts maison , avant de découvrir murder ... J'aurais l'occasion d'essayer ...

  • # Répliquer des fichiers sur n machines

    Posté par  . Évalué à 4.

    Multicast c’est bon, mangez-en !

    Mais bon, nos très chers opérateurs nous on bien bridé ça à leur manière :)

    • [^] # Re: Répliquer des fichiers sur n machines

      Posté par  (site web personnel) . Évalué à 7.

      Trop de contrainte... En plus, il faut que tous les noeuds télécharge en même temps.

      Je ne crois pas au multicast sauf dans quelques cas bien précis. Un système peer to peer a bien des avantages sur le multicast.

      • [^] # Re: Répliquer des fichiers sur n machines

        Posté par  . Évalué à 2.

        Soit, mais si
        - l'utilisation se fait via un hub ou un réseau sans-fil (== bande passante partagée)
        - le téléchargement est simultané
        alors le multicast a un clair avantage par rapport au P2P présenté !

        • [^] # Re: Répliquer des fichiers sur n machines

          Posté par  (site web personnel) . Évalué à 5.

          Avec des si, tu met Paris dans une bouteille ;-)

          Justement, on ne veux pas forcément que cela soit simultané, ce qui oblige a un processus synchrone au final complexe à mettre en place d'un point de vue administration système. Par exemple, que faire si un poste plante ?

          Pour ce genre de chose, il vaut mieux à mon sens un système asynchrone clairement tolérant aux pannes et aux plantages des clients. Le P2P diminue très clairement la bande passante sur le réseau, limite la charge du serveur... Cette solution me semble bien plus robuste pour cette problématique.

          • [^] # Re: Répliquer des fichiers sur n machines

            Posté par  (site web personnel) . Évalué à 4.

            J'ai travaillé dans une entreprise qui utilisait du multicast pour déployer des images sur les machines d'un réseau local (des écoles principalement), ça marchait très bien et c'est aussi plus facile pour planifier : tu lances toutes les machines, tu as le temps estimé qui s'affiche et tu sais que tu peux aller faire autre chose durant ce laps de temps.
            Des fois il y'avais des machines qui plantent, mais tu peux toujours relancer.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: Répliquer des fichiers sur n machines

              Posté par  (site web personnel) . Évalué à 8.

              Pour le déploiement d'image de poste, surtout de salle de cours, le multicast est effectivement idéal. Toute la salle se fait d'un coup.

              Ici, on parle de déployer des applications sur un parc de machine en fonctionnement, qui n'a pas d'unité géographique. On n'est pas du tout dans le même contexte.

  • # XGET

    Posté par  (site web personnel) . Évalué à 9.

    Un système en peer to peer pour faire cela et dédié au cluster, cela existe déjà. Cela s'appelle xget !

    http://xcpu.sourceforge.net/xget/

    C'est notamment utilisé par perceus et je crois rocks.

    • [^] # Re: XGET

      Posté par  . Évalué à 3.

      intéressant mais la dernière mise à jour date de 2009 et la doc est plutôt vide

      • [^] # Re: XGET

        Posté par  (site web personnel) . Évalué à 2.

        C'est clair, il faudrait séparer xget du reste et le rendre autonome.

        Coté doc, elle est vide car la commande semble super simple ! J'ai regardé du coté de murder, cela ne semble pas de la même échelle pour faire tourner les deux...

        A mon sens, xget n'est pas forcément fait pour 200000 noeud mais sur un réseau local avec moins de 1000 noeuds, il me semble qu'il est le plus simple.

        Comme perceus et rocks l'utilise, j'ai relativement confiance sur le fait qu'xget tourne encore dans quelques années. A vrai dire, une fois l'infrastructure en place, remplacer un outil de copie en P2P par un autre ne devrait pas être le point le plus bloquant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.