SRM server as part of a protection group

[komanek]

Hi,

I just tried a planned migration with interesting results and I would like to ask you to give me an advice for best practice on that:

- two sites, each with 3 ESXi 5.0 hosts and its own vCenter+SRM server running together on a VM with standalone win2008 r2 sp1 server (not part of a domain)

- each site has its own NetApp box with two primary NFS volumes and two replicas from the other site (snapmirror) plus one non-replicated mini-volume for SRM placeholders

- both primary volumes at each site are covered by protection groups and a recovery plan. It means SRM+vCenter server is part of its own protection group

In a disaster recovery mode, to finish the recovery plan, the vcenter+srm from the protection site has to be started, so it needs to be started on the recovery side.

In planned migration mode, the recovery plan cannot finnish because automated shutdown oh the vcenter+srm on the protected side breaks down the migration.

Distaster recovery is more important than planned migration, so I think that protecting vcenter+srm server by its own measures is all right. But what about the planned migration ? Is there a way to tell the SRM at the protected site to do everything what is needed and then shutdown without errors preventing the recovery plan to be completed from the recovery site ? I hope there is a better solution than to have another pair replicated volume just for the vcenter+srm server. As a workaround now I need to stop the rest of VMs at the protected site manually and re-run the recovery plan in DR mode once for moving to recovery site and then again to tell SRM that the machines were powered off at the protected site before it can advance to reprotection mode, which is far from an ideal solution.

Thanks on advance for comments and suggestions.

David

[mal_michael]

Hi,

The simpliest solution is to place SRM and vCenter VMs on separate, non-replicated volume.

Michael.

[komanek]

Thanks, but it will not work well, because if the production site dies, there will be no way to start these VMs in the disaster locality and to do a reprotect. It seems to me the DR and "planned migration" scenarios have contradictory requirements.

What happens if I give vCenter and SRM machines the 1st priority and everything else will be 2nd or later. Will it work well ?

UPDATE:

I tried planned migration from production to recovery site and back. The vCenter+SRM server was set priority 1 to be shut down at the very last moment. Stil, it does not work. In the case production => recovery site, the migration could be completed in DR mode. The transfer back in the oposite way was not possible, until I moved the vCenter+SRM to a different volume. It resulted in manula migration for this particular VM (remove from inventory at DR site, add to inventory at protected site, SVMotion to the protected volume, configure protaction).

So, the result is:

- for real DR, the vCenter+SRM need to live on protected volume

- for planned migration and recovery back to primary site, the vCenter+SRM need an extra volume

- real DR need to run vCenter+SRM servers for both sites to complete the DR scenario and reprotect before VMs can be migrated back to the primary site.

I am a bit disappointed, but I still hope, someone can give me an advice how to easily migrate between both sites without so many extra steps and hadrware needed. In my situation, there are only two netapp boxes, one per site and there is demand to do both DR and planned migrations as close to a "single hit on a button" as possible.

Thanks in advance,

David

Message was edited by: komanek

[komanek]

To reply to myself:

Possible solutions:

a) svmotion + remove from one and insert into another inventory vcenter/srm server before planned migration + reverse this after the planned outage - inventory operations require the vm to be shut down for a while, time consuming, not easy for operators

b) make an extra volume for vcenter/srm server which not part of protection group - the drawback is less storage capacity "in a pool" and higher free space "fragmentation"

c) run vcenter/srm servers out of virtual infrastructure - an expensive solution (an extra cost for at least two ohysical servers, physical space, hw maintenance, ....)

I choose "b".

David