VMware Site Recovery Manager (SRM) is a disaster recovery technology that allows VMware ESX environments to be replicated to a secondary site. The ability to move protected virtual servers between sites quickly and easily takes away a lot of the difficulty associated with implementing a Disaster Recovery (DR) solution. SRM does require a significant investment in hardware and high performance links (fibre is recommended) between sites making it a solution for larger sites.
SRM leverages SAN to SAN replication technology to keep up to date copies of the production Virtual Servers at the recovery site. Any changes made to production servers are replicated in real-time to the recovery site. The recovery site has VMware host servers with Virtual Servers in a shutdown state, in even of a failure at the production site, these servers are started (manually or automatically). SRM uses plug-ins to manage the underlying SAN storage environment simplifying management of the total solution.
Testing and validation of the recovery site is often one of the most complexed and often difficult parts of managing a DR site. One of the best features of SRM is the testing functionality. This allows the recovery site to be tested without shutting down the production environment. VLAN’s are used to isolate the recovery site during the test. This lowers the risks and costs associated with testing the site.
Recovery time is essentially the time taken to boot up the recovery site. Multiple protection groups can be created and started in a predefined order. Within a protection group, servers can be give priorities e.g. Active Directory starts before Exchange servers which start before Citrix and Blackberry.
Basic requirements:
- Two VMware farms (a production farm and a recovery farm)
- Two VMware vCentre servers (one at each site)
- Two SAN’s with replication between sites (a wide range of SAN’s are supported)
SRM can fill a big part of the Disaster Recovery jigsaw and should be considered by any organisation with a VMware environment and DR needs. It is a competitive solution in terms of functionality and low on going management costs. It does require high performance data links between sites so ensure you can get and afford those services at the start of the planning process.
SharePoint lightbulb moments 
Hello Steve
Was wondering if using SRM for SharePoint 2013 will be a good idea. Having the primary environment under a DMZ and planning the DR to the secondary environment which will also be in a DMZ. Do you suggest SRM here.
Also heard that Microsoft does not recommend SRM for SharePoint 2013, Please provide your advise on my above points, thank you.
Regards
Harshaa Annadurai
Hi Harshaa,
You are correct that Microsoft don’t support SRM with SharePoint 2013. Supported methods are generally SQL replication based – using SQL logshipping to keep a secondary replicate of the SharePoint configuration and content databases in-sync at your secondary site. A good starting point for planning SharePoint Disaster Recovery is this Technet Article https://technet.microsoft.com/en-us/library/ff628971.aspx
I hope this helps.
Regards,
Steve
FYI the technet article you mentioned actually supports the usage of VM image shipping (as you have with SRM) for warm standby purposes. The use of database centric replication technologies is typically a hot standby approach. For further reference I’d note that sharepoint does provide a VSS writer so that image level copies can be application consistent rather than crash consistent as well, see https://msdn.microsoft.com/en-us/library/office/cc264326.aspx
Thanks Ben, it’s been a long time since I worked with SRM. Appreciate the comments here.