This chapter is from the book
This chapter is from the book
This chapter is from the book
A Brief Explanation of CMDB Federation
Federation, described in much greater detail in Chapter 4, is a new approach to maintain accurate configuration information about the IT environment, although the concepts behind federation date back to the 1980s. CMDB federation was proposed soon after the CMDB first gained traction on the coattails of ITIL, but formal federated CMDB acceptance has been elusive until recently. The new breakthrough is a definition for integrating data sources called the CMDB Federation standard. The name is not the most clever title, but its publication marks an important step toward a successful CMS. Developed by an ad hoc group of vendors called the CMDB Federation Working Group (CMDBf), the specification has now been handed off to the DMTF for further development. We explain the concepts and some details of the CMDBf specification in Chapter 6.
The federated model enables more flexibility than a monolithic database model. The standalone model was originally the accepted model and assumes all data is collected in a single database. This is impractical for a CMDB, as it is easily corrupted by synchronization issues with data that is usually geographically diverse and rapidly changing. The monolithic model places a heavy burden on the database, its related infrastructure, and the related administrators. Sheer resource utilization forces lengthy update intervals, which hamper timely updates to the database. Data quickly becomes stale in such a scenario, and stale data is more harmful than no data at all.
Federation enables a “divide and conquer” approach to the CMDB architecture, distributing the load and leveraging the optimum tools for each technology domain and locale. By using the best tool for a specific domain, the CMDB contents are better tailored to a domain’s unique needs and can be updated more frequently. Both result in higher accuracy.
To overcome CI differences and still capture the relevant data for the CMDB, the CI definition extends beyond a simple single-table database structure. Relational databases can be used to organize and capture these CIs in a more complete form across multiple linked tables, although the interchange and federation of data is best addressed by object-oriented technologies such as object repositories and XML. If a relational database is used for the remote linking, federating the data is much more cumbersome. Many will dispute this assertion, but the explosive success of XML is evidence enough that it is the superior mechanism for linking and exchanging remote data. This fact does not diminish any RDBMS for what it does best. The RDBMS is indeed integral to the many pockets of the CMDB. It just doesn’t work well for the complex linking of the distributed and seemingly disparate data sources. For this, XML works best in partnership with the databases.
In federation, the data is spread across multiple CMDBs, more accurately referred to as Management Data Repositories (MDR), illustrated with the simplified example in Figure 2.6. There is no single CMDB. Instead, the aggregate “CMDB” is an abstraction built upon the contents of the MDRs, and metadata models dictate the assembly of relevant MDR data based upon needs. The MDRs may reside in different systems and data storage formats. Federation is at the heart of what ITIL v3 now refers to as the Configuration Management System (CMS).
)
Figure 2.6 CMS relationships across MDRs
If the CIs from Figure 2.3 are reflected in a federated structure, you would see something similar to Figure 2.6. Here, the MDRs are aligned with domains as we advise in the CI candidate descriptions.
){kind=link}
Note how the HR database is represented as one of the MDRs. Two of the CI categories are embodied within the same database, with a relationship inherent inside the database. This relationship is a branch of the federation structure, even though it appears to be isolated. This illusion of isolation results from viewing federation too myopically.
The HR database is maintained separately from most other MDRs, but its inclusion emphasizes a growing practice in the whole CMDB arena, that of the foreign CMDB. A foreign CMDB is an element (an MDR, if you will) that is not under direct control of the IT organization or those responsible for the CMDB architecture, design, and operation. It is a data source rich in information that can be used, but it is available only in a “read-only” mode. There is nothing wrong with this. In fact, it is indicative of the future, as third parties will assume more responsibility for certain domains and therefore the MDRs and CMDBs of those domains. Your overall CMDB needs this data, so proper integration and federation are needed beyond just the HR database.