SRM 5.5 VR Reprotect question in a 1:N setup

[tonelson13]

I am in the initial stages of testing a 1:N SRM 5.5 setup. I have vcenterA (production) and vcenterB (DR). I also have two remote clusters, clusterA (production, hosted on vcenterA) and clusterB (DR, hosted on vcenterB). I have a primary appliance deployed on the prod and DR vcenters, as well as an appliance at each remote site. (The connection is much faster directly between the remote sites then trying to route it through one of the vcenter locations)

The initial fail-over works flawlessly, but my issue is on the reprotection. When it configures the Storage & Protection in the reverse direction, it automatically assumes I want to use the primary VR appliance for that vcenter, and not the one at the remote site (which is added as an additional appliance under the vcenter, if I am setting up the initial replication I can easily specify the remote appliance, it is just the reprotect where there is an issue). Is there any config setting where I can set specific protection groups / recovery plans to reprotect on a specific VR appliance as opposed to the auto-assign? The "Move to" option is grayed out..

I have tested just removing the replication and recreating it on each server during the reprotect, which has worked in my test environment, but I would not want to do that in an actual DR situation as I feel like that amount of manual intervention adds a significant amount of risk...

[beefy147]

an old thread to bring up but after much research the only one which matches my own experiences. using SRM 5.5.1 and vsphere replication 5.5.1

we have 2 vCenter servers. each has a primary VR appliance but also 2 branch based VR's in other countries acting as a local DR source managed by the same vCenter instances

When setting up vsphere replication for a VM we can override the auto-assign and pick the appropriate VR to carry out the replication

an SRM fail-over works as expected. However the SRM re-protect is where issues start. it seems the re-protect auto assigns the VR to use and the logic behind auto assign is to use the VR with the least replications! Therefore it picks our branch based VR on a slow link causing long/impossible re-protect times. It also tries to do a full sync which doesn't seem right at all.

has anyone else experienced these quirks and or worked around them?

my only workaround might be to power off the branch VR's during a re-protect so it forcefully goes to the right place but this isn't a fantastic solution!

thanks