Ask the Expert: EMC RecoverPoint for Virtual Machines: Simple, Efficient, Proven Data Protection for VMware

This discussion is now open for questions. We look forward to a lively and informative event.

Best regards,

Roberto

As you know, RecoverPoint for VMs and RecoverPoint are powered by the same technology but are really two different products, protecting data in two different environments.      RecoverPoint for VMs protects VMware VMs and  RecoverPoint protects the physical storage array LUNs.    One other major differences between the two product (there are many) is that RecoverPoint for VMs has auto-provisioning and DR orchestration capabilities built-in while RecoverPoint leverages VMware Site Recovery Manager (SRM) through product integration to have such capabilities.     

Let me just start with the basic question by asking how is DR orchestration done?  

It may be beneficial that we use this forum to begin the discussion about the building blocks used to enable the orchestration process such as Consistency Group and  CG set.  

any best practices around journal space ?

Hi Dynamox,

RecoverPoint for Virtual Machines best practices around journalling are pretty much the same as with the classic RecoverPoint. If possible use a dedicate resource pool for journal. If you need more than 1 journal for a vmdk (across multiple datastores) per copy use CLI to add multiple journals.  You can approach sale engineer to get your sizing requirements.

Hope that answer you question.

Ori

   Consistency Groups (CGs) and Consistency Group Sets (CG Sets) are important components of RecoverPoint for VMs' orchestration feature set. CGs allow for the creation of VM DR policy groups to perform DR, Test Copy, and Fail-back operations. CG Sets allow admins to group together CGs into logical sets and perform DR operations across multiple CGs.

This is particularly valuable where consistent bookmarking is desired (or required) between VM sets hosting components of a mission critical application. For example, a Sales Portal Use Case comprised of VMs hosting a clustered database application, and VMs hosting the corresponding web front end application.

CG sets allow you to be able to create a consistent bookmark of both the Database VMs and the web front end VMs but perform DR operations on each CG individually, or the entire set.

Is this recoverpoint 4.2 version already available or still under a beta program?

Hi,

RecoverPoint for Virtual Machines, 4.2 release, was not released officially yet. However you can see various blogs mentioning it.

My favourite is the one of Stephen Manley and Beth Phalen on Pulse blog.

Ori

Thanks for the fast answer, Rich.

Hi Paul,

The iSCSI requirement is between the ESXi host and the vRPA. So the requirement on the ESXi host is to create an iSCSI software adapter and bind a couple of vmkernels to it. Every ESXi host in the HA cluster should have this configured on the basis of a vRPA vMotion to any ESXI host in the cluster.

Regards,

Rich

In a discussion we had with Zahid, I believe he mentioned that somewhere in the stack, iSCSI was needed... I seem to remember it was for the vRPA communication back to the array, but I've slept since the presentation. Do we need to allocate some RE's for iSCSI? If not, where is iSCSI used in RP4VM? We're really looking forward to testing RP4VM as we are 100% virtualized and RP4VM will offer more granular control over our environment. I would like to +1 the request to have RP4VM be able to snap/replicate in addition to continuous replication. Another option I'd like to see is auto-enrollment of a VM into a protection policy - similar to how the latest version of Avamar can auto-enroll protection of a VM based on it's location in a particular cluster, VM folder, etc. Today, our consumers know that if they want their VM to be part of the DR plan, they select one of the RP protected datastores as the location for the VM. In RP4VM, they would have to deploy the VM to wherever, and then go to the RP4VM tab in the vSphere Web Client to enroll the VM. I can see times where the consumer will forget to do that and believe their VM is protected when it really isn't. Some sort of compliance checking will need to be implemented by us for the initial deployment, but we'd love to see auto-enrollment in a future version. Thanks and kudos to all the RP4VM / DPAP team for making this product a reality!

Hi there

How about AppSync Integration? Surely it is not needed for granular VM Restore, but what about the Application Integration (Application Consistency) and Single-Item-Restore Features (Files, Mails, Tables)?

In the Videos posted so far, the Topology is two distant HA-Clusters each managed by its own vCenter. What about two Sites with a Stretched Cluster ("Campus" Distance) managed by a single vCenter but - is this supported too? (Separate Storage on each Site)

How is it licensed? Per VM, Capacity, Socket?

When can we test & play with it?

Thanks & Regards

Daniel

Hi Daniel,

There's no AppSync integration with RP4VM's at this time. We will be providing a vss apllication package for a VM to faciliate an application consistent image in conjucntion with a bookmarking capability. Note that crash consistent images can be used by databases to recover without issue but often the diffrence is RTO, i.e. databases recover quicker using application consistent images as opposed to crash consistent images. Also, note that when replicating synchronously, every image is application consistent.

Let me check on the stretch cluster question.

Licensing is tiered depending on the number of VMs you wish to protect starting with a minimum of 15.

You should be able to try before you buy very soon.

Regards,

Rich

Sorry but there is AppSync integration with RP4VM

AppSync provides following features RP 4 in Physical and Virtual modes with VMAX and VNX as current arrays supported

     AppSync acts as orchestrator with RP to automate the protection of VMs, Applications inside as SQL, Exchange or Oracle and File Systems in general for Windows, AIXs and Linux OS

     Focusing in VM case:

           AppSync is able to recover, mount or move across ESX clusters automatically in individual or group of VMs protected by AppSync Service Plans using RP integration

     AppSync is able to recover, mount or move individual VMDKs  using RP integration

     Appsync create bookmarks in RecoverPoint at Operating System consistency level using VMWARE tools in each machine, after this process the bookmark remains in AppSync database to be used in the future for mount, repurposing and restoration cases. After the bookmark is created the VM native snapshot is erased and the only maintained copy is the bookmark

     AppSync has a expiration rotation policy feature to maintain a predefined number of active bookmarks in RP

     AppSync automate the entire process to copy an VM from one datacenter to another and is able to migrate the alive VM copy mounted as snap in the DR Vcenter to the selected target datastore and this process has finished the snap and bookmark is unmounted in RecoverPoint infrastructure

               This feature allows that the target datastore could be located in Block (VMFS) in VNX or VMAX or in a NFS datastore, so you can use it in DR Datacenter or for repurposing  in same Datacenter to move VMs across the Vcenters and different types of Datastores

     AppSync can use in logged access or virtual access methods to mount the Snap in Vcenter

     AppSync not only can orchestrate its own consistent bookmarks can access to the all crash consistent copies in the bookmark journal to automate this process with selected point in time. This feature is useful to save RTO mounting copies with RPO near to 0 in required cases

I've uploaded some reference snapshots to help to fix concepts and processes

Regards

Jesus

The AppSync full support explained in previous post is for RP 4.1 and below

There 4.2 version is not test yet

Regards

Jesus

I'm glad you clarified that Jesus.

Regards,

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)

Data Protection & Availability Division