Absent Member.. Absent Member..
Absent Member..
681 views

Duplicate Node CI in uCMDB

Jump to solution

Hello.

We are running uCMDB 9.05 and we have multiple integrations, including DDMA, BSM, and NNMi.

 

We are finding an alarming number of duplicate Node CI's within our uCMDB.  All of these nodes seem to have changed somewhat during theor most recent discovery.  Perhaps a node had a significant patch applied, or was rebuild altogether.  This causes another Node CI with the same display label to be created.  I believe this to be expected functionality, but can we control when a "duplicate" Node CI is created?  Can we examine the threshold that determines when a new CI with the same display label is created?  These Nodes are really messing with CI resolution in OMi.

 

Also, I am aware that these Node CI's are not actually duplicates, in that they have different global ID's, but for this conversation, it seems easier to refer to them as duplicates.

 

Any help is appreciated.

 

Tags (4)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

In reconciliation there are 3 major parts, identification, verification and validation.  These 3 parts do distinctly different things and try to identifiy the CI in question (node in this case) as unique or a duplicate with an existing node, in which case we would try to merge it with the existing node.  Problems can arise when we don't have enough reconciliation data to prove or disprove that the node is unique.  You can see the reconciliation rule in the CI Type manager on the details tab.  For example:  the node reconciliation rule uses identification data to see if it can match a wide set (positive match) of CIs that exist already.  This collects the mac addresses of connected interfaces to determine if 66% of them match, or 66% of IP Addresses associated match, if the name attribute is the same, snmp_sys_name, and so on.  Once this pool of potentially matched CIs is gathered, there are things that will make them unique.  Verification looks at differences and excludes CIs based on this (these things cannot ever be different on 2 CIs and be the same CI).  For node, if the node is a cluster_resource_group and has a different name, or if it has a different os_family, then they will never be matched and so a new CI would be created.  Next, we look at the validation rules to see if we have enough to match a node in our pool to the node we're trying to add in the data-in bulk (be it from discovery, an integration or even a user creating a CI).  In validation, we are looking for anything that might be a positive match.  Generally, in node, this would be a hardware attribute and a software attribue.  If a pair match (even though other validation rules don't match or return an unknown value), then we will try to merge the nodes and recheck them to see if it is a valid merge.  If it is not a valid merge, then a new CI would be created.

 

That is a quick overview of reconciliation... it might be more helpful to determine why 2 'duplicates' exist.  We would need to compare the nodes with eachother by the rule and find out which piece of reconciliation is failing.  It might be helpful to open a support case in this instance, or you could post the details of a pair of duplicates (all attached interface mac addresses and attached IP addresses plus the values that exist for the 2 nodes in their attributes) and we could tell you why UCMDB doesn't think those 2 nodes are the same.

 

Hope this helps!

 

Keith

Hope this helps,
Keith Paschal
UCMDB Worldwide Support Lead
Micro Focus Support
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution."

Click the KUDOS star on the left to say 'Thanks'

View solution in original post

Tags (1)
5 Replies
Absent Member.. Absent Member..
Absent Member..

Hello,

 

This would happen because there is not enough data to reconcile with. Changing between each other can change the data priority for the integrations. I strongly suggest to open a support ticket to further look into this issue.

Regards,

Ana Acosta-Diaz

"HP Support
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution."

Click the KUDOS star on the left to say 'Thanks'
0 Likes
Absent Member.. Absent Member..
Absent Member..

I am not sure what you mean when you say "there is not enough data to reconcile with."  These are simply Node CI's that have had significant changes since theor previous discovery.  Those changes are apparent, and I can see the differences.  Is there a way to tell uCMDB to keep the original CI and simply add, change, or remove the newly discovered informatino without creating a whole new Node CI ?

0 Likes
Micro Focus Expert
Micro Focus Expert

In reconciliation there are 3 major parts, identification, verification and validation.  These 3 parts do distinctly different things and try to identifiy the CI in question (node in this case) as unique or a duplicate with an existing node, in which case we would try to merge it with the existing node.  Problems can arise when we don't have enough reconciliation data to prove or disprove that the node is unique.  You can see the reconciliation rule in the CI Type manager on the details tab.  For example:  the node reconciliation rule uses identification data to see if it can match a wide set (positive match) of CIs that exist already.  This collects the mac addresses of connected interfaces to determine if 66% of them match, or 66% of IP Addresses associated match, if the name attribute is the same, snmp_sys_name, and so on.  Once this pool of potentially matched CIs is gathered, there are things that will make them unique.  Verification looks at differences and excludes CIs based on this (these things cannot ever be different on 2 CIs and be the same CI).  For node, if the node is a cluster_resource_group and has a different name, or if it has a different os_family, then they will never be matched and so a new CI would be created.  Next, we look at the validation rules to see if we have enough to match a node in our pool to the node we're trying to add in the data-in bulk (be it from discovery, an integration or even a user creating a CI).  In validation, we are looking for anything that might be a positive match.  Generally, in node, this would be a hardware attribute and a software attribue.  If a pair match (even though other validation rules don't match or return an unknown value), then we will try to merge the nodes and recheck them to see if it is a valid merge.  If it is not a valid merge, then a new CI would be created.

 

That is a quick overview of reconciliation... it might be more helpful to determine why 2 'duplicates' exist.  We would need to compare the nodes with eachother by the rule and find out which piece of reconciliation is failing.  It might be helpful to open a support case in this instance, or you could post the details of a pair of duplicates (all attached interface mac addresses and attached IP addresses plus the values that exist for the 2 nodes in their attributes) and we could tell you why UCMDB doesn't think those 2 nodes are the same.

 

Hope this helps!

 

Keith

Hope this helps,
Keith Paschal
UCMDB Worldwide Support Lead
Micro Focus Support
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution."

Click the KUDOS star on the left to say 'Thanks'

View solution in original post

Tags (1)
Fleet Admiral Fleet Admiral
Fleet Admiral

Nice explanation, Keith. To the bookmarks!

Regards
-Dmitry Gomel, PMP
Click the Like button at the bottom to say 'Thanks'.
0 Likes
Absent Member.. Absent Member..
Absent Member..

I agree.  Thank you for your help.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.