Getting started with VMware Cloud DR is a fairly simple task. In this series of articles, we will look into the basic steps for getting started with this new VMware Cloud DR solution. This is not meant to replace the product documentation, other training materials, or direct product access such as the Hands-On Lab. Let’s get started and learn about creating a protected site with VMware Cloud DR.
Protecting Your Applications
In the 2nd part of the series, we’ll cover the basic steps needed to get your on-premises environment configured, and cover protecting the VMs to the VMware Cloud Disaster Recovery system set up in the first blog series. The simplicity of this setup makes it easy and cost-efficient for organizations to begin protecting important on-premises vCenter workloads in an offsite location even before establishing a cloud-based DR site.
The set up consists of two basic steps:
- Creating a Protected Site connected to the VMware Cloud Disaster Recovery cloud components,
- Creating Protection Group Policies to match the desired VMs with their designated SLAs.
Create a Protected Site
A Protected Site represents an on-premises vCenter environment that is connected to VMware Cloud Disaster Recovery. This includes at least one DRaaS Connector, which provides the scheduled snapshot and replication services, and a vCenter which provides visibility into the VMs that are going to be protected. A Protected Site is a logical component of VMware Cloud Disaster Recovery and is simple to set up with a few steps in the orchestrator UI (under the Sites options), as seen in the figures below. Note that the Time Zone will be used for scheduling and reporting details.
The DRaaS Connector is easy to install and configure as an appliance VM through typical OVA setup methods. Once deployed and configured, the DRaaS Connector communicates with the VMware Cloud Disaster Recovery system for the designated Protected Site. The DRaaS Connector is a stateless component of the system and is automatically updated from centralized VMware Cloud DR control. Multiple connectors can be deployed per Protected Site, providing for some added resilience and bandwidth if desired. Details on deploying the DRaaS Connector are shown in the figure below. Note that connectivity from the on-premises datacenter to the AWS Cloud is required. Details on firewall ports can be found in the documentation as well as online.
Once a Protected Site has the first connector deployed, then the corresponding vCenter is registered and the basis for a logical Protected site is complete. The VMware Cloud DR orchestrator will then communicate with the DRaaS Connector to protect the designated VMs for the registered vCenter. Users will need the appropriate user-level access to the vCenter when registering it with VMware Cloud DR as shown below.
It is possible to register more than one vCenter per Protected Site, as long as the associated DRaaS Connectors are configured with the right scope to access the VMs, vCenter and ESXi hosts necessary. Note that a vCenter can only be registered to a single Protected Site.
For details on the Protected Site setup process are outlined in the corresponding sections of the VMware Cloud DR documentation. Once the Protected Site is configured, users can then build Protection group policies which will be used for the DR plans.
Create Protection Policies
Protection Group Policies define 3 basic elements of the VMware Cloud DR on-premises site operations:
- What is being protected – the VM inventory
- Recovery Point Objective (RPO) SLAs: frequency of snapshot and replication tasks
- Storage Level Policies (SLPs): retention period for each captured recovery point set
The inclusion rules that define which VMs are protected is based on some combination of:
- VM name – wildcards and exclusion rules allow for dynamic inventory specifications
- VM folders
- vCenter Tags
The schedules define when snapshots are taken, and the change blocks replicated to the offsite Scale Out Cloud Filesystem for later use. Each schedule also defines a retention period for keeping that recovery point in the offsite inventory. A Protection group can have multiple schedules with different frequencies and retention.
Note that a VM can be a member of multiple Protection groups. The exact number of protection policy variations is derived from the current limits of the solution. To help better understand the limits that might apply to your environment, the number of Protection Groups, VMs in each Protection group, snapshots of each VM, and other configuration maximums that exist are all documented online.
Initiate the First Recovery Point
Once a Protection Group is defined, the first execution will take a full copy snapshot and send that initial set of data to the cloud repository. The first execution will follow the prescribed schedule set in the Protection group definition but can also be manually invoked by the administrator as shown below to begin the process when desired.
From that point forward as long as the underlying disks are intact, the snapshots will be incremental, driving savings in network bandwidth and time. It is important to note that the incremental changes are assembled along with previous data sets to provide what is structurally a full point in time copy ready in the cloud filesystem for expedient recovery use. Once these two steps – creating the Protected Site and Protection Group – are completed, users can begin leveraging the Scale Out Cloud File System (SCFS) with up-to-date copies of their on-premises application VMs and have them ready for Live Mount recovery into the VMC SDDC. Now that you’ve learned about creating a protected site with VMware Cloud DR, we’ll cover setting up the SDDC and the DR plans in the next blog, stay tuned!
Useful Resource Links
- VMware Cloud Disaster Recovery product website
- VMware Cloud Disaster Recovery blogs
- VMware Cloud Disaster Recovery videos
- VMware Cloud Disaster Recovery Hands-on Lab
- VMware Cloud Disaster Recovery online documentation
- VMware Ports and Protocols
