Inchoate Curmudgeon

An intriguing aspect of ITIL change expected in a virtualization project is CMDB. I missed this on my recent post on ITIL and virtualization. It’s a funny slip, in the sense I’ve been pondering this subject quite a bit lately.

Virtualization concepts are increasingly realized in all the classic components of infrastructure: compute, storage, and networking. What impacts might you expect to CMDB for enterprises deploying virtualization technologies? What are the particular challenges with respect to CMDB and virtualization?

The pondering for me started with a combination training trip and workshop sort of exercise to a CMDB vendor recently. The workshop was more focused on the use of the CMDB as an embedded component of another facility, not a classic CMDB implementation in an enterprise. I was probably more interested in the general and typical utility of the product myself, not having much direct experience with CMDB implementations.

What struck me were the exchanges we had with the vendor with respect to modeling virtualized infrastructure and components. The issue is that this CMDB implementation, like most if not all others I imagine, really had no existing constructs to deal with many emerging virtualization concepts. Furthermore, we were having some trouble describing these technologies in a way that the vendor could discern how they should be modeled. A lot of this could be attributed to discussing abstract concepts that were not realized as physical components in the infrastructure. Grasping abstractions is just naturally harder than grasping boxes and wires.

There was no particular difficulty with the concept of a VLAN, or a service IP or VIP, this is relatively mature technology. There was much more trouble with more nuanced differences between technologies like Solaris Zones versus VMware or Xen type virtualization technologies, and some of the networking concepts like virtual NICs and the impact of real or virtual VLAN tagging on interfaces as they relate to things like link aggregation. I feel like we only scratched the surface insofar as discovering all the modeling challenges.

The problem with this as it is related to CMDB is that many of the core use cases involve understanding the impacts of change and the impacts of component outages on dependent services. If you can’t model relationships correctly, the utility of the CMDB is significantly eroded. Jamming a virtual thing into a CMDB as though it were a real thing probably won’t cut it.

There’s also an irony. The need for CMDB in IT operations is far greater when using virtualization than when you aren’t. As an example of the kinds of issues we face, in my little own three machine lab, I have an explosion of DNS entries related to dozens of virtual machines, and I can no longer remember if these things still exist and where they are or were realized. I have iSCSI LUNs that are used both as direct attach block devices to real machines and others that are used by VMware to provide storage to dozens of machines, and others that are direct attach to virtual machines *within* the VMware infrastructure. The mind boggles.

Discounting the completely unconstrained lab as a good example of our modern, discipled and constrained enterprise architectures (*cough*, *cough*), it seems there is still a vast gapping chasm between what we need in a CMDB and what can currently be readily realized, both in terms of our collective experience and understanding as well as the readily available tools.

Trackback URI | Comments RSS