Imaging computers at 2.6Gbps
-
@Bob-Henderson That’s a really good idea. Gives me ideas for audio/video stuff that gets plugged in wrong every time they wax the floors…
-
@Obi-Jon Thats how it started with us too. Labels didn’t work, cuz who can asked to read something written in big letters on each end…
So we stock 10 colors now, and they all have a reason for them. We have a sign made up for the colors, and posted it in every room laminated.
-
From my experience:
Your FOG machine doesn’t need to be that fancy to accomplish this. It will be useful for concurrency and what not, of course, but I’ve had similar results with a 2nd generation i5, 6GB RAM, 500GB HDD (!!!) and 1gbps link
The key to fast imaging is primarily down to the target device (assuming your imaging 1 device of course). Modern multi-core CPUs tend and faster storage solutions tend to get deployed to quite a bit faster.
-
@Quazz Yes, the target device does appear to be the deciding factor for deployment speed when imaging 1 device. That said, my old FOG box was running 0.32 (didn’t upgrade it due to some customization I had made to it) and was WAY slower than this, even with the same clients. The server was no slouch, even for 5 year old hardware, but the newer versions of FOG (partclone, etc) are making a big different too.
From now on I think the bottleneck (if you can call it that) will be endpoint network bandwidth. We’re pretty much saturating 1Gbps links as this test shows, so going concurrent with 10Gbps link at the server is the next logical step. For me, 10Gbps is overkill since I have mostly 100Mbps endpoints with 1Gbps uplinks, but as I upgrade endpoint switches client speeds will improve a lot. Heck, with 100Mbps endpoints and SSD on the server I am thinking I can saturate 50-100 clients simultaneously at 100Mbps each. Can’t wait to try it.
-
@Bob-Henderson My color scheme for network cables has been based on length (5’ = white, 7’ blue, 10’ pink, 14’ yellow, etc). Maintenance disconnects everything every summer, waxes the floors or shampoos the carpets, then hooks everything up again, so the different colors on each row of computers is useful for figuring out which cables go where. Not sure I can do away with that for network cables, but I’ll definitely incorporate your idea for everything else.
Good idea to post laminated signs too.
-
Ah, yeah, I remember that game. We ended up doing a disconnect/reconnect system myself, to alleviate the issues.
good thing there are more colors available, huh?
-
@Obi-Jon @Junkhacker it would be interesting to see the speed difference using our new fog 2.0 transfer protocols / techniques when it’s more ready for testing. Generally speaking our new approach we’re working on is far more stable in transit (less packet loss), and capable of a much higher throughput / network efficiency.
-
@Joe-Schmitt Any documentation or such available for this? I’m curious about how you’re doing it from a technical perspective.
-
@Bob-Henderson there’s really 2 factors going into it (keep in mind this is a very simplified / high level overview of what we’re doing). First is the removal of NFS (it’s still an image storage option if you want, but not how FOS reads the images now). The server is now the one responsible for streaming an image to the client, this means we can use protocols such as http/2 streams, SPDY, on-the-fly packet compression, so on.
Secondly is making the server and client more intelligent (giving it a basic ai of sorts). FOS will basically be running a custom build of the linux FOG client to give us access to our existing framework, and real-time server communication. This means the server / client can automatically take care of throttling on congested networks and on-the-fly transferring which server (assuming you have a multi server setup) FOS is receiving the image from incase of high workload, or if a more optimal server frees up.
TL;DR By making FOS smarter, and upgrading our transport protocols.
-
@Joe-Schmitt Just dropping from NFS over to HTTP/SPDY/etc is huge.