In this article I am discussing DR within HCX. It is a bit of a lightweight, but a quick and easy way to protect individual VMs if you don’t have anything else in place, or rather don’t want to interfere with your current DR implementation.
Key points for DR in HCX
- RPO 5 Minutes > 24hrs
- Reverse Failover
- Multiple recovery points possible by utilizing additional snapshots
- Optimized throughout when used in conjunction with the Wan Optimization appliance
- Fully integrated with the vSphere Web Client
A few pre-requisites
- Requires compute at the destination site (d’ur)
- Enabled Interconnect services for the Mesh (it will use the IPSec tunnel for the replication traffic here as well)
- Enabled DR Service on Compute Profile and Mesh
If you read the previous article, you already know that you need to add the additional service in BOTH Compute Profiles – so both Source and Destination – and then also add it to the Service Mesh
Once that is all done, you can simply use the Hybridity interface to navigate to the SR section. Don’t be fooled, the section will be available even if you don’t have the Service enabled yet – process will simply fail.
Click Protect VMs
Select the VM(s) you’d like to protect. Here I only got one so here I select my Linux Test VM, Select Datacenter, Cluster, Storage and Network and choose the appropriate RPO and snapshot interval and hit Next
Make sure the validations succeeds
The VM will now be configured for DR
You can hover over the yellow triangle to see the status
The sync should eventually start
And of course complete as well
Now click Actions > Test Protect
Select the destination and snapshot and hit Test
The test will go underway.
Note: This is not like SRM. A test will not use an internal isolated network. The difference here between test and proper DR is mere the fact the original VM will not be deleted from the source site. If you do NOT tick the above box to power the VM off – you will end up with both VMs, protected, and tested recovered one, online with the same IP – causing an IP conflict.
Also if the VM protected is one you have migrated before and you kept the MAC address (retained) – you will see that the VM has now the MAC set to manual. So you will not just end up with a VM with duplicate IPs, but duplicate MACs as well.
Anyway, the test should be going ahead
And eventually finish
Next, the cleanup, this will power off the recovered VM and also removed
A real failover of course will of course move the VM to the destination site, rather than keep the original in the Source.
Next I will be looking at Cross-Cloud vMotion.