This post will cover how to protect a VM in my on-prem environment to VMC on AWS. I will then show how that VM can be recovered in the cloud. The same premise can be used to protect multiple VMs. While SRM can be used for datacenter migrations, I would recommend that you use HCX for this task, especially with VMC on AWS as there is an additional cost for SRM. Although HCX can also do protection, SRM is a much more feature rich way to do it.
Prerequisites:
- SDDC set up and VMC on AWS Functioning
- SRM and vSphere Replication (VR) deployed both on-prem and on VMC on AWS
- Appropriate VPN and firewall rules created
- SRM and VR have been connected and paired
As per my HCX guide, I will be using a single Ubuntu 16.04 LTS VM with a basic phpbb3 website configured. Once the VM has been recovered on the recovery (VMC) site, DNS will have to be updated to point to the new VM if this were a real web server.
First of all, within the vSphere Client, head to Menu > Site Recovery. You should see the existing site pair already created, on that site pair choose View Details and it will show you the Site Recovery overview. Note: you may have to re authenticate with the recovery (VMC) site.
First head to network mappings. SRM doesn’t know what Port Groups local and remote do what. So we need to specify which port groups map together. Head to Network mappings and New.
It may be possible depending on your naming convention that the mappings will automatically work. Since this is a single VM, and there are a lot of networks in VMC on AWS prior to any ones being created for workload usage, we’re going to do this manually.
My local network is VLAN 2 and I’m choosing my workload network on VMC on AWS. It’s important no local networks overlap with VMC on AWS. The two networks here are on entirely different subnets. Make sure you click on add mappings – remember there may be multiple mappings here so it could take some time.
For reverse mappings just choose next – it’s out of scope for this post. In short, they’re used if you recover a VM back to the original site and you want to change the network the VM is recovered onto.
For the test network choose the default isolated network. Unless you have specific requirements to test them on other isolate or segregated networks.
Back at the network mappings screen, select the new mapping and then add IP Customization.
Now we map the on-prem subnet to the VMC subnet. These will be different as we are going to change DNS so the application will still work at the end.
It’s largely the same process for folder mappings. Don’t forget that in VMC on AWS you have some folder limitations. I’m just going to map all my folders to the workload folder at the recovery site.
And again with resource pool mappings. You can only choose the compute resource pool or any custom pools sat under it.
Storage policy mappings are next. You may have different on-prem policies which are not allowed on VMC on AWS, such as thick provisioning on the vSAN datastore.
Next we choose our placeholder datastore. This is an area where SRM creates a dummy VM for the purposes of replication. It is not where the replicated data is created.
Now that all mappings are added, we need to add a replication group. Head to that tab and then set up a name and direction. Remember, as per HCX this should always be done on the source site, so outgoing in this case. Choose the default (or appropriate) replication server and click next.
I’m replicating a single VM.
Then select the WorkloadDatastore as the target.
vSphere Replication supports an RPO of 5 minutes, which is pretty agressive. It’s not really needed in my situation! I’ve also enabled network compression as I have enough CPU cycles and I’ve disabled encryption as it’s going over an existing IPSec tunnel. If you wish, you can also create point in time instances, think of this as replicated snapshots of the VM giving you a choice of recovery time.
The key difference between vSphere Replication by itself and SRM is that SRM automates the complete process en-mass including testing and failback in a way which simply isn’t possible using VR alone. For just a few VMs, using SRM is likely not required. Certainly for a single VM, it’s not worth it but I will show it for demonstration purposes. I’m going to create a new protection group.
I’m also going to create a recovery plan.
After confirming, it will start to replicate the VM. The time this takes depends on many factors of course.
While the VM is replicating, we need to configure protection for that VM. Head to Protection Groups > Virtual Machines and then select the replicating VM then select configure protection.
After it finishes replicating, we can test the recovery plans. In this instance we’re just going to recover it. On the VMC side we can simply recover the VM under incoming replications. This would be fine for very few VMs.
If there are a lot or we are planning a large migration, executing the recovery plan would be more suitable. Head to recovery plans and select ‘run’ (we can also test it here on isolated networks). Please note – this should never be done unless there is an agreed outage as it will cause an outage.
You are warned not to do this as it will cause a permanent change. If you just want to test it then cancel here and go to test. I’m choosing that this is a planned migration.
After you select finish, SRM will initiate a final sync if it can and then fail the VM over. This involves switching the VM off on-prem and switching it on, and re-ip’ing it at the VMC (recovery) site.
If all is well you will be able to access the web UI of the VM.
This has been a very simple overview of SRM and how you can use it to migrate workloads to VMC on AWS from your on prem environments. It’s an extremely powerful tool which can automate large scale disaster recovery – perhaps a little more complicated for smaller migrations where HCX would be much better suited.
I hope this has been useful.