FOG server hardware workload
-
@nockdown You missed a number that tells the current performance of your imaging. During image deployment, on the target computer, what is the download rate on the partclone screen. It will (should) be measured in GB per min. What do you see today?
-
@george1421 , could you at least answer to some my questions without this “number of performance of my imaging”?
Today is holiday in our country and I’m not at work. -
@nockdown said in FOG server hardware workload:
CPU
- What is workload on the CPU during image capturing/deploying? Is the main workload of CPU on client? Or is on FOG server CPU? Or are on the both?
The main workload is done by the target computer. The fog server is only involved with moving the image from the network adapter to the disk storage subsystem. As long as your fog server is on a vm or a physical box and the disk subsystem is either flash or multiple spindle hdd behind a raid controller you will be fine. The CPU of the fog server isn’t really a factor for imaging. I have a Raspberry Pi3 running FOG and it images at 3GB/m understand that is from a small ARM processor and the storage is the micro SD card.
- What is more important for FOG server CPU during capturing/deploying? Core and threads? Or CPU frequency? Does FOG use multi-threading?
We will typically recommend 2 vCPU for a site with 200 or less workstations running the FOG client software. The fog client software has a bigger impact on the CPU requirements than imaging. We are actually looking at performance tuning the mysql database to resolve a discovered bottleneck on larger installs. Again the main function of the FOG server during imaging is moving data from the network adapter and storage and the overall imaging process management. There are no heavy calculations going on with the FOG server.
RAM
3. How much RAM does FOG server need?
DISK4GB of RAM is generally sufficient for the FOG server. The more fog clients you have you may need to increase this value. But for imaging 4GB is enough.
- What is performance dependence of FOG server disk system?
When you are doing multiple unicast imaging the disk subsystem on a HDD has a bigger impact than the CPU. Consider moving multiple 85GB images to different target computers at the same time. The read head will be seeking all over the place to keep up with the imaging process. So adding more spindles to disk subsystem will help spread the load. For flash based storage its not a factor.
- How could RAID 5 array improve performance in comparison of single 7200 RPM disk?
Again the single disk will have the entire load on sending multiple unicast images. It will have to do the entire seeking process. I have an article where I tested FOG server performance between single, raid and flash based. For RAID 5 for reading there will not be the parity raid penalty, but for writing (upload) there will be.
NETWORK
6. What is performance dependence of FOG server LAN connection speed? How could 10Gb/s LAN connection of FOG server improve performance in comparison of 1Gb/s LAN connection?On the network side, testing shows that I can saturate a 1 GbE link on the FOG server with 3 simultaneous unicast messages going on with my test rig. So for the FOG server it would be beneficial to run a 10GbE link if you plan on running multiple unicast streams at one time. The other option if you don’t have a 10GB network core is to use a multi link trunk (MLT/LAG/802.3ad/LACP) connection. This will spread the unicast images over multiple lanes of network uplinks. With a MLT/LAG you will never get a faster than single link speed for each unicast, but there will be more network links to share the load with multiple clients. On the client side (usually) the 1GbE network speed isn’t the bottleneck. On the client end it usually the CPU or disk subsystem that is the bottleneck.
Here is the article I mentioned before with some testing results: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast For the “FOG Server” for testing I used an old Dell 790 desktop computer. I picked this system to be on the lower end of performance to give a relative “feels like” experience.
Why I asked for the partclone speed is that number is a good representation of how your complete FOG environment is running. That partclone number is a composite speed of FOG Server + Network + client computer. This will show us how fast the client can intake the image sent by the fog server. On a well managed entire 1 GbE network, I would expect a value near 6.4GB/min transfer rate. On a well manged network with a 10GbE core but 1GbE to the desktop I would expect ~13GB/min to contemporary hardware (i.e. Dell 7040 with nvme drive).
The last bit is that a 1GbE link has a theoretical maximum of 125MB/s (7.5GB/min). A single 10GbE link has a theoretical maximum of 1,250MB/s (75GB/min). So how is it possible to get 13GB/min transfer rate with a 10GbE core and a 1 GbE link to the desktop when a 1GbE link can only carry 7.5G/min? That is because the partclone number is a composite number of not only server transfer speeds, network speeds, but the expansion and writing of the image to disk on the target computer. I would assume with a 13GB/m transfer rate that the network link is saturated and the target computer is expanding the image that is about a 2:1 compression ratio.
-
thank you very much for reply and the link to your testing!
I will test my partclone speed to evaluate my environment. -
@george1421 ,
My Ave. Rate is 7.01GB/min -
@nockdown I would say that rate is in the good range for a 1GbE busy network. (In general terms) your fog server, disk subsystem, and network are running well.
-
Thank you very much!
What do you think about installing FOG on the system with one hdd (mounted like /) and one ssd (mounted like /images)?
As I understand placing /images on ssd will help to improve deployment, because reading image from ssd is more quickly by comparison to reading image from hdd. -
@nockdown In general I recommend having one disk/partition for the ( / ) root partition and having a second for /images (fog images) and possibly a third for /opt/fog (snapins). The logic here is that /images and /opt/fog/snapins could grow in an uncontrolled manner.
Since it appears you have a physical machine having an ssd for the /images would be a good choice. Typically the /images directory is write (few) read (many) so an SSD well suited for this use.
If you have a 1 GbE network, having multiple network links configured in a switch assisted LAG group will also help. Use LACP/802.3ad/MLT mode for this LAG.
-
Thank you! What is the purpose of /opt/fog/snapins directory? Is it required for capturing? Or for deployment too?
-
@nockdown snapins are programs (think ms office) that you will install post imaging. By putting those on a different partition than the root, you reduce the risk of filling up the root file system and bringing down the fog server.
