Dell EMC RecoverPoint for Virtual Machines 5.1 – Protect VM

By Victor Wu on 2017 年 08 月 04 日 • ( 3 Comments )

In this post, we will perform one demonstration of new Virtual Machine protection (Local Copy) and see the power of auto-provisioning of replica VMs as well as Journals and VMDKs.

Firstly you login into vCenter by Administrator in vSphere Web Client, then will protect the virtual machine “TestVM” by RecoverPoint for Virtual Machine.

Right-click the TestVM, and then select All RecoverPoint for Virtual Machines > Protect.

Note: Once you right click on the VM, it might take few seconds for the All RecoverPoint for Virtual Machines option to appear at the bottom of the menu.

On the first step, you must select whether you want to create a new Consistency Group or add the VM to an existing CG. For the TestVM, you will create a new Consistency Group. Ensure Create new consistency group for this VM is selected.

The Protect VM wizard in RecoverPoint for Virtual Machines allows protection of multiple VMs within the same Protect VM wizard. In this case, only the TestVM should be protected at this point. Therefore, Do not select Select additional VM(s) to protect within the same consistency group.

In the Enter a name for the new Consistency Group field, type TestVM_CG.

Then you will select a RecoverPoint for VMs cluster to protect the TestVM. Select vRPA51 as the production cluster which is going to replicate the TestVM. Click Next.

NOTE: vRPA51 is local vRPAcluster, DR-vRPA51 is remote vRPAcluster.

In the Enter a name for the production copy field, type TestVM_PROD. Select Manually select a registered datastore from the table below, and select DS3_SDD.

Expand Advanced options > TestVM> VMDKs

Other options under Advanced Options are:

Protection Policy – Automatically protect new VMDKs.
Disk Provisioning – Select the same Disk Provisioning as the source VM or create the replica VMDKs as either THICK or THIN regardless of their type on the source VM
Hardware Changes – Replicate Hardware changes made to the source VM towards the replica VM. If this option is deselected, the replica VM would be created with virtual Hardware configuration as the source on the time the production VM was initially protected.

Click Next.

In this step you will configure one of our two target copies. You will start by configuring the local copy. In the Enter a name for the new copy field, type TestVM_Copy1. Select vRPA51, and then click Next.

Here, you will configure the journal volumes for the vRPA51 local copy. Leave the Journal size as 10GB as well as the current configured datastore.

Replication type to Asynchronous or Synchronous and you can also specify an RPO in terms of allowed lag based on size, number of writes or time (seconds, minutes..etc). For now, leave this option unchanged. Click Next.

In this demonstration, you want to automatically create the replica VM so leave the Automatically create a new VM copy at the target cluster option selected.

Select the resource to run the replica VM. Expand vRPA51 > vrp-vcenter6.victorlab.com > New Datacenter, and then select Site-A. Click Next.

In this step, you will configure the datastore which the target VM will reside on. Select the DS1_SDD datastore to store the target VM. Click Next.

In this step, you will define failover network for target VM. Click Next.

In the Ready to Complete screen, a summary of selections that you made during the wizard are displayed. Take a moment to review the settings, and then click Protect.

The RecoverPoint for VMs system is now creating the shadow (.shadow) and replica (.copy) VMs as well as auto-provisioning VMDKs for the replica VM and source and target journals.

After waiting and refreshing vSphere Web Client, you will see that replication initialization begins. Depending on what step the system is running, you might see the rp.TestVM.copy.shadow VMs in the inventory list on the left.

If you see any displayed errors about vRPAs unable to access certain devices, ignore those – they will be cleared once the volume have been provisioned.

Ignore any warnings on vRPAs running on the same ESX as the protected VM. It’s recommended that vRPAs protect VMs running on different ESXi nodes. vRPAs and VMs can co-exist on the same node, but the recommendation is to have the vRPAs protect other VMs.

In a production environment, the Consistency Group state would change from Paused by System, to Init (%) and finally to Active state. Active state would indicate that point-in-time images are available at the target replica VM.

In a production environment, the accompanying screenshot shows how replication displays an Active state which would indicate that point-in-time images are available for test and recovery operations.