Bit Torrent
-
It occurs to me that (with some work) you could use something like bit torrent to distribute images (as a poor mans alternative to multicast). Advantages are that blocks could come in in any order (so machines would not have to boot in lockstep), and all machines might contribute to uploading blocks so the network IO would be spread out over multiple machines (though the total network capacity is still the same).
Disadvantages are that the software becomes rather more complex and there would be no real boost to speed if machines tend to be imaged one at a time.
-
That would be cool.
One of the schools I worked for, had a program called LanDesk, and it would do p2p for deploying windows and also updates. They would have the main server, that gets the updates, then sends it to a few clients, then other clients would connect to those few clients and then it would just grow from there.
But we had a few problems, like one time we where deploying windows on every computer at a school, and one of the first computers, that got the information from the main server, got a corrupted copy, then sent it on the all of the other clients. We ended up having to redo everything again.
But that would be fixed if they just did a CRC check on all of the files. I think that is what the normal bit torrent does. -
Bit-torrent is generally a better solution than Multicast, simply because it’s easier to use and has greater flexibility.
There are some good python torrent clients available now.Is there anyone who can tell me how I could write a torrent client into the boot image so clients can receive their image over torrent?
I’m trying to image about 50 lab PC’s at once that are on the same vlan. -
the actual mechanism in init.gz using partimage would have no idea how to download using bittorent (it mounts the NFS, and uses partimage over it directly). If you want to use bittorrent, you need some space to save the image before dumping it to the disk… That’s a not trivial thing to do given how the process is done currently, I’m afraid
Though it would be awesome… Like… Let’s check the size of the image, let’s check if we have size_of_image_decompressed + size_of_image, deploy using bittorent on the extra space, dump the image, then remove the temp partition and extend the main one… Not trivial, but interesting
Also, it would probably be slower, as you need to write all the image twice… on the disk…
The upload process gets around it by splitting the image inside the RAM (and would thus be heavily faster on a 64 bits kernel) before sending the chunks out there, but bittorrent wouldn’t be able to do that (or you’d have to force the upload to be sequential, and find a way to dump the part of the file that is properly downloaded, but then that reduces the impact of bittorrent because everyone starts downloading the same part of the image file, rather than distributing randomly over the chunks…). -
(And if you have 50 PC in a VLAN, properly isolated, use multicast, that will be way faster… Even if your switch sees it as broadcast, it probably would work faster in anyway…)
-
I would like to get someone to look into this idea again. Using bittorrent instead of multicast has many advantages. First and formost, it is easy to move the traffic away from the server connection.
If you have some of the same challenges as I have, multicast traffic from the server to a set of clients will affect networking in a bad way, on all swicthes between the server and the clients. Using bittorrent, you can easily limit traffic from the server to a single tcp connection, and let the traffic between the clients go crazy instead. The clients I am working with are usually limited to a few switches at a time, with no other traffic while I am imaging, but the connection to the server in a different building might go through a number of switches that facilitate normal traffic as well.
The challenge will be to get sequentual downloading of the image files, which is not the standard bittorrent way. We have seen this done in quite a few applications related to videos, applications that play videos while downloading. En example to look into might be btcat from p2ptube, script [URL=‘http://p2ptube.sourceforge.net/btcat.py’]here[/URL]. I have not looked into how btcat can seed from it’s download, since the download is not going to a file, but perhaps some kind of buffer in memory?
I suggest using bittorrent only for deployment, not for uploading. It could just be an addition to current deployment methods, having the fog server running a tracker and a seeder. The seeder should have the option to limit the number of connections. An optional seeding delay on the clients after finishing download could also improve the result.
I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.
-
You could setup BittorrentSync to distribute your images to your storage nodes…
but as for writing an image entirely over bittorrent… would probably be a big rewrite.
-
i didn’t realize this thread existed, but i’ve been working on this feature.
[quote=“Bjorn Jentoft, post: 35888, member: 587”]
I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.[/quote]if you had shared this, you could have saved me some work. lol
-
There’s a FOG alternative developed by some people from spanish universities that support BitTorrent for cloning. It’s called OpenGnsys ([url]http://www.opengnsys.es[/url]).
I’ve tried it a couple times, but the client side interface doesn’t catch me at all.
-
for anyone interested, torrent-casting is now functional in the current svn, but it does require a few steps to be done manually at the moment. if anyone is interested in trying it out, i can walk them through it.
-
is this the server distributing it to clients primarily or do the clients play a big part in distributing to each other now?
-
It starts with the server or wherever you first start seeding from. At tasking time, the clients download the image to a partition. Once its downloaded it is peered out as expected. The more download tasks the more peers there are.
-
Are you thinking this could replace multicast? (which has had a ton of problems)
Or possibly become the main method of distributing images?Can the clients peer the parts of the image they have already in chunks or does it need the whole image to download to become a peer?
Is there a configurable time after the image finishes downloading on that machine that the client reboots to allow getting into the new OS, so people could have 5 minutes peering to speed up others and then reboot?
Is there a tracker/torrent file that could be added to other torrent clients? easy setup storage node…
-
[quote=“VincentJ, post: 36284, member: 8935”]Are you thinking this could replace multicast? (which has had a ton of problems)
Or possibly become the main method of distributing images?[/quote]
i’m thinking of this being an alternative to multicast, but so far as i know there isn’t any intention to drop multicast support
this method won’t become the “main” method of imaging for a few reasons, one of them being that it isn’t as fast as unicast if you have hardware that can keep up (server, network, and client)i don’t even know if it’s faster then multicast (since i’ve never gotten multicast to work, or tried very hard to do so)
[quote]Can the clients peer the parts of the image they have already in chunks or does it need the whole image to download to become a peer?[/quote]
as per a normal bittorrent download, the file is split into small “chunks” for transfer, and all clients that have downloaded a chunk can share it with others as soon as they get it
[quote]Is there a configurable time after the image finishes downloading on that machine that the client reboots to allow getting into the new OS, so people could have 5 minutes peering to speed up others and then reboot?[/quote]a client continues to share the image while the computer is using, it only stops sharing when the computer is done imaging, so all clients should have a reasonable amount of time to finish downloading before clients stop sharing
[quote]Is there a tracker/torrent file that could be added to other torrent clients? easy setup storage node…[/quote]
yes, that is part of the intention. it is compatible with any standard bittorrent client, qbittorrent has been working best for me, for windows -
for those interested, torrent-casting is not functional in the current SVN
changes have been made to the way that fog handles partition structure and other elements of imaging. these changes will be transparent to the end user, but greatly increase the overall capabilities and compatibility of fog. these changes did, however, undo much of the work done toward torrent-casting. while i plan on working to re-implement torrent-casting, i felt i should inform everyone that it could be a while before this feature is brought back. -
It’s alright, you can blame me.
-
[quote=“Tom Elliott, post: 39160, member: 7271”]It’s alright, you can blame me.[/quote]
Improving the core functionality of fog is more important then retaining compatibility with a new experimental feature. So, ok, i blame you for improving the core functionality of fog.
-
Any chance of torrent cast working anytime soon I just deployed 400+ images this weekend and could have really used it.
-
@Joseph-Hales i hope to resurrect the method, but it’s going to be more complicated than the last implementation. i’m up for the challenge, it’s just hard finding the time.
-
You go, /u/Junkhacker! I would love to have bit torrent sync, so long as it allows me to lower my overall deployment time when doing 6+ clients.
I can’t use multicast because that hurts our network in a VERY bad way (all network traffic basically halts), so I use 5 concurrent single casts typically to about 30 computers at a batch.
Thus, whatever you do, my deplying to 6-10 clients takes about 2x as long as 1 client does. If the torrent send can reduce that number for 6+ to 1.5x of 1-5 clients, then I would be extremely happy and would find great benefit for my company.
If it works as good as possible, I would expect total deployment time for 30 clients to be like 15-20% of what it currently is.
