How long should it take to deploy and image on average?

  • I just got back from MDT and due to some unforeseen circumstances I now have to use FOG again. Last time I used it was about 2003 2005 ish not sure but its been a while. I had to set up everything and kind of relearn FOG in a way since the GUI changed (currently using 1.5.9-RC2) a lot from when I started using it. I do remember it being really quick to deploy images to PCs so that’s why I thought about using it again.

    What is happening is that it is taking very long to deploy my images. On the Old FOG, I remember deploying to 30pc would take about 45 min to a 1 hr or 1 1/2 hr for a 60GB image over a 1GB network with several HOPS.

    Now for 12 PCs, it tasks about 4hrs with fewer HOPS

    I don’t know what I am doing wrong with this new FOG setup. I notice in the forums that there is a new compression used but don’t quite understand the use of it. I did notice a table with the compression and decompression speeds but not sure if I am doing the process correctly.

    I have tried capturing a new image (about 60GB) with Partclone Zstd 6 and 11 but all I get is a fast capture time (about 10 to 14 min I think maybe because its only one PC to capture) but when I deploy it takes about 4 hrs on average for 12 PCs. All the PCs are exactly the same all are connected to a cisco Gig network switch the FOG server has 2 storage nodes (total of 3 including the master FOG) set to the default of 10 connections/pcs all FOGs are Virtual on VMWare Vcenter on a Cisco Mini UCS system

    What I am looking for is a faster deployment. I don’t mind the capture time since usually its only 1 PC. The decompression on the client systems should be okay since its mostly newer hardware PCs like SSDs and Multithreading CPUs with 4 to 8 GB ram on them.

    Any suggestions or tips are very welcome.

    Do not want to go back to MDT

    Thanks in advance

  • Moderator

    @vemoya Well 3 GB/s is on the bottom edge of acceptable (in my book). There may be some tuning needed to do in your infrastructure. Its not horrible just a bit slower than expected.

    Just be aware with 3 ongoing unicast images you will saturate a 1 GbE link (125MB/s or 7.5GB/min theoretical max) This isn’t a fog issue specifically but a limitation of 1GbE ethernet. You can supplement this by adding additional network cards in your FOG server and then creating LAG links between your network switch and the FOG server. Even if you create these LAG links between the FOG server and switch, if your switch to switch links are 1GbE links that will become your next bottleneck. Again this isn’t a FOG issue, but a byproduct of using a FAST imaging solution. Also if you are imaging more than 2 computers at a time, its best to have an SSD or RAID array in your FOG server and not try to serve multiple unicast streams with a single spindle HDD. That single HDD will not be able to feed the data fast enough to the network adapter.

    You mentioned multicasts. This is a great solution to push out one image to many computers, but it also has its drawbacks. You need to ensure your network is capable of multicast imaging (again not a fog issue). If your target computers are on the same subnet as the FOG server that is the easiest solution. You just need to turn on IGMP Snooping on your network switches and then multicast away. Just remember the slowest computer in your multicast group sets the pace for the group. But if properly setup you can multicast 30 computers in about the time it takes to image 2 computers (serially) using unicast imaging.

  • @george1421 Thanks for the reply when I do 1 capture and 1 deployment the average time for 60GB of data used on a 512 SSD is about 12 min for Capture and 16 min for deployment. The speed is usually around 3 to 5 GB/min. The issue is when I keep adding more. The more I add the more time it takes and the speed goes from GB to MB sometimes less than 100MB/min. @Tom-Elliott suggested I try deploying with multicast so I will give that a try and see if that makes it faster.

    Thanks for the reply

  • Moderator

    @vemoya What are the reading when you deploy 1 unicast image to a target computer. What is the value of GB/min that partclone says after 2 minutes of downloading? Lets start with some benchmarks. This test deployment should be to a contemporary computer over a 1GbE network.

    So your size on the target computer is 60GB before compression?

    For zstd set your compression to 11 to start out when you capture. Compression only has an impact when you capture an image. For deployment its just decompressing what ever was compressed. So the compression setting is not used.

    On a well managed 1 GbE network with a modern target computer and FOG server you should get about 6.1GB/min for a single unicast image.

  • @Sebastian-Roth said in How long should it take to deploy and image on average?:

    connect one of your PCs

    Thanks for the reply. This is how I am doing it:

    once the image capture is complete, I then boot the client computers to PXE and on the PXE FOG menu I select deploy image type in the username and password and then select the image to deploy (is this the Unicast way?) I do this for all 12 PCs

    If I am doing 1 PC it goes pretty quick like 16 min the issue is when I keep adding more. The estimated time increases and the rate goes down like a lot from 3 Gb into the 100Mb or less than that.

    Is this normal? What should I look out for?

    Thanks for the help

  • Moderator

    @vemoya Do you use unicast or multicast deployment?

    In most cases slowness is not due to FOG being slow but a bottleneck slowing things down. On a well managed network you should be able to push out a 60 GB image in way less than 4 hours!

    So let’s get into testing and rule out certain things:

    1. let’s make sure it is not FOG itself (for whatever reason) -> connect one of your PCs to the very same switch you have your VMware server on and do a simple unicast to that one PC. How long does it take?
    2. Connect that same PC down your network where it would belong to (or maybe even take another step in between depending on the number of switches used). See how fast a deploy is going then.