General Availability of Azure Site Recovery for Azure VMs

After quite a long preview, Microsoft has made Azure Site Recovery (ASR) for Azure virtual machines generally available, providing inter-region replication of IaaS workloads. This is also known as Azure to Azure Site Recovery or A2ASR.
 

 

Myth Busting

Many people who are novices to The Cloud make two incorrect assumptions:

• All virtual machines are backed up by default: They’re not but Azure Backup is quite affordable. It has made its availability very clear and easily enabled in the Azure Portal when creating a virtual machine.
• Everything is replicated from one Azure region to another: Some things are, but most things are not. It requires you to enable replication or to duplicate deployments at some additional cost.

If an Azure region was to fail, all of your Azure virtual machines would go with it, even if you had deployed using availability sets (single compute cluster in a single building) or availability zones (workloads spread across buildings in a region).
Without A2ASR, you would have had to:

1. Duplicate the virtual machine deployment in another region, thus doubling your Azure costs.
2. Enable inter-region networking and replicate all data, configurations, and settings between the deployments across that link.

Azure and other costs would have been very high. Luckily, ASR is quite affordable!

A2ASR

The general availability of A2ASR should impact customers very quickly:

• Simplicity: The ASR team has made the process of replicating an Azure virtual machine very easy. In some ways, I think it’s too easy because some will fail to realize that there will be some considerations.
• Low cost: A2ASR is quite affordable for a disaster recovery solution. You pay $25/month (RRP, East US) to replicate a virtual machine and the storage (managed and unmanaged disks) that is consumed in the DR site.
• Orchestration: With recovery plans, optionally extended by Azure Automation and Traffic Manager, you can convert a failover (real or test) into a predictable and ordered process.

How it Works

Even though Azure is built on the same Hyper-V that we can use, Microsoft did not use the Hyper-V Replica-based method for replicating Hyper-V virtual machines. Instead, they used the same system that is used to replicate VMware virtual machines to Azure. When you enable replication for a virtual machine, a “mobility service” extension is installed in the guest OS of the virtual machine.
At this point, the mobility service will start to communicate with recovery services in the DR site (failover region) and duplicate the contents of the disk and subsequently the changes using continuous asynchronous replication.
Watch out if you block outbound traffic to the Internet because this will break virtual machine replication to other regions. You will need to create exceptions for the mobility service communications.
As with replication from on-premises, it is the disks that are replicated to the DR site. The virtual machine is only created in the event of a test or real failover. The process of enabling replication will create things like availability sets and virtual networks/subnets but other pieces, such as network security groups, load balancers, public IP addresses, and so on will need to be created manually. Some items, such as NAT or load balancing rules, can only be created after a virtual machine is failed over. See Azure Automation being triggered by ASR recovery plans.

Opinion

I used A2ASR for my own web server before I migrated to App Services. I’ve recommended and deployed A2ASR for customers. One customer has tens of millions of Euros worth of seasonal business protected by the service. The low cost insurance that the service offers has a huge value and the ease of deploying it should provide an easy adoption process.