I have been working at a larger Danish customer lately, and one of the tasks I was faced with was to help the customer decide, if they were to buy and implement Nomad from 1E.
One of the key features of Nomad is to eliminate the vast majority of System Center Configuration Manager (SCCM) distribution points, and therefore greatly reducing the administration overhead of managing those servers. This is done by allowing the clients to download content from each other. The benefits of this are many such as fewer servers to manage, greatly reduced replication needs etc. but the key feature that the customer was interested in, was minimizing the load on the WAN connections without having to add additional distribution points to the remote sites.
To document this impact, I ventured out into a Proof-of-Concept implementation to show that the product will do exactly that!
In this blog post I will share some of my findings, so anyone who has the same questions about whether or not Nomad actually works as promised.
The PoC setup
First thing was to figure out what to measure and how, to document the impact. For this it was decided to use the following scenarios:
Five computers in the main office (LAN) was identified, these five computers were all connected to individual ports on the same managed network switch, so traffic could be monitored and analyzed.
The following tests would be performed on these computers, while capturing the network traffic impact on the switch.
- Deploy an application containing “Microsoft Office 2007 Pro Plus 2007 SP3” which is about 989MB to all five computers at the same time, using native SCCM distribution points located at the main office (LAN)
- Re-image the computers simultaneously using native SCCM methods (no Office installed).
- Deploy Nomad Branch client to all five computers
- Deploy the Office application once again using Nomad Branch as the content provider.
- Re-image the computers using Nomad
Four computers in a remote office connected through a congested WAN was identified, these four computers were also connected to individual ports on the same managed network switch, so traffic could be monitored and analyzed.
The same tests as described in scenario 1 were performed at the remote office.
After hours of crunching the numbers that came out of the switches, I came to the conclusion that some graphs were needed to make the results more readable to the decision makers. For each of the tests there are two graphs using the same scale to make them easily comparable, one for the native SCCM test, and one when using Nomad.
Scenario 1 – deploying office at main office
The first graph shows the network load when deploying the Microsoft Office application to 5 computers on the same subnet, using the SCCM Distribution Point. All computers download the same data from the distribution point therefore causing high network traffic on the uplink. Each computer is connected to port 1 to 5 on the switch.
The second graph shows using Nomad as the content distribution engine, this graph clearly shows that the impact on the uplink is greatly minimized, as only one computer downloads the Microsoft Office application from the SCCM distribution point and then shares the content with the other four computers.
Using Nomad in this scenario proves that the content transfer over the uplink to the distribution point is 1/5th when compared to a native SCCM infrastructure
Scenario 1 – Re-imaging computers
Using the existing SCCM infrastructure to deploy a new operating system to 5 computers simultaneously, we see that the uplink is heavily loaded, as each computer downloads the operating system image and other resources needed to complete the installation.
Nomad will use its intelligent bandwidth throttling technology – Reverse QoS – while downloading the required OSD content to the cache on the computer. This will ensure that no part of the network or other business traffic will be affected during download. Due to this, the timespan can be longer than it normally would be if the individual clients downloaded the content directly, however multiple clients downloading content over a congested WAN link may take considerably longer and could cause more congestion!
The 4 other computers has been targeted with a re-imaging of their operating system, and they will detect that a computer with Nomad is present and has the needed content already stored in its cache. The computers will then download all needed resources from the Nomad master.
In a production environment the needed content would already be distributed among other Nomad enabled computers, so a pre-caching would not be needed.
Using Nomad, the amount of content that would be downloaded from the SCCM distribution point is minimized. Each computer will download content from the nearby Nomad master, resulting in a slightly faster re-imaging as content is already available locally on the subnet. OSD re-imaging can be further optimized by using the content that has already been stored in the Nomad masters’ cache.
Scenario 2 – deploying office at remote office
This graph shows the network load when deploying the Microsoft Office application to 4 computers on a remote subnet, using a centrally located SCCM distribution point. All computers download the same data from the distribution point therefore causing high network traffic on the uplink (WAN).
Using Nomad as the content distribution engine, this graph clearly shows that the impact on the uplink is greatly minimized, as only one computer downloads the Microsoft Office application from the SCCM distribution point and then shares the content with the other three computers.
The deployment of the Microsoft Office application at the remote office shows the same trend as the deployment at the main office. Content is downloaded from the local Nomad master (instead of across the WAN) therefore ensuring a small impact on the network traffic on the WAN line and computer resources.
Scenario 2 – Re-imaging computers
No need for further explanation, the graphs tell the story by themselves.
The first peaks in the chart (1 to 13 minutes) are caused by each client downloading the PXE boot media. In a production environment 1E Nomad’s PXE Everywhere would also be implemented, allowing Nomad masters to serve PXE requests as well, causing boot media to be downloaded using Nomad.
This PoC has only been focused on the network traffic reduction capabilities of Nomad. The Nomad product offers much more functionality and benefits than just reducing network impact.
Feel free to contact me if you want to know more!