VMware Cloud Disaster Recovery is currently the solution that has the most interest from my customers and partners. It’s a solution that offers the best way to deliver an on-demand easy-to-use cost effective DRaaS solution for workloads running on-premise.
A few months ago, it added the ability to protect cloud workloads running in VMware Cloud on AWS with inter-region DR failover (i.e. failover from one region to another region).
Very recently, the solution has now the ability to protect cloud workloads running in VMware Cloud on AWS with intra-region DR failover (i.e. failover into a different availability zone (AZ) within the same region).
Let’s see how we can leverage this to protect workloads.
Deploying vCDR in VMC on AWS
Accessing the vCDR dashboard
First of all I need to access the CSP Console and locate the VMWare Cloud DR tile under the My Service menu.
If I click on the tile here it brings me to VMware Cloud DR landing page.
As you can see it looks very similar to the CSP page. The development team have been doing a great job integrating vCDR in the Services portal.
Currently the dashboard is showing you the health capacity and especially the number of protected VMS, the number of Protection groups, as well as the replication direction of each of your protected sites and recovery SDDC.
In my current Demo environment, there are 3 protected on-premise sites and one recovery SDDC (CSLAB-M17).
The cloud backup site where the Scalable Cloud Filesystem stands is CSA-VCDR-SCFS.
On the left, I can see the replication events and any recent alarms and alerts displayed.
Adding the SDDC as a new Protected site
In this lab, the Scalable Cloud File system has already been deployed. So we can directly jump into the deployment of the vCDR connector on my VMC on AWS SDDC by clicking the Set up a protected site link menu.
Here I choose VMware Cloud on AWS and Click Next.
The list of SDDCs in my organization are then displayed. I can see that only the SDDC that is in a different AZ from my SCFS can be used. So I picked the SDDC in US East North Virginia region.
Here I am presented with two choices: manually create the Gateway Firewall rules or leave vCDR automatically add the right rules. The DRaaS Connector is a VM that has to be deployed on a Compute segment in the SDDC. I decided to choose Automatic and pick the default segment of my SDDC. Obviously it’s up to you to choose another segment dedicated for it.
If you are not sure which option to select, see Network Considerations for a Protected SDDC for more information.
To finish the site creation I clicked Setup.
After a few seconds, the SDDC (JG-LAB-TEST) appears as a Protected Site.
Deploying the DRaaS Connector in the newly protected SDDC
Once the site is configured, the next step is to deploy the DRaaS connector which would enable the SaaS orchestrator communicate with the Protected SDDC vCenter. Refer to the Documentation for the VM CPU and network requirements
This process is quite straight forward. Just click on the Deploy button.
You will presented with a screen that explains every steps.
First of all you have to download the virtual appliance that will enable connectivity from the SDDC to the Cloud filesystem, second connect on the console to finish setting up the IP and to enter the Cloud orchestrator FQDN.
Make a note of the Console credentials, which you need to log in to the VM console: admin/vmware#1. Also copy (or write down) the Orchestrator Fully Qualified Domain Name (FQDN), which you need when you configure the connector in the VM console
A few things you need to know:
- Do not name the DRaaS Connector VM using the same naming conventions you use to name VMs in your vSphere environment.
- Avoid giving the DRaaS Connector VM a name that might match the VM name pattern you use when you define protection groups.
- If you are deploying the DRaaS Connector to a VMware Cloud SDDC with more than one cluster, you must choose a cluster to deploy the connector VM on. Each cluster in your SDDC must have the connector VM deployed on it in order for the VMs running on the cluster to be added to protection groups and replicated to a cloud backup site.
- Do not use non-ASCII characters for the connector name label.
After downloading the OVA by using the URL, I have uploaded the OVA to a Content Library in my SDDC. And started the deployment of the OVA.
I gave it a name.
The only Resource pool that I can choose is the Compute-ResourcePool.
The Storage datastore can only be WorkloadDatastore.
I have chosen the default compute segment (sddc-cgw-network-1).
I am then presented with the final page of the wizard and I click finish to launch the deployment.
After a few seconds, the Connector Virtual Machine appears in the inventory. I just started the VM to be able to continue the setup.
Finishing configuring the Cloud Connector in the SDDC
Second phase of the deployment is to setting up the networking.
Once the VM has started, I have had to open a console from vCenter in order to finish the configuration I have had to connect with credential presented is the latest window: admin/vmware#1.
I have typed ‘a’ to start Static IP allocation and entered a new IP address and subnet mask plus a DNS IP address (I picked the google one).
Next step is to enter the Cloud Orchestrator FQDN.
And to achieve the configuration the site specific pass-code…
and the site label (I kept the same name as the VM).
After a few seconds, I received a Success message to inform me that the setup was achieved.
To finish this phase, I have checked that the right firewall rules have been created in my SDDC.
With the newly added rule, the segment where the Cloud Connector runs has access to the Cloud Orchestrator in the cloud with SSH and HTTPS, to the SDDC vCenter, and to the Auto-support server in HTTPS. Finally it has also access to the scalable Cloud File System on the port TCP 1759.
That’s conclude the first part of this very long series of post on vCDR.
In my next post I am going to show you how to start protecting VMs in the Protected SDDC!