Virtual Center server failover

[Arkady]

Hi,

I am looking for a solution for Virtual Center failover. Can I run a second VC server (connected to the database) with Virtual Center disabled? If primary VC server goes down, enabled VC on the second server. Can I have 2 Virtual center servers running at the same time?

Thank you in advance!

[Troy_Clavell · Accepted solution]

You can cluster VC....

[RParker]

Hmmm... interesting...

But not quite good enough. They will still have different IP and operationally the cluster may stay alive, but for connections it won't know which VC will accept the incoming connections. Not to mention if you have only 1 VC license, it won't work, since VC isn't deisgned for clustering...

[vmroyale]

You can have the standby server sitting in wait mode like you said. You can also use Microsoft Clusters. Check the two links below for more info:

http://www.vmwarewolf.com/clustering-virtual-center-for-availability/

http://www.vmware.com/resources/techresources/945

[Borat_Sagdiev]

Arkady,

To answer your questions:

1) No, you can not run a second VC connected to the same database. I recently tested this with a client using VC 2.5 and SQL2000.

2) While you can run 2 VCs at the same time, they need to be connected to different databases and no one VM can be managed by two separate Virtual Centers.

If your VC server is virtual machine you may want to consider using Vizioncore's vReplicator to replciate the VC server to an alternate location and use either vReplicator or log shipping to protect the database. Log shipping would be more reliable.

Andrew.

[RParker]

In theory this could work, but I don't think this is possible. VC isn't really a cluster server, and the only reason why VC even goes down is because if someone shuts the server off or the database is offline. VC is pretty stable. If you keep it running on good hardware, you should be fine.

This is where a iLO or DRAC card would come in handy, or if its a VM, you can start the server remotely.

[Troy_Clavell]

Hmmm... interesting...

But not quite good enough. They will still have different IP and operationally the cluster may stay alive, but for connections it won't know which VC will accept the incoming connections. Not to mention if you have only 1 VC license, it won't work, since VC isn't deisgned for clustering...

Why do you think VMware would put out a white paper on how to cluster your VC server if it won't work? I have never seen a clustered VC enviornment, but from what I have read in the .pdf, it seems as though it "should" work just fine.

[Arkady]

Andrew,

If I install the second VC server without connecting to a database? When primary goes down, I will establish connectivity to a database on the second VC server. Will it work?

[Borat_Sagdiev]

Arkady,

Koneshno, eto vozmozhno. Virtual Center sam po sebe bez uma kak skazat. Vso shto tam proishodit, derzhitsa v database. Znachit samoye glavnoye delo, eto database. Yesli u vas yest copia, ili replica database, mozhno luboy Virtual Center ustanovit, i soyedenit k database i budet srazu kak bilo ranshe. K state 2 nedeli nazad y atak i zdelal u klienta katoriy poprosil pomosh zdelat upgrade ivo Virtual Center hardware.

Good Luck! (I'm taking a guess here that you can read Russian )

Andrew

[RParker]

Well first from a purely operational point of view both machines will have unique IP's. So when one goes down, you must use DNS to resolve the name to the other server, at the point the first goes down. And if you can't have 2 connections to the same database, and the services are running.. I just don't see how this would work.

I see the whitepaper, I will look it over. But unless someone ACTUALLY tests it for viability, it's a theory not a given at this point. I say it sounds good but in a Datacenter this is going to wreak havoc. MCS is good for 2 servers that run but not be required to have external access, even the first link points out that you must have the same configuration files in both servers for this to work.. which isn't a big deal, but maintaining the configuration across 2 servers is going to be a lot of work. This hasn't been mentioned very much either, so either that means VC isn't going down or this is just too much work to make it feasible.

I am thinking that VC if maintained properly should be sufficient. This goes back to the server that isn't used by users will not become a problem. I have many Windows boxes that are up 24/7 for several years with only planned reboots with no issue, so I don't see VC being an issue either.

One issue that's readily apparent is most people don't have spare resources available to setup 2 DB servers and 2 VC. This is for standby in case VC goes down, which how many times does that really happen? I realize the importance of HA for VC, but maintaining good practices on the VC, restrict use to only admins (that can login via RDP) and make sure it's healthy, the VC will work fine.

This would make a good project for someone with lots of spare time...

[Arkady]

Andrew,

Yours guess is right.

Probably I will end up with this scenario instead of clustering. I will have a physical server with VC connected to a database, and virtual VC server without connectivity to a database as a failover.

Arkady

[Borat_Sagdiev]

Good plan. Make sure you keep the Virtual Center versions in synch. Example: If your production version is 2.5.0 Build 64192, your backup version should be the same. Later.

[RParker]

That's a good point, since most people have VC in a VM anyway, why not make regular backups? If one VM fails, the other can be brought online, identical to the first, no?

[Troy_Clavell]

points well taken... I do agree. However, as you stated, this would

be a great project for someone to see if in fact what Vmware says will

work will actually work in a functional capacity. MSCS does have it

benefits, such as using it to backend a VC SQL 2005 database.

Thanks, Richard!

[Borat_Sagdiev]

Why Mr. Parker! Gasp! :smileymischief: I have actually seen the exact opposite - most people use a physical machine for VC unless they have no spare hardware. I know VMware wrote a whitepaper on this topic and yes, you can certainly run VC in a virtual machine, but that adds an extra layer of Catch22 that sysadmins usually try to avoid. Also in large enviornments running it in a VM may make things sluggish.

[hicksj]

Agreed with Borat (re: physical VC servers). We just run Converter against our physical VC system, to create a backup copy of our VC server. If the physical ever totally fails, we could bring up the P2V'd clone. Essentially, just run the P2V process whenever the VC version changes.

Regards, J

[Arkady]

VMWare recommended to use a physical server as VC - this is their Best Practices. But running VC on a virtual machine is also supported solution.

Just a fact that VC will be running on ESX host with shared resources does not look attractive.

[dinny]

Yup,

I use the same methodology as Hicksj,

I run VC on a physical server - but use vmware converter to back it up to a VM.

I leave that VM powered off, unless I need to use it (or test it) in which case I power off the physical server (so there are no IP/DNS conflicts).

I then reclone it whenever the VC version changes.

The SQL DB (that both connect to) is on a separate SQL MSCS cluster.

Dinny