This chapter is from the book
This chapter is from the book
This chapter is from the book
Reconciliation
In the existing world of CMDB, reconciliation is considered to be a necessity and indeed it is...today. Reconciliation is the synchronization of two or more matching database segments to ensure consistency across them. Data stores that should be identical copies are compared. If any differences exist, the reconciliation engine attempts to correct this inconsistency. Most existing CMDBs are isolated, and integration involves a periodic upload or download of bulk data. It is not federation. In this “unfederated” model, data synchronization decays over time. The copies drift apart and become inaccurate. Reconciliation attempts to sync the CMDBs, usually in a brute-force manner that scans all CMDBs and makes corrections as the reconciliation engine finds discrepancies.
Reconciliation is driven by policies that determine who “wins” when a conflict arises. Some may be by majority vote (for example, three of the four CMDBs agree, so the fourth is forced into agreement), some by pre-establishing the winner (for example, the network CMDB is the trusted source for the network), and others can get more complicated. Full reconciliation can be automated to correct the discrepancy, or it can merely inform a CMDB manager to take action to reconcile. Initial phases will be the latter, but those that are trustworthy or become annoyingly repetitive can be automated.
Figure 2.8 shows a simplified example of three CMDB instances where reconciliation is needed. This VMware virtual server is identical across all instances except for the middle one’s physical host. This is a bit like that Sesame Street game “one of these things is not like the other.”
)
Figure 2.8 Three CMDBs needing reconciliation
The reconciliation engine scans these three and recognizes this discrepancy. It can either notify someone of the issue or it can correct it to match the other two. If automated action is taken, you must be absolutely certain that the results will be as desired. In this situation, one might think that the “majority vote” rule would apply, but that middle instance might be the trusted source extracted directly from VMware. Because it reflects the truth, it has precedence over the other two, and they, not the middle one, must be corrected. As systems become more dynamic (for example, virtualization), situations like this will become more common. By the way, Europa is the sixth moon of Jupiter, so of course the middle instance is right!
No matter how you view reconciliation, all agree that it is difficult to get it right and even harder to get it properly automated. From firsthand experience, we can tell you that there will be many weeks and months spent tweaking your reconciliation rules to try and automate the reconciliation process. The ideal CMS would eliminate reconciliation because it is too painful (our VMware example is only the tip of the iceberg). As the CMDB gets ever closer to the CMS ideal, we will approach the ideal of eliminating the need for reconciliation. When we finally achieve that ideal is a great mystery, but don’t expect to totally shed reconciliation before 2012.
A properly federated CMS will significantly minimize the need for reconciliation because the very nature of federation (as you will see in Chapter 4.) implies that data is always captured and managed only once. There is no need to reconcile CI details because there should never be duplicate copies! The only attributes that are duplicated—and therefore need reconciliation—are those representing the matching criteria for referencing the relevant data. As in RDBMS development, these are the indices (the matching attributes) to point to the right federated data. Even these attributes will eventually graduate beyond a need for reconciliation as better XML-based remote-linking technologies emerge. Technologies that enable an idealized view of federation are only now beginning to appear. Over the next several years, vendors and end users alike will chip away at the pockets of duplicate data. Someday we will tackle that final step, but be patient and diligent. If there was ever a real-life situation where “slow and steady wins the race” in IT, it is in the pursuit of a true CMS.