Déploiement : troquez FTP pour Bittorrent

Préambule

Les 150 techniciens de mon client, qui interviennent sur site, ont besoin d’images iso des terminaux et des quelques ordinateurs qu’ils dépannent. Cela représente respectivement 17 et 22Go de données.

Les 17Go leur sont mis à disposition quatre fois par an sur un serveur ftp. Les 22Go une seule fois par an.

Ce serveur ftp est derrière une LS dont le débit est de 50Mbps symétrique.

Les serveurs métiers de mon client sont derrière cette même LS de 50Mbps symétrique.

Le métier de mon client nécessite que ses clients accèdent aux serveurs métier. Les terminaux acceptent toutefois de ne pas être constamment connectés aux serveurs.

A votre avis, que s’est-il passé le jour où une nouvelle version des images iso a été rendue disponible aux techniciens ?

Étude

La LS a été saturée, les terminaux ont cessé de se connecter aux serveurs, et nous avons dû en urgence reconfigurer le serveur ftp pour qu’il n’accepte qu’on nombre limité de connexions afin de libérer de la bande passante pour que les terminaux se connectent de nouveau. Le téléchargement des images par les techniciens s’est poursuivi pendant environ 2 semaines.

Et nous avons cherché une solution pour que cela ne se reproduise plus.

Nous avons passé en revue plusieurs options :

  • Doubler la LS et déplacer le ftp;
  • Envoyer des clés usb ou des disques durs aux points de ralliement des techniciens;
  • Mettre les images sur un serveur externe, au hasard Amazon S3;
  • Utiliser bittorrent.

Les connaisseurs noteront que la dernière et l’avant dernière solution peuvent se combiner : tout fichier déposé chez Amazon S3 peut être « bittorrentifié » en mettant ‘?torrent’ derrière son url.

Mais pourquoi utiliser Bittorrent ? Rappelons qu’au delà de l’utilisation qui en est faite, et de sa réputation, bittorrent est un protocole de partage de fichiers. Il est particulièrement adapté pour mettre à disposition des fichiers de gros volumes sans saturer la bande passante de son émetteur.

Soyons honnêtes : j’avais eu connaissance, à ce moment, de Murder : un moyen utilisé par Twitter et Facebook pour déployer leur code. J’avais eu l’idée de déployer l’application de mon client grâce à ce protocole, mais la mise en œuvre était trop compliquée.

Mais chassez le torrent par la porte, il revient par la fenêtre…

Les techniciens, pour récupérer les images iso (au format Norton Ghost), utilisent donc un client ftp. Comme les images sont assez conséquentes, ils ont pour habitude de lancer le téléchargement depuis chez eux, la nuit, derrière leur *box, et d’éventuellement le reprendre s’il est interrompu. Ils sont donc un peu débrouillards avec l’informatique.

La première solution (doubler la LS) était longue à mettre en œuvre. Et de toutes façons c’est un chantier que nous devions mener, ne serait-ce que pour la sûreté du site.

La seconde solution (diffusion par clé usb) était en fait plus ou moins en place : c’est de cette manière que certains techniciens mettaient à jour leurs fichiers images iso. Le coût (temps et argent) ne pouvait pas être estimé, mais à vue de nez il était supérieur à celui de déposer des images sur des serveurs : envoyer les clé usb par la poste, faire revenir les techniciens au centre, renvoyer les clés usb par la poste …

Nous avons pu estimer la troisième solution (mettre les images sur Amazon S3) assez précisément, surtout en termes de prix, et nous nous sommes aperçus qu’il y avait deux problèmes de taille:

  • De tuyau : pour faire simple, les postes qui génèrent l’image iso sont derrière des *box adsl ; transférer 17Go d’images iso chez Amazon allait donc prendre beaucoup de temps;
  • D’image : la taille maximale d’un fichier à uploader chez Amazon est de 5Go. Certaines de nos images ont une taille supérieure.

Restait la dernière solution (utiliser bittorrent) : la moins chère, la moins impactante, la plus économe en bande passante, la plus robuste (en matière de reprise sur erreur de transfert). Mais elle nécessitait de mettre en place l’infrastructure logicielle nécessaire.

Notez que nos serveurs sont sous Linux.

Mise en œuvre

Une architecture bittorrent nécessite :

  • Des clients, dont surtout le premier : le seeder, qui possédera les images disque à diffuser
  • Le tracker, auquel se connectent les client afin de savoir quels autres client sont connectés.
  • Des fichiers .torrent.

Le but est de fournir aux techniciens un moyen simplissime de télécharger les images. Par « simplissime » nous entendons « en un nombre minimum de clics ».

Les logiciels

Il faut un logiciel bittorrent sur le serveur qui héberge les images disque, mais aussi sur les postes des techniciens.

C’est Transmission qui a été choisi, parce que je le connais : il n’est pas graphique et a une interface web, il fonctionne bien (en tous cas à partir de la version 2), il est disponible en package pour la distribution Linux de nos serveurs, et surtout il fonctionne en mode démon.

Pour le logiciel client pour les techniciens, c’est uTorrent : il en existe une version portable qui permet donc de l’installer où l’on veut sans les droits administrateur du poste et il est configurable « off-line » avec un fichier de configuration. De fait uTorrent est configurable en déployant ce fichier de configuration via, par exemple, un package NSIS.

Pour le tracker, c’est bittorrent-tracker, du package bittorrent.

Les fichiers .torrent sont générés avec un script fait maison qui utilise mktorrent. Ils sont déposés dans l’arborescence du serveur web auquel les techniciens se connectent.

L’installation

Le plus complexe est la configuration de tout ça, ainsi que la colle qui va autour afin de fournir un ensemble robuste et facile à utiliser, autant pour les ops (ajouter de torrents, … ) que pour les utilisateurs (les techniciens) (télécharger les images… ) Transmission, disponible uniquement en version 1.34,  buggée datant de 2008, n’a pas facilité la tâche …

Une procédure indique aux techniciens comment installer uTorrent ainsi que les bases de son utilisation et quelques renseignements sur le protocole bittorrent : où sont téléchargés les fichiers, le fait qu’il faille laisser uTorrent lancé même si le téléchargement est arrivé, que signifie tel ou tel bouton…

Un package NSIS installe la configuration de uTorrent : démarrage en mode réduit avec l’ouverture de Windows, localisation de répertoire destination.

Et un script sur le serveur sert aux administrateurs à créer les torrents, les mettre dans Transmission et à disposition dans le serveur web.

Quelques coups de chignole dans le firewall afin d’ouvrir les ports adéquat et voici nos techniciens qui téléchargement maintenant les images iso par bittorrent.

Conclusion

Voici comment un protocole à la réputation sulfureuse a permis de libérer la LS de mon client et de, à un coût dérisoire, fournir un service robuste et de qualité à ses techniciens : l’un d’eux dit être passé de 160h de téléchargement pour les dernières images à … 24h.

9 commentaires pour “Déploiement : troquez FTP pour Bittorrent”

  1. Quid de la sécurité ? Si le torrent est malencontreusement rendu public, n’importe qui peut télécharger les images du client, qui contiennent peut-être pas mal d’information sur le moyen d’accéder au SI.

  2. Bonjour,
    La sécurité a été prise en compte. Il en a été conclu qu’un fichier .torrent ou un accès en ftp étaient aussi risqué l’un que l’autre.
    Et les images iso ne contiennent pas d’informations sensibles à ce point : après tout, ce qu’elle contient va se retrouver sur le poste du client final :)

  3. Par curiosité, pourquoi utiliser la version 1.34 de transmission? Un problème de version du serveur?

  4. Bonjour,
    Oui : c’était la seule dispo sous notre version de Redhat. Mettre à jour RedHat afin d’avoir une version plus récente « coûtait trop cher » en temps et en énergie par rapport aux bénéfices apportés (du point de vue de Transmission)

  5. Je me doutais bien que c’était pour une raison de ce type là. Pour ce qui est de la sécurité du torrent, on peut toujours imaginez rajouter une passkey au torrent, et limiter les IPs pouvant utilisés cette passkey, certains trackers de torrents privés fonctionnent comme ça.

  6. Marrant j’ai mis en place il y a quelques semaines une architecture de ce type dans ma boite :)
    Par contre j’ai utilisé rtorrent coté serveur (client console) pour seeder, bittornado pour générer automatiquement les .torrent, un script Ruby qui utilise la lib inotify pour appeller bittornado dès l’apparition d’un fichier à « torrenter ». Et utorrent coté client windows car il fonctionne en mode service. J’ai hésité avec l’excellent qbittorrent en Qt et donc multi-OS.

    De plus le script Ruby upload par ftp les .torrent qu’il a créé, vers les clients torrent, tout est donc automatisé.

  7. Pas mal! Je m’en souviendrai :)

  8. Comme que vous êtes une boite qui a compris l’intérêt de bittorrent en backend, et que vous utilisez également zeromq je pense que mon projet pourra vous intéresser. En effet je développe le backend de mon projet opensource nodecast.net et je souhaite rendre ce backend agnostique.

    Voici l’archi actuelle http://img856.imageshack.us/img856/6297/ncs.png son objectif sera de pouvoir traiter n’importe quel type de données envoyée par http ou xmpp. Ensuite à charge de développer sa logique métier dans des workers zeromq. Le backend apportera une tracabilité des flux, un monitoring des workers et une interface de gestion.

    Enfin je souhaite intégrer dans le client geekast une lib torrent ce qui permettra de déployer automatiquement en torrent des fichiers depuis ses workers vers ses clients ou serveurs.

  9. Bittorent viens de rendre dispo en beta public son service share : http://korben.info/share-torrent.html

    d’une facilité déconcertante… (mais pas encore parfait pour des besoins pro… on approche…)

Laissez un commentaire