Enabling multi-cloud fail-over of VMs (I’m a big fan of multi-cloud and not having an ‘OR’ mindset – Azure OR GCP, Azure OR AWS) is much easier than you may think, especially when one of the cloud environments you’re using is Azure.
ASR (Azure Site Recovery), a Microsoft Azure service that orchestrates and manages disaster recovery for Azure VMs, and on-premises VMs and physical servers. ASR can also be used as a migration tool to migrate VMs across Microsoft data centres but also from other cloud providers and your own data centres into Azure!
For this blog post I’ll show how I have used ASR to migrate VMs out of Google Cloud and into Azure.
For the purposes of this blog post I have created two VMs in a new GCP project.
One of the VMs will be used as the ‘Sync Server’ and one of the VMs will be the server that I’m wanting to failover into Azure. To make it a little more ‘fun’(?) I have configured the VM I’m wanting to failover in London, the sync server it will sync via in the US and it will sync into an Azure resource group located in Amsterdam.
Next up you will need a recovery vault, if you don’t already have one (I’d recommend creating a new one for testing purposes of this). I won’t go into how to create that as there’s already good documentation out there on how to do this if needed.
Once you have the recovery vault in place you can start the ASR configuration.
Configuring ASR for on-premises or other cloud migrations is a little more involved than replicating VMs across Azure data centres for migration or DR. There’s several steps to go through and as the blade warns these are long running tasks and time needs to be dedicated to completing each step.
Important to note that the ‘Are your machines virtualised?’ Should be set to ‘Not virtualised / other’
It’s highly recommended that you run the deployment planner (http://aka.ms/asr-deployment-planner) Using ASR to migrate machines can require very high bandwidth, storage and cost. The planner can help forecast with this to prevent replication issues.
Next you will need to add a configuration server. Think of this like a proxy server from the VM you want to sync and Azure. You will need to ensure that the VM you’re wanting to sync and this configurations server are able to talk to each other. You’ll configure the ports etc. later.
For my configuration server I will be using is the Instance 3 located in US East-1 region. It’s important to ensure that the config server and Microsoft can happily talk to each other through any firewalls and proxies you may have. Microsoft’s latest service URL list can be found here (http://aka.ms/serviceurls). They do keep this updated on a regular basis.
Next you will need to install the ‘Microsoft Azure Site Recovery Unified Setup’ application. On the ‘Before you Begin’ screen you will be asked if this is for a new deployment, or if you’re adding an additional to an existing deployment for HA. Obviously if you’re setting this up for a live, production project this maybe something you want to consider.
Next you will need to agree to the terms for MySQL as part of the install the installer will download, install and configure MySQL for you.
Next you will need the Site Recovery Registration Key. This is what will tie your configuration server into your Azure Site Recovery vault. You can download the key from the Azure portal. Step 4 on the ‘Add Server’ blade you should have open in Azure is ‘Download Vault Registration Key’.
The next few screens in the installer are for configuring any proxy information, checking pre-reqs are in place (you may get warnings about none static IP addresses etc.) You will be asked to provide a password for the MySQL root user. Under ‘Environment Details’ you will be asked if you want to protect VMWare virtual machines, in my case I don’t as I’m setting this up for replicating GCP VMs. You will then be asked the basic questions of where do you want to install to. And finally you will be asked a question about with NIC you are wanting to use for replication and which port. Port 443 will be used for the comms between this server and Azure and will be opened on all NICs on the VM. The port you specify is for the actual data transfer and will only be opened on the NIC you select.
After all of that you will install the software. This took around 10 minutes for me as it downloads MySQL and configures a fair few settings.
Once installed you will need to use the Cspsconfigtool.exe tool (you should have a shortcut on the desktop) to configure the Sync. You will need to provide a username and password which will be used to install the ‘Mobility Agent’ service on the VM that you will be replicating. In my setup the servers we’re standalone/workgroup joined so the user account I configured was a local user added to the Local Admins group on the server I’m wanting to sync.
You will see other tabs in there for configuring the vault registration and port numbers which you have already configured during the setup process. You have now configured Step 3 ‘Source’ of the ‘Prepare Infrastructure’ blade.
So onto Step 4 ‘Target’. Here you configure the subscription, storage and network accounts you will want to use. If you’re not ready to associate to a network you can leave this blank for now and configure later but bare in mind you will not be able to failover until this is done.
And finally Step 5 ‘Replication Settings’. Here you conifer the RPO, recovery point retention and app-consistancy. If you already have one configured you can select it or create new one.
Back on the Site Recovery blade you will see the next Step ‘For On-Premises Machines and Azure VMs’ Step 1: Replication Application.
The Source should be ‘On-premises’, Source Location should be the Sync server you have just configured, in my case ‘Instance-3. The Machine type should be ‘Physical Machines’ and the process-server is again the server you have just configured ‘Instance-3’ in my scenario.
Next onto Step 3 ‘Physical Machines’ you add the IP address and Hostname of the VM you are wanting to sync into Azure.
Next on 4 ‘Configure Properties’ you can specify the disks that you’re wanting to sync. You will also need to select the account to use. This is the account you specified when setting up the Configuration Server and the account that you have added to the local admins group. This account will be used to install the Mobility Service agent.
Finally on step 5 ‘Replication Settings’ you can select the policy you configured earlier.
You’re nearly there! You can now select ‘Enable Replication’.
Back on the main Azure Site Recovery blade you can now see the VM and the status of its replication. Navigate to ‘Protected Items’ and ‘Replicated items’
The ‘Replication Health’ will show the status of the replication as a percentage. For my VM it took around an hour for the initial to happen.
And that’s it, once the initial replication and the snapshot has been created you will be able to test fail-over or real fail-over the VM. Don’t forget if you didn’t setup the networking earlier you’ll need to configure this before you fail it over.
Although there’s a lot of clicks and a fair few steps in multiple blades to configure the whole process is fairly simple and is a great way to enable multi cloud fail-over or VM migration.