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:
Scenario 1
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
Scenario 2
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.
Results
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
Using SCCM
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.
Using Nomad
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.
Conclusion
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 SCCM
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.
Using Nomad
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.
Conclusion
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
Using SCCM
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
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.
Conclusion
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.
Using SCCM
Using Nomad
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.
Final thoughts
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!
Hey,
Good artichle, but I miss seeing the DL’s over the WAN compared to local traffic. Now its a mixture of the two, not as clear. If you look at our BranchCache reports, you can see what came from the DP and what came from the Peers. Makes more sense in my opp.
Nevertheless, great info, how did you pull the data from the switch? Got a script to share so I can run the same for a BranchCache deployment?
Best regards,
//Andreas
Forgot to add the link: http://2pintsoftware.com/products/branchcache-reporting
//A
Customers who own 1E Nomad have access to the Nomad Reporting Pack. It’s great for displaying exactly where cached content is throughout the enterprise (per-computer, per-subnet, per-site, per-location, etc).
There are about 12 reports. One specific report shows the content bytes that a specific client obtained from a remote DP and content bytes that were obtained locally from another peer SCCM/Nomad client.
[…] For anyone involved in teaching, one of the most rewarding aspects is seeing your students develop and start sharing their knowledge with others, building a community of peers. When people outside your organization begin to share what they have learned with their peers, communities of knowledgeable people begin to grow and benefit users everywhere. Like when Dave Kawula and Emile Cabot recently published their book Advanced Windows Deployments Using 1E Software (available on amazon.com), or when Johnny Radeck shared his experience running a Nomad PoC on the CoreTech blog. […]
Hi
How does this keep software licensing straight?
not sure i fully understand your question…
This is all about distributing your installation source using the clients instead of multiple distribution points.
The software is not installed, but contained in a folder that can be restricted so users has no access.
OK Thanks. So there is a central record somewhere that records where the software has been dropped? I was involved in a project that fell apart because the software was tied to users and each time the user moved devices their person stack was retrieved from local clients and installed on their current workstation
Nomad is not responsible for installing software, ConfigMgr is. So it is your normal deployment rules that controls who and where the software is installed. Nomad will just be “the man in the middle” that will provide the installation content, either from a local client (peer caching) or from the nearest DP if no peers has the content.
Hello Henrik
Amazing article, I must say…Only bcoz people like you share the knowledge, people like us have an easy day.
I have few questions though, as I have been working on SCCM since last 8 years now but “completely” new to NOMAD.
First, as I understand (correct me if I am wrong) NOMAD is basically establishing a peer to peer network (something we find in torrents). But when the NOMAD master gets the application or the OS content, the wim or the boot file, how would the other machines, with NOMAD clients of course, know of its presence with the NOMAD master…?
In SCCM pkgtransfer manager does the job, say…in case of PULL DP. It tells the other DPs to get it from the source D.P.
In case of branch cache, we need to specify a bandwidth timeout value exceeding which, it will look for the branch cache,
So how does it happen with the NOMAD clients, in other words how would it know that it’s neighbour has the content and it does not have to go far to the D.P. to get it…
And…is there any log to check in such cases..
Thanks! If we all share our knowledge and findings, life becomes much easier 🙂
Nomad acts as an alternate content provider for SCCM, so when the SCCM agent needs content it hands over the download to Nomad. The first thing nomad does is do a broadcast to locate peers with the content needed, if noone replies it will use SCCM boundary groups to locate DP and download via HTTP. Only difference is that Nomad uses “Reverse Quality of Service” backing off/slowing down if user needs performance/bandwith. also it constantly monitors the available bandwith durring download. If a neighbouring peer has the content (with the right content version) Nomad will download via SMB from that peer. Once downloaded the content is hash checked to verify that content is correct and has not been tampered with.
There are of course logfiles for Nomad, and all events are reported as state messages to SCCM, allowing us to filter, create queries etc. reports are also available for admins to verify on which locations content is available. It is also possible to precache content to sertain peers prior to large deployment, significantly reducing deployment times.
Hope this answers your questions.
/Henrik
Ok, now I get the picture, so SCCM hands over the job (like a CTM or DTS job) to Nomad client and the NOMAD client is already programmed to ask its neighbour before asking the far DP (or locate the DP). If NOMAD gets the content close at hand, it does the download and if it does not then, we have SCCM anyway, to do the job, that is so cool…!
Just one more question (hope I am not being a pain), rather a confirmation, I don’t think NOMAD or any NOMAD user account has any access to the SMS provider to write straight into the SCCM SQL DB. I think NOMAD does the SCCM bidding, completes the download job, hands over the status to SCCM (in the form of status messages, I guess…!!) which SCCM then writes to the SQL Database…right..??
Yes, Nomad does work seamlessly with SCCM, its administration is fully integrated into the SCCM console. All communication between the site and Nomad clients are handled by the SCCM client using policys and state messages.
As for the election of the master, this is truly a dynamic process. an election is held each time content is needed, so the peer that is best suited for the job gets the role. there can be multiple masters, each handling its own piece of content. furthermore elections are reevaluated every 5 minutes, to be sure that the master is still the best candidate. Take this for example: One peer needs Office 2016 and does a broadcast to locate peers on the same subnet that might already have the content. It does not get a response so it elect itself as master and begins download from remote DP. durring download a new peer comes online which have all the needed content in its cache. This will be discovered during the evaluation process, and the new peer becomes the master, and the initial peer gets the rest of the office 2016 content from the local peer.
And ya…Among the machines which NOMAD client will get the content first and become the NOMAD master..?, is there any way to determine that, or becoming the NOMAD master is just a random process…?
Amazing, Thank You so much Henrik…!!
You Rock…!! 🙂
Do you have any documentation on setting up Nomad as a PoC with a detailed how to guide?
Hi Arindam, The election process has a number of criteria. The election process is completely predictable based on the criteria at the time of the election request. Some of the criteria: Does someone have the content already, currently an elected master for this transfer, machine up time, user logged on, free space, etc etc etc.
whoops wrong thread. Sorry
Hi Karthik,
Aboslutely. All documentation from 1E including quick start guides are published online at http://help.1e.com. You will need to register for an account but that is a quick process. Feel free to reach out to http://www.1e.com/contact or myself and we can get you setup in a moment.
[…] This CoreTech Article is great at showing measured real world network savings by 1E Nomad. […]