Consolidation - Documentation for Bmc Discovery 11.3
Note Consolidating from an Unpatched to a Patched Appliance: the Latest Patch Release (11.3 Patch 5) Has Created Potential Loss of Data Between Unpatched...
Note
Consolidating from an unpatched to a patched appliance: The latest patch release (11.3 patch 5) has created potential loss of data between unpatched scanning appliances and patched consolidating appliances.
In general consolidation works across supported versions of Discovery and we do not insist that scanning appliances and consolidating appliances are the same versions. However it is now the case that if your consolidating appliance is on the latest patched version, and a scanning appliance is not yet patched to the latest patch version some data will be lost in consolidation.
The simple solution right now is to upgrade any scanners to the latest patch level; these are:
- 11.0 patch 6
- 11.1 patch 8
- 11.2 patch 6
- 11.3 patch 5
Consolidation refers to the centralization of discovery data from scheduled or snapshot scans on multiple scanning appliances to one or more consolidation appliances. You might want to use consolidation in the following scenarios:
- Firewalled environments—When an environment is divided by firewalls so that a single appliance is unable to reach all parts of the network, a scanner can be situated on each section of the network blocked by a firewall. The scanners can all feed back data to a central consolidator.
- Restricted (policy) networks—Certain lines of business might enforce policies on the control of IT infrastructure in their environments. Where such policies limit or prohibit access, scanners can be deployed which all feed back data to a central consolidator.
- Restricted (time) scanning windows—Where a discovery window is short, a single appliance might be unable to complete a scan of a large range of IP addresses during the permitted time. Sharing the IP addresses between multiple scanners means each smaller scan can be completed in less time, and the results can be consolidated and viewed on the consolidator. You may consider using a cluster in this situation.
In each of these situations, multiple scanners can be deployed, and their data consolidated into a central consolidator. The consolidator is then used for reporting and provides a coherent view of the entire scanned network. A consolidator must be set as one which accepts connections or feeds from scanners. Scanners must in turn register with a consolidator.
Any consolidation appliance can also be used to perform discovery in its own right.
Note
Although consolidation can be used to scan a firewall environment, it is essential that the IP address ranges scanned by each scanner belong to the same IP address space. That is, if two scanners scan the same address, they must both reach the same device. If the IP address spaces are not consistent across all the scanners, information on the consolidator can be missing or incomplete.
This restriction applies only to the addresses scanned by the scanners; if discovery targets possess other IP addresses, there is no need for them to belong to a consistent IP address space.
Consolidator—The main purpose of the consolidator is to report on data consolidated from a number of other scanners. A consolidator can also be used to perform discovery in its own right.
Scanner—The scanner appliance also operates as a normal appliance. The only difference is that it constantly sends discovery data to the consolidator. After setting up, this process is transparent to the user. A scanner must request and be approved on a consolidator appliance before it can send any data to the consolidator. This is described in Approving or rejecting a scanner request. A scanner can send consolidation data to more than one consolidator.
On the consolidator user interface, the Currently Processing Runs tab shows any local scans and any consolidation runs in progress. The Currently Processing Runs is described in The Discovery Status page.
Restrictions
The consolidator's service pack release must be the same or greater than the scanner. This is checked when you test the scanner-consolidator connection and when the scanner periodically checks that the consolidator is still accessible.
- An 11.0 consolidator can accept data from a 9.0, 10.x and 11.0 scanner
- An 11.1 consolidator can accept data from a 9.0, 10.x, 11.0 and 11.1 scanner
- An 11.2 consolidator can accept data from a 9.0, 10.x, 11.0, 11.1 and 11.2 scanner
- An 11.3 consolidator can accept data from a 9.0, 10.x, 11.0, 11.1, 11.2 and 11.3 scanner
If you try to consolidate to an earlier version, warning messages are shown in the UI.
Must Read
What is consolidated?
The consolidated data is the BMC Discovery Directly Discovered Data (DDD) nodes including the data collected by the patterns. The data inferred by the scanners, for example, Software Instance nodes, is not consolidated, but the consolidator will infer it again (based on its pattern configuration).
Note
The TKU release package and custom patterns that are loaded on the scanning and consolidators must be the same in order to infer the same data, for example, Software Instance nodes. This is not enforced in any way by the system.
The data imported via CSV in a scanner will not be consolidated. It has to be imported into all other appliances too.
Missing information when patterns run commands on other hosts
When a host is discovered and patterns are triggered which run commands on a second host, the DDD on both hosts is updated. In versions before 11.1, when the original host is consolidated, the DDD from the second host is not available to the patterns that trigger on the consolidator. When the second host is consolidated, the DDD created on it when discovering the first host is not included. Consequently the consolidator will always report that the information from the second host is unavailable. The error "Request for information not part of the consolidated data" will be reported in the consolidated DiscoveryAccess. This can lead to missing nodes (licensing Detail, SoftwareComponents, and so on) and relationships on the consolidator. To work around this behavior, scan the original host from the consolidator.
Note
From BMC Discovery 11.1, a scanner sends the results of requests on the second host with the consolidation data from the original host. This allows commands run against other host to be successfully consolidated.