Although RP for VMs (RP4VM) has been out for a while now, and there are plenty of other blogs and documentation, I thought I’d just recount one scenario I ran into where it really saved me. Now make no mistake I am a VMAX guy and my replication/DR solution of choice is SRDF 🙂 But truth be told RP4VM and SRDF have different use cases and sweet spots – primarily being that SRDF is an all VMAX solution designed for enterprise scaling at the device level (physical, virtual makes no difference) while RP4VMs is a storage agnostic, VMware solution that operates at the VM level. There are clearly other differences which I won’t elaborate on since that’s not the focus here – suffice it to say EMC has replication solutions for every use case. Now being in the VMAX world I typically use SRDF, but sometimes circumstances – be it lack of equipment or in this case the desire to replicate only a couple VMs – call for something else. So that brings me to my implementation of RP4VM and how I used it.
As there are other docs/blogs out there that cover RP4VM installation, I’m going to generally skip over the detail of that. It’s very straightforward anyway – configure iSCSI software adapters, deploy vApp OVA, run the Deployment GUI, enter the info and you are good to go. My only issue with the install has been getting my lab to provide me enough IP addresses since each cluster (2 vApp) needs 9 if memory serves so that’s 18 IPs for one setup. My environment consists of 2 clusters deployed on one vCenter and 2 clusters on another vCenter. This my small lab so yes, I admit I do not follow best practices – you’ll see evidence of that in my videos. Don’t be like me 😉 Since RP4VM uses datastores, it doesn’t care about storage at all. There also is no “tagging” of devices to make them RP usable. As it replicates at the VM level, however, the VM must be running – this is not device replication but VM replication and it cannot copy data it cannot read. I deployed mine on my VMAX3 datastores. If you are just using RP4VM in your test/dev environments you don’t need a license – you’ll get a trial message like below, but all the functionality is there.
Click to enlarge – use browser back button to return to post
To access RP4VM there is the standard Unisphere for RecoverPoint interface but all the functionality is not exposed through that application (like protecting a VM) so while I sometimes use it for monitoring or failover, configuration is done through the vSphere Web Client plug-in – think VMware SRM 5.8 (btw no support for that yet) or the VSI Web Client. When I started to play with RP4VM I replicated VMs that were most critical to me – vCenters and demo environments – vROps/ESA, Unisphere for VMAX, vRealize Log Insight – you get the idea. This video walks through the setup of the VM in question for this post, Log Insight.
Click to play in place
So I had this setup and frankly just forgot about it – it does its thing and I do mine. A couple weeks later I had a customer demo come up for the VMAX Content Pack for Log Insight. So about an hour before, I took a quick look at the environment, or rather tried to. The web server was not responding, and when I opened the console of the VM I got the dreaded MKS error.
Click to enlarge – use browser back button to return to post
That error has a ton of possibilities, so much so VMware has a KB on it, but seeing as I couldn’t SSH into the VM and I send lots of data into the LI VM, my money was on a full OS. In any case I just didn’t have time to fix it before the demo but I knew it was working a couple days before so I was off to RP4VM to see what I could do. Well my replication looked good and I had lots of journal entries to choose from. At that point I had two options as I saw it – enable image access for a test, or failover. If I enabled access only, any logs destined for Log Insight were going to be sent to the enabled image VM while it was up, but once I disabled access, I would lose those logs. If I failed over I would not lose the logs. Since my VM was dead anyway for some time, I had already lost logs so I decided to enable image access. If this were not a lab environment my decision may have been different of course. Again I’ll use a video to demonstrate this. To mimic my full OS I simply paused the VM so the IP was unavailable. In the video below I walk through what I did (obviously I’ve done a recreation) on that demo occasion.
Click to play in place
In real life after I did my demo and disabled image access, I resolved the problem with my primary VM and I was good to go; however let’s say my primary was just completely dead and gone for whatever reason. I could failover then and my copy would become my new primary and I could remove my group and setup a new one. If the primary was still viable, I could recover production, etc. Lots of options available. I encourage you to give RP4VM a try since you don’t need to buy any additional components – just your vCenters, some datastores and IPs of course.
Dell PowerFlex and PowerMax with VMware 
Leave a Reply