Last week I was asked to participate in a project regarding Azure Site Recovery, where we conducted a Proof-of-concept to show the capabilities of ASR to migrate/protect VMware workloads towards the Azure platform. As you might know, one of the pre-requisites of a replicated Virtual Machine in Azure is to be connected to a Virtual Network. In our case, the customer already had some workloads running on the platform, so we were provided with a Virtual Network and a VPN site-to-site connection.
The workloads of that customer are running in Azure V1 Virtual Machines, so that gave us the ease of being able to patch in to that network and saved us a lot of time. Next thing is to check the Virtual Machine in vCenter to see if the Operating System is within the Azure Supported OS boundary.
What a luck, its a Windows Server 2008R2 box, so we’re good to go!
Next steps are to create a Site Recovery Vault and the installation files for the combined roles of the “Unified Server”. This is a combination of the configuration – and the process server, which actually converts the VMDK files to a format which Azure better understands. Don’t forget to download the registration key while your at it.
Next step is to download and install the vSphere 6 PowerCLI tools. This still needs to be version 6, even when you’re running version 5.1 or 5.5 on-premises. When the VMware CLI is installed, we can finally move on with installation of the unified ASR server.
When you want to present your customer with the ASR installation log, or you need to troubleshoot certain issues, you can find the Azure Site Recovery installation logs here: C:\ProgramData\ASRLogs\DRASetupWizard.log
After the installation completes, you are presented with the Microsoft Azure Site Recovery Configuration Server interface. If you closed this wizard by mistake, you can re-run this wizard by navigating to: “E:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\bin\ cspsconfigtool.exe”
The friendly name you define, will be shown in the Azure portal when you add VMware resources to the Azure Site Recovery Vault. For migration purposes, the user defined here, to connect to vSphere, must also have local admin rights on the target Virtual Machines. For this single migration scenario, we achieved this through a manual addition of this account to the “local admins” group on the server which is to be migrated.
When this connection is made, and the unified process server has a proper connection to Azure, it will show up in the Azure portal and show you information of its configuration, like IP address, provider version, etc.
Next step is to add VMware resources to Azure Site Recovery. Because there’s already a connection between Azure en vSphere, this is made extremely easy for us.
We’ll define the vSphere server from the perspective of the Unified process server. That’s why we can use a private ip address, after the green checkmark appears, we can again provide a friendly name for this environment and define the processerver from a dropdown and the vCenter account we specified earlier in the ASR Configuration Server wizard.
When the connection between vSphere and Azure Site Recovery is established, you can start to create “empty” protection groups, where you’ll define the direction of the protection and the times on which synchronisation will take place.
By default, ASR will create two Protection Groups for VMware to Azure based implementations.
- One in the direction on-premises -> Azure
- One in the direction Azure -> on-premises
The second one is created automatically and will be used in the case of a fail-back after a disaster.
When the protection groups are created, you’ll be able to add Virtual Machines to them.
After a target is selected, the mobility service is automatically pushed to the machine, that’s why the ASR service account needs local admin rights on the box. During the protection definition phase you are asked to define the processserver for conversion of the selected virtual machines and a storage account in Azure where the data will land. Make sure to size your protection groups to enable maximum performance of your storage accounts.
When initial synchronisation is done, you might want to tweak the settings of the replicated vm for the event when its spun up in Azure. People already acquainted with Azure might think this can be done, like VM’s replicating from VMM, by some sort of network mapping in advance, but I’m afraid they’re in for a small disapointment.
All settings for VMware migrations need to be done on a per-vm basis, so in the properties of each replicated VM, you can define the VM Size, Name, IP Address and Network which need to be activated when the Virtual Machine is started in Azure.
There you go, your VMware Virtual Machine is protected by the Microsoft Public Cloud and can be migrated on your command. Or it can be brought up, using a recovery plan, in the event of an outage in your own datacenter.
Want to know more, or did any questions come up when you were reading this? Do you have some feedback for me? Leave a comment or drop me an email.
Until the next time, keep it cloudy!