EMC Recoverpoint 4.0 (codenamed “Elarra”) was announced last week to “clear the deck” for EMC World, but is shipping this week, so I held my post back until GA and EMC World. I’d highly encourage people to read Itzik’s blog on it here.
It’s a HUGE release, improving on just great technology. There are a ton of happy Recoverpoint customers – and this will broaden it even further.
Recoverpoint isn’t like how many customers do replication – it isn’t a “point in time copy”, but rather a “Tivo/PVR” like continuous replication technology (can be used for both local and remote uses). It’s architecture always has involved a “splitter” (software that copies off an IO) and Recoverpoint “appliances” (called RPAs) to manage the replication, carry the replication load, present virtual views of volumes, and more.
This architecture has always had good and bad:
- First thing first – Recoverpoint has been, and continues to be SUPER efficient. It does deltas only, which are in turn compressed/block deduped/write folded/prioritized. I laugh out loud whenever a customer tells me that our competitors are describing EMC as only having full SRDF copies these days :-)
- Broad platform support vs. “replication built into the platform”. It’s possible to use Recoverpoint with different array types.
- Decoupled the replication load from the production array. Customers with very complex replication topologies know that sometimes this can interfere with prod in ways you don’t expect when the replication load isn’t isolated in some way (this is true of EMC and non-EMC arrays). I’m not saying this isolation needs to be “physical”, but until array have robust isolation techniques for storage stacks (think EMC C4 VNXe project – google it – or array-based virtualization approaches like vSphere) as an example – it is tricky topic.
- Splitter can live in different places (today, it’s embedded in VNX, VMAX, VPLEX, and host splitters). The VPLEX splitter is pretty handy, as it means the solution can work with any array in effect.
- If splitter implementation isn’t rock solid (dependencies on splitter, fabric intelligence, and how they tie together), and customers can have problems. In the early days where the splitter was embedded in 3rd party switches – these often were very troublesome. We don’t architect those anymore. Conversely, customer satisfaction for embedded splitters is awesome.
- The requirement for physical RPAs means two things: environmental load (space/power/cooling) and cost (outside the array itself).
Beyond the cool new features – Recoverpoint 4.0 goes a long way towards keeping (and expanding!) all the good, while fixing all the bad.
- 4.0 has huge performance leaps (one example is a 60% bump to 400MBps async replication per consistency group – and the total for a cluster is much larger)
- 4.0 has huge scale increases (up to 8000 devices and up to 2PB protected by a single recoverpoint cluster).
- Important new functionality (one of the most requested things) like fan in (4:1) and fan out (1:4) topologies.
But, there’s even more:
- Virtual Recoverpoint Appliances! As Itzik points out in his post, this started as a field/customer initiated effort to make playing with Recoverpoint easier (I remember, I was there). Pat Gelsinger in his former role as the EMC EVP on products (and less important people like me) hinted at all EMC products being made as virtual appliances bit by bit. Here’s one that is super handy. Deploy a 8GB RAM, 8vCPU VM (you can use smaller ones, performance will scale down), and as a Recoverpoint customer – you can deploy as many vRPAs as you want. Each 8GB RAM/8 vCPU vRPA can do around 8500 write IOps to the journal, and can replicate about 80MBps (or ~640Mbps). This makes deploying Recoverpoint simple and easy. You can also imagine all sorts of multi-tenant, and service provider options. We’ve also indicated that we anticipate making Recoverpoint (and VPLEX) data services into ViPR in the future. Here’s a demo from Itzik about how easy it is to install and use!
- VMware SRM multiple Point-in-Time recovery! Another huge feature request from customers. As a sophisticated data replication technology, Recoverpoint can recover to any point in time in it’s journal. This is important, as with all replication – it will replicate latent errors. If someone accidentally deletes a table – that gets faithfully replicated to the other side. One needs to either be snapshotting the remote side periodically (do you have the right snapshot?) or use something like Recoverpoint’s continous journal approach. BUT if you use VMware Site Recovery Manager (SRM) – the APIs and the recovery model has no way to specify a point in time (it uses the lowest common denominator approach in storage land – a sync or async single copy replica). With this release (and a VSI plugin), the VMware admin can – without leaving their console – restore to any point in time. Itzik also recorded a demo of how this works in action…
Recoverpoint can be automated and made programmable via EMC ViPR! This means that there is now a fully automatable, RESTful API compliant, decoupled control plane for remote replication.
Truly, this is software defined in BOTH senses – an abstracted control plane, and a software-implemented data plane.
There’s more to come. Think about the power of a software-based replication engine (vRPA) as kick-a$$ as Recoverpoint, tested at scale, with rich features, and great VMware integration. Then, think of a software based splitter. Where would be a great place to put that splitter?
If you’re in the UK, and use vSphere 5.1 Recoverpoint – please comment. I would love to hear feedback (from anyone), and if you’re in the UK – I have something I want you to try :-)