Ask the Expert: RecoverPoint for Virtual Machine 4.3 SP1

Hello Mohit,

Questions about RP4VM -

What is the best practice in terms of journal placement and datastores? Do we want to always place journals on the same Datastore as VM? Or would you recommend all journals on a single datastore? Is it necessary to "load balance" the journal vmdk across datastores?

In terms of the RPO feature, how is the protection window defined? What is the default protection window? When I define a RPO of 25 seconds, I can only go as far back as a few minutes, but it seems like there is a snapshot for every few seconds. However, if I define a RPO of 1 minute, my protection window is extended much longer. How does the RPO / protection window work?

Hi,

The journal need not to be placed on the same datastore as VM. Journal is a high performance entity and should be on RAID5 or RAID10 datastore. We also need to make sure that datastores hosting journal have enough resources to handle the IOPS. "Load balance" would definitely a recommendation to avoid any over utilized datastore.

Protection window is the span of time DR copy can be rolled back. For example if the current protection window is 24 hours, it means that DR can have a image rolled back to 24 hours.

There is no such default protection window. It depends on the size of the DR journal. The amount of snapshots hold by a journal estimates the current (default) protection window. Larger the journal size, more snapshots it can hold.

RPO in general terms is the maximum amount of data that an organisation is willing to lose in case of a disaster. In Recoverpoint RPO is by default set as 25 seconds. RPO can be expressed in terms of time, quantity of data, or number of writes.

Though as per best practice application is not regulated by default but if there is a need host application can be regulated when the specific RPO value is reached. (by default application regulation is disabled).

RTO is the time within which business application can be restored after the disaster. In RP RTO is controlled by Maximum Journal Lag. If RTO needs to be regulated,  Maximum Journal Lag need to be set accordingly.

The Maximum Journal Lag is the maximum amount of snapshot data (in bytes, KB, MB, or GB) that is permissible to hold in the copy journal before distribution to the copy storage. In case the current value precedes, the distribution enters into 3 phase distribution skipping the snapshots to be created for that duration.

Hope above answers your query.

This Ask the Expert session is now open for questions. For the next couple of weeks our Subject Matter Expert will be around to reply to your questions, comments or inquiries about our topic.

Let’s make this conversation useful, respectful and entertaining for all. Enjoy!

Points to be remembered while having 4.3.1 with older versions 4.3 and 4.2.

=> RecoverPoint for VMs 4.3.x system does not support 4.2.x vRPA clusters

=> RecoverPoint for VMs 4.3 clusters and RecoverPoint for VMs 4.3.1 clusters can co-exist on the same vCenter, however, the 4.3.1 plugin does not support 4.3 clusters.

=> RP4VM 4.3 upgrade to 4.3.1 would require RecoverPoint for VMs Deployment Manager to upgrade the vRPA code version. Splitter upgrade would need to be upgraded manually by first removing the old splitter version and install the new version either from VIB or from boxmgmt. Please note that to avoid full sweep at any point of time at least one ESXi with an installed splitter for the vRPAs to keep working. Also the RP4VM plugin would be upgraded separately. Once the plugin is upgraded any vRPA cluster running earlier version would not be accessible.

New features for release 4.3.1 over previous 4.3 and 4.2 versions.

A new tool RecoverPoint for VMs Deployer introduced which will replace RP Deployment manager tool for install/upgrade and connect cluster option. Few changes like change in IPs would still require deployment manager for RP4VM but would later be introduced in RP4VM deployer.

Improved RP4VM Plugin allowing

- ESXi cluster registration

- RP log collection

- VC credentials management

- vRPA clusters conflict management

Multisite protection is increased from 3 to 5 vRPA cluster per system.

Improved REST API programming.

VxRAIL Bretton Woods 3.0 support included.

RP4VM now supports protecting VMs, repository and journal volumes on vSAN 6.0 and 6.1.

Virtual volumes (VVOLs) qualification with vVNX and VMAX3.

Question on CGs in RP4VM... I notice maximum is 128 per cluster. What is best practice around CGs?

In the past, it may have been putting LUNs as part of the same workload (IE Database, Exchange, etc.) into one CG but given the 128 limit, do we want to create a CG per VM? 128 VMs seems like a low limit.

Hi,

In both Recoverpoint (LUN based protection) and Recoverpoint for VMs the objective to include entities into a consistency group is to make sure that we have the ability to failover LINs or VMs that require to be present to bring up the application.

It is possible that instead of only 128 VMs being protected by 128 CGs multiple VMs can be protected by same CG. In case of a environment wherein 128 CGs are already used up while protecting X VMs, upto 7 more RP4VMs clusters can be connected to the same vcenter server. Please see the below scale limits affecting the total number of VMs to be protected.

upto 8 vRPA clusters connected to a vCenter server

upto 512 VMs protected by a single vRPA cluster

upto 128 VMs per consistency group

For more details on the scale limits please refer to RecoverPoint for Virtual Machines 4.3 Scale and Performance Guide page 10.

There are multiple variations available for implementing different solutions. Also the scale limits continues to be increased as the new code versions are released.

Hope this helps.

thank you!

Is it possible to remove a journal from a CG that was already created and initialized (replicating), and create a new journal on a new datastore? I understand full sweep would occur but is this ok? Or would we need to delete entire CG and recreate? I want to avoid re-initializing at target location.

Hi,

Journal from Production/DR copy can be removed and later new journal can be added without deleting and re-creating the CG. However removing a journal or journal volume necessitates a full sweep synchronization on all volumes of the consistency group to ensure consistency between the production and copy volumes. (Journal will be cleared)

Regards,

Mohit

thanks Mohit, just to be clear, we will have full sweep (clearing of journal), but the target VMDK will still be somewhat in sync with the production copy and we will avoid full initialization?.

Correct. The following full sweep will have only changed data transferred to target VNDK.

digging deeper into the journal and datastore issue.. if the array in question is XtremIO, can we theoretically create a single LUN/datastore just for journals? I know you said best practice is to "load balance" which I assume you mean keep them with their source/target VMDKs, but to keep things organized on a system like XIO, can we create 1 LUN/datastore for everything?

"Load balance" was meant in terms of keeping the journal volumes distributed over multiple LUNs thus avoiding the bottleneck on the journal LUN level. Every write IO from production leads to 5 R/W IOs on the target journal LUN. this proves performance bottleneck if all the journal are from same disks.

in RP4VM, in theory it is possible to create a single LUN/datastore for journal purpose but recommended to spread the journal to avoid performance bottlenecks.

Whether if its a XtremIO or any other array, a detailed check on the required IO specs would provide a correct answer for your question.

Few questions...

1. What does RPO control? Does RPO define how often “snapshots” are taken of the production VM? I’m not sure what the RPO value actually does and what effect it has on replication. What happens if the RPO value is too high/low for the link?

2. What is snapshot granularity? Does this refer to how often a snapshot of the production VM is taken and replicated to the target journal? If so, what is the difference between this option and RPO?

Finally, can you go over the process of distribution in RP4VM for me? As I understand, production VM is “snapshotted” as in classic RP and this snapshot (delta of changes since last snapshot) is transferred to target journal and later distributed to target VMDK?