Best Practices around RP4VM and DRS

Hi Jerry,

In answer to your first question, it only makes a difference if the ESX suddenly fails. It would mean that that the protected VM would have to be moved and re-enabled.

In answer to your second question I do not think that DRS can provide this assurance.

Regards,

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)

Data Protection and Availability Solutions

EMC Europe Limited

Mobile: 44 (0) 7730 781169 44%20(0)%207730%20781169>

E-mail: richard.forshaw@emc.com

Twitter: @rw4shaw

I was wondering if you could expand on this scenario a bit.  Let's say we have a 2-node cluster, with ESX1 and ESX2.  vRPA1 and vRPA2 are running on ESX1 and ESX2 accordingly.  Let's say vRPA1 is replicating Exchange1, a VM which also lives on ESX1.  Assuming everything is healthy (all hosts up and running), is this a problem in and of itself?  The WARNING message in RP4VM is annoying, especially if this is not a problem.

Next scenario, let's say ESX1 host dies.  vRPA1 crashes, and so does Exchange1.  VMware HA kicks in within 30 seconds and boots up vRPA1 and Exchange1 on the other ESXi host: ESX2.  Does replication of Exchange1 resume automatically once vRPA1 boots up on ESX2?  Of course in this scenario we have vRPA1 and vRPA2 running on the same host (temporarily) which is not recommended.  But my question is, does everything operate correctly until ESX1 is brought back into service?

Thanks,

Bill

Hi Bill,

I believe you are talking about the warning as below

"WARNING: At least one virtual RPA is running on the same ESX as the VM it is replicating. It is recommended not to have the virtual RPA that replicates a VM running on the same ESX as the replicated VM. Use vMotion to move one of them to another ESX."

There is absolutely no problem in a case wherein the vRPAs in a vRPA cluster and the protected VMs are on the same host. Though it is not as per the best practice. The best practice suggests to separate the ESXi host of the vRPA VMs from the protected VMs.

If the warning annoys too much you can simply change the CG owner vRPA to a different vRPA hosted by the different ESXi host. (Unless such change disturbs the load balancing too much).

For the second scenario, in simple words, when a vRPA is down, another surviving vRPA takes care of the replication.

for the above described scenario, when the vRPA1 and Exchange1 crashes on ESXi1, the replication temporarily pauses unless the Exchange1 is back on the other ESXi (for example ESXi2) host. When Exchange1 is on, other surviving vRPA2 takes care of the replication untill vRPA1 is back on another ESXi (could be ESXi2 or any other ESXi) host. Once the vRPA1 is online it resumes the replication ownership for Exchange1.

untill the ESXi1 is back online and vRPA and protected VM is moved back, replication continues on owner vRPA hosted by other ESXi hosts.

Hope this explains your query.

Thanks Mohit, this definitely helps.  It sounds like the behavior is as I would expect.  However, I am still curious why you say running the vRPA on the same host as the VM being replicated is "absolutely no problem" but also "not as per the best practice"?  If there is absolutely no problem doing this, why does EMC go out of their way to indicate this is not a best practice, and generate an error message?  Because VMware DRS load balancing will be moving VMs around all the time, it's impossible for me to guarantee that a VM won't live on the same ESXi host as its vRPA, unless we were to build a completely dedicated ESXi cluster for the vRPAs, with nothing else running on that cluster.  This would add a significant cost to an RP4VM solution, so I suspect only the largest customers will go this route.  I am more familiar with VMware vSphere Replication, which has no restriction against where the vSphere Replication Appliance (VRA) runs, so I am curious why RP4VM's best practice has this limitation?

Hi Bill,

Another option would be to create DRS rules to keep protected VMs away from the vRPA that is replicating it. I understand that this is a very manual process, but not a procedure that involves a lot of steps.

I have not done it (yet), but it should be possible to create a script that finds out what VM is replicated by which vRPA and then invoke a PowerCli script that creates/updates a DRS rule to keep them (protected VM and its vRPA) apart from each other.

Hope this helps,

Fred

Thanks Fred, that is definitely something we could do, although as you say it would be a ton of manual effort or error-prone scripting.  My main concern is the contradiction between Mohit's statement above that it's "absolutely no problem" to have a replicating VM on the same host as the vRPA, but EMC's documentation stating to keep the VM on a separate host.  Which is accurate?  If it's no problem to have them on the same host, I'd rather prefer to avoid all the unnecessarily complex work of these DRS rules.  On the other hand, if it's absolutely critical to keep VMs separate, I'll go ahead and do all this extra work.  I just really need to understand the true reason/meaning behind this recommendation and implications for ignoring it.  I implement VMware vSphere Replication for my customers all the time, which does not have this limitation, so I really want to understand this more clearly before I consider pitching RP4VMs to my customers.

Going to guess here and say the replication is unaffected, except for these downsides:

1: In the event of failure you have to make sure the vRPA nodes restart before the guest to ensure 100% synchronous disk replication.

2: Performance - every disk write will cause the host to write to the splitter, splitter writes to the disk and the iSCSI interface (network IO out) to the vRPA, which gets the traffic as network IO IN (however this runs a the speed of memory in the same hosts, depending on how the vswitches are setup with their uplinks between the vmkernel and vrpa data interfaces. Then another disk write from the vRPA writing to the journal. When on separate hosts, these writes would be distributed among two hosts.

I'd like to see integration though with DRS kick off an auto-migration or recommendation without admin intervention though.

This is now a very old thread, but still relevant in the latest versions of Recoverpoint, and vSphere 7.
If there were VM/Host Placement Rules that allowed for "Keep Group A of VMs away from Group B", or the like, this would be easy enough.  Anti-affinity rules won't work without creating a rule for every protected VM / appliance pair, which is a no go.  It seems a 'best practice' that generates errors without a reliable solution is juts asking for trouble.
Am I missing anything that's changed in the past 5 1/2 years?

Hi,

Thanks for your question. It doesn’t look like anything has changed. https://dell.to/3ZTzYB4 and https://dell.to/3J1j38D

Let us know if you have any additional questions.