Setting up a remote disaster recovery site

[VBDINO]

Hi, I need your opinion or experience on setting up a remote disaster recovery site. At a remote site elsewhere in the city, we have expanded our datacenter to include a cluster of 3 ESX hosts connected to their own SAN. There is only one Virtual Center installation at the primary site.

We replicate LUNs that are exploited by physicals servers, to the secondary SAN. In case of disaster, an already running VM, will be connected to those replicas using raw device. Then DFS setting will be updated to point to that VM.

We also replicate a VMFS LUN. In case of disaster, we will add this replica lun to the ESX cluster and inventory the VMs.

About Virtual Center, we thought of copying the database to the remote site, and disaster happen to primary site, reinstall Virtual Center on secondary site using the latest backup of VC database.

Problem is that all ESX hosts points to a server at primary site, for VC and licensing. So re-using the database, would require cleaning up.

So I am not sure if there is a real benefit to recover the database, during a disaster.

What are you opinions or experiences on this subject?

Thanks

[polysulfide]

One option is to run a p2v on your VC server as part of your backup proceedure. Make sure its not powered on and gets replicated. Then a DNS update at the DR site would point your ESX hosts at the Virtualized copy of your VC server.

This would preserve the realtionship, ssl certs, etc. You would also need to make sure you had a replicated copy of your database if it's not local to your VC.

As with any DR and backup reccomendation, I reccomend thorough testing of any suggestions before relying on them.

The main benefit is the cluster configuration information, permissions, etc.

You could also setup a 2nd VC at the DR site, make the local ESX hosts local to that server and import the replicated vms at the DR site.

If it was useful, give me credit

http://communities.vmware.com/blogs/polysulfide

VI From Concept to Implementation

[mike_laspina]

Hi,

There are some importent factors you may want to consider here.

Replicated LUNs may be in an inconsistent state depending on the application and method of replication. This should not be the only method of protection, use application side backups.

Relication of LUNs does not protect from corruption or human error. Use point in time images/snapshots.

Since the ESX hosts may be different on the DR side your VC database is not that critical, you can import the machines if required etc.

Virtualization of the VC can speed up and automate the DR process.

Keep in mind that the VC is useless without a functional AD and DNS

Many VC addressing components rely on having the same VC IP address so having that subnet available at DR is a good thing.

[mitchellm3]

Another option would be to create a new VC server in the DR site. Then Have the DR ESX hosts point to that.

Cons: You will have to open up two VC client sessions to manage all your ESX hosts and VMs. I prefer it all to be in one management console.

You will have to pay for a second VC license + OS license and hardware if you want it to be physical

Pros: You will not have to worry about restoring a VC server when disaster strikes...one less thing, eh?

You will have the proper DR setup if you decide to buy VMwares DRS when it comes available. (this helps with the IP addressing...so they say)

[VBDINO]

What if I would install a virtual center with licensing, on the server at secondary site and leave it as is. Then if necessary because the primary gets down, I would add my three esx hosts and create a cluster. And then start up my VMs.

For the replicated LUN, we assume the risk of corruption but I will look into a backup alternative.

Richard

[mike_laspina · Accepted solution]

Installing and configuring a functional inactive VCat the DR site is a good idea, it does not take long to add hosts to it and it is more or less just a tool.

[VBDINO]

I am also considering to install a new VC at secondary site. Then disable VC services. Then replicate database, etc. to remote site over existing data.

Then if it becomes necessary, I would change the ip address of this secondary installation, to the ip address of my closed primary installation. Note that our vlan for this virtual center is extended to the remote site. I presume then, that all ESX servers still running, will be able to see the VC server without any differences

[mike_laspina]

You will need to copy over the certs and you would have to rename it to the original name as well for it to work that way.

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL

[blp848]

What I have done works very well for us. We have 2 sites which storage is replicated between. My virtual center servers are Boot from san and I have a physical server at both locations that is mapped to the same storage as it's boot device. I run out of Site A all the time but if Site A were to go down I just need to power on Site B and everthing is back up in running in a couple minutes.