Failover Workflows from On-Premise to Cloud Using vCloud Availability

In this exercise, we will be learn

  • How to protect VMs from On-Prem to Cloud.
  • How to Test recover, Test Cleanup, Recover and Reverse Replicate the VMs from on-premises to cloud and back.

 

Configure Replication from On-Prem to Cloud

Login to vCenter

You should still be logged in to vSphere Region A and in the DRaaS section. If not, open a browser window, log in to vSphere as administrator@regiona.local, and go to the DRaaS section under the Menu.

Now we will configure an Outgoing Replication. There are two replication options:

  • Protection - Protecting a virtual machine from on-prem to a VCD target; keeps the workload running in the source site.
  • Migration - Migrating a virtual machine from on-prem to a VCD target; powers off the source and runs the workload in the destination site.

In this lab exercise, we will configure Protection of VM from On-Premises to Cloud.

  1. Click on Outgoing Replications
  2. Click on the icon New protection

Enter Credentials to manage replications to Cloud

Login to vCenter
  1. Username: t1admin
  2. Enter Password: VMware1!
  3. Click on LOGIN

Select vCenter VM for Replication

Site Pairing
  1. Select VM core-A
  2. Click on Next

Select Destination VDC and Storage Policy for Replication

Register new Connection
  1. Select vDC Tenant1
  2. Select Storage policy Any
  3. Click on Next

Configure Settings

Register new Remote Site Connection

Brief overview of the parameters on this page -

SLA Profile - The premise of a SLA Profile is to provide a grouping of target settings when protecting a workload. This minimizes the amount of time spent configuring for protection. Think of this as a logical grouping construct which is a single selection to protect a workload. One does not need to think about what settings to configure. A SLA Profile consists of the following:

  1. Target Recovery Point Objective (target being the key word here)
  2. Retention Policy for Point in Time Instances
  3. Ability to Quiesce or Compress Replication Traffic
  4. Time select of the synchronization.

Just select SLA profile, and done. You can either use default or custom created SLA profile. SLA profiles are optional and only pertain to protections. They are not utilized for migrations at this time.

Target recovery point objective (RPO) - The RPO is the longest tolerable timeframe of data loss. For example, with one hour RPO the recovered virtual machine can have no more than one hour of data lost. Shorter RPO intervals, ensure less data loss during recovery, at the expense of consuming more network bandwidth to keep the replica up to date.

Retention Policy - Maximum number of retained snapshots per single virtual machine replication within an organization.

Delay start synchronization

  • To schedule the start of the replication, select this option and enter the local date and time to start the replication.
  • To start the replication when the wizard finishes, leave this option deselected.

Exclude disks -To exclude some hard disks of the virtual machines from replicating to the destination site, select this option.

Configure Seed VMs - For each new replication that you configure, an initial full synchronization operation is performed. During this operation, vCloud Availability copies the whole data from the source vApp or VM to a datastore in the target site. Due to the size of the vApp or VM or to the network bandwidth, an initial full synchronization might take a long time.

To reduce the initial synchronization time, you copy the source vApp or VM to the target site by using removable media, failover of a previous replication, or other means of data transfer. Then, in the target site, configure a replication that uses the vApp or VM copy as a replication seed.

When a replication uses a seed vApp or VM, vCloud Availability does not copy the whole source vApp or VM data to the target site. Instead, vCloud Availability copies only the different data blocks between the source vApp or VM and the seed and reuses the seed data in the target site as a basis for replication.

We do not have Seed VM available at the target site for this exercise

  1. Leave everything as Default and Click Next

 

Complete Replication to Cloud

Choose Hybrid Services
  1. Verify the Replication Settings are correct and click Finish

Confirm the Replication is started

Local Gateway Parameters
  1. Confirm that the replication is started. You can monitor the % progress here.

Note: the time it takes to replicate a VM depends on the size of the VM. In this case, the VM is relatively small, so it should only take a minute or two.

Replication is Completed

L2 Concentrator Configuration

Confirm the replication status of VM core-A

  1. Replication State is Healthy
  2. Overall health is Green

Note: In case you see Unexpected vCloud Director error during replication, please retry. Due to the nested environment in Hands On Lab, sometimes the error is seen, in real world it should work seamlessly.  

Confirm the Replication Status from Cloud Provider Site

Ready to complete

You should still have a second tab open logged in to the Cloud SiteB as t1admin. If not, open a new tab, go to VCD-SiteB - Tenant1 from the Region B folder in the bookmarks bar, log in as t1admin, and click on the More menu and select Availability (SiteB).

  1. Click on the second browser tab to go back to the Tenant1 OVDC in VCD SiteB.

Confirm the Replication Status at Cloud Site

Ready to complete
  1. Click on Incoming Replication - from On-Premises
  2. Confirm the VM core-A replication state is Healthy

Configure Network for Recovery Workflows

Verify Site Pairing

Before we can run Recovery of the replicated VM, we need to configure a Test/Failover Network. This step can be either done from On-Premises or the Cloud. This Network would be connected to the Recovered VM.

  1. Switch to On-Premises tab
  2. From the Outgoing Replications, check the checkbox for core-A
  3. Expand ALL ACTIONS
  4. Click on Network Settings

Configure Network for Recovery Workflows

Fleet Deployed and Tunnel is Up

Before we can run Recovery of the replicated VM, we need to configure a Test/Failover Network. This step can be either done from On-Premises or the Cloud. This Network would be connected to the Recovered VM.

For HOL lab exercise, Migrate and Test Failover networks are pre-configured. In production environment, please create migrate/test failover networks before configuring it here.

  1. Select MIGRATE/FAILOVER
  2. Expand None
  3. Select Tenant1-OVDC-B-OrgNet-Rtd

Configure Network for Recovery Workflows (contd..)

Fleet Deployed and Tunnel is Up
  1. Select TEST FAILOVER
  2. Expand None
  3. Select Tenant1-OVDC-B-TestNet
  4. Click APPLY

We have successfully configured network for both Migrate/Failover and Test Failover workflows.

Configure Test Failover

Fleet Deployed and Tunnel is Up

By performing a test failover you can validate that the data from the source site replicates correctly in the destination site. Test Failover can be configured from either the On-Premises or Cloud site. For HOL exercise, we will configure Test Failover from On-Premises.

  1. Check the checkbox for VM core-A
  2. Click on the icon Test Failover

Configure Recovery Settings for Test Failover

Fleet Deployed and Tunnel is Up

For the recovered VMs, here are Recovery Settings:

  • Power on recovered vApps - Select to power on the virtual machines in the destination site after the task completes.
  • Network settings
    • Select Apply preconfigured network settings on failover, to assign the network configured during the virtual machine replication.
    • Select Connect all VMs to network and from the drop-down menu select a network to connect the replicated virtual machines to.

 

  1. Check the checkbox Power on recovered VMs
  2. Network Settings: Select Apply preconfigured network settings on failover . We preconfigured network settings in the previous steps.
  3. Click NEXT

Configure Recovery Instance for Test Recovery Workflow

Fleet Deployed and Tunnel is Up

Select recovery point in time -

- Synchronize all VMs to their current state - Creates an instance of the powered on vApp with its latest changes and uses that instance for the Test Failover operation.

- Manually select existing instance - Select an instance without synchronizing the data for the recovered workload.

  1. For the Recovery point in time select Synchronize all VMs to their current state
  2. Click on Next

Ready To Complete the Test Failover

Fleet Deployed and Tunnel is Up
  1. On the Ready To Complete page, review the test details and click FINISH to initiate the Test Failover

Test Failover is in progress

Fleet Deployed and Tunnel is Up

Verify the Test Failover is started and Recovery state is updated to Fail-Over. You can monitor the % progress for test failover.

Test Failover is Completed and Successful

Fleet Deployed and Tunnel is Up

Confirm the Recovery State is Test Image Ready and Overall Health is Green.

Please be patient, it may take few minutes for the Test Failover to be Complete.

Note: In case you see Unexpected vCloud Director error during test failover, please retry. Due to the nested environment in Hands On Lab, sometimes the error is seen, in real world it should work seamlessly.  

View Failover VM at Cloud Site

Fleet Deployed and Tunnel is Up
  1. Switch to tab VMware Cloud Director Availability as a tenant
  2. Click on Data Centers
  3. Click on Virtual Datacenters Tenant1-OVDC-B

Verify Test Recovery on Cloud Site

Fleet Deployed and Tunnel is Up
  1. Confirm that core-A VM shows up here.
  2. Verify the network is Tenant1-OVDC-B-TestNet

 

Configure Test Cleanup

Fleet Deployed and Tunnel is Up

To delete the test failover results, we will configure Test Cleanup. The cleanup deletes all recovered vApps and virtual machines.

  1. Switch to On-Premises tab
  2. Click on Outgoing Replications
  3. Check the checkbox for VM core-A
  4. Expand ALL ACTIONS
  5. Click on Test Cleanup

Confirm Test Cleanup

Fleet Deployed and Tunnel is Up
  1. Click on CLEANUP.

Test Cleanup is Started

Fleet Deployed and Tunnel is Up
  1. Confirm Test Cleanup is started.

Test Cleanup is Successful

Fleet Deployed and Tunnel is Up

Test Cleanup is completed successfully. Please Confirm

  1. Recovery State is Not Started
  2. Overall health is Green

Confirm VM is removed from Cloud Site

Fleet Deployed and Tunnel is Up
  1. Switch to tab VMware Cloud Director Availability as a tenant

Notice core-A VM is removed from here after Test Cleanup is successful.

Perform a Failover Task from On-Prem to Cloud

Fleet Deployed and Tunnel is Up

If the protected source site is unavailable, in the destination site user can perform a workload disaster recovery operation. Lets DR failover a VM in Cloud.

  1. Expand More and Click on Availability (SiteB)

Perform a Failover Task from On-Prem to Cloud

Fleet Deployed and Tunnel is Up
  1. Click on Incoming Replication from On-Premises
  2. Check the checkbox for VM core-A
  3. Expand ALL ACTIONS
  4. Click on Failover

Configure Recovery Settings for Failover

Fleet Deployed and Tunnel is Up

Consolidate VM disks - Enable for a better performance of the recovered virtual machines at the expense of the failover task taking longer to complete.

Power on recovered vApps - Select to power on the virtual machines on the destination site after the task completes.

Network settings

  • SelectApply preconfigured network settings on failover, to assign the network configured during the virtual machine replication
  • SelectConnect all VMs to networkand from the drop-down menu select a network to connect the replicated virtual machines to.
  1. Leave the defaults and Click on NEXT

Configure Recovery Instance for Failover

Fleet Deployed and Tunnel is Up

On the Recovery Instance page, you can choose the recovery point in time instance for failover.

  1. We'll continue with default latest instance and Click on NEXT

Ready to Complete the Failover

Fleet Deployed and Tunnel is Up
  1. Review the Failover details and Click on FINISH

Failover in Progress

Fleet Deployed and Tunnel is Up
  1. In the Detailed Status, you will notice Failover in Progress with % progress.
  2. While Failover progresses, you will notice the Recovery State is updated to Fail-Over

Failover completed successfully

Fleet Deployed and Tunnel is Up

This process will take a couple of minutes. Please be patient. After the failover task finishes, the failed over workload is running in the destination site and the workload is no longer protected upon the task completion

  1. Replication State is Healthy
  2. Recovery State shows Failed-Over.
  3. Overall health is Green

Note: In case you see Unexpected vCloud Director error during failover, please retry. Due to the nested environment in Hands On Lab, sometimes the error is seen, in real world it should work seamlessly.  

Verify VM is Failed-Over to Cloud

Fleet Deployed and Tunnel is Up

After DR failover, we will confirm that the VM is Failed-Over and powered-on in Cloud site

  1. Click on Data Centers
  2. Click on virtual datacenter Tenant1-OVDC-B

Confirm VM is Failed-Over and Running in Cloud

Fleet Deployed and Tunnel is Up
  1. Confirm that core-A VM shows up here.
  2. Verify the network is Tenant1-OVDC-B-OrgNet-Rtd (since this was the one preconfigured for Failover workflows in the previous exercise).

The Failed-Over VM is running on the destination site now. The VM is no longer protected.

Go to Hosts and Clusters view on On-Premises Site A

Fleet Deployed and Tunnel is Up

Since we performed DR failover in Cloud assuming protected source site is unavailable, VM remains powered on in Site A. Lets confirm that.

  1. Switch to tab for vSphere On-Premises site
  2. Expand Menu
  3. Click on Hosts and Clusters

Go to Hosts and Clusters view on On-Premises Site A (contd..)

Fleet Deployed and Tunnel is Up
  1. Expand RegionA01
  2. Expand RegionA01-COMP01
  3. Confirm core-A is still powered on at On-Premises SiteA

Configure Reverse Replication from Cloud to On-Prem

Fleet Deployed and Tunnel is Up

After a failover from the source site to the destination site, the migrated workload runs on the destination site. A subsequent reverse task replicates the recovered workload data back to the source protected vApp or virtual machine.

We will reverse replicate the VM core-A from Cloud to On-Premise in this exercise.

  1. Switch to tab Cloud Site
  2. Expand More and click on Availability

Configure Reverse Replication from Cloud to On-Prem (contd..)

Fleet Deployed and Tunnel is Up
  1. Click on Incoming Replications from On-Premises
  2. Check the checkbox for VM core-A
  3. Expand ALL ACTIONS and click on Reverse

Confirm Reverse Replication from Cloud to On-Prem

Fleet Deployed and Tunnel is Up
  1. Click on REVERSE

Reverse Replication is in Progress

Fleet Deployed and Tunnel is Up

Reverse Replication is in progress. You can monitor the progress of the Reverse task in Last changed section.

Reverse Replication is Completed

Fleet Deployed and Tunnel is Up
  1. As soon as Reverse replication is successfully completed, Incoming Replications from On-Prem is empty now
  2. Since the replication is now configured from Cloud to On-Prem, we will view Outgoing Replications to On-Prem

View Outgoing Replications from Cloud to On-Prem

Fleet Deployed and Tunnel is Up
  1. Here you will notice VM core-A is replicated back to On-Prem and Recovery State is Reversed

Migrate VM back to On-Prem

Fleet Deployed and Tunnel is Up

Since the VM is successfully replicated back from Cloud to On-Prem, we will learn to Migrate the VM from Cloud back to On-Prem. Migrating a vApp or a virtual machine to a remote organization runs the workload in the destination site.

The difference between Migrate and Failover workflow is that Migration assumes everything is up and running well at both sites so it powers off the VM/vApp at source site whereas Failover workflow assumes source site is not reachable and leaves the VM/vApp at source running in the same state.

  1. Check the checkbox for VM core-A
  2. Click on Migrate

Configure Migrate Settings

Fleet Deployed and Tunnel is Up
  1. Leave the Defaults and Click on NEXT

Complete Migration to SiteA

Fleet Deployed and Tunnel is Up
  1. Review the Migation Settings and click on FINISH

Migrate to SiteA in Progress

Fleet Deployed and Tunnel is Up

Migration is in progress.

Note: This process will take a few minutes. In case you see an error during, please retry. Due to the nested environment in Hands On Lab, sometimes the error is seen, in real world it should work seamlessly.  

Migration to SiteA is Completed Successfully

Fleet Deployed and Tunnel is Up

Confirm the:

  1. Replication state is Healthy
  2. Recovery state is Failed-Over
  3. Overall health is Green

Confirm VM is Migrated back to SiteA

Fleet Deployed and Tunnel is Up

Since Migration from Cloud to On-Premises site is successful, workload now is powered on and runs in the destination site (On-Premises here)

  1. Switch back to tab vCenter SiteA
  2. VM core-A now shows up in the inventory.

Reprotect VM back from On-Prem to Cloud

Fleet Deployed and Tunnel is Up

After migrating over the workload to On-Premises, we can reverse the replication and reprotect it back to Cloud site. This is done by selecting the Reprotect button. Once Reprotect is successful, this will show as outgoing replication from On-Premises to Cloud

  1. Switch to tab vCD SiteB
  2. Expand Outgoing Replication to On-Premises
  3. Check the checkbox for VM core-A
  4. Expand ALL ACTIONS and Click on Reprotect

Configure Reprotect Settings

Fleet Deployed and Tunnel is Up
  1. Click on REVERSE

Reprotect from On-Premises to Cloud Is In Progress

Fleet Deployed and Tunnel is Up

Reprotect is in progress.

Reprotect from On-Premises to Cloud Completed Successfully

Fleet Deployed and Tunnel is Up
  1. As soon as Reprotect  is successfully completed, Outgoing Replications to On-Prem is empty now
  2. Since the replication is now configured from On-Premises to Cloud, we will view Incoming Replications from On-Prem

View Incoming Replications from On-Prem

Fleet Deployed and Tunnel is Up
  1. Select Incoming Replications from On-Premises
  2. Here you will notice VM core-A is replicated back from On-Premises to Cloud and Replication type is Protection

Verify replication status from On-Premises site

Fleet Deployed and Tunnel is Up

Lets look at On-Premises site and confirm the VM is reprotected from On-Premises back to Cloud site.

  1. Switch to tab vSphere On-Premises site
  2. Expand Menu
  3. Click on DRaas

Verify replication status from On-Premises site

Fleet Deployed and Tunnel is Up
  1. Click in Outgoing Replications
  2. Confirm VM core-A-xxxx is replicated back from On-Premises to Cloud and Replication type is Protection

Congratulations!! You have successfully replicated a VM from On-Premises to Cloud, run the recovery in Cloud, and now replicated and migrated the VM from Cloud back to On-Premises and reprotected the VM from On-Premises back to Cloud.

Please close all tabs on the browser.