When we talk about federation in a CMDB implementation, it's because there are multiple data sources that need to be combined as a single repository (even if the data is not physically combined into one single database).
Having multiple data sources implies that they will many times refer to the same Configuration Item, raising the question of how to reconcile these records. Traditionally, CMDB products chose a primary key that is used to merge the data; however, my experience shows it's difficult to identify a single attribute that can be universally to identify a CI type. As an example, although a computer serial number might seems a good candidate, we have seen that many products don't provide such attribute, but relies on IP address as the identifier. The same argument can be used for IP address and any other attribute.
At IBM, we decided to take a different approach: instead of relying an attribute or a collection of attributes to uniquely identify a CI, we have defined many naming rules for each CI types and enforce that each data source provides the attribute of at least one rule. So if a product uses serial number to identify a CI, another uses serial number and IP address, and a third one, just IP address, this ingenious approach will be able to determine when they represent the same CI.
So the integration with IBM CCMDB is based on having products providing data according to a common data model in a process named Discovery Library Adapter.
The alternative of implementing this federation / reconciliation approach is to defer the reconciliation of the data instead of doing it before the data is imported into a CMDB. Some products define the concept of many buckets of data that are combined through a reconciliation mechanism. Although this approach simplifies the data loading process, it defers to the user the responsibility of federating and creates another hop in the data chain.
Next we'll talk about how we can use Tivoli products to assist in federating the data into a CMDB.
No comments:
Post a Comment