So a lot of customers use Site Recovery Manager as the tool to automate their Disaster Recovery Policy, usually it’s deployed on an one-to-one relationship – i.e. a single protected site and a single recovery site where the SRM/vCenter server on the protected site is paired to a SRM/vCenter server on the recovery site.
Not many people are aware that since SRM 4.0 you could actually set up a Shared Recovery Site which allows you to ‘fan-in’ your recovery from several protected sites (ie N-to-1 relationship).
This could be very useful if an organization has several remote/branch offices and requires them to be protected by a single shared site. Another example is where a service provider offers business continuity services to multiple customers – DR-as-a-Service.
In a shared recovery site configuration, you install one SRM Server instance on each protected site. On the recovery site, you install multiple SRM Server instances to pair with each SRM Server instance on the protected sites (so if you had two protected sites, in the recovery site you need to deploy two SRM servers).
All of the SRM Server instances on the shared recovery site connect to the same vCenter Server instance.
Similar to how standard SRM is deployed, you can use either array-based replication or vSphere replication.
SRM Server A (Field Office 1) is paired to SRM Server C (HO)
SRM Server B (Field Office 2) is paired to SRM Server D (HO)
So what are the limitations of a Shared Recovery Site?
- You can’t reconfigure an existing standard SRM deployment to use a shared recovery site, this is because a custom installer is used when deploying SRM which allows you to set the SRM Identifier (which must be identical for the SRM pair).
- Each instance of the SRM Server at the shared recovery site must be deployed on its own host machine, ie you can’t deploy multiple SRM servers on the same VM.
- Each instance of the SRM server requires its own database.
- You’re limited to a maximum of 10 protected sites per shared recovery site.
- When accessing SRM through vCenter Server on the shared recovery site, you can view all the SRM extensions (and pairs) and hence see all the VMs, protection groups, recovery plans, etc.
One thing you need to be very careful with is how your solution is licensed if you’re thinking about using the Reprotect functionality of SRM (or bi-directional protection).
As with standard 1:1 SRM deployments, you can re-use your protected site SRM licenses at the recovery site (assuming they are no longer in use at the protected site) and invoke reprotect/failback.
However, if you use a new set of keys at the recovery site, then you need to ensure you have enough licenses to cover the VMs that need to be reprotected.
Site A – licensed to protect 20 VMs.
Site B – licensed to protect 10 VMs.
Shared Recovery Site – licensed to protect 25 VMs.
If you don’t transfer the licenses from the protected site to the shared recovery site, then you can only perform reprotect on 25 VMs. If you recover all of the VMs from sites A and B to the shared recovery site and attempt to perform reprotect, you have sufficient licenses to reprotect only 25 of the 30 VMs that you recovered!
The Operational Limits for SRM in a shared recovery site can be found here:
At some point before Christmas I’m hoping to get this all up and running in MTI’s demo centre…… =)