One of the big issues with Peer Cache is that clients can only get content from Peer Cache sources (“Super Peers”) when the Peer Cache source has got all of the content.
Operationally, this means when you deploy something new (e.g. a critical patch) to all clients in a remote location at the same time, you expect them all to pull the content from the remote DP over the WAN.
You may have heard that Peer Cache now includes Partial download support.
(introduced in CM CB 1806). It “tries to eliminate more than one download of the same content per boundary group”. So how does it actually work, and does it really address the problem?
The link above provides a good explanation of how the feature works. Here’s quick a summary on how to set it up:
- Build a Collection of systems that you want to act as Peer Cache sources (Super Peers)
- Defined Custom client settings enable Peer Cache and deploy this to the Peer Cache sources Collection
- Define a Boundary Group for each remote location. You do this not so that it does not have a DP associated with it, but has a relationship with a neighboring Boundary Group that does have an associated DP and a fallback delay of, say 30 minutes. This is important. It’s the only thing that prevents regular clients from downloading from the DP straight away, giving the Super Peers time to get the content first.
- Update all Application Deployment Types to allow download from neighboring Boundary Group (otherwise they will never be deployed to the remote Boundary Group)
- Update or create Software Update or Program Deployments to allow download from neighboring DP (disabled by default).
- Enable partial download for Peer Cache in Hierarchy Settings
When you do this, Peer Cache source computers (‘Super Peers’) targeted with content will download the content in blocks.
Block 1 downloads first. If another Super Peer requests the same content while the first is downloading block 1, it will start to download block 2 and so on. This can be seen observing the ContentTransferManager.log on two ‘Super Peers’:
As each Super Peer aggregates all the blocks, it updates the Management Point and then other clients in the Boundary Group can get the content from it.
10/15/2018 9:27:56 PM Download complete for all 4 blocks
10/15/2018 9:27:56 PM Reporting the download completion status to MP
However, it’s only Super Peers that can use this partial download. To prevent the other clients in the Boundary Group from just going straight to the DP while the Super Peers are doing their partial downloads, you must deprive the Boundary Group of a DP and configure a fallback delay (say 30 minutes) to a neighboring Boundary Group that has a DP. The Super Peers will ‘ignore’ the fallback delay and start downloading immediately. The other clients will wait 30 minutes then attempt the download, by which time the Super Peers should have the content.
You could just make all clients Super Peers. However, if there are more Super Peers than blocks of content (in my test, Office 2013 at just over 700MB was split into 4 blocks), Super Peer starts to download a block until there are no more blocks from the DP. The remaining Super Peers will wait for the Boundary Group to fall back interval-like the regular clients.
So how does this compare with Nomad?
- To get this set up, you have to configure or modify Boundary Groups, Client settings, Hierarchy settings, Application Deployment Type Settings, Program and Software Upgrade Deployment settings. Nomad only requires enabling Nomad in Client settings and on each Package. It doesn’t require intricate management of Boundary Groups
- This configuration forces clients to delay download of the content, based on the fallback interval defined between Boundary Groups. Every deployment to clients in those remote Boundary Groups gets delayed. Nomad starts downloading content and sharing it among other peers without delay.
- The process has no resilience built in if any of the Super Peers go offline while content is still being downloaded. You can expect peers to go back to the DP when this happens. As the Nomad master shares the content with peers as it is downloading, it can quickly recover and resume (not restart) download from another peer within two minutes of the elected master going offline.
- Peer Cache uses BITS (which is incapable of bandwidth management) to download content from the DP. You can expect to see network congestion as multiple Super Peers simultaneously download different blocks. Nomad downloads content from the DP. Only one master (either per subnet or per site if you are using Single Site Download) gets the content sequentially from the DP. Using proper bandwidth management enables them to assess and use the end-to-end available capacity. Simultaneously, it backs off when other data is being transferred.