What happened to the CMDB (Configuration Management Database) - the heart and soul of the "new" management frameworks? Well, they are still around as part of the Big 4 and others portfolios - but the onset of virtualization and cloud has thrown them a "curveball."


Just to recap, a CMDB was defined as "a repository of information related to all the components of an information system" [1]. This was updated in ITIL v3 to the CMS or "Configuration Management System" as "a set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships" [2]. A broad goal of the CMDB can be defined as a being a key enabler in delivering IT as a service through improved incident and problem management (root cause and impact analysis), change management, auditing and compliance amongst others. A worthy goal indeed - and a goal that is more relevant than ever with virtualization and cloud getting us closer to true service delivery models and blurring the traditional boundaries across technology domains, organizational roles and management disciplines.

Virtualization and the clouds they help enable bring their own set of challenges through. Bernd Herzog does a great job in his article here and here at describing many of them. 

Some similar key challenges we see brought about by virtualization and cloud include:

  • New Objects - We have a new class of objects to deal with. Virtualization has in essence defined a new "blueprint" for the datacenter. There are new abstractions like clusters, resource pools and so forth. This is important because it doesn't always make sense anymore to manage in the weeds every piece of data - we need to bubble it up to the right level of abstraction upon which decisions can be made.
  • New Relationships - How does this new set of objects relate to one another? VMs, files, hosts, clusters, datastores, and applications - we need to understand how all of these things tie together, whether we are trying to troubleshoot a performance issue, plan for capacity or understand the impact of changes.
  • Rate of change - It was arguable whether traditional CMDBs could keep up with the rate of change in a physical environment, let alone a virtual one. Technologies like vMotion, Storage vMotion for example mean we need to have continuous discovery to keep the new relationships above up to date.
  • More than configuration - Virtualization is blurring boundaries - configuration changes can strongly correlate to performance, and affect capacity and so on. We need a unified approach that brings (and ties) together performance and service assurance information in addition to configuration data.
  • Needle in a haystack -  Many CMDBs offer rudimentary search capabilities - but how do we leverage this to search across unified and integrated data sets to make sure the right people get the right insights they need?

When you speak to those with highly virtualized environments, it's not uncommon to hear comments on the CMDB like "yeah, that's the data warehouse thing that we populate with information occasionally - we don't use it" or "CMDBs don't work for virtualization/clouds - they don't keep up".


Take Away - The goal of a CMDB is more relevant than ever, how it gets delivered has to change in a virtual environment.


[1] http://en.wikipedia.org/wiki/Configuration_management_database

[2] http://wiki.en.it-processmaps.com/index.php/Service_Asset_and_Configuration_Management