2 Replies Latest reply on Dec 3, 2018 11:38 PM by Andrew Mark Shaw

    CI duplication

    Andrew Mark Shaw

      Hi,

       

      I realise this is perhaps more CMDB related, but hs anyone any advice on how to avoid CMDB CI duplication of data coming in from Discovery? We have a number of scenarios where Discovery behaviour creates challenges on the CMDB side:

       

      P2V: A new host is discovered with a new set of SI's. The physical host becomes superseded, but as we wait for it to age out, we effectively end up with duplication in CMDB (Asset dataset).

       

      SI Key change: Increased permissions on the target server allow Discovery to capture additional data, resulting in SI key change. While the earlier SI ages out we must contend with duplication in CMDB (Asset dataset).

       

      There are other examples, but understanding the above might help us to understand the rest.

       

      While we would expect to see all CI's in Discovery's CMDB dataset, we would expect recon to maintain a single CI record in the Asset dataset. We're trying hard to introduce consistency into the Asset dataset, especially where federated data is linked to a CI. Are there any recommendations on how to build a workflow to avoid duplicate CI's (with unique keys) getting into Asset?

        • 1. Re: CI duplication
          Brian Morris

          For P2V you probably have a different serial number, so reconciliation can't uniquely identify the server if nothing else changes and you don't include this value. I think the merge operation wouldn't work if you were less specific and just wanted the new virtual system to update the old Asset record as there would be 2 records in BMC.ADDM (and the physical record is still tied to the Asset record).

           

          For the original EOL system, maybe have as part of your change management ticket for the P2V process, one task to set the old record to End of Life or perhaps some other meaningful status, maybe MarkAsDeleted after you see both records if you want it out of your Asset Dataset.  Add another change task to scan the new virtual system which hould get your new record in.  Another consideration here is that any relationships you've made from the old CI to other tickets, changes, people, etc wouldn't be on the new record.

           

          If you wanted to keep all that, you'd probably want to set the MAD flag in BMC.ADDM and manually identify the new virtual record with the same Recon ID as the one in Asset, so then the new system updates the old record. Set the reconID for the old physical one to 0.  This isn't meant as a blueprint on how to do this, just some thoughts.

           

          For the SI keychange - this is a bit more difficult because you may not be expecting this to happen necessarily, so you'd just end up with duplicate data and an Asset record that stops updating since we no longer have a unique match for the ID criteria in BMC.ADDM.Monitoring the CMDB reconciliation logs for Identification errors about non-unique records would help you find these.

          2 of 2 people found this helpful
          • 2. Re: CI duplication
            Andrew Mark Shaw

            Hi Brian,

             

            Thanks for taking the time to respond to this post. We've discussed internally and come to a similar conclusion - that there is no easy way to avoid temporary duplication in the asset dataset where one CI has become superseded. As you suggest, we could fast-track MAD by manually destroying nodes as part of the CR workflow, but that doesn't resolve the actual challenge we have: an SI in Asset that has federated data linked to it should retain its federated data in a P2V event (or any event that triggers SI key change). That said, I've forwarded your suggestion on setting the reconID to 0 to our CMDB guys.

             

            I feel that we will have to rework the CMDB/federation workflow simply because Discovery CI's are ephemeral - however much we would rather they were not. Another example on expectations: the team would like a DR SI failover to happen transparently with no impact to the existing SI CI in Asset - only a relationship change from SI to Host. It probably needs a different approach.

             

            Anyway, thanks again for your reply.