Idea ID 1647650
It is needed to synchronize all important Cis between 2 UCMDB to have all of them in one main UCMDB. It is also needed to synchronise the data with a “UCMDB Push”, including the deletion of Cis, and is needed to discover and synchronise everything every day. Since the data is huge, cannot do full push all the time, so it is needed to do delta sync.
1- UCMDB doesn’t look what the target UCMDB have when he wants to sync. The sender UCMDB just keep a baseline of what he thought was previously transferred, so it’s already not really robust at first. And if you modify a TQL, then the baseline change, so it’s creating more problems to know what needs to be deleted or not in the target system.
2- The new specific problem that we saw, is that a CI will be deleted in the target system as soon as it’s not in a TQL anymore, even if the CI still exist, only because a relationship is not there anymore.
Let’s take the next 2 little TQL (See attachments). The relationship is 1-N, to avoid pushing everything everywhere all the time. So on day 1, a computer has a tcp port and installed software, so it’s in both TQL and send the data correctly to the other UCMDB. On day 2, this computer doesn’t have tcp ports anymore but still have the software. Since it’s not in the first TQL anymore, the server would be deleted in the destination UCMDB, ouch.
Possible solution :
A) Merge both TQL in 1 TQL. But since in reality I have many tql and some a lot more complex, it would be really big to include everything with optional Cis in the same TQL. And in this case, if a node have 0 ports and 0 software at a given time, it would delete the node anyway execpt if I include my soluation #B. And it would be long to test to confirm that there’s no error.
B) In each TQL, do 0-N relationship instead of 1-N everywhere. That way, all the servers would be push in both TQL, even if they have no port or no software at a given time. In theory, it would work, but it would make my TQL containing a lot more CI. In a simple example like that it would not be too big to include all nodes in both, but since I have many tql, and some are more complex, it would create a really big load to try to put 0-N relationship on everything. Some tql would move from few thousands Cis to few millions Cis, and many would be duplicate from other TQL. And I would have to include my solution #A at the same time to avoid duplicate data as much as possible. And it would be long to test to confirm that there’s no error.
C) Was tried to “hide” some object in my tql, to only push the main CI in a TQL and the relationship, but it failed because the node or other related Cis were often mandatory.
D) Could stop to include the deletion in the push job. The problem is that there would be no way to clean up the data in the destination UCMDB. Could not have aging unabled, cause aging doesn’t support multi ucmdb. I say this because the delta push doesn’t sync data when there was only a touch to it. So if a CI doesn’t change, in the first system, it would become old in the target system without any way to know if it should really be deleted or not. And even if you could include the delta sync to sync when there’s only a touch since we discover everything every day, it means or delta sync would become a full sync, and it would be too big.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.