It has been a while since I’ve written anything about RecoverPoint since my original post on RecoverPoint 4.0 several years ago. To my delight I was recently put on a couple of projects to deploy new virtual RecoverPoint clusters for two customers. Several things had changed since the first appearance of the virtual RecoverPoint Aplliance (RPA), so why not write a small series on the deployment of these appliances? Gotcha’s included!

If you’re new to RecoverPoint…

For those that are not familiar with RecoverPoint, a quick oneliner. RecoverPoint offers both synchronous and asynchronous local and remote replication of LUNs in a DVR-like fashion. The vital part here is the “DVR-like fashion”.

Normal synchronous replication will ensure that the data at the target array is always in sync with the primary array before acknowledging the write back to the host. This is vital if you want to achieve an RPO of 0 (i.e. no data loss). There’s one downside: if there’s a virus outbreak or some sort of corruption of your data, your virus will also be neatly replicated to the remote site. So while synchronous replication will protect your data perfectly against a transient or permanent physical event like a power failure, fire, multiple disk failure or exploding storage system, it’s less suited to guard against logical events that unwantedly alter the data.

You could protect against those viruses with asynchronous replication: replicate once every 4 hours and hope someone can pause the replication somewhere between detection of the corruption and the next synchronization cycle. Apart from the obviously paramount task of responding fast enough in these events, it also leaves you with a less than desired RPO: in case the primary array blows up, you’ve now got data loss up to 4 hours.

You could use synchronous replication to guard against the physical events and pile some snapshots on top of that. While this may work, snapshots usually come with some kind of performance penalty. And there’s usually still a fairly large window between snapshots.

What if you could increase that granularity between snapshots to the individual I/O level. Basically: log every write to the remote site and allow the admin to choose which point in time to restore to. Not with a granularity of minutes of hours, but individual writes or application generated bookmarks. Enter RecoverPoint CRR or Continuous Remote Replication.

Physical or Virtual?

You can deploy RecoverPoint using either physical or virtual appliances. The physical appliances offer FC and iSCSI connectivity options to the storage array, whereas a virtual appliance can only connect to the storage array over iSCSI. Additionally the physical appliances are faster, offering synchronous replication, deduplication and distributed consistency groups. A vRPA only supports synchronous replication and deduplication if you deploy it in it’s most powerful form. A vRPA cluster never supports distributed consistency groups, so for those really high I/O consistency groups that can’t be handled by one vRPA, you’re stuck with physical RPAs.

The vRPAs can be deployed using an OVF package. During deployment you can choose how powerful you want the vRPA to be: 2 vCPU & 4GB of RAM, 4 vCPU & 4GB of RAM, or 8 vCPU and 8GB of RAM. Only the 8CPU/8GB version supports features like synchronous replication and deduplication.

Both customers chose the virtual appliances: they’re cheaper than physical appliances and the replication requirements didn’t necessitate physical nodes anyway. This series of post will discuss the deployment of those virtual appliances into a RecoverPoint cluster. But before you start clicking, make sure your deployment architecture is sound!

Gotcha’s!

A couple of pointers before deployment:

• RecoverPoint cannot use a MirrorView port on a VNX. If your array has a MirrorView enabler installed, the lowest ports in the array will automatically become MirrorView ports. You cannot use these ports with RecoverPoint! This means you will have to choose different (higher numbered) ports to connect to, or uninstall the MirrorView enabler. The latter might be a problem if you also use MirrorView on that array in a multi-tenancy situation.
• Each vRPA will need 4 paths to a VNX. In low cost implementations, you might be tempted to direct-connect the ESX host to the VNX array. This will not work, since this means your vRPA will only have two paths to the array. You will need a switch between the ESX hosts and your storage array. (Or direct-connect 4 NICs in the ESX host to the VNX, but that makes little sense since this will immediately claim all the iSCSI ports on the smaller VNX-es with one ESX host).
• The RecoverPoint splitter needs to be installed on the VNX. This is a small enabler that you need to upload to the system.
• You will need a vCenter server to deploy the OVFs. You cannot deploy straight to a vSphere host, due to some vApp limitations.
• Configuration of the RPAs is not possible if the link between deployment manager and RPA is NAT-ed. Make sure you run the deployment manager from the LAN subnet without Network Address Translation. After the deployment, you can access the cluster using NAT without problems.

Do you meet all the prerequisites? Read part 2 for the deployment of the vRPAs!