Dell EMC today announced the impending availability of RecoverPoint (RP) 5.1 which is built for use with VMAX3 and VMAX All Flash (I’m just going to use VMAX3 from here forward). You may recall that RP is available on VMAX2 but can only be attached to a VMAX3 via VPLEX. I have a paper that actually uses both VPLEX and VMAX2 with RP which you can check out if interested. This new release is similar to the VMAX2 configuration, though with some important differences which I’ll go through. My explanation below is going to assume a VMAX3 at each site, though of course heterogeneous implementations are very common.
The new implementation with VMAX3 does not use a splitter where every I/O is captured by RP; instead it uses VMAX3 TimeFinder SnapVX technology. Through snaps, changes are forwarded to the local or remote array. This is a very efficient way to do replication, however it means by design it is an asynchronous process only. It is most analogous to XtremIO’s implementation of RP. Note that when there is a non-VMAX3 array at the remote site, a splitter will be used. For those who have used RP in the past, I should mention that the terms CRR (continuous remote replication) and CDP (continuous data replication) are no longer used. This is straightforward enough seeing as the replication is not continuous.
The configuration of RP on the VMAX3 is more automated than the VMAX2. There is a new SYMCLI binary, symrpi, which does most of the configuration for the user. Once the zoning is complete, you need only create an initiator group with all the RPA HBAs and a port group following naming conventions for RP. Then issue the setup command:
symrpi -sid xxx -cluster <cluster_name> environment -setup -repository
That single command will create the repository, Gatekeepers, and the masking view for both. Then create the journals:
symrpi –sid xxx –cluster <cluster_name> create –journal –cap xx GB –N xx
That’s it. The storage groups will be created with the naming “_RP_<cluster>_Journal/SG/Attic“. Now you are ready to protect a storage group. This command makes the storage group available to protect in the GUI.
symrpi –sid xxx –cluster <cluster_name> protect –sg <sg_name>
You’ll also need to run the same CLI against the remote storage group so it is available to pair with the local storage group.
At this point you can use the RP GUI to configure all the options. The GUI is essentially the same as one I used in the previously mentioned whitepaper.
Here are some important considerations of note:
- RP protects at the storage group level only, you cannot protect a subset of devices in that group or individual devices (unless it is the only one in a storage group)
- Four copies are supported (production and three copies)
- RP appliances must by physical, there are no virtual RPAs (vRPAs would be for RP4VM)
- RP does not support using devices with RP that are already part of an SRDF relationship (this is a change from the VMAX2 implementation)
- Only asynchronous replication with varied options for when to take snapshots. There is a minimum snapshot interval of 1 minute. There is a screenshot of it here – note that synchronous is grayed-out
So with that covered, let’s get to the SRM part of the post. RP has an SRA that integrates with VMware SRM to do both testing and failover. In fact you don’t even need an updated SRA for RP with VMAX, the current one is fine. You can download it from VMware’s site. When running test failover in SRM one of the benefits of RP is that you can assign which bookmark you wish to test. This is accomplished through Virtual Storage Integrator and is done at the VM level (any VM that is part of the consistency group):
You can see the bookmark is assigned at the consistency group level. You can also select an expiration date after which the SRA will use the latest bookmark. Remember that RP bookmarks are not application-consistent, just crash consistent. If you need application consistency you can use AppSync to create the bookmark and then assign that in VSI. I created a demo of this so you can see how it is achieved.
There is one configuration issue I want to call out since I hit it each time I rebuild my environment. When you add an array manager in SRM, if you get this error during discovery “Failed opening session for
user to site mgmt IP.“, follow this doc to resolve: https://support.emc.com/kb/462016. Basically the issue is that the RP SRA only supports HTTPS while the RPAs allow both HTTP and HTTPS. Therefore you have to disable HTTP.
One reminder about RP with VMAX and SRM is that the replication is asynchronous. If you have a failure and will use SRM to recover, it is going to use the latest bookmark which will not have the most current transactions. There is nothing wrong with that of course, it is just like SRDF/A. This is simply a reminder that most likely there will be data loss.