CMDB synchronization provides a configurable mechanism to keep data in the BMC Atrium CMDB (CMDB) synchronized with information discovered by BMC Atrium Discovery.
Data model mapping
The BMC Atrium Discovery data model (Discovery model) is different from the Common Data Model (CDM) used in the CMDB, so the synchronization mechanism is responsible for transforming the required information from one data model to the other. The Discovery model is known as the source model, and the CDM is referred to as the target model.
Both models are graph models, meaning that they represent data as nodes connected to each other with relationships. Synchronization operates on portions of the full graph known as subgraphs. A subgraph contains a root node (such as a host computer), plus all the related nodes that belong to it (such as interface information, software information, and so on), referred to as its components. Some nodes can be shared, meaning that they belong to more than one subgraph. For example, the node representing a subnet is shared by all the host computers on that subnet.
The mapping between the Discovery model and the CDM is defined in syncmapping definitions within TPL files.
The Default CDM Mapping provides a comprehensive mapping from the Discovery model to a best-practices CDM model. If you have added custom nodes to Discovery they are not exported automatically by the default CDM mapping, instead, you will have to create additional mapping definitions within TPL files.
Supported CMDB versions
The following versions of BMC Atrium CMDB are supported:
For more information, check the compatibility table for your CMDB version (support login required).
Deprecated versions of CMDB synchronization
BMC Atrium Discovery version 8.1 introduced the first automatic integration with CMDB synchronization. With the introduction of the CMDB synchronization described in this and the following sections, the mechanism used in version 8.1 is now deprecated. For backward compatibility, it is still included in the product. For information on the mappings used, see the version 8.1 documentation.
Synchronization occurs in five stages:
- A root source node is chosen for synchronization. The root node kinds are
Printercorresponding to the main kinds of device that can be discovered. The list of possible root nodes is fixed and cannot be altered in the Syncmappings.
- The source subgraph is populated by retrieving all the relevant data from the Discovery datastore.
- The source subgraph is transformed into a target subgraph, centered around a target root node.
- The target subgraph is compared with the corresponding subgraph stored in the CMDB.
- The CMDB is updated (by creating, updating and (soft) deleting CIs and relationships) so that the stored subgraph matches the target subgraph.
Restart tideway service after making changes to CDM
If any changes are made to the CDM (for example, adding attributes), you cannot synchronize to those attributes until the tideway service has been restarted. After the tideway service starts, the CDM is read and all customized classes and attributes are available for CMDB synchronization.
The following steps are required to set up CMDB synchronization:
Synchronization can be configured to run in a continuous mode, meaning that as soon as Discovery completes its scan of a device, the data corresponding to it is queued for synchronization with the CMDB. Alternatively, synchronization can be launched manually for one or more devices from within the browsing interface.
Preventing synchronization at certain times
Typically, synchronization can occur at any time. However, synchronization can place a substantial load on the CMDB, so it may be necessary to prevent synchronization from occurring at times the CMDB will be used heavily. This can be achieved by configuring CMDB Sync blackout windows.
By default, all details about all devices are synchronized to the CMDB. In some situations, it may be useful to only synchronize a subset of the data.
After each of the first three synchronization stages described above, the data can be filtered, to affect the data that finally reaches the CMDB.