I have received a few questions lately asking how Dell EMC’s RP4VMs (RecoverPoint for VMs) compares to VMware’s SRM (Site Recovery Manager). SRM alone does not directly compare to RP4VMs so this is one of those “it depends” kind of answers, but I will do my best to explain here. To understand how to compare the two, we need to first look at each of their jobs, because they each solution has a different purpose.
VMware SRM is used to failing over VMs in the case of a disaster and determining the startup order for the VMs. It doesn’t do any replication itself. It is designed to solve the RTO (Recovery Time Objective) of a DR plan where something like vSphere Replicator (or even traditional RecoverPoint) will take care of the RPO (Recovery Point Objective). This is why vSphere Replicator (VR) is often used alongside SRM. Because needs something else to actually move/replicate the data to the other site.
RecoverPoint for VMs on the other hand, can do both the replication and failover itself. RecoverPoint for VMs provides integrated management and orchestration with VMware vCenter Server at no additional cost. SRM should only be used with RecoverPoint replication for storage arrays. Because of this, RecoverPoint for VMs does not work with VMware SRM (Site Recovery Manager). RecoverPoint for VMs can co-exist with SRM+VR. However, there is a limitation that each solution is used to protect different VMs.
That being said, I would say it would come down to if you put more value on your RTO or on your RPO. RP4VMs is more efficient with replicating data to a DR site because it has advanced features like WAN optimization (Dedupe and Compression over the WAN), the DVR like roll back with journaling, it offers synchronous replication, and multi-site support with up to 4:1 fan-in for centralized DR site protecting multiple branch offices (and 1:4 fan-out replication). It even has the ability to replicate to AWS S3 with the latest code in 5.2.1, whereas SRM only has integration with vCloud Air today. SRM with VR is more efficient at failing over VMs to another site since you can set the priority of individual VMs (instead of whole consistency groups like in RP4VMs). Plus you have the ability to ability to set the sequence of VMs to start up so that certain VMs that need to be up first (i.e. Active Directory, Domain controller, etc.) will start before everything else. That is more of a manual task for RP4VMs.
As far price goes, each solution is different. vSphere replicator is free but it is limited. For VR, the best RPO you can get is 5 minute and it can only be applied to a maximum of 100 VMs on VMFS 6.0, VMFS 5.x, NFS 4.1, NFS 3,
and vSAN 6.2 Update 3 storage and later. The maximum for VVOL datastore is 50 VMs. So it is very limited and you get what you pay for. The only added cost is where you add on SRM to provide the automated failover, and it isn’t cheap. Site Recovery Manager Standard Edition is designed for smaller environments and is limited to 75 protected virtual machines per site and per instance of Site Recovery Manager. According to VMware’s site, Site Recovery Manager Standard Edition costs about $6,080. Meanwhile, for RP4VMs you get the replication for RPO and automated failover for RTO at a Per VM or Per Socket price. I went over the pricing for RP4VMs in detail here.
Of course, if you want 0 RPO and 0 RTO and you are using vSAN, you could just leverage vSAN Stretched Clusters. Then you wouldn’t have to worry about failovers or replication times, but that is a post for another day. 😊
In the meantime, I hope this helps.
It is possible to set per VM priority within RP4VMs CG. So it is on a VM level just like in SRM.
Nope, it’s on a per CG bases, not per VM like SRM. That’s also a great point to consider as well.