I’m super excited today about a new product that we have just released, RecoverPoint For VMs 4.3 (RP4VMs) is out, this release is a substantial one since it contains so many new features that were asked by you our customers, so before we talk about these features, let’s do a quick recap of what RP4VMs is


The RecoverPoint product family is comprised of two different products that are powered by the same technology but targeted at two different audiences, solving different business problems.

The traditional RecoverPoint is targeted for storage administrators that want to protect array LUNs of over 50 supported EMC and non-EMC storage arrays.

RecoverPoint for Virtual Machines is geared towards vAdmins of VMware environments for protecting individual VMs or multiple VMs in consistency groups for crash consistency protection.


RecoverPoint for VMs is targeted at the VMware admin (vAdmin) and protects at the virtual machine level. It is fully managed through vCenter, is deployed as a virtual appliance on existing ESXi hosts, has an embedded I/O splitter within the ESXi host kernel, and is storage agnostic and supports any SAN, vSAN, NAS or DAS storage arrays certified by VMwares Hardware Compatibility List (HCL).

RecoverPoint for VMs is a completely separate product from the traditional RecoverPoint product. There is no upgrade, no downgrade and no interoperability with the traditional RecoverPoint products.

RecoverPoint for Virtual Machines simplifies operational recovery and disaster recovery with built-in orchestration and automation capabilities accessible via VMware vCenter. vAdministrators can manage the lifecycle of VMs directly from the vSphere Web Client GUI and perform Test Copy, Recover Production, and Fail Over to any point in time.

RecoverPoint for VMs is a software-only solution that is installed in a VMware vSphere environment. The virtual RecoverPoint Appliances (vRPAs) are delivered in an OVA format. A RecoverPoint for VMs cluster can have 2 – 8 vRPAs.

The RecoverPoint for VMs splitter is installed on all the ESXi hosts involved in VM replication and is delivered as a vSphere Installation Bundle (VIB). The ESXi software iSCSI adapter is utilized to communicate with the vRPAs.

Management for RecoverPoint for VMs is fully integrated as a plugin into the VMware vSphere Web Client.

Now, lets talk about the enhancements in the 4.3 release and boy, we have so many of these!

Multi Site Support


RecoverPoint for VMs 4.3 supports concurrent local and remote replication for production VMs.

Multisite configuration of 2:1 (fan-in) or 1:2 (fan-out) for flexible disaster recovery topologies are possible and scalability of inventory and protected VMs has increased.

RecoverPoint for VMs delivers data protection for VMs. It is designed with vAdmins in mind to enable them with the proper tool. With RecoverPoint for VMs, vAdministrators can take a more active role in data protection which has traditionally been served by storage administrators. This tool allows them to protect and recover VMs in which their mission critical applications are deployed. Data protection Service Level Agreements (SLAs) can be met, VMs are protected at the hypervisor level with individual VM granularity, and the tool now offers better visibility and recoverability in the data protection processes. RecoverPoint for VMs 4.3 can have up to three (3) RecoverPoint for VMs clusters in a RecoverPoint for VMs system. In this star topology, cluster 1 is connected to cluster 2 and cluster 3, but there is no connection between cluster 2 and cluster 3. One site is connected to all the remote sites.

Increased Scalability


RecoverPoint for VMs 4.3 supports a vCenter inventory of up to 5,000 registered VMs.

Large numbers of protected VMs and VMDKs can be supported and VMDKs can be as large as 40 TB.

A consistency group can have up to 32 VMs while a RecoverPoint virtual appliance cluster can support up to 128 consistency groups.

VMware clusters can have up to 32 ESXi hosts and up to four (4) ESXi clusters can connect to a single vRPA cluster.

Orchestration enhancements

RecoverPoint for Virtual Machines simplifies operational recovery and disaster recovery with built-in orchestration and automation capabilities accessible via VMware vCenter.

Virtual machine hardware changes are now replicated to its copies. RecoverPoint for VMs 4.3 extends the use of wizard guided work-flow for recovery orchestration and prioritization. It determines the VM start-up priority as well as the integration of scripts for the start-up sequence.

If necessary, replica VMs can now have their network automatically re-configured when they come online in a disaster recovery situation.

Real time and historical activity reporting for the recovery activities are available.


RecoverPoint for VMs 4.3 automatically replicates virtual hardware changes made to protected Production VMs. The motivation is to keep the Replica VMs inline with the Production VMs in terms of virtual hardware configuration. Replication of hardware changes occurs periodically. Replica VM hardware configuration is changed when performing Test Copy. Select the Virtual Machine or Consistency Group or Group Set that you want to use for testing a copy. The Test a Copy Wizard is started and when the image is selected, the hardware configuration is applied as well.


Use the Protect VM Wizard to protect a Virtual Machine (VM). Under Advanced Options you will find the configuration parameters for how a VM and its vHW is protected. By default, the Replicate Hardware Changes option is enabled. If this is not desirable, then unchecked it.

RecoverPoint for VMs 4.3 has multiple enhancements and new features around virtual machine automation in protected and disaster recovery environments. Built-in orchestration and automation capabilities are integrated with VMWare vCenter at no additional cost. These features work on Replica VMs when performing Test Copy, Recover Production, and Failover.

Examples of use cases for why this automation is provided: modifying parameters within the VMs to match the different environments, pausing a start-up process and allowing manual intervention, or configuring network parameters like DNS, Firewall, DHCP and so on before starting up the VM copy.

The Startup priority is improved for recovery orchestration and prioritization through a wizard guided workflow. It supports application dependencies with a complex power-up sequence priority for each VM within a Consistency Group (CG) and to each CG within a group set.

Another option of the RecoverPoint for VMs 4.3 orchestration features is the before-power-on and after-power-on scripts. An external host can run scripts when executing a Test Copy, Recover Production or Failover to ensure environment or application consistency.

Furthermore, prompted messages provide the possibility of administrator configurable messages during the recovery flow.

The Re-IP information for Replica VMs is automated to avoid IP duplication and can be applied through scripts and network information in CSV format.

RecoverPoint for Virtual Machines does not work with VMware Site Recovery Manager (SRM). SRM should only be used with traditional RecoverPoint and the data protection for storage arrays.


All of the orchestration features just listed can be used for Replica VMs when performing Test Copy, Recover Production, and Failover. Here is an example showing how these advanced configuration options could all work together. Two VMs with the highest start-up priority 1 in a consistency group start first when, for example, a Test Copy on this CG is performed.

Each VM can have a Pre-Power-on external script assigned and a Pre-Power-on prompt configured. User prompts define a message to be displayed in vCenter to prompt the administrator to perform specified tasks before continuing with the start-up sequence.

The power-up process then continues. If a RecoverPoint for VMs system environment does not have an L2 network between sites, Re-IP of the VMs is necessary when the Replica VMs are brought up on the secondary site (for testing copies) in order to avoid IP conflicts. Additionally, a Post-Power-on external script and prompt with stop can be set per VM.

All these advanced configuration steps can be set for the highest priority VMs in the highest priority consistency groups within a group set.

These VMs could have network services (like DHCP, DNS, FTP and so on) running on them that need to come up before application servers or other VMs.

After the highest ranked VMs in the highest ranked CGs have started, all the VMs with Priority 2 in the highest ranked CGs will start. These VMs can again have all the advanced configuration possibilities configured that were just described for the Priority 1 VMs.

After all the VMs in the highest ranked CGs have started, VMs in CGs with Priority 2 would be next and so forth.


we configure the start-up priority for VMs by selecting RecoverPoint for VMs Management in the VMware vSphere Web Client. Here select Protection and then Consistency Groups. Select the CG to be configured from the list of CGs. The button Edit Start-Up Sequence can now be selected which opens the Start-up Sequence of VMs in this Group window. Here it can be checked if the VM is critical (by default) or not. The Start-up priority default settings is 3. Open the dropdown list and select a setting from 1 to 5.


Before- and After-power-on scripts can be configured. The purpose of the scripts is to tie Disaster Recovery (DR) and Business Continuity (BC) tasks into the recovery flow.

Select RecoverPoint for VMs Management and the CG to be configured. Open the Start-up Sequence of VMs in this Group window. These are the same windows where the start-up priority for VMs was set before.

The additional RecoverPoint for VMs 4.3 automation enhancements allow administrator scripts to run before power-on and directly after power-on on virtual machines. The scripts are executed with SSH on an external host. Check Run script to activate this feature, enter the script name and command for the script. Each script also has a mandatory timeout period. The recovery flow is blocked until the script has successfully executed. If the script does not execute within the set time or the script fails, the system will retry the script a pre-defined number of times. The administrator receives a prompt indicating if the script failed.

The after-power-on script can be entered here as well.


The Dashboard > Overall Health window displays Recovery Activities. The activity report shows the involved consistency group, the activity and state, if a User prompt is waiting, the involved copy, the transfer state, and the image access progress. The User prompt number is linked to the Recover Production wizard. If selected, the wizard will open. Here it shows that a User prompt is waiting and the activity Recovering Production has been paused by the system as it awaits the administrator to dismiss the prompt.

RE-IP

IP information can be imported and exported for automated IP addressing to avoid IP duplication between Production VMs and Replica VMs when testing a copy, recovering production, and failing over.

The Re-IP information can be applied to Replica VMs through scripts and CSV file network information. The scripts are executed directly on the Replica VMs and parameters are passed to the script via VMware tools. In case VMware tools are not installed, a warning is displayed and Re-IP does not take place.

The Re-IP can be set on a batch of VMs. The virtual network interfaces are used in the reconfiguration.

The supported changes can be IPv4 and IPv6 addresses, subnet masks, gateway, DNS, and NTP information.

The RecoverPoint for VMs 4.3 software release also provides CSV template files, Linux bash and Python scripts, and Windows batch and Python scripts. The user can choose to use his own scripts and leverage the parameters passed by RecoverPoint for VMs. The user is responsible to place the scripts in the appropriate location for the changes to be persistent across reboots (OS dependent).


Go to RecoverPoint for VMs Management > Administration > vRPA > Networking. Here you can import a CSV file for a system-wide network configuration and export a CSV file with the current network configuration.

In this example CSV file, VM names are highlighted. Multiple vCenter servers and their names are displayed as well. This is an RP system-wide network file. There is an option to generate an empty template CSV file with all VMs and NICs in order to import them again.

Reports


The reports for recovery activities can be viewed in the RecoverPoint for VMs Management window under Reports. Select the relevant consistency group on the left, and then scroll through the list of recovery activity reports on the right.

Clicking on a report displays the details of the specific activity report underneath in the same window. It is an overview of the type of activity, and the start and complete time. This is where a report can be exported in CSV format.

Within each activity report, you can expand the steps to view more details.

Deployments Enhancements

The vRPA and RecoverPoint cluster deployment has been simplified, now running faster, and reboots have been eliminated.

This is also true for the ESXi splitter installation.

The RP for VMs 4.3 release supports the VMware 6.0 environment and vCenter servers can run in linked mode.

Support for a deployment server is added to RecoverPoint for VMs 4.3 which allows automated deployments using API calls.

The deployment process remains mostly the same in this release of RecoverPoint for VMs 4.3 compared to the 4.2 release. Changes, enhancements, and critical steps are covered in this module.

The deployment needs a VMware vSphere environment 5.1 U1 and above with ESXi hosts 5.1, 5.5 and/or 6.0. A minimum of two ESXi hosts are needed since the RecoverPoint for VMs cluster has a minimum of two virtual RecoverPoint Appliances that need to run on different physical ESXi hosts for high availability.

First, install the RecoverPoint for VMs ESXi host splitter on all the ESXi hosts in a VMware cluster that hosts protected Production VMs or their Replicas.

Prepare the virtual network configuration (WAN, LAN, iSCSI1, and iSCSI2) on the ESXi hosts in the VMware cluster where the vRPAs are deployed. The iSCSI network is required between the vRPAs and ESXi host splitters. They are not visible to VMs or storage and require the same broadcast domain as the VMkernel ports for the Software iSCSI Adapter enabled on each ESXi host. For best practice, separate iSCSI traffic from LAN/WAN traffic. It is recommended that each network maps to a separate physical NIC. NIC teaming is not supported.

After you deployed the planned number of vRPAs using the OVA file, run the Deployment Manager and configure a RecoverPoint for VMs cluster, including the installation of the vSphere Web Client plugin for RecoverPoint for VMs. The Deployment Manager is also used to connect a new RP cluster to an existing RecoverPoint for VMs system.

The RecoverPoint for VMs splitter comes as a vSphere Installation Bundle (VIB) file and is installed with the user root through SSH and the esxcli command.

The RecoverPoint for VMs ESXi host splitter is to be installed on all ESXi hosts in the VMware cluster. If a new ESXi host is added without the splitter to an ESXi cluster, a warning is displayed and protected VMs will not be able to use this ESXi host.

The splitter installation in RecoverPoint for VMs 4.3 no longer makes a reboot of the ESXi host necessary, simplifying the splitter installation.

Additional Product Enhancements

RecoverPoint for VMs 4.3 has added and simplified functionality and management for VMDKs, RDMs, thick and thin provisioning, and resizing of VMDKs.

The license is based on the production site vCenter ID. Furthermore, application consistent bookmarks with RecoverPoint KVSS are supported.

The upgrade from RecoverPoint 4.2 to 4.3 can be performed online.

With VMware Thin provisioning operating at the virtual disk level, VM administrators gain the ability to allocate virtual disk files (VMDK) as thick or thin. Thin provisioning of virtual disks allow virtual machines on VMware ESXi hosts to provision the entire space required for the disks current and future activities, but at first commits only as much storage space as the disk needs for its initial operation.

RecoverPoint for VMs 4.3 allows you to replicate data in a mixed environment of thick-thin configurations across sites, including thin-to-thick and thin-to-thin.

An advanced option in the Protect VM wizard allows you to choose a different configuration for the Replica VMDK copies.

When setting up a Replica VM with automatic provisioning, it will have the same provisioning as the Production VM.


When the Protect VM wizard is used to setup protection for a VM, the Advanced Options are available under the Configure production settings. The Advanced Options offer settings for the Protection Policy for new VMDKs, Disk Provisioning settings, and Hardware Changes. These options are set within the VM production copy settings and are valid for all the Replica copies of this Production VM.

Notice the option Disk Provisioning with its default setting Same as source. Clicking the drop down list shows the available options.

Application Consistency with VSS

Point-in-Time snapshots with RecoverPoint for VMs systems are typically crash consistent.

Application consistency can be achieved, for example, by leveraging the RecoverPoint KVSS utility, which is a command-line utility. It enables application consistent bookmarks for a certain VM. This utility can be installed on Windows 2008, 2008 R2, and 2012 R2. The commands are issued against the CG and not the VM.

Recovery execution is possible for any application supporting Microsoft Volume Shadow Copy Service (VSS). Validated applications include MS SQL 2012 and later and MS Exchange 2010 and later.

you can download RP4VMs 4.3 from here, http://www.emc.com/products-solutions/trial-software-download/recoverpointforvms.htm

Ok, that was a lot to cover up, time to show you some demos,

Let’s start with the actual deployment

Now, lets show a basic protection workflow

And here’s an advanced protection workflow

And finally, the recovery (failover) workflow


Leave a ReplyCancel reply