eoli3n a écrit 27 commentaires

Les machines s’échangent des parts entre elles pendant qu'elles téléchargent d'autres parts. Comme les machines doivent continuer leur processus de déploiement, il ne sert à rien qu'elles continuent d’émettre après avoir récupérer l’intégralité de l'archive… si ce n'est, perdre du temps.

En ce qui concerne le nombre de primo seeder, c'est un prérequis au fonctionnement optimal du système, n'as tu jamais vu de torrent avec 10000 peers bloqués à 98% ?
Bien que tous les clients discutent entre eux, le processus global est limité par la vitesse d’émission du primo-seeder, d'où la nécessité de multiplier les seeds possédant toutes les parts du fichier pour "ouvrir les robinets au maximum".

Tout est exclusivement "développé" en une somme de scripts bash sur mesure (table de partition, montages, partitions à restaurer, outils de compression, etc…).

Je voulais dire par là que ce n'est pas encore dynamique, pour le moment, j'indique les partitions à traiter en dur dans le fichier. Par la suite ce sera via le fichier de configuration en yaml que j'ai mis dans mon premier post

Quand je parle de formatage, je parle de monter la partition et de rm -Rf *
mkfs ne supprime pas les données, et restaurer une table de partition par dessus une ancienne identique revient à ne rien faire.

Non.

1° parce que d'après mes tests, pour 800 machines à 1Gbps, les performances sont optimales à partir de 6 primo-seeders (seeders qui ont toutes les parts du fichier). Ca ne sert donc à rien d’encombrer le réseau avec 800 seeders qui parlent sans cesse avec le tracker.

2° parce que si je déploie une nouvelle image, je dois la déployer partout, en une fois, donc les seeders en question devront eux aussi rebooter pour se redeployer = les primo-seeders doivent être des serveurs à part.

Grossièrement :

Je lance le tracker de murder sur mon serveur.

Sur une machine source, je crée un archive tar.xz contenant tout le système, je dump la table de partition avec sfdisk, puis le fichier .torrent associé à l'archive est généré, stocké via NFS.

J'ai un serveur PXE avec un nfsroot (debootstrap de debian 8)
Un script me permet de creer les fichiers de boot pxe par machine, s'appuyant sur mon fichier hosts d'ansible, je peux donc pointer des groupes de machine facilement.

Le fichier de boot pxe generé, passe en paramètre du kernel le nom de l'image à déployer, et d'autres variables.

Quand la machine cliente boot pxe, un service parse les options du kernel, puis un autre lance le script de déploiement sur tty1.

Le script restore le dump de la table de partition, monte les partitions locales, formate proprement tout ca, lance un client bittorrent pour récupérer l'archive, décompresse où il faut, puis réinstalle le bootloader.
Un webservice sur le serveur attend une requête du client lui disant qu'il a terminé le déploiement, pour pouvoir supprimer son fichier de boot pxe.

Je pensais à une license MIT, hebergé sur github et readthedocs.io

http://sourceforge.net/projects/xcpu/files/XCPU/1.2.3/
le tar est là
Installation
Extract the XCPU tarball and use the target xget for make to build and install xget.

make xget

Merci ! Je regarde

J'apprecie l'intention, mais si tu voulais vraiment m'aider, tu testerais de ton côté pour valider le fonctionnement, et tu me dirais comment tu as fais ?

Quand on lance le binaire xget sans options :
root@xub64:~/xcpu/xcpu-1.2.3/xget# ./xget
usage as the master server: ./xget [-D debuglevel] [-p port] [-o] [-x] [-m] file|directory
usage as a client : ./xget [-D debuglevel] [-p port] <-n netaddr> [-s] [-o] [src file | src dir] … dest

Donc non.

"cela suppose donc que tes machines vont recevoir la mise à jour, et devenir source pour les machines qui vont demarrer plus tard.
cela impose donc que les machines du premier lot contiennent aussi le master pour les machines similaires du second lot…"

En quoi ce ne serait pas le cas dans le fonctionnement que je decris ?

Premiers tests pas concluants du tout.

Pas de problème à la compilation, il me manquait juste libelf-dev.

Sur une même machine :
./xget ./test
puis
./xget -n 127.0.0.1 . ./dest
j'obtiens
Could not connect to server

Je me suis dis, sait on jamais qu'une machine ne pouvait pas être master et cliente.

Même manip sur 2 machines differentes sur un même réseau local, ni pare feu ni rien, pareil :/

Je ne vais pas recetter l'installation de 500 paquets et plein de confs tordus, quand je peux synchroniser niveau fichier. Et j'ai une image unique sur les 800 postes de configs materielles differentes, donc pas de soucis à ce niveau là.

Ah ben elle y est la doc là. A voir si je ne m'en sors pas avec bokor, ou s'il y a trop à adapter.

Parce qu'en soit si xget permet de diffuser de pair à pair un dossier sans tracker ni client autre que lui même, ca pourrait etre la soluce bien plus simple, je remplace juste mon rsync par xget et zou

"The Bittorrent protocol was created for the purpose of
transferring multi-media files over the Internet. Due to
its scalable properties, it is also being used for trans-
ferring files over LANs. Bittorrent and XGet are quite
similar; they both create a peer-to-peer network and
generate an ad-hoc tree. Bittorrent usually requires at
least three items in order to transfer files: a torrent file,
the tracker, and the client. To use Bittorrent, one needs
to first create a metainfo file (or .torrent file) that in-
cludes: the tracker’s URL, file size, suggested file name,
and other data about the file(s) being shared [16]. Next,
a tracker needs to be started before any of the clients
can begin transferring data. The tracker is a lightweight
server that provides routing information to each of the
clients in the network. After the tracker is running, a
client with a completed version of the file(s) being served
needs to start. This client then “seeds” the file(s) for
the other clients. Once other clients have started, they
connect to the tracker, which redirects them to the ap-
propriate client to download from. The main differences
between Bittorrent and XGet are: XGet does not require
clients to load small files informing them of the files be-
ing transferred, and Bittorrent clients receive portions
of files from many clients, rather than being assigned to
a single secondary server as in XGet."

Ca me semble même plus adapté que bittorrent… je test ca demain

C'est ca l'idée, mais pour le côté à chaud, j'y crois. Si des binaires sont en cours d'execution, ils sont chargés en memoire, c'est ce qu'il se passe quand tu mets un paquet en cours d'utilisation à jour donc pas de soucis à priori.

Et pour le reste oui c'est ca, c'est d'ailleurs deja en prod avec le rsync pour la simple synchro des machines, c'est comme ca que je deploie des confs et des applis, bien que je ne rsync pas l'integralité de l'arborescence.

Et 800 rsync sur une même source, comparé à bittorrent, tu vois quoi ;)

Si, c'est ce que j'ai indiqué dans le schema de mon premier post.
Mais il serait plus flexible de pouvoir se passer d'une archive ou d'un dossier temporaire, depouvoir ecraser directement les données modifiés à la facon d'un rsync. Je ne pense pas que ce sera gerable ici, à voir.

Ici l'interêt serait de pouvoir detaré à chaud sur une machine en utilisation, c'est de ca dont je suis moins sûr.

root@xub64:/tmp# tar zcvf image.tar.gz / --exclude='/dev' --exclude='/proc' --exclude='/sys' --exclude='/tmp' --exclude='/run' --exclude='/mnt' --exclude='/media' --exclude='/lost+found' --exclude='/net' --exclude='/usr' --exclude='/auto_home' --exclude='/cdrom'

root@xub64:/tmp# du -hs image.tar.gz
2,5G image.tar.gz

ah ! Plus de 50% moins lourd que l'archive clonezilla, je test une decompression sur / d'une autre machine à chaud demain ! (j'exclude /usr et /net parce qu'ils ont une particularité sur notre systeme)

On en parle juste un peu au dessus ;)

Ben le problème c'est que j'ai pour le moment 10Go de libre, mais ca risque d'evoluer, j'aimerais eviter de passer par une archive ou un dossier temporaire.

Après ca risque d'être chiant si j'utilise pas l'un de ces 2 fonctionnements.
Bittorrent ne gère pas les droits, donc si je mets à jour une machine à chaud, il faudrait repasser un script pour restaurer les droits. J'risque figer la machine si j'ecrase directement les fichiers existants via bitorrent, qui n'auront temporairement pas de droits… avant même de pouvoir lancer le script.

Dans la conf, tu dis que deployer des petits fichiers par bittorrent a un gros cout en ressource, le problème c'est qu'un systeme complet n'est composé quasiment que de ca.

Aux dernieres nouvelles FOG etait axé Windows, gestion de Linux en beta seulement.
Et puis ca repond uniquement à la problématique de deploiement complet, pas de la maj de l'arborescence via un master.
Mais merci ;)

Je regarde la conf, ca a l'air d'être parfaitement ce que je recherche.

Super ca, je regarde, merci !

https://github.com/bearstech/bokor

• Je voudrais un fonctionnement torrent type Rsync, comme le font Syncthing ou Bittorrent-sync, et à ce compte là, je deploie que le diff, et pas tout le systeme. (voir mon shema plus haut, et les lignes "paquets X Y Z")

• Et donc oui parce que les machines ne chargent pas TOUT le systeme à chaque démarrage. Juste le diff (3mo par exemple pour un paquet quelconque), et juste une fois (la synchro suivante après l'installation sur le poste master).

De toute facon, je n'ai pas l'infra pour faire en sorte d'offrir une qualité de service satisfaisante avec un LTSP.

Je vais explorer cette piste là, ca devrait t'en dire plus sur ce que je vise :
Murder, outils utilisé par twitter : https://vimeo.com/11280885

La partition linux fait 30Go dont 20 d'utilisé. Même si elle est compressée (pour exemple clonezilla compressse l'image pour un fichier de 6Go), ca fait quand même bien lourd à demarrer. Pas une bonne solution.
Et imagines une coupure de courant, tous les postes se relancent d'un coup, ne serait-ce que toute une salle :

6Go x 24 postes, moi qui voulait economiser de la bande passante, pas top