As virtualization becomes more and more pervasive across the data center, many of my customers are now considering their vCenter Server as a tier 1 application. This means more focus is being places on maintaining the availability of vCenter Server. To quote Gene Kranz:
vCenter Server is central to the following aspects of a virtualized data center:
- provides DRS & DPM monitoring and host load management
- enables vMotion (central to both DRS and DPM)
- centralized management portal for all VMs and ESX server running in a cluster (ESX and VMs still run without vCenter, but management become much more cumbersome)
- feeding data from VMs and ESX to other IT management platforms
- hosts SRM plugin for VM business continuity between data centers
- provisions desktops for View (desktop virtualization)
There are a number of different strategies that can be taken to provide availability of the vCenter Server, these typically fall into one of two categories: a cold standby server or a warm standby server. Since the time needed to manually bring up a cold standby server for a large vSphere deployment can easily reach into the hours, most large organization tend toward a warm standby scenario and leverage some software automation to trigger the fail over. There are many options here that fall into the general categories of clustering or host replication. These tend to be complex and not always application specific.
To fill this gap and provide the monitoring and fail over needs of running vCenter Server as a teir 1 application, VMware recently released vCenter Server Heartbeat, which provides monitoring and automated fail over of both the vCenter Server and (optionally) the vCenter database.
Key aspects of Center Server Heartbeat:
- Monitors application (vCenter Server and optionally vCenter Database), network, and OS
- underlying technology licensed from NeverFail for vCenter Server and SQL Server awareness and fail over
- Supports VM or Physical deployments of vCenter Server
- Uses replication engine to replicate data and transactions to standby server
- fail over of vCenter and Database across wan or LAN
- Protects from Split Brain scenario if a network outage were to occur
- Fail over of IP address so all hosts/VMs continue to function with vCenter normally
- Easy to configure, auto cloning of vCenter Server VMs (if deployed virtually) to create stand by server
My recommended approach to providing Tier 1 availability of the vCenter server
- Ideally: run your vCenter server as a VM and utizliae vCenter Server Heartbeat to monitor and fail over vCenter. All accomplished with the minimal amount of configuration due to vCenter Server Heartbeat’s VM cloning capabilities.
- Minimally: run vCenter server as a VM and configure a HA pair for that VM. vCenter HA operates independantly of vCenter Server and will function even when the vCenter serer fails. Becuase it is designed to provide general HA for a wide variety of situations, it is not application aware like vCenter Server Heartbeat. Also, many architects don’t prefer this solution becuase the fail over is being provided by the tool that you are trying to protect. But, it is better than no fail over solution for vCenter Server.
Good article and thanks. Quick question….
Outside of the VM cloning feature and the cost of physical HW is there any advantage to running both VC’s as VM’s?
We are looking at the 2 physical servers model right now for a new DC. I have to admit the VM option is nice, but for mission critical I am just wondering if VM’s for vc is the way to go or not? (cost issues aside).
Thanks!
[Reply]
latoga Reply:
April 14th, 2009 at 7:31 pm
Other than the reasons mentioned above for running your VC virtualized, I guess I would ask the question why wouldn’t you? If you are comfortable running other Tier 1 applications in a VM or if you have a virtualization first policy for applications, why not not run VC in a VM? I’m seriously curious what others give as reasons for not running your VC in a VM…please post your opinion.
[Reply]
Well that’s a great point. First understand that I’m considered the crazy renegade who thinks he can virtualize anything at my office. In other words I’m the least conservative when it comes to these things.
Now to give you an example, we used to have some some of our hardware monitoring servers on physical hardware because we needed something “out of band” that could monitor the ESX hardware. Now with CIM/SMASH support in the vCenter health monitor this is less important (along with other agentless methods) so the next time this question comes up, I will most likely push for this to be virtualized as well.
When it comes to vCenter I think it’s just our cautionary prejudice that makes us wonder if this is a goog idea or not. But as you point out with your challenge, is there really a technical reason why a virtualized vCenter with vHeartbeat is less safe than a physical one?
First of all you’ll have anti-affinity rules to keep the 2 servers on different hosts. And if a host does fail, vHeartbeat will function the same with VM’s as with physical servers.
So unless I’m missing something, I’m so far not able to come up with a scenario with vCenter that could be handled better with physical servers than with virtual servers.
On a side note we have Neverfail today running on VM’s that run Blackberry’s BES software. WE’ve had to deal with some of the cloneing issues manually so I can really appreciate how the VM clone feature in vHEartbeat would be a big time saver!
Now….how do I convince the rest of my office that this is a safe thing to do? 🙂
[Reply]
Running VC in a VM = you enjoy making your job more diffucult! If (no when) the shit hits the fan in your ESX enviroment, you will want a rock solid fondation on which to debug your enviroment in the hopes of restoring service (or improving service) ASAP. Why would you install your cluster-level admin/debugging tool IN the same cluster!?!? …because you really don’t want to see your kid and wife???
Servers are cheap, don’t complicate your life needlessly…we have cell phones, iPads, and the Internet for that.
[Reply]