When VirtualCenter was first introduced, many could make the argument that VC was simply a utility class service that provided centralized management for a virtual infrastructure. If the VirtualCenter Management Server (VCMS) was rebooted in the middle of the day or if the VC services were stopped for some reason, it wasn’t too big of a deal providing the outage didn’t interrupt a key task such as a VMotion migration or a cloning process.

Times are changing. VirtualCenter is becoming a fairly critical component in the VI and high availability of VC and the VCMS is becoming increasingly important. Several factors have contributed to this evolution. To identify just a few:

• Virtual infrastructures are growing rapidly in the datacenter. The need for a functioning centralized management platform increases exponentially.
• Increased and more granular VC alerting capabilities are relied upon to keep administrators updated with timely information about the load and health of the VI.
• The introduction of more granular role base security extended Virtual Infrastructure Client or Web Access deployment to more users and groups in the organization increasing dependability on VC and visibility of downtime.
• The exposure of the VC API/SDK encouraged many new applications and tools to be written against VC. I’m talking about tools that provide important functions such as backup, reporting, automation, replication, capacity analysis, sVMotion, etc. Without VC running, these tools won’t work.
• The introduction of plugins. Plugins are going to be the preferred bolt on for most administrators because they snap in to a unified management interface. Obvious dependency on VC.
• The introduction of new features native to VC functionality. DRS, HA, DPM, VCB, Update Manager, Consolidation, snapshot manager, FT, SRM, etc. Like the bullet above, all of these features require a healthy functioning VCMS.
• The Virtual Datacenter OS was announced at VMworld 2008 and is comprised of the following essential components: Application vServices, Infrastructure vServices, Cloud vServices, and Management vServices. I don’t know about you, but to me those all sound like services that would need to be highly available. While it is not yet known exactly how existing VI components transform into the VDC-OS, we know the components are going to be integral to VMware’s vision and commitment to cloud computing which needs to be highly available, if not continuously available.

VirtualCenter has evolved from a cornerstone of ESX host management into the the entire foundation on which the VI will be built on. Try to imagine what the impacts will be in your environment if and when VirtualCenter is down now and in the future. Dependencies may have waltzed in that you didn’t realize.

A single VCMS design may be what you’re used to, but fortunately there exists a method by which VC may be made highly available on a multi-node Microsoft Cluster. This document, written by none other than my VI classroom training instructor Chris Skinner, explains how to cluster VirtualCenter 2.5.

If you’re on VirtualCenter 2.0.x, follow this version of the document instead.

Update:  Follow up post here.

• Previous Entry: Blog maintenance
• Next Entry: He sed / she sed