Previous Post in Series: Part 6: ASR Invoke Failover to Azure
Overview
Welcome back folks. In the last part of this guide we ran through a failover of our VMware VMs into Azure and what we learned was that as with most things in tech, if you nail the steps that lead up to it, the process of failing over is actually pretty straightforward.
So we’ve only really got one last thing left to do to close our ASR loop, and that’s to failover our VMs from Azure back to our on-premises VMware environment. As such, this will be a fairly short section as there isn’t much too this task.
So without further ado…
Invoke Failover From Azure to On-Premises VMware
So I’m assuming a couple of things here, that you’ve followed the guide successfully up until now and as such your VMware VMs are running in Azure, are in a “Protected” state and are fully synchronised.
Assuming all of the above, let’s move on:
Rather than failover both of my VMs at the same time, I decided to go ahead and try only one of them to make sure there were no issues and that the process would work as expected. With that in mind and within your Recovery Services Vault:
- Navigate to the “Replicated items” blade
- Click “…” to launch the context menu
- Select “Failover”
The “Failover direction” will already be populated as the systems knows where your VMs are currently running from.
- For “Recovery Point”, select “Latest processed (low RTO)”
- Tick “Shut down machine before beginning failover”
- Click “OK”
As ever, you can watch progress from the “Site Recovery Jobs” blade.
How long these jobs take to complete will vary, even down to how long it takes Azure to shut down that particular VM
Once the job has completed, go back to the “Replicated items” blade and take note of the “Replication Health” and “Active Location”. We’re now running in an unprotected state from our On-premises VMware environment.
If we jump back into our vCenter server, we can see that our failed over VM is now up and running.
If we log onto the VM, we can see the “REPLICATE_ME.txt” file we created after we failed over to Azure. We can also have a look on the “C:” drive for the presence of a folder named “WindowsAzure”. It’s not that I don’t trust things, it’s just good to be able to see the evidence 🙂
Just to finished things off, I went back and ran through the same process for my 2nd VM, both are now running in an unprotected state from on-premises.
In a production environment, you likely wouldn’t leave things here, you’d go on to make sure your VMs were back in a protected state but I’m not going to that as I’m about to tear down this lab and reuse it for something else 🙂
Well I hope this has been as useful for some of you out there as it was for me. Good luck in your Azure DR journey and I hope to see you in the next guide…whatever that may end up being.