The pace of improvements to Microsoft’s disaster recovery (DR) in the cloud solution has been staggering. Many Microsoft partners and customers see Azure Site Recovery (ASR) as a valuable business solution that finally solves old issues at an affordable cost and does so in a non-threatening way by supplementing existing skills and investments in IT.
ASR is also a nice introduction to Azure IaaS, allowing new tenants to explore Microsoft’s cloud and find new ways to enhance service delivery. The ASR group has been busy and a number of interesting changes has been launched or put into preview in recent weeks.
Until recently, you could only failback virtual machines from Azure to their original hosts and clusters. This could be spun a certain way, such as, “hey, you’re gonna love Azure so much that you’ll never want to leave.” The reality is that a lot of companies will leave once their insurance companies finally pay out, where they will want to return workloads to a new premium site. Until recently, that was impossible.
With a change made in April, ASR allows you to failback your virtual machines to a new location if the original primary site was lost in the disaster. This means that you can limit the role of Azure to that of the emergency secondary site and opt to use it as your permanent residence. But you know, Azure is pretty cool, and you might want to stay …
Let’s get this clear: Azure does not allow you to run Generation 2 Hyper-V virtual machines. However, ASR recently added support with an updated ASR provider on your hosts for replicating Generation 2 virtual machines to Azure. ASR converts your virtual machine into a Generation 1 virtual machine that can run in in Azure in the event of a test failover or a real failover.
There are some notes:
ASR has always required that the boot drive of production site virtual machines be no larger than 127 GB, which is the typical size of the C drive for any Azure virtual machine. This limit was removed, and now the boot drive can be up to 1 TB. Note that the exception is with Generation 2 virtual machines.
ASR will now support failing over virtual machines with more than one virtual NIC. Note that this requires that the failover virtual machine specification in Azure must support the required number of virtual NICs.
When a virtual machine is failed over, ASR strips away the IPv4 configuration from the virtual machine. The IPv4 stack of the VNIC appears to be configured by DHCP, but in reality, the Azure VNET supplies an IP configuration. Like with all Azure virtual machines, this IP address is not reserved, and it might change throughout the virtual machine’s life in Azure.
An essential step when you have completed the initial copy of a virtual machine to the Azure Recovery Vault is to pre-configure the replica virtual machine:
Now you have the option of pre-configuring a valid IP address for the failover VNET. Make sure that this IP address is valid for the VNET and is not used by another virtual machine, otherwise the virtual machine will fail to start, bringing your recovery plan to a grinding halt.
The marketing machine behind ASR pushes the concept of a “one-click recovery” that is enabled by ASR recovery plans. A recovery plan can order the failover of virtual machines, thus eliminating much of the effort required during the invocation of a business continuity plan (BCP). However, many tasks require a bit more effort to be automated, and this is made possible with Azure PowerShell scripts in the form of Azure Automation runbooks.
When you create a new runbook, you will find eight samples that you can import, use, and customize for the purposes of disaster recovery. The samples that caught my interest are:
I’m saving the best for last! Did you ever imagine a world where a VMware customer might replicate virtual machines to Microsoft Azure? The day is nearly here, because this functionality, as well as the ability to replicate physical servers to Azure, is in preview right now.
One or more on-premises virtual appliances work with agents in the OS of the machine being replicated to send data to a set of virtual machines running in the customer’s Azure subscription. The machines are converted into Azure virtual machines, enabling both VMware virtual machines and physical servers to failover to Microsoft’s cloud.
The ASR group is very feedback oriented. They love to hear from customers of all sizes that are using their products. Let them know via the official feedback forum if there’s more that you want from ASR.