RecoverPoint for Virtual Machine (RP4VM) allows you to create disaster recovery per Virtual Machine in your vSphere environment. By itself, the application is great because you can pick and choose what VMs to protect, test failover and even restore your production VM at various points in time. However, if you have vRealize Automation (vRA) and the vendor is trying to sell you the miracle of self-service DRaaS that RP4VM+vRA can bring, you may want think harder about it.
Note: this is a review of 4.3, but I didn’t think much changed for 5.0
1. Very limited set of services from vRA blueprint, not true DRaaS
A very limited set of services are exposed to the automation blueprint. As far as I am aware, there are no other means of creating customized workflow if the standard blueprint does not satisfy you requirements for DRaaS. There are no blueprints to perform production failover, test failover nor to manage CGs or protected VMs. The current blueprint only allows a user to create protected VMs. All other administration has to be done from vSphere.
2. Limited access to CG on blueprint
When creating a new protected VM from blueprint, you have to specify a consistency group (CG). The CG is tied to the user account who created it, that is the CG is only exposed to this user’s account. If another team member tries wants to use the same CG for another VM that he is creating, he is out of luck; the CG is not visible to this user. The problem is that when a CG is created from blueprint, the email address of the user is tagged into the name, e.g. email@example.com-MyNewCG1. Only the user account with the same email can see that CG from the blueprint and add protected VMs to it.
This obviously don’t work well in an highly controlled enterprise environment like in a bank or where you have teams of staff to support that application function. It is ridiculous that only one person can manage a production CG, because this never happens in a bank.
3. No mapping of networks between two sites
When you create a protected VM on a stretched network using NSX cross vCenter features, the replicated instance’s network will default to a random network. This is because in a cross vCenter NSX setup, the network names on both sides are different even though they are within the same stretched L3 IP network. So whenever you create a new protected VM, you need to manually edit the network on the cloned instance to the correct one. There are no functions to map one network to another during the protection.
4. No control over CG creation in vRA blueprint and limited CGs per RP4VM cluster
Each RP4VM cluster can support up to 128 CGs. This is not a big issue if RP4VM is managed by cloud admins. But it will be a nightmare if you allow users to create their own CGs via blueprints and you have no control over this. Further more with a limit of 1024 VMs per vCenter, this number fills up very fast when you have no control
This is not to say that RP4VM is not a good product. Its a great product the allows VM specific DR protection and provide DR testing and recovery features. Now each application owner can arrange to test their own DR (with admin folks I guess) solutions anytime. In a tradition site-to-site DR, you only know if your application DR works when you have a full scale failover.
However, if DELL EMC is trying to sell you DRaaS with vRA, then its way too immature as a product for self-service and automation.