How do you protect vCenter?
August 10, 2011 
Sean Crookston 
vCenter is more and more becoming a critical piece to remain online at all time. By no means am I saying that it wasn’t always nice or a good idea to protect vCenter, but more and more products outside of vSphere or advanced features such as the distributed virtual switch and VMware View have a greater reliance on vCenter then just the hosts themselves. While the above mentioned will continue to run as is, any updates to networking or recomposition of desktops would not happen.
vCenter Heartbeat is a solution albeit a fairly costly one for smaller deployments that provides vCenter redundancy. I recently found out you can even deploy this across the WAN as long as you have a reasonable network connection and the system shares the same date/time zone settings. Additionally in the future release you will now have full protection for the View Composer database.
My question to everyone is what is your experience with vCenter Heartbeat ? I have not talked with many who have used the product so I’d also be curious to know what other methods you prefer to protect vCenter?
Another consideration is whether to virtualize vCenter or not. One of your design decisions here is do you want to place the management server on the set of hosts its managing? If you choose to do so you can take advantage of HA and DRS too keep the machine highly available in the event of host failures and smart placement to ensure resource, but what about in a situation where the whole environment goes down and vCenter can’t come back up? Again this may not be a decision driven strictly by technical requirements, but policy itself.
If you are interested in learning a bit more about heartbeat you can check out one of my previous posts for the VCAP-DCA study guide here.
Tags: 
I can only speak from a small 5 node 100 VM cluster. We currently run vCenter as a VM to take advantage of the options you mentioned (HA & DRS) as this was better suited then running it on a single physical server as MS clustering also was not an option.
For us getting into the cost of using vCHB off set the potential risk of being unable to manage the environment as whole in case of an extreme emergency. This may change in the future as we begin to migrate towards VDI solutions, but will cross that bridge when we get there.
-Jason
Hi Sean
Starting with your second question, I always recommend virtualising vCenter servers. I can’t see any practical reason why you wouldn’t. You get to take advantage of HA, DRS, snapshots, storage mirroring for BR, hardware independence etc. There are no performance limitations with running vCenter as a VM. If you have a big environment split vCenter and SQL into separate VMs. You will use the benefits of virtualisation far more than having it isolated as a physical server.
I’ve written before on the limitations of the current architecture of vCenter in terms of availability which unfortunately aren’t really addressed in vSphere 5.
http://www.wooditwork.com/2010/11/25/why-vcenter-is-letting-vmwares-side-down/
As for vCenter Heartbeat, I’ve used it in production for 2 Linked Mode vCenters with separate heartbeat protected SQL Servers.
I found the WAN mode just didn’t work as well as expected. I thought it could solve availability and DR in one solution but I had issues with vCHB updating the IP address and failover happening when it shouldn’t have (It was a gigabit network between primary and secondary site)
I’ve then changed the mode to work in a LAN mode for local availbility which has worked fairly well. No IP address change required. With the current version I am on, 6.3, the secondary is entirely off the network. The secondary gets re-cloned and re-added to the Heratbeat cluster manually after monthly security patching and also to update the computer domain secure password account. If you don’t do this then when you fail over your secondary falls off the domain. The new version allows the secondary to be on the network and get managed like another VM but I haven’t tested this yet.
For BR we use storage mirroring to mirror both vCenter and SQL VM pairs to a secondary site (along with many other VMs) and then bring up just the primary (using DHCP to get a new IP address) in the BR site and vCenter is available in BR.
Currently we are not using heartbeat in our customers. I will start using it for Enterprise Plus customers from here on out.
I am typical fine with using Veeam’s insta restore feature for vCenter.
I’ve run vCHB as a proof of concept, but found that when suffering a multiple blade outage (and therefore the loss of both the primary and secodary vCHB VMs), there was significant manual input required to get back up and running. vCHB doesn’t appear to automatically re-initialise as Primary/Secondary and become available.