Site Recovery Manager

SRM Multi-Site Options

Most of the time, SRM is deployed as a single site to single site solution. This is something SRM has done well since the first version. What isn’t as widely known is all the different ways that SRM works in multi-site configurations. Deploying SRM in multi-site topologies provides flexibility to support a wide variety of use cases and business requirements. To learn more about the creative ways SRM can be setup in multiple site arrangements, read on!


SRM and Stretched Clusters

VSAN Stretched and SRM

SRM and stretched clusters, either VMware Virtual SAN Stretched Clusters or vSphere Metro Storage Clusters (vMSC), work well together to provide local as well as remote disaster recovery. This solution provides rapid recovery from widespread disasters that affect both sites in a stretched cluster. This is accomplished by having the stretched cluster support protection of the VMs at the local sites, and having SRM provide protection for VMs running at one or both of the local/stretched cluster sites to a third site, and by treating the stretched cluster sites as a single site from the SRM perspective. Where this solution works especially well is when the two stretched storage sites are close enough as to be impacted by the same event. An added benefit of this solution is support for zero-downtime disaster avoidance between the sites that make up the stretched cluster.


Consider datacenters situated in New York City and across the river in New Jersey configured with a VMware Virtual SAN stretched cluster with the third site located in Arizona. If either the New York or New Jersey site went offline, VMware Virtual SAN and vSphere HA would automatically recover the VMs at the other site. If both New York metro area data centers were affected, SRM could be used to perform a rapid, reliable recovery at the data center in Arizona. The approach provides multiple levels of resiliency and risk reduction.


Shared Recovery and Shared Protection Sites


SRM Shared Protection Recovery


The shared recovery site model has been supported by SRM for a long time and is one of the most common of the multi-site topologies in use. It provides a good option to protect virtual machines at remote sites that have local vCenters. This model can support flexibility when it comes to resources at the recovery site. To minimize resource requirements, provide only enough resources at the shared recovery site to recover one or two of the remote sites. Or if the ability to recover all remote sites at the same time is required, sufficient resources to accomplish that can be provided, or some option in between.


SRM enables precise control over which workloads are failed over. For example, if a disaster only impacts one remote site, SRM can be designed to recover only the VMs at that site while still protecting the other sites. If budget to build out a DR site is limited, it is possible to provision just enough resources to facilitate the failover of one or two of the remote sites since it is unlikely that a number of geographically separate sites will need to perform disaster recovery at the same time. Having a vCenter at the protected and recovery sites allows both of these options to offer the advantage of supporting vSphere management operations even if the link between the primary and remote sites is down.


Shared Recovery Site – Central vCenter Option


SRM Shared Recovery Central VC


There are other ways of providing the same kind of protection offered by the shared recovery site configuration discussed previously. In the configuration shown above, instead of deploying a vCenter and SRM server at each remote site, we deploy the protected site vCenter and SRM server at the recovery site. The advantage to this arrangement is that it simplifies management and reduces the number of vCenters and SRM servers required for remote sites. The downside is that if the link to the remote site is down, the remote site hosts would lose connectivity to their vCenter with the resulting loss of manageability. Note that as with any correct SRM configuration, recovery would still work without issue even if the remote site link is unavailable.


Additional Multi-Site Topologies


In addition to the above topologies, as of SRM 5.8 and higher, SRM now supports other arrangements as long as the following requirements are met:

  • As seen in the diagrams in this post, SRM requires that it be deployed in pairs

  • SRM supports a maximum of 10 SRM server pairs

  • As outlined in the diagrams there needs to be a vCenter server at each “site” (in the central vCenter option above we are treating all remote sites as a single protected “site”)
  • Each VM can only be protected a single time/by a single SRM pair
  • SRM only supports point-to-point replication. It does not currently support replication to multiple destinations

SRM 3 site config

This topology would support a three (or more) site topology where:

  • Virtual Machines at Site A are protected at Site B
  • Virtual Machines at Site B are protected at Site C
  • Virtual Machines at Site C are protected at Site A


Additional notes on SRM multi-site


Multi-site topologies work quite well for data center consolidation as well. SRM is already an excellent solution for migrations. Multi-site topologies provide additional flexibility to allow SRM to handle any number of complex scenarios.


The examples above aren’t close to a complete list of possible topologies. As long as the design adheres to the requirements listed above there are numerous other configurations that would work.


With all of the above examples, SRM can orchestrate and automate the reprotection of workloads after failover or migration. This provides the ability not just to failover but to failback.


SRM multi-site management improvements




In the latest releases of SRM (5.8, 6.0 and 6.1) there have also been significant improvements to the use and manageability of SRM multi-site configuration. First, it is now possible to convert an existing SRM installation to multi-site. Previously SRM had to be configured from the initial installation to support multi-sites. SRM now supports configuration for multi-site regardless of how it was initially configured.




Second, with the migration of SRM to the vSphere Web Client the management of multiple sites has been vastly improved and simplified. Sites, Protection Groups and Recovery plans are now organized around the configuration of their pairing. This makes daily operations much easier and more intuitive.



  • SRM supports a number of different options when it comes to multi-site configurations
  • Pay attention to the limits and requirements for SRM and multi-site
  • Take advantage of the recent improvements to SRM around management and usability



22 comments have been added so far

  1. Hi,

    great article: thanks alot! One question: Would it be possible to use SRM mutually on two sites? To be able to recover site A on site B, but also site B on site A?

    Best Regards,

  2. Older post but just now found this and what to ask about this quote: “First, it is now possible to convert an existing SRM installation to multi-site. Previously SRM had to be configured from the initial installation to support multi-sites. SRM now supports configuration for multi-site regardless of how it was initially configured.”

    I’m unable to find documentation for any version that talks about converting an existing install to a multi-site. Can you point us in the right direction?

  3. This was first enabled in SRM 5.8. It is in the documentation here:

    “You can convert an existing one-to-one configuration of Site Recovery Manager into a shared recovery site configuration. To convert a one-to-one configuration to a shared recovery site configuration, you deploy additional Site Recovery Manager Server and vCenter Server instances as protected sites, and pair them with additional Site Recovery Manager Server instances that all connect to the existing vCenter Server instance on the recovery site. Each pair of Site Recovery Manager Server instances in the shared recovery site configuration must use a different Site Recovery Manager extension ID. For example, if you installed a one-to-one configuration that uses the default Site Recovery Manager extension ID, you must deploy all subsequent Site Recovery Manager Server pairs with different custom extension IDs.”

  4. Thanks for the reply! I was hoping there would be a way to actually convert an existing one-to-one relationship to a one-many without having to build new SRM servers and recreate everything, but it does not appear there is a way to do that?

  5. Are you using a version of SRM earlier than 5.8? If so, there isn’t a way to convert it to one-to-many without reinstalling. If you are using 5.8 or later just follow the documentation.

    As this post highlights, SRM is deployed in pairs so when you convert a site to site config to a multi-site config you are just deploying additional SRM pairs. In 5.8 and higher nothing happens to your existing pair. Make sense?

  6. Yes, and I just did that yesterday and got it working by setting up two SRM servers on both sides, one using a new vCenter and on the recovery side using an existing vCenter already paired and it worked. However, Recovery Plans, Resource Mappings, Test network mappings, etc all exist between the pairs. Unless I’m just not understanding, there’s no way to shares those between the two pairs. Therefore, in my production configuration, I have to recreate all of that from scratch unless there’s a migration option I’m not aware of. Again, thanks for the replies!

  7. You are correct, those things exist between pairs. There isn’t a way to share or migrate those settings between SRM server pairs. Since the pairs are usually deployed at different sites (different vCenters) there isn’t often much that could be shared anyway.

  8. hi,
    Is it possible to replication one VM to multiple target sites with vSphere replication (say to two recovery locations)?

  9. Not currently. VR can replicate different VMs to different sites, not the same VM to multiple sites.

  10. However, it’s possible if you were to use array based replication to one site and vSphere replication to the other.

  11. Yes, that is possible for replication, not currently for protection by SRM. SRM would only be able to protect the VM for one of the two legs at a time.

  12. Thanks for all the information.!

    1. Is it possible and okay if multiple sites say (6-7 sites) are managed by one common VCenter and have to configuration VM based replication from these sites to a single DR using SRM.?
    **Currently only one VCenter is managing these different sites as multiple clusters.
    2. Can Only one cluster be failed over in a disaster situation while other.
    3. Install multiple VCenters on each site in linked mode (unsure if one VC Console can be used to achieve above manageability/ ease of use).?

  13. 1. Yes. Keep in mind that SRM isn’t a replication solution, it uses either vSphere Replication or Array-based replication. The requirement for SRM is a VC at each “site”. A “site” could span multiple physical sites if that is desired, just make sure to keep in mind what that means in the event of failures.
    2. Not sure what you’re asking. SRM can run 10 recovery plans at the same time. These don’t have to just be a single cluster.
    3. Multiple VCs can be installed in linked mode within a site, keep in mind that each SRM server is paired with a single VC

  14. Thanks a lot for your response.
    Sorry my question 2 was not complete or clear.

    2. I meant if there is only one central VC managing multiple physical sites, configured as different clusters within this single VC. – Can only one Cluster be failed over (disaster) while others continue to function normally.?

    3. I believe this option of having multiple VC (linked mode) and SRM paring on all sites makes manageability more painful compared to already having a central VC for all sites as we speak. – Advise Please.

    So I believe it will be considered as single site paring if using Central VC topology while we can always define protection groups, cluster wise to segregate and identify these physically apart clusters.

  15. 2. Yes. VMs are failed over, not clusters. So some/all VMs from one cluster can be failed over and none from a different cluster
    3. Not sure what the comparison is here. With one VC you don’t have DR, with SRM and multiple VC you do.

  16. Nice article,

    My questions is, for multi site SRM deployment. Correct me if I am wrong. I need VC on each remote site including central site. but how many SRM license I required to purchase? In my case, including all remote site it will not go more that 25 application VMs.


  17. SRM is licensed per protected VM. That licensing doesn’t change when using a multi-site configuration. If you are protecting 25 VMs you would need 25 licenses, regardless of if you were using a single pair of SRM servers or multiple pairs. There is no license for the SRM servers themselves.

  18. Hi,

    Can I have a scenario as mentioned below

    I have 2 sites configured on Stretched cluster with some VMs on it.

    I have a DR site which is away and needs to have this site as a DR for my stretched cluster environment.

    Can I have stretched cluster + SRM ?

    How does this work?

  19. We are planning to setup multi-site SRM topology in order to use it for datacenter consolidation between 3 sites.
    Existing Primary and DR sites have an SRM paired and working. We have come up with a new DR site. In order to migrate workload from older DR site to new DR site, we have performed custom install of SRM on new DR site with custom site pairing ID and while we install the corresponding New instance of SRM on older DR site, it threw up an warning stating,

    “vCenter in older DR site already has a registered extension for SRM. Are you sure, you want to overwrite the existing registration.”

    I am concerned about the existing pairing between primary site and old DR site breaking.

    Any suggestions, on how to implemented this topology without breaking the existing configuration.

Leave a Reply

Your email address will not be published.