Contents
Comparisons of transfer methods
The sections below describes the basic features of each transfer method and the conditions that best suit each of these.
| Scenario | Peer-to-peer | Central multicast | Local multicast | |
|---|---|---|---|---|
| 1 | Small branches with less than 100 computers | P2P is simpler to implement than multicast and may provide the most efficient transfer of content. Optionally use the Nomad FanOut feature. | ||
| 2 | Large branch networks with multiple subnets | If multicast is not possble then use the Single-site download feature (which requires an ActiveEfficiency Server) to re-distribute content between fast-connected subnets. | Central multicast is recommended if possible. It is likely to provide the most efficient utilization of the WAN link and distribution throughout the branch network. | Alternative if Central multicast (multicast over WAN) is not possible. Local multicast provides the most efficient means of locally re-distributing large packages once they have been downloaded over the WAN. |
| 3 | Internet distribution | If the local branch is small, then P2P is likely to provide the most efficient method of local re-distribution. | Usually not applicable as it is likely that multicast over intervening routers are liable to be disabled by the ISPs. | If the local branch is large, then local multicast is likely to provide the most efficient method of re-distribution. |
Not using Nomad
If you are not using Nomad to manage your downloads, you will probably require a local Distrution Point, or your central Distribution Point server is likely to be saturated with requests and large amounts of redundant transfers being made across the WAN as each target computer on the target subnets requests its own copy of the download.
Local multicast
Local multicast is designed to reduce LAN network traffic at the branch and reduce the load on the elected Nomad master computer. Use this feature in preference to central multicast if multicast traffic is prohibited over the WAN. Nomad local multicast utilizes all the functionality of Nomad, but once the download is at the branch, it is distributed locally using multicast. Local multicast improves the performance of Nomad across the LAN and is ideal for branch offices containing hundreds of computers.
It is best to use local multicast:
- When sending a package to a large number of Nomad clients on a subnet with no local DP – multicast is the most efficient mechanism when there are a large number of Nomad clients. In this scenario local multicast reduces the load on the locally elected Nomad master.
Central multicast
Package data is sent from a central multicast transmitter to all deployed Nomad clients prior to execution. The central multicast job is manually set-up by an administrator making this a suitable transfer mechanism for sending the same package source to most of the organization. Data sent from a single source location to multiple subnets is only transferred once over each connection. This greatly reduces load on the DP and increases the number of subnets that it can service whilst significantly reducing network traffic going across any intervening WAN links. Central multicast improves the performance of Nomad across the WAN.
It is best to use central multicast:
- When sending a package to a large number of Nomad clients – due to the method of file transmission multicast is most efficient when there are a large number of Nomad clients.
- If the network topology is suited to multicast – for example, in topologies where network traffic is routed over a single communication pipeline and subsequently distributed to large numbers of branches, normal transfer to all of the Nomad clients can lead to saturation at the pipeline. This is because the transfer may need to be performed once per branch. Central Multicast helps in this case as the packets that form the multicast are sent just once over the pipeline and subsequently routed to all the branches on the other side.
- If the number of DPs in the Configuration Manager hierarchy is small – if there are large numbers of DPs in the Configuration Manager hierarchy, these may already contain the package being centrally multicast. In this case the package will already be distributed throughout the network and downloading directly from each DP is likely to be preferable to using central multicast.
Setting-up central multicast
To setup central multicast:
- Update the application or package content on the Configuration Manager Distribution Point (DP).
- If multicasting a package, ensure it is configured to use Nomad
- If multicasting applications or software updates, ensure the global
- Create a deployment scheduled for some time in the future – this schedule must be at least beyond the poll interval defined in Configuration Manager client settings.
On the Configuration Manager DP, run this command-line referencing the deployment ID.
%ProgramFiles%\1E\Client\Extensibility\NomadBranch\NomadBranch.exe -central=<DeploymentID>
Nomad client is module in 1E Client, and has a different default install location to previous versions of Nomad.
When the deployment is sent to each target computer, the local Nomad joins its computer to the multicast session, just prior to the its scheduled time, and waits for multicast to begin. Scheduling in this way increases the efficiency by enabling the Nomad clients to start receiving the multicast data at around the same time.
Schedule set too soon in the future
If the mandatory scheduled time is set too soon in the future for the size of the package, the central multicast job will be cancelled as it will not have time to prepare and start the job. When this happens, this notification appears in the Nomad log files Sorry – Multicast job cancelled – Too late to start this job with these parameters.
You will need to change the original schedule so that sufficient time is allowed for Nomad to perform its preparations – 30 minutes is a reasonable amount of time. Do not add a new schedule as Nomad will use the first available deployment that is in the future.
When the scheduled time arrives, Nomad on the DP starts the multicast and the simultaneous transfer of blocks to all computers begins. By design, multicast was never intended to be a reliable network protocol. This means that in normal circumstances data packets are not acknowledged by the recipients.
Although this allows for increased scalability and network efficiency, some network packet loss is expected in any multicast transmission. Nomad has built-in patented technology that ensures that missed network packets are recovered. Computers that miss data blocks communicate with their local Nomad master. Requests for the repeat sending of specific blocks are then pooled at the master and communicated back to the DP in one go.
Cache management
If you are going to manage the caches, the cache cleaner will automatically take into account the space required by all the concurrent jobs running before purging a cache. There is no additional configuration needed for this to happen.
Setting-up local multicast
To setup local multicast:
- Edit the package properties.
- Select the Nomad tab and check the Multicast checkbox. (see Configuration Manager 2012)
- Click OK.
Things to avoid if you are using multicast
We recommend you take note of the following when using multicast:
- During multicasting avoid the use of hibernation or sleep on Nomad client computers
- Influence the election weighting for laptops so that they are not considered as candidates for a master
- Synchronize downloads so that all Nomad clients are ready to receive the multicast at the same time
- Send the multicast overnight when there is minimal disturbance to the networked computers
- Limit the number of simultaneous active deployments
mult
Configuring multicast on your network
To fully realize the potential of using multicast, it must be enabled on your network. Multicast is typically enabled on routers so there should not be any specific changes required. Nomad multicast uses Multicast Address Dynamic Client Allocation Protocol (MADCAP) to get its range of multicast addresses. One implementation of MADCAP is bundled with Microsoft’s implementation of the Dynamic Host Configuration Protocol (DHCP) standard and is used to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks. Ordinarily, DHCP scopes provide client configurations by allocating ranges of unicast IP addresses. MADCAP scopes can be used to allocate separate ranges of IP multicast addresses on a standard Windows DHCP server.
Nomad can be configured to use:
- A MADCAP scope name – where an environment uses multiple MADCAP servers or
- A specific server IP, scope IP and TTL setting – where the location of a specific MADCAP server is known
This configuration can be done during installation with the MADCAPSCOPE installer command-line argument or post-installation by modifying the MultiCastMADCAPScope registry value.
If company policy prohibits multicast traffic from crossing your routers, you can still benefit from using Nomad multicast. Multicast communication can simply be restricted to each subnet and downloads over the WAN is done once per subnet instead of once per branch. Local multicast is an excellent option for large branches (typically more than 100 computers) as it reduces LAN traffic and the load on the elected Nomad master.
Nomad registers each package it downloads with a key derived from the package name/version. In this way, a unique multicast address is designated for each package advertised using Nomad. The size of the MADCAP scope used should allow for sufficient concurrent package distributions.
To enable multicast to work across your network, you need to open UDP port 2535 in Windows Firewall.
Configuring MADCAP
MADCAP configuration is fairly complex and there are many different implementations of it, so complete coverage is beyond our scope. However, we will instead focus on the specific settings for Nomad.
To enable Nomad and MADCAP to work correctly:
- Set a short time to live for the Multicast packets.
- Set a short lease time for the Multicast Scope.
- Exclude the first Address in the range to enable its use by Nomad. The first address in the range "*.*.*.0" is used by Nomad as a control channel.
Microsoft's implementation of MADCAP is integrated with the DHCP server where you can configure its settings. Our example shows the properties for the SMSNomad multicast scope.
There is a bug in certain versions of the MADCAP implementation where the entire address range gets excluded by default. If this occurs, delete the exclusion and create a new one that just references the first address in the range.
In our example, the start address of 239.0.9.0 should be excluded. This is done as an action on the Address Pool in the MADCAP configuration interface.
