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. |
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.