Multiple Virtual Center Servers

[Borat_Sagdiev]

A customer I am working with is looking to create a VI environment where each building would have a DAS/DRS cluster of its own and be fully functional in case one building is lost. Sounds simple, but what about Virtual Center? In case of VI loss, DAS/DRS/Vmotion is lost, but the hosts and VMs stay up, but what if it's a long outage where redundancy is needed?

Is it possible to create an environment where Virtual Center is redundant? Multiple VC servers?

[MR-T · Accepted solution]

You can have multiple VC's, but only one active per environment. (That is, each ESX host can only be managed by a single VC).

HA doesn't require VC to function, only to configure, Then it's self aware.

DRS & VMotion are dependant on VC though and it's this you may wish to have a recovery option available.

The main thing to look at with VC disaster recoery is the database. If you use SQL, try and implement somthing like log shipping to keep another copy of the data elsewhere.

The VC itself is just a simple application and service & you could have a 2nd VC created as a VM with the service disabled, pointing at a copy of the database.

It's a manual switch over, but with the correct processes in place, it works.

[esiebert7625]

An ESX server can only be managed by one VC server. You can run VirtualCenter as a VM and if you have HA configured it can be started on another ESX host.

Running VirtualCenter in a Virtual Machine - http://www.vmware.com/pdf/vi3_vc_in_vm.pdf

Running VC on a VM in production - http://www.vmware.com/community/message.jspa?messageID=635594#635594

[VirtualNoitall]

Hello,

For local recovery you can use MSCS to cluster Virtual Center and/or the database.

You can also setup the VC server as a virtual machine in an HA cluster for a higher level of availability.

Both are very common practises.

You could look at separate VC servers across sites if you don't want that single point of failure within one site.

[davidbarclay]

No,

Two separate instances of VC can not manage one ESX server (or cluster).

You need to replicate the existing somehow for D/R purposes, or have another instance and be prepared for some host re-registrations!

Dave

[DaveBerm]

Yes it is possible to cluster VC between two different buildings using software from my company, SteelEye Technology. The LifeKeeper for VMware Virtual Center Suite combines data replication with system and application level monitoring and failover of both VC and the underlying database (Oracle or SQL) for automatic recovery of VC in either the same data center or in your disaster recovery site, without re-registering the VMs!

You can find the details here...

http://www.steeleye.com/pdf/literature/lk_for_vmware_vc1h07.pdf

David A. Bermingham, MCSE

Director of Product Management

www.steeleye.com

Message was edited by:

DaveBerm

[DaveBerm]

A 30 day eval is also available from our website, www.steeleye.com

Message was edited by:

DaveBerm

[Borat_Sagdiev]

Thank you for all the info guys... I think I've found my solution though it has not been tested yet:

\- VC will run as a virtual machine on one cluster in building A

\- the database will run on an Oracle installation, the DBAs will babysit that

\- esxReplicator will replicate the VM to a cluster in building B thus giving us a constant ready version of the virtual center VM

\- the database replication will be handled to the DBAs to building B

Disaster Strikes! We bring up the replica of the VC virtual machine, we bring up the replica of the database. Tada!

What do you guys think? Will it work?

[BMMGaucho]

We have 2 sites but only 1 VC server. If we wanted to set up a VC server at the second site (with services stopped, etc as mentioned), would we just have to connect hosts to it? What signals to the ESX hosts that they are no longer managed by a VC server? can 1 VC server "steal" hosts away?

[esiebert7625]

Not positive but I think the mgmt-vmware and vmware-vpxa services on the ESX server are linked to the VC server. So the proper way to go about it is to remove the ESX hosts from the other VC and then just add them to the new VC server. If the original VC server was not available then you could probably just restart the mgmt-vmware and vmware-vpxa services and then add them to the new VC server.

[VirtualNoitall]

If the current VC server is unavailable just add the hosts to the new VC server. You will get a prompt that they are already managed by a VCMS but you can click OK and "steal" them.

[mreferre]

>esxReplicator will replicate the VM to a cluster in building B thus giving us

>a constant ready version of the virtual center VM

You don't need to do this strictly speaking. The VC server (as long as it's not also the db server) is not subject to any data delta of sort. Evertyhing happens in the database.

So you could just keep a dormant vm on the other site with VC installed (and configured to point to the same db) and when a problem occurs on the production vc machine you can start this one).

Of course using ESXreplicator would solve other management issues such as keeping VC releases in sync between the two vm's (i.e. if you install patch xyz on the production VC you have to apply manually that patch to the backup VC machine as well.......)

Massimo.

[WintelIBMBE]

Hi,

I did some testing and research on this. I started to cluster VC using Majority Node Set clustering of M$ with file share withness. It is vagely discribed in doc : http://www.vmware.com/vmtn/resources/945

And this works perfect, only one problem, how to make the back-end VC DB redundant ...

I don't consider clustering SQL 2005 as a full redundant solution because the SAN is a single point of failure.

So I thought of SQL2005 DB mirroring but this is not completly supported because an automatic failover is only possible when you use the SQL 2005 Native Client driver to let VC connect to the DB and that is according to the release notes not supported.

Second thought was using SQL2005 peer 2 peer replication, this makes 2 writable replica's. M$ warns about replication conflicts and that this should be handled on application level, but in this case no issue because only one node is actively running VC. But down side here is that not all tables of the VC DB have primary keys so we can't setup bi-dir. transactional replication.

I made a support ticket to ask for advice from Vmware, but no big results, only that I should raise a feature request. I told him I allready did twice but no reply. The support engineer told me that that was normal.

The chance the feature request is taken serious, is when a lot of people, ask for the same feature.

So let this be a call to everybody to raise a feature request making VC able to work with the SQL2005 Native client and/or change the VC DB that it's optimized for replication using transactional peer-2-peer replication.

Kind regards

[DaveBerm]

In the meantime, if you are looking for an alternate solution, you might want to check out LifeKeeper from my company, http://www.steeleye.com.

LifeKeeper for SQL Server is an alternative to MSCS and supports both shared storage or replication using SteelEye's Data Replication for Windows. In addition to LifeKeeper for SQL Server, we also have a cluster solution for Virtual Center.

Check out the following links for more details.

http://www.steeleye.com/pdf/literature/lk_for_vmware_vc1h07.pdf

http://www.steeleye.com/products/sqlserver.html

David Bermingham, MCSE

Director of Product Management

SteelEye Technology

[doctormiru]

Just to post another solution

We're running VC on a SAN boot config with replicated storage to 2nd location. In a disaster case we can switch quickly the active disks and power on the standby box.

regards

dr.miru