Putting CMDBs On a Pedestal: In the Cloud
From research and my recent conversations with co-workers and analysts,
A Pedestal in the Clouds: Accelerating Your Virtualization Journey
it seems clear that there is an increasing awareness that the existing notion of a configuration management database (CMDB) — where it is the central repository for all information about the data center and the decisions are made for its management — is an unrealistic and problematic model.
In today’s data center, the rate of change alone is too daunting a task for any one database management solution to effectively handle.
However, the CMDB remains a key piece of the puzzle because it offers a single place where we can go to make critical decisions about how to optimize operations, address configuration issues, and triage problems and service outages.
We need the CMDB — especially as our data centers continue down the road of virtualization and make their way to the private cloud. But we need to make sure that it has not only up-to-date and accurate information, but has the “right” information and that it provides federated access to real-time information about the resources that underpin the critical business services. Without integration from the discovery to the CMDB - and without integration between the discovery sources - this simply is not possible.
So, rather than continuously building new connectors to link discovery to our CMDB and hope that it can reconcile all the configuration items (CIs), EMC offers a new approach…Perhaps it’s not new…It’s actually well aligned with the ITIL v3 concept of a configuration management system (CMS)where the CMDB is part (a critical part) of a more modular and federated approach to configuration visibility across the data center.
EMC Ionix Data Center Insight offers a single integration point for best-of-breed discovery across applications, servers, network devices, and storage — inclusive of virtual environments. On top of this, it deduplicates CI data so a customer can reconcile CIs. It provides - through a Web services interface - virtualization of cross-domain dependency maps and the applied “best practices” based CIs to EMC’s (and third-party) CMDBs.
The result is a practical approach to populating and managing a CMDB with the “right” information, such that customers can easily understand the resources that underpin the business services. And they can visualize the infrastructure dependencies so they can more effectively plan changes and avoid inadvertently disrupting business services. With this, customers have all the foundational components needed to build an effective configuration management system — while making the most of their existing environments.
In my opinion, this is a real game-changer and I look forward to the continued buzz (and philosophical debate) that the announcement has already generated.
Thoughts???
Jeff Abbott
Related posts:
- EMC Ionix - From Physical to Virtual to Cloud…It’s a Whole New Ballgame Today, we announced EMC Ionix - a next-generation IT management...
- You’re Terminated? Hardly…Automating IT Simply Makes Life Easier Rise of the Machines The movie “The Terminator” paints a...
- Extra! Extra! - Big EMC News at VMworld Some big news rolling out today from EMC Ionix at...
- The Evolution of Ionix Ionix: The New Frontier Late last week, EMC and VMware...
- Deep In the Heart Of…IT Service Management Finally, I’ve had a chance to catch my breath -...
Related posts brought to you by Yet Another Related Posts Plugin.
Change and Configuration, Cloud, Configuration Management Database (CMDB) Population, Dependency Mapping
Hi Jeff,
I’ve been working with large scale (Global) it operations related problems for over 15 years now and with CMDB related questions about 7-8 years. I think the problem is that most involved think backwards when it comes to the CMDB and what to put in there.
The working methodlogy should be like this:
1) Empty CMDB.
2) Anything that only used or dependant of own responsabilities, its no need to put it into the CMDB.
3) If something is used or depending of other than your own responsabilities, the CMDB is the tool to relate the config needed in between.
Example:
I’m responsibl for a unixserver with a DB which is run by others that is used by others.
Manual
1) manually put the unixserver CI into the CMDB.
2) Manually put the DB CI into the CMDB
3) Relate the two togeather.
Discovery
4) Make a “DiscoverUnixserverService” CI, which you relate to the unixserver and a “DiscoverDBService” CI which you relate to the DB.
5) The discover tool is setup to query the CMDB for stuff to discover and find two CI’s. To be able to do the actual discover some information is needed. This information is stored in the relation-attributes between the Discoverservices CI’s and the Unix/DB CI’s. For example: IPAdr, DB user/passwd.
6) So what should the Discover tool discover and feed into the two CI’s attributelists? Of course ONLY that is needed by other Services. Example, we need a monitor that act as a user doing periodic client test against the DB. This test of course is a “MonitoringService CI” which maybe need the DB version, and more. The discover tool discover the attributes as they are also listed in the specific DB Discover Service to be discovered.
It take a while before one realizes that the discovery tool is the most critical part of the CMDB - AND how it’s own configuration MUST be handled within the CMDB. I’ve seen places were it take 6-7 years of failing CMDB projects. Most comes onto the correct track in thinking when they realize that it’s just like standard SOA mapping, and belive me… It takes time
Just a thought, you asked for it….
/Roberth
Great insight Roberth. This aligns well with the approach of Data Center Insight, where we focus on using the CMDB for the configuration information that relates to the infrastructure dependencies, and then leverage real time access to the discovery sources themselves for deep level configuration information of a particular domain.