How to make deployment quicker with Windows 7 and fog
-
ok question here regarding one upload/download of a image. I have tested one image that is 35gbs of space used on a 60gb hdd and to upload this one image takes 15mins and compresses to 24gbs in the fog /images directory, to download or deploy the same image back to the workstation takes 10 mins flat. so based on the images’ times of upload/download if i had 8 identical workstations to deploy wouldnt that mean it would take 1 Hour and 20 mins to deploy one at a time back to back…what about all in a multicast, would that take longer or shorter then 1hour and 20 mins?
-
It should be shorter but I’ve never had any luck with multicast. If you set all jobs as unicast it should be about 15 to 20 minutes flat for all 10. They will all image at the same time even on unicast.
-
and unicast is kicking off a task for one deploy one after another so i have 8 different deploys? or task one deploy one image then once thats complete perform another?
-
There are many ways you can do this. Yes, you can task all jobs individually. Or, you can create a grouping of the host, and that group, when you apply the host, will create all the tasks individually, but from one location for you. Or you can do the multicast thing.
Your system management queue is telling you how many systems are imaging at the same time. Once that limit is hit, then systems after that number are in queue until a slot opens up.
This means, you can (Unicast) create a task for 10 systems (usually 10 is the default) even if they’re all different image ID’s. Turn all of those systems on at the same time and they’ll all starting imaging. Anything more than 10, (lets just say you have 15 systems) the extra 5 will wait in turn for there turn to image.
The reason, I think, this is faster is because the decompression is being done by the clients (the ones receiving the image) where in multicast, it’s all done on the server before getting to the client.
In review, in multicast deployment, the server is not only imaging all of the clients, hosting the database and the GUI, but it’s also performing the additional task of decompressing the image and sending it to the clients. In unicast, the clients are doing the majority of the leg work.
Lets try to put that in perspective. Multicast, ultimately should theoretically be faster because it only has to decompress the image once, but it also requires that all clients receiving the image are getting the data and placing it on the drive at the same time. They have to continuously sync themselves with what the server is doing (or vice versa) so everything is on the same page. It may initially start out faster because the server doesn’t have any issue starting off. However, as time drags on, the systems may not be all in sync, so the server has to wait until all systems are matched up.
Theoretically, unicast should be slower because each client creates a link to the server. It’s not slowing the server down though, but timewise it would be slightly slower because it’s up to the client’s to do the work. However, it doesn’t have any requirement to keep all in the same sync frame so, the client is free of waiting for other machines.
-
Sometimes, you can’t use multicast (cheap switches, mixed environment…). But you can make unicast faster, especially if the server’s disks are faster than the clients, and that it has shitloads of RAM. If you deploy a 16 GB image, and you have 16 GB of RAM, chances are that if the tasks starts simultaneously, they will hit the cache on the server, thus they will be only limited by their own disk speed. Which usually goes slower than 1 Gbps. So you can get 2-3 hosts to be deployed at once, and still be faster than 1:1
-
thanks for info you guys, thats one thing I didnt bother to try was doing a unicast of 8 seperate deploy tasks…I deployed one image which took 20 mins so i went full boar and tried 8 in a multicast and got stuck with 9 hours to deploy…so when i go back to site im going to have a 8-port 1Gb switch and plug the stations into that directly and try the unicast method to see how the times change.
-
Faster server disk subsystem usually equals faster unicast deployment to multiple clients. I use an old Dell server that has 5 disks in RAID5 array. I can image 15 clients at about 3GB per minute per client, or I can image over 30 tablets that only have 100Mbps interfaces, and get about 900 MiB per minute per client.
When I was using an old desktop with a single 7200 RPM SATA drive it in, imaging more than 2 clients at a time slowed everything down due to the non sequential disk read requests. RAID5 makes it better, as does a RAID controller with built in cache.
-
[quote=“chad-bisd, post: 19665, member: 18”]Faster server disk subsystem usually equals faster unicast deployment to multiple clients. I use an old Dell server that has 5 disks in RAID5 array. I can image 15 clients at about 3GB per minute per client, or I can image over 30 tablets that only have 100Mbps interfaces, and get about 900 MiB per minute per client.
When I was using an old desktop with a single 7200 RPM SATA drive it in, imaging more than 2 clients at a time slowed everything down due to the non sequential disk read requests. RAID5 makes it better, as does a RAID controller with built in cache.[/quote]
Confirmed!!!
I have a FOG machine built out of some old hardware, I used a 7200 rpm disk in them. It images at a decent speed, I wouldn’t say it is slow, it is QUITE the improvement over our WDS choice.
I got a hold of a e-Server IBM machine with RAID5 10K rpm disks. I installed my ubuntu of choice and fog 0.33b and this sucker FLIES compared to my 0.32 server. I’ve also tried installing the Fog 0.32 on this server and it seems it is the hardware that has made the major improvement.
I had some trouble initially setting up the IBM eServer because of the raid control it uses, but once I removed the PCI card, things went swimmingly, not to divert too far from the subject here but I am still working to try to get the PCI card to work incase it has some kind of caching abilities. This use to be a Novell Netware server (which to my understanding is a Linux OS), so I am not sure what I need to do to get the sucker to work right but I’m not giving up yet!
-
Ok heres my update as to why I had terrible speeds trying to deploy a multicast to 8 workstations. It was because my mobile fog server was plugged into a 8-port 1Gb port switch…which eventually was uplinked to a VOIP phone (100mb) which in return the voip phone was the uplink to the rest of the network…so my fog deployments were severely bottleneck because my fog server was eventually squeezing thru 100mb pipe…by temporarily bypassing the voip uplink and plugging in the 8-port switch to the real network im happily able to say i successfully deployed 8 Windows 7 workstations thru muliticast at 590mb/min which took 52 minutes tops! then i had to image one 6200 and that took 6 mins at 3.39Gb/min.
-
This post is deleted!
