19 September, 2023
November 27, 2022
VMware’s Site Recovery Manager, introduced around 15 years ago, is a policy-based management tool that automates failover and failback to ensure minimal downtime during a disaster. Unlike VCDR, which I discussed here, SRM was explicitly designed to replicate data using physical storage or vSphere replication appliances. It is a powerful solution that enables the replication of entire data centers with the help of extensive automations, automated testing, recoveries, and reporting.
There is a decent amount of overlap between VCDR and SRM. Here’s how to figure out which is right for your needs:
Reporting and functionality for SRM and VCDR are comparable; the difference is in the location of the replication: SRM is relevant only for on-prem to on-prem replication, while VCDR can replicate on-prem to the cloud and cloud to on-prem. Further, SRM is asynchronous, meaning that it uses a data gap between transactions, not live protection. As such, SRM users also need to utilize other solutions, such as a stretch cluster or application-level-based DR solutions.
Infrastructure Ownership Models
SRM is a great option for companies that own their data center. For example, one of TeraSky’s clients, a large Malaysian TelCo company, wanted to protect one data center from another in different countries. SRM was clearly the best solution for this scenario; plus, we then scaled it to additional locations and were able to protect more than 2000 VMs at once. In cases like this, SRM simplifies management, ensures fast and reliable recovery times, and lowers the total cost of ownership.
On the other hand, VCDR’s on-demand DRaaS model provides more flexibility for those who either do not own a second DC or who have two or more locations for their environments. Unlike SRM, VDCR is fully developed and maintained by VMware engineers, with standardized services accessed on an identical VMware console. VMware claims 99.999% availability.
Some things for SRM users to keep in mind are that not all configurations are supported, and you cannot replicate virtual machines that have shared storage between them (like RDM storage, legacy database engines, etc.). Further, large VMs with high I/O needs might require other types of solutions for data protection, like: always-on for SQL server, or an application-level (rather than infrastructure-level) approach are two potential options.
No Matter What, Prep is Key
SRM users face similar challenges to VCDR users, often stemming from the need to determine protection groups. While customers usually want everything protected, the cost in terms of pricing for resources can be prohibitive. As such, I work with them, train them to use the solution, demonstrate it before implementation, and conduct stress tests for a variety of scenarios. This process supports the client by answering all of their questions and helping them decide how to prioritize their needs.
|VMware Cloud Disaster Recovery||Site Recovery Manager|
|Protected site||On-prem or VMware Cloud on AWS SDDC||On-prem, hyperscalers SDDC (Azure VMware Service (AWS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Service (OCVS)|
|Recovery site||VMware Cloud on AWS SDDC||On-prem or hyperscalers SDDC (AWS, GCVE, or OCVS)|
|Recovery site SDDC requirement||No||Yes|
|RPO||30mins||5 mins (vSphere Replication) 0 mins (array-based replication only)|
|Recovery points||±1000 per VM||24 with vSphere Replication|
|Synchronous replication||No||Only with array-based replication|
|Multi-writer disk support?||No||Only with array-based replication|
|RDM support||No||Only with array-based replication|
|RTO||Fast RTO (“Live mount” reduces recovery time)
When used without a pre-provisioned SDDC, it is required to deploy it. Usually, it could take up to 2 hrs.
|Faster RTO. Pre-provisioned failover capacity.|
|Costs||Per VM/hour + per TB||Per protected VM|
|Deployment type||SaaS in the cloud||Manual solution installation|
|Solution support||VMware Managed||Customer managed/maintained|
Written by: Sirijus Dailidonis, Senior Systems Engineer