Recent Enhancements to Azure Site Recovery

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.

• Related: Getting the Most Out of Azure Site Recovery

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.

Failback to Different Hosts and Sites

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 …

Support for Generation 2 Virtual Machines

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:

• You lose some of the features of Generation 2 virtual machines, such as secure boot.
• The boot disk of the virtual machine cannot be larger than 300 GB.
• The time to failover a virtual machine, or the recovery time objective (RTO), is 1 hour per 100 GB in the boot disk.
• Windows guest operating systems are supported now and Linux support will be added at a later time.

Support for Larger Boot Drives

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.

Multiple NIC Support

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.

Configuring Failover IP Address

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:

• Virtual machine specification
• Azure VNET and subnet

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.

Azure Automation Sample Runbooks

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:

• Creating standalone or load-balanced endpoints to NAT the virtual IP address of the recovery plan cloud service.
• A runbook that can be used to run a script in a virtual machine. You might use this sort of functionality to flush the IP configuration of virtual machines that are permanent residents of Azure so that they no longer cache records for pre-failover services.
• Another runbook that can be used on all failed over virtual machines.

Preview for VMware Virtual Machines and Physical Servers

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.

Microsoft is using InMage to replicate VMware and Physical machines to Azure (Image Credit: Microsoft)

Feedback-Driven Change

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.