Without SSD, an elected master for each subnet always accesses a DP, often over a slow or congested WAN, even if a neighboring subnet in the LAN had the requested package. In practice, this had no major impact on WAN traffic as Nomad only uses a proportion of the current free network capacity rather than the total rated capacity, but efficiency can be improved by enabling access to Nomad caches on other subnets.
When a Nomad client requires a particular package, it attempts to find a copy on the local subnet. If it is unable to find one, it queries ActiveEfficiency to see if there are Nomad clients on adjacent subnets that hold a copy. If it finds one, it will download the package from it; if it doesn't, it will download the package from the DP over the WAN as a last resort.
Nomad reacts dynamically to network adapter changes, and if its IP address changes it will automatically update its subnet information in ActiveEfficiency. So, for example, closing the lid of a laptop and moving it to another subnet and resuming work there is handled by Nomad.
The following is how SSD interacts with other Nomad features:
The following restrictions apply:
Before enabling Nomad clients to use SSD, you need to ensure the following:
High-level overview of how to enable Single Site Download (SSD)
The following information applies to both new and existing installations of Nomad.
Building a subnet profile in ActiveEfficiency
For ActiveEfficiency to build a subnet profile for SSD and the peer backup assistant feature, Nomad must communicate with its web service. When the Nomad service starts, it connects and registers the hosting device by name with ActiveEfficiency which returns a device ID in the form of a GUID that enables it to uniquely identify the Nomad client and its default subnet.
If it is unable to communicate with the ActiveEfficiency web service, it retries every 5 minutes until it succeeds (as long as SSD is enabled). An attempt to communicate with ActiveEfficiency is also made prior to a package download to register its status.
Configuring the Single-Site Download feature in the ActiveEfficiency documentation takes you through the setup process. There are also example PowerShell scripts for retrieving information about sites and their associated subnets from the AD and how to add these to ActiveEfficiency. Information about sites and subnets are typically obtained from the AD but you are free to get this information by other means.
Please refer to Enabling SSD in WinPE to make use of Nomad SSD in OS Deployment.
When you uninstall Nomad all its registry values are deleted. However, if you subsequently reinstall it, the device ID returned when Nomad next registers with ActiveEfficiency is one that is recycled from the database – this is because that is the device registered for the named computer so it recognizes that the same computer is involved and restores the previous values to the registry.
|If you change the host name or domain, Nomad and ActiveEfficiency will regard this as a new computer and generate a new device ID for it.|
If a cached package is reactivated, such as after an OSD upgrade or cloning, Nomad will register the package with ActiveEfficiency. (If this is a re-registration, the ActiveEfficiency record is effectively unchanged).
The Content Registration Sync Cycle is available in Nomad 7.0 or later (1E Client 4.1 or later) which registers pending and failed content registrations with ActiveEfficiency.
Registrations can fail when ActiveEfficiency or the SQL Server hosting ActiveEfficiency DB is busy, overloaded or down for maintenance, resulting in content registration mismatch between the clients and ActiveEfficiency.
The following are registry settings used by the Content Registration Sync Cycle feature.
The information about sites and their associated subnets are stored and maintained in ActiveEfficiency. When a Nomad client downloads a package, it registers this information with ActiveEfficiency, enabling it to build a profile of which Nomad client holds particular packages and on which subnet.
When a Nomad client on a subnet requires a particular package, it first tries to find a copy on the local subnet using the standard method for retrieving cached Nomad files.
If no local copy of the package is found it then tries the ActiveEfficiency database to see if any Nomad clients on other subnets at the same site hold a copy.
Only when all other avenues have failed will Nomad resort to downloading the package from the DP over the WAN.
When the master has a portion of the package it, registers itself with ActiveEfficiency to say that it can provide this package to other subnets if required.
When Nomad receives a request to download content, an election takes place for a master. The master queries ActiveEfficiency about neighboring subnets (accessible on LAN rather than WAN) so that it can download content from a peer in an adjacent subnet (within the same location) if that content is not available on a peer in its own local subnet. For each subnet, the top 10 Nomad clients (in terms of percentage cached by the Nomad client) are listed – the subnet containing the master is excluded from the list if no peer has the content. During this process, the percentage specified by the requesting client is ignored. Although neighboring Nomad clients may have a lower percentage than the requesting Nomad client, they may in fact have gained more since they last communicated with ActiveEfficiency, so they are potentially useful sources for the package, hence the top 10 rule.
The master (now a subnet master) iterates through the list (which is sorted by percentage) and sends a package status request to each Nomad client. If it receives a response, the master attempts an SMB peer-to-peer download from that Nomad client (the current site master). If the attempt fails (it is not contactable or the limit on the number of concurrent connections is exceeded), it tries the next one in the list. If it fails to get the package from any of them, it downloads from the DP. If the list is empty, the master downloads from the DP. Nomad clients with a lower percentage of the package than the Nomad client requesting it will not respond.
|Nomad peers never deal with SSD; they only copy packages from their subnet's master. The subnet master may have the package completely cached or it may be actively downloading from another site or from a DP – the source makes no difference to the peer|
If a download is interrupted part way through (i.e.: the source becomes unavailable), Nomad iterates through the remainder of the list and if it fails to get the package from any of them, it downloads form the DP.
When a download starts, Nomad registers the progress with ActiveEfficiency (0% of the content has been downloaded) and when it finishes, the final percentage is also recorded. As long as the content downloaded is greater than 0%, the host becomes a candidate for another client until the package is deleted from its cache. Records with status of 0% downloaded are purged from ActiveEfficiency.
|All Nomad clients that have SSD enabled will register content download with ActiveEfficiency, not just the subnet master.|
If the Nomad client is running as a guest on VMware, it registers itself as
To enable SSD in WinPE:
https://<server_FQDN>/ActiveEfficiencydepending on the protocol you are using, where <server_FQDN> is the FQDN of the server or its DNS alias.