Welcome to this Ask the Expert discussion. On this occasion we're giving you the opportunity to debate with our expert about RecoverPoint for Virtual Machine 4.3 SP1.
EMC RecoverPoint for Virtual Machines 4.3 is a hypervisor-based, software-only data protection solution for protecting VMware® virtual machines. RecoverPoint for VMs enables both local and remote replication, allowing recovery to any point-in-time. RecoverPoint for VMs 4.3 SP1 includes few features like Multi-cluster support , VC licensing, Deployment automation and Orchestration
Meet Your Experts:
Technical Support Engineer II
I have been with EMC for last 4.5 years and has an overall work-experience of 9 years. I have worked on multiple technologies before joining EMC and has a strong specialization on EMC storage and Virtualization technologies apart from RecoverPoint solution.
|INTERESTED ON A PARTICULAR ATE TOPIC? SUBMIT IT TO US|
This discussion will take place May 16th - 27th. Get ready by bookmarking this page or signing up for e-mail notifications.
Share this event on Twitter or LinkedIn:
>> Ask the Expert: RecoverPoint for Virtual Machine 4.3 SP1 http://bit.ly/1TvVXnI #EMCATE <<
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?
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!
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.
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.
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.
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.
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.
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)