Itzikr's Blog

This one is a big one!

Many customers have been waiting for the ability to use RP4VMs to replicate the VMs to AWS.

• RecoverPoint for Virtual Machines is software-only continuous data protection solution for protecting VMware VMs
  • Features Any PiT capabilities
  • Includes centralized management and built-in orchestration
  • Supports only on-prem replication pre-5.2.1
• Cloud DR enables orchestration in the cloud with minimal costs and footprint
  • Features centralized management
  • Available for Avamar and DataDomain as well as for iDPA
  • AWS and Azure

RecoverPoint for VMs 5.2.1 together with Cloud DR 18.4 enable the protection of VMs to Amazon cloud. RecoverPoint for VMs works in conjunction with Amazon Web Services (AWS) to protect your production VMs, by replicating them to the AWS cloud. Copy data is compressed, encrypted, and stored as incremental snapshots in an Amazon S3 bucket. As part of the protection configuration, you can modify the snap-replication policy by specifying the time interval between replicated snapshots. You can also modify the retention policy, and specify the period of time during which copies should be available for recovery.

After your VMs are protected, the Cloud DR Server user interface is used to create, manage, test and fail over the protected snapshots in AWS. Cloud DR provides crash-consistent, image-level, VM recovery to native AWS EC2 instances or to VMware Cloud on AWS. After failover, you can fail back from AWS to an on-premises vCenter. DR plans are used to recover multiple VMs and pre-configure recovery orchestration, including network and security groups association, VM boot order definition, and VM type selection. You can also accelerate the recovery process by creating rapid recovery images for protected VMs.  Using temporary restore services, Cloud DR allows the automatic consolidation of snapshots according to the retention policy

The RecoverPoint for VMs cloud solution can be deployed as a standalone solution, or alongside the on-premises copies of an existing RecoverPoint for VMs vSphere solution. The deployment of Cloud DR Server (CDRS) is performed automatically by RP4VM upon registration. CDRA is not required except for failback to vCenter or recovery to VMware cloud on AWS.

Highlights of this Release:

• RecoverPoint for VMs Cloud Solution Main capabilities:
  • Proprietary snapshot replication to S3 with RPO as low as 15 mins. First full copy followed by changes only
  • Low RTO using Cloud DR Rapid Recovery
  • Allow replication to cloud only (w/o DR site) as well as multi copies to cloud and on-premises (local/remote)
  • Test / Failover to AWS EC2 or VMware cloud on AWS
  • Failback to on-premises VMware environments
  • In-cloud DR orchestration
  • No additional license cost
  • Restore services / VMware Cloud SDDC on demand
  • Configure and protect directly from RP4VM UI. Monitor and recover through Cloud DR UI
  • Automatic deployment of Cloud DR Server
  • No additional components on-premises. Only standard RP4VM is required on production vCenter

• Additional features introduced in Cloud DR 18.4:
  • Enable maintaining source VM MAC Address and UID when recovering directly to vCenter/ VMware Cloud on AWS
  • Private IP orchestration for recovered cloud instances (when recovering to AWS EC2 instances, or Azure VMs)
  • Support for Azure Hybrid benefits for minimizing licensing costs
  • Enable user configuration of Rapid Recovery copy creation intervals

Solution Overview

Use Case Example 1: Cost Effective DR to Cloud

Description: Customers that would like to use the cloud as a DR site.

Benefits:

• Cost-effective
• RPO as low as 15 minutes
• Flexible recovery options to VMC/EC2 instance
• Orchestration

Use Case Example 2: Replication Tiers

Description: Customers would like to replicate critical tier-1 VMs to a DR site with RPO of seconds and replicate tier-2 VMs to the cloud with RPO of minutes.

Benefits:

• Single management and monitoring point from VC

Multi-copy options

Architecture

High Level Principles

• RP4VMs replicates directly to S3 (Data Path)
• CDR in in charge of orchestration in the cloud (Control Path)
• RPVM vRPAs communicates with S3 for replication and CDRS for deployment and monitoring
  • Sends VMDK segments to S3
• vRPAs have a CDRA components built into them
• The restore services in the cloud have a RPVM component that is in charge of consolidation – PiT expiration in the cloud and most importantly, rehydration
  • Consolidation occurs every night at 1AM GMT
• Restore services are being spun up when a recovery action is performed
  • As well as every night at 1AM in order to remove snapshots which are out of policy
  • CDRS is always up and running
• RP4VMs replication leverages snap-based replication to the cloud
  • Minimum RPO of 15 minutes

On-prem copies would always use continuous replication

Architecture Diagram

Snap-Based Replication

When replicating to the cloud, periodic replication is optimal

Continuous replication would be too expensive in terms of billing costs of ingress BW and would also require heavy replication instances in the cloud

RP4VMs snap-based replication leverages the splitter to intercept writes as they come in from the guestOS

These writes are sent to the snap replication volume (on-prem)

The snap-based replication DS is configured by the user in the plugin

Different than a journal as it holds only the latest copy of every block

When the snap-based replication periodic interval has passed or a bookmark is issued then the data from the snap replication volume is replicated

Another volume is provisioned to hold the writes that came in during replication

Previous volumes is removed when replication is done

All provisioning tasks are automated by RPVM

Deployment

• On-Prem
  • Minimum of vSphere 6.0U2, 6.7U1 is supported
    • Always refer to the RPVM ESSM
• On AWS
  • Accept AWS marketplace software terms
    (In order to launch a CDRS instance from the marketplace)
  • AWS IAM user with permissions as per CDR requirements
  • S3 bucket on a supported region
  • Protected VMs must adhere to AWS import requirements:
    • http://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs.html
      
• Standard RPVM deployment
  • Deployment flow remains unchanged
• Post-RPVM deployment, in the plugin, under Administration -> Cloud Services
  • Register AWS Account
    • Provide Access Key ID and Secret Access Key
  • Register S3 bucket
    • Select one bucket associated with this account, for a specific region
  • Register CDRS
    • Provide CDRS admin password
    • RPVM would search for a CDRS on that account and region and will try to login to it. If there is no existing CDRS, a new one would be deployed with the provided admin password
• Snap Replication datastores can be registered on the same screen or in the protect VM wizard

Protection

• Protect VM wizard enhancement for adding a new type of copy
  • Creating a new CG
  • Adding a copy to an existing CG
• Copy type AWS Cloud
• From a system topology point of view, the cloud copy is a local copy
  • Minimal representation in the UI
  • Local copy (continuous replication) can still be added
  • Cloud copy consumes 2 replica copies
    • The maximum FAN-out is prod going to cloud and additional 2 non-cloud replica copies
• The new copy should be configured with Snap-based replication mode, retention policy and RPO
  • Retention policy can be configured by defining the amount of time to keep in days
  • RPO is changed in accordance with the Snap-based replication periodic interval
  • Default interval is 1hr with RPO of 90 minutes and retention of 5 days
  • Minimum interval is 15 minutes and maximum is 7 days
  • Minimum retention of 1 day and maximum of 90 days
  • Other than SBR periodic mode, there is also Manual which is replication on demand, when issuing a bookmark
    

Recovery Actions

• All recovery actions for cloud copies are initiated from the CDRS UI
  • Test
    • Promote to failover
  • Failover
  • Failover to vCenter
  • Failover to VMC (VMware cloud on AWS)
  • Failback
• All failover/failback to vCenter actions (including VMC) requires manual deployment of CDRA
• From the RP4VMs Web Client plugin, recovery actions would be possible only on non-cloud copies
• Failover to the cloud requires to shutdown of production VMs to prevent conflicts
• Rapid Recovery is fully supported for RPVM-created snapshots in the cloud
  

Test Flow

Failback

Recovery To VMC

• VMware Cloud on AWS – VMware software stack running on AWS infrastructure
• AWS provides dedicated bare-metal hosts
• VMware provides the vSphere stack
  • vSAN for storage
  • NSX for networking
  • ESXi for compute
  • vCenter for management
• Purchased on building blocks of 4 ESXi hosts

• Creating a Software Defined Data Center (SDDC) and configuring it is through the VMC web portal
• An SDDC cannot be “turned off”. If you shut it down – everything will be deleted
• After an SDDC is configured, the rest of the configuration is done through the VC

• Ability to recover a protected VM directly from S3 to VMC
• When you need to recover to VMC, a CDRA needs to be deployed on the SDDC vCenter
• CDRA on the SDDC needs to be enabled for direct VC recovery
• Recovery is performed from segments stored on Cloud DR Targets, no rehydration process
• Ability to recover protected VM to any on-prem VC with a CDRA with the direct failover feature enabled
• Recovered VM can be vMotioned to on-prem vCenter

Failover to non-cloud copies

• Upon failover to non-cloud replica copy
  • Cloud copy is removed from the group upon ‘set production’ to remote copy
  • User is notified that the cloud copy is lost
  • CDRS is updated and marks the policy as “to be deleted…”
  • Copy would be removed next time consolidation occurs
• Upon fail over back to original production copy
  • It is possible to add a cloud copy

Will be different than the original one

Caveats and Limitations

• Scale*
  • 256 VMs per RPVM system
  • 64 CGs with 1 cloud copy each
  • Max VM size – 10TB
  • Max VMDK size – 4TB
  • Total capacity per copy – 60TB
• Log collection
  • When collecting logs from RPVM, a S3 link would be provided with the CDRS logs
• VMDK exclusion
  • When excluding VMDKs through the RPVM plugin, during protection or post-protection, VMDKs would not be excluded for cloud copies, only for non-cloud replica copies
• RP4VMs is supported only in Cloud DR standard mode

  Miscellaneous
  

• RP4VMs 5.2.1 fully supports IPv6 for LAN and WAN
• Enhanced support for stretched clusters in RP4VMs 5.2.1
  • There is now awareness of the latency between the preferred vRPA and the protected VM and its splitter
  • This makes sure that the preferred vRPA is on the same datacenter as the protected VM
  • This enables support for higher latency between stretched DCs
  • Pre-5.2.1, RPVM supported up to and including 1ms
  • With 5.2.1, max of 5ms RTT is officially supported
• Support for FTP/S
  • Log collection in plugin and boxmgmt CLI
  • ISO download in Upgrade flow in Deployer
  • Applies to REST as well
• Specific Uninstaller version for RP4VMs 5.2.1 – Uninstaller version 1.2.0.0-90

you can download RP4VMs 5.2 SP1 from the link below (click the screenshot)

if you want to see a video about how it all works!