Bonsoir,
 
J'ai eu une idée, probablement farfelue, mais on "ne sait jamais".
 
Partons d'un constat "simple" : il est relativement facile de se créer son serveur miroir local pour sa/ses distribs favorites (exemple avec Debian/RSync).
Pour du versionning, l'ajout d'un CVS par dessus n'est pas forcément intéressante... sauf si on procède à du développement (FAI l'utilise par exemple pour l'installation), et que l'on cherche à avoir un retour le plus rapidement possible en cas de soucis avec une version sans devoir relancer un RSync sur le miroir maître pour ensuite remettre la version "kimarchebien" sur le poste client. Pour mon cas, un simple en "ajout seulement", soit l'équivalent d'une backup incrémentielle, me suffit.
 
Miroir maître ?
Ben oui, quand vous allez mettre à jour sur Internet, vous avez l'accès à un miroir "fils", lui-même allant chercher ses paquets sur un miroir de plus haut niveau, lui-même sur un autre,... donc une bonne grosse pyramide.
 
Mon soucis :
Imaginons j'ai 150 serveurs dispersé dans toute la France + Dom-Tom, qui me servent de firewall (ligne ADSL ou SDSL suivant l'endroit), VPN (transparent pour l'utilisateur), serveur proxy, et... miroir pour la redistribution locale (sur le même serveur (dual xeon avec 4Go de RAM par xeon et 2 SAS en RAID 1, ça se tourne largement les pouces même). 149 serveurs tapent actuellement tous sur le même pour mettre à jour les paquets à redistribuer.
J'y ajoute mon versionning. Jusque là ok, pas de soucis, mes ajouts de nouveaux paquets se font sans soucis. Cela fait bizarre d'avoir du OpenOffice ou Firefox en 3-4 versions différentes mais "au cas où" ça marche.
 
Il ne me manque plus que ma redistribution par torrent.
Torrent ? Oula mais c'est pas légal ça mon gars, les modos vont fermer !
On se calme, on lit la suite : j'ai donc mes x versions différentes qui sont (pour le moment) mises à jour et ajouté en allant chercher sur mon miroir maître, pendant que dans certaines filiales j'ai d'autres serveurs qui se tournent les pouces (exemples : nuit en Dom-Tom, journée en métropole ; vacances scolaires suivant les académies ; etc ). Résultat : mon miroir maître tourne quasiment H24 rien que pour ça, et donc ne peut servir pour autre chose (ce que font les 149 autres)
 
Pour la répartition des mises à jour des paquets, la technologie du torrent me semble pas trop mal (une limite de charge d'upload, genre 30ko/s, et en download 300ko/s -> pouf je vois sur 10 serveurs qui se "tournent les pouces" sans pour autant pourrir le reste), même si là il me faudrait un tracker interne au réseau (PHPBTTracker ? TorrentFlux ?), lui-même à répliquer (prise de tête en perspective )
 
Est-il possible de faire de ces miroirs "fils" mais à jour et qui se tournent les pouces des miroirs maîtres temporairement (pouf plus à jour, ils redeviennent de simples miroirs), automatiquement, et qui par dessus le marché se répartirait "équitablement" la charge des mises à jour des miroirs ?
 
Dernière précision : j'ai utilisé l'image de la pyramide au début, oui mais là je ne souhaite pas avoir à utiliser un tel système : un serveur intermédiaire tombe en rade, ceux en dessous ne peuvent se mettre à jour.

j'ai pas tout compris à ton truc.
Mais j'utilise moi-même bittorrent pour la diffusion en environnement professionnel, sans soucis ( j'utilise rivettracker sur HPUX  et un client ctorrent sous linux - 600 clients ).
Dans chaque fichier .torrent, tu peux mettre l'url de ton tracker et d'un tracker secondaire.

Pour faire plus court : je voudrais remplacer RSync par un système bittorrent, afin d'avoir au fur et à mesure des mises à jour de plus en plus de sources de mises à jour

ok ok ...
En fait , bittorrent est tres adapté à l'envoi de peu de fichiers vers beaucoup de clients, c'est comme ça que je l'utilise ...
En fait, pour chaque fichier, il faut générer le "hash" correspondant, au suffixe .torrent et le déclarer sur le tracker ...  
Si tu synchronises une arborescences avec beaucoup de trucs, ca va être difficile.
 
Moi, j'aurais fait un cron qui interroge une page php, la réponse contenant les paramètres et les taches à effectuer. Derrière, ce serait encore du rsync ... Faudrait coupler avec un limiteur de débit , je n'ai plus le nom d'un produit en tete ...

Quand je regarde les mises à jour c'est toujours très light
 

Aie, c'est ce que je craignais.

Pour limiter le débit j'ai vaguement vu ça, mais à remettre au goût du jour... notamment si dispo sur Debian ou non (et wondershapper ne m'a pas l'air propre propre, n'hésitant pas à faire faire des attentes sur des paquets "non prioritaires" )
 
Mais là je ne me limiterais qu'à une seule source, chose que je voudrais éviter  
 
Dans quel cadre utilises-tu bittorrent ? (mises à jour de données ? télédéploiement de logiciels ?)

Pour limiter le débit, j'avais trouvé trickle:
http://www.tuxradar.com/content/co [...] th-trickle
 
Pour ma part, je diffuse en général des gros packages Oracle ( noyau de BDD ou serveur d'appli ): jusqu'à 2Go vers 600 machines partout en france et dans les DOMs.
J'amorce avec une source à Paris, puis le truc vit tout seul ... J'ai un seul tracker sur Paris.
 
Pour remplacer ça (bittorrent a mauvaise presse...), j'avais pensé à faire un arbre de diffusion et utiliser zsync , ou alors utiliser un système de cache distribué.

Oui bittorrent à mauvaise presse, mais bon
 
ZSync je ne connaissais pas, et semble intéressant :

(source : http://zsync.moria.org.uk/ )
A voir si justement rien que cela n'améliorerait pas un peu les choses.
N'étant pas le décideur, je ne peux que "proposer", néanmoins l'idée d'une redistribution par bittorrent est donc à exclure ?
 
Le système de cache distribué par contre c'est lourd du point de vue sauvegarde non ? Mais cela semble bien adapté à des BDD.

Pour bittorrent, la création des fichiers .torrent est scriptable ( buildtorrent en ligne de commande ), et probablement l'inscription sur le tracker, puisque c'est du php .
Mais, bon, il vaudrait mieux bosser avec des "patches" , c'est à dire un gros fichiers (tar ou autre) qui modifie toute ton arborescence d'un coup, là c'est jouable, d'autant que tu disposes de la possibilité d'exécuter une action en fin de téléchargement avec des clients comme ctorrent (j'ai récupéré, je patche ... ).
Faire dans la dentelle, ce sera difficile.
 
Pour le cache distribué, j'avais trouvé un projet intéressant qui m'avais donné cette idée. J'essaierai de retrouver ça.

https://github.com/lg/murder
 
c'est ce qu'utilise facebook pour ses déploiements.

Merci black_lord donc ça c'est ce qu'ils utilisent pour faire du déploiement, et donc pour faire de la mise à jour (version Ruby) :
- avec un cron je fais un diff pour savoir quels fichiers ont été mis à jour
- je crée un torrent pour ces fichiers
- je distribue le torrent à tous les clients*
- dès qu'un serveur à fini il devient seed
 
Pas mal, bonne idée, mais je vois qu'ils utilisent Ruby pour cela* (Capistrano). Or d'après ce que j'ai vu sur les serveurs actuellement déployé "chez moi", on peut mettre du python sans soucis mais du Ruby en plus il faut voir
 
J'ai réfléchi un peu et ce que cela donnerait sans avoir besoin de Ruby par dessus:
- avec un cron je fais un diff pour savoir quels fichiers ont été mis à jour
- je crée un torrent (avec un nom "alacon" update_aaaa_mm_jj_hhmm_crcenhexa.torrent) pour ces fichiers, je le met sur un serveur qui va le distribuer après (et qui aura le tracker en même temps)
- tous les clients via un cron (différent de 1 minute par serveur pour un lancement différé du download) vont chercher le torrent sur le serveur du tracker (un wget basique)
- mes clients lancent leur torrent fraîchement reçu
- dès qu'un client à fini il devient seed
Au besoin, par un 2ème cron (mensuel ou hebdomadaire) un script supprime éventuellement les versions trop anciennes ou instables des paquets (un torrent qui contient la liste des fichiers à supprimer ?)
 
En cas d'ajout d'un 151ème serveur : je wget tous les torrent présents sur le serveur du tracker, les versions trop anciennes ou instables ne seront pas trouvable donc j'ai que du stable (pas très propre, donc à voir )

 
les crons c'est laid pour cet usage... regarde pour un système d'orchestration de masse qui te permettra de signaler à tes serveurs qu'un update est dispo. charge à toi de t'assurer que tous les downloades ne se lancent pas en même temps (un sleep random doit le faire).

C'est lait, mais avec du thé ça passe  
 
Hmm, OCS Inventory en déploiement par exemple ? Mouais, à voir par dessus quoi mais c'est vrai que les updates ne se font pas tous les jours, donc ça pourrait être intéressant pour alléger la charge réseau (rien à télécharger mais torrent déployé quand même) et le nombre de torrent à créer et à maintenir.
 
Comme je n'ai qu'un seul serveur NTP, tous les serveurs ont normalement une différence minime (tous en UTC avec une dizaine de secondes au plus entre Paris et Tahiti, qui dit mieux ?), donc la minute sera mieux que le sleep_random. Mais à garder sous le coude