UCMDB and UD Practitioners Forum (Previously CMS)
cancel
Showing results for 
Search instead for 
Did you mean: 

NNMi Topology Integration for uCMDB

SOLVED
Go to solution
Highlighted
OrbitZer0
Super Collector

NNMi Topology Integration for uCMDB

Hello all,

 

I have the NNMi Topology Integration working.  It populates the "Node" ci's in RTSM correctly, and as expected.  However, I was wondering if you guys have any advice on how I might enrich the results and populate the Windows ci with the Winodws Servers that NNMi knows about.

 

I realize that this is working as expected.  Just want to know if there might be a way to make the Windows ci's actually show up as Windows ci's in RTSM.  This would help me greatly down the road with SHR.

 

Thanks

 

 

P.S. This trhead has been moved from Application Perf Mgmt (BAC / BSM) Support and News Forum to CMS and Discovery Support and News Forum. - Hp Forum Moderator

16 REPLIES
Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

From NNMi directly - no way. From other data collector that you may have in your BSM that monitors the Windows servers and report them to BSM as Windows CIs - yes (in this case the 2 CIs will be merged by RTSM reconciliation mechanism).

OrbitZer0
Super Collector

Re: NNMi Topology Integration for uCMDB

Thanks Dmitry.

Your response is certainly more than HP Support gave me.

 

Are you saying I could deploy a "probe" from the RTSM that would enrich or merge the CI's that are created from NNMi?

 

My situation is such that I have 300+ Windows servers that are only discovered and monitored for up/down via NNM.  They don't have OM agents, and they are not discovered my our DDM probes.

 

I know the old way of integrating BAC and NNMi was a probe.  Maybe I need to try something like that ?  I dont need much, just the ability to have a Windows node from NNMi get set as a Windows CI in RTSM.

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

No, I didn't say about deploying a probe from RTSM. I was talking about BSM data collectors that could monitor the same Windows servers that are reported by NNMi as Node CIs.  Example of such data collectors could be OM or SiteScope. If you don't have such data collectors in your BSM environment and don't use regular DDM discovery for those Windows servers then you are out of luck.

 

What you mentioned (the old probe based integration) is still available. However, it's not a recommended way to do topology sync from NNMi to BSM. Also the overall product direction is to change even this probe-based integration mechanism to report Node CIs rather than specific router, switch etc. CIs. I didn't check whether it was already implemented in the recent BSM and UCMDB versions, but I wouldn't be surprised if it is already there.

gcuervo
Collector

Re: NNMi Topology Integration for uCMDB

dimitry, what do you think about new recommendation of integration that appears in the manual BSM_922_NNMi_Topology_BP.pdf (june 2013, page 8)?

OrbitZer0
Super Collector

Re: NNMi Topology Integration for uCMDB

HP Support is saying I can use both the standard Topology Integration and the old probe, to achieve what I need.  I'm leary of that.

 

Seems like it should be a lot easier than this, since NNMi knows these are Windows servers, and identifies them as such.  I thought a rtsm enrichment would do the trick, but I strike out every time I try.

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

Do you mean this paragraph?

 

Note that if your environment does not have other data collectors to refine the NNMi data, all CIs

will be of type Node. In this case the Data Flow Probe "pull" integration method is more useful for

BSM, where functionality is based on more specific "strong type" CITs - sub-types of the Node

CIT.

 

I strongly disagree with this statement, and don't really understand how it was made to the best practices guide. Having "strong" CITs is the least to be useful for BSM use cases. As I said I'm not sure that the "pull" integration in the recent BSM and UCMDB versions still produces CIs of "strong" CITs. I've just checked the list of discovered CITs for NNM_Integration adapter (used for the pull integration) in UCMDB 10.01 and BSM 9.22, and I don't see any "strong" CITs there any longer - no switch, router, Unix or Windows CITs etc.

 

Also I believe TBEC rules are designed to work with Node CIs, not Windows or Unix CIs. That's why the recommendation from the best practices guide doesn't look reasonable to me.

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

>>>HP Support is saying I can use both the standard Topology Integration and the old probe, to achieve what I need.

 

I don't think so. Certainly NO for the PUSH integration without any other source that can report Windows CIs, so that they could be merged with the Node CIs by the RTSM reconciliation mechanism.

gcuervo
Collector

Re: NNMi Topology Integration for uCMDB

i think that cmdb needs detailed cit (windows,switch,router,etc) to replicate into service manager.

 

i 've tried integrate nnmi to rtsm (or cmdb)  using probe, when event arrives to omi ci resolver works good.  and rtsm (or cmdb) send correct ci types to service manager.

 

in new cmdb 10 all data collectors sync with universal discovery, i think that nnmi-ucmdb not be discontinued.

 

other option will be change citype using noderole atribute, is it posible?

Dmitry Shevchen
HPE Expert
Solution

Re: NNMi Topology Integration for uCMDB

UCMDB and RTSM are designed to handle different use cases, so what can fit UCMDB use cases might not be such a good thing for BSM use cases. Does UCMDB care about TBEC? No, but BSM does. Does UCMDB care about real time discovery? No, but BSM does.

 

There is no way to change CIT of a CI based on any attribute value. There are very valid reasons why NNMi to BSM direct topology integration produces Node CIs with corresponding NodeRole attribute populated, rather than CIs of specific CITs.

 

Network devices can easily and dynamically change their role with only minor configuration changes in the device (or by adding a single card to the device). Reconciliation can make a CIs type "more specific" (i.e. change a Node into a NetworkDevice, or a Node into a Router), but it can only make those changes in the same "branch" of the CI Type Model. In other words, while a Node can become a Router (because Router is a subtype of Node), reconciliation cannot change a Unix CI into a Router (Router is not a subtype of Unix). These limitations/rules of CI Type reconciliation were just too limiting for today's network elements. Consider a Linux system discovered by NNMi. With just a minor system configuration (enable 2nd network interface, assign IP address and assign a route), this device has changed from a "server" type of device to a router. That is a change that is not supported by UCMDB/RTSM reconciliation rules. Or look at a network router that changes into a firewall just by adding a few ACL statements to the router's configuration. There are many more examples, both within the network domain, but also between "computers" and "netdevices", or even with application servers (regular computer becomes a voice gateway by adding e.g. Cisco CallManager software). For all these reasons, NNMi (and the BSM Data Model architects) decided to use "weak" typing with a "strong" NodeRole attribute for NNMi-generated topology.

 

Keep in mind that a single node can have multiple node roles, that was the original reason for the "weak" CI typing and introduction of the NodeRole attribute. NNMi will decide based on the node's capabilities (as discovered by NNMi) which NodeRole(s) to set. If a node has IP forwarding capability (com.hp.nnm.capability.node.ipforwarding), then NodeRole is set to "router". If the node has switching capability (com.hp.nnm.capability.node.lan_switching), then "lan_switching" is set.

gcuervo
Collector

Re: NNMi Topology Integration for uCMDB

dmimitry, what do you think about this?

 

1. integrate nnmi to ucmdb using probe. cmdb has all cis servers,network devices, services, applications, collections, databases, (rum ci types), asset data. 

2. sync ucmdb to bsm inlcuding services, collections

3. integrate nnmi to bsm

4. not sync bsm to cmdb

 

my customers dont have tbec only event foundation. they use bsm connectors to send events. topology comes from ucmdb.

 

question. how can i change citype to subtype (child type)? 

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

Your scenario is no go. First of all, NNMi doesn't support simultaneous integrations with UCMDB and BSM, so #1 and #3 will contradict. When you have NNMi, BSM and UCMDB you have to decide where to integrate NNMi topology - to BSM or to UCMDB. It's either/or, not both/and.

 

There is no one universal answer that will fit all situations - whether to integrate NNMi into BSM or UCMDB. It will depend on the overall solution architecture, size of the environment, use cases and tons of other factors. In vast majority of cases if you expect NNMi events in BSM/OMi the direct NNMi to BSM topology integration is the way to go, with subsequent RTSM to UCMDB sync for network related CIs. But again there may be some factors that will point to NNMi-UCMDB integration as a preferred one.

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

>>>how can i change citype to subtype (child type)?

 

By inserting/creating another CI of that subtype and allowing reconciliation engine to do its job.

gcuervo
Collector

Re: NNMi Topology Integration for uCMDB

yes, NNMi doesn't support simultaneous integrations with UCMDB and BSM, but ucmdb can be integrate nnmi using adapter (integration studio). and can be filter TQL to sync cis to bsm to avoid conflict. so 1 and 3 would be works good.

 

 

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

No, 1 and 3 would NOT work well. What you are writing right now would work, but it is not what you wrote previously:

 

1. integrate nnmi to ucmdb using probe...

3. integrate nnmi to bsm...

gcuervo
Collector

Re: NNMi Topology Integration for uCMDB

 

I have tested this in my lab

 

may i not explain well

 

1. ucmdb integration point (population from nnmi)

3. hp nnmi to bsm topology integration

 

 

Dmitry Shevchen
HPE Expert

Re: NNMi Topology Integration for uCMDB

As I said # 1 and #3 together are not supported. NNMi is supported for topology integration to either BSM or UCMDB, not to both at the same time. You can test whatever you want, and it may work for you. But it doesn't change anything - you run an unsupported deployment, and take all risks associated with this.

 

Should you come across any issues and create a support case, and HP Support finds out that you run both UCMDB and BSM topology integrations from NNMi simultaneously, they will ask you to first revert to the supported deployment and reproduce the problem in the supported environment.

//Add this to "OnDomLoad" event