Use Cases – Multiple CMDB Deployments: RTSM–CMS Solution

The solution includes:

• RTSM

• The central CMDB acting as the CMS

• Service Manager (SM)

RTSM is the operational storage of OMi. Configuration items (CIs) discovered by different OMi data sources are reconciled and stored in the RTSM.

It is recommended to connect the Data Flow Probe to the central CMDB instance (which can also serve as a CMS) and then use topology synchronization between CMDB/CMS and OMi to populate RTSM with additional CIs that are relevant for operational use cases.

For guidelines on which topology is recommended to be synchronized from CMS to RTSM and from RTSM to CMS, see the OMi RTSM Best Practices.

To setup CMS-OMi synchronization, it is recommended to use an out-of-the-box integration point. See Set Up Integrations between CMS and OMi to learn how to configure the out-of-the-box integration point.

OMi supports a hierarchical deployment that allows the forwarding of events and topology from one OMi instance to another. The main motivations for building hierarchical deployment are:

• Scale. When a hierarchy of OMi deployments is defined to deal with a very large number of events. The upper instances of the deployment get only "important" summary events.

• Geographical distribution. When several Data Centers in different geographical locations manage their own instances of OMi. In this use case, the data from the different geographical locations can be consolidated into one central instance (Manager Of Managers).

• Organizational structure. When the structure of the organization includes several OMi instances for each business unit or department. The consolidated picture is achieved either by synchronizing those instances two ways or by defining one central MoM (Manager of Managers) instance.

• Functional structure. When the IT department chooses to manage applications and infrastructure separately by creating two separate OMi instances for Application owners and Infrastructure owners. In this deployment, there can be several OMi instances, each one operated by domain experts — APM (Application Performance Management performed by OMi), NNMi, or HPOM.

• Different consumers. When the multi-tenancy is implemented by multiple instances of OMi.

• Organizational mergers and acquisitions. Sometimes there are several OMi instances as a result of mergers and acquisitions. Consolidation can be achieved by synchronizing the data to one central instance.

To setup simple OMi-OMi synchronization, it is recommended to use an out-of-the-box integration point. See Set Up Integrations Between Two OMis to learn how to configure the out-of-the-box integration point.

For details about setting up a custom integration point, see "How to Work with Population Jobs" on page 239.

For more complex deployments that include both hierarchical, multiple OMi deployments, and CMS, as part of one ecosystem, see the OMi RTSM Best Practices.