Disaster Recovery for Azure IaaS virtual machines in public preview

On May 31st, Microsoft announced public preview of disaster recovery for Azure IaaS virtual machines. Learn how to implement this solution and what you should be aware of.

Hey folks,

Azure Site Recovery, Microsoft’s disaster recovery solution for your on-premises server infrastructures has been extended to the cloud. Yes, it always offered cloud-based disaster recovery but now you can also protect your Azure IaaS environment which makes it pretty easy to implement geo-redundancy.

It’s pretty simple to configure and once it’s ready the service helps you to protect your Azure IaaS workloads from a disaster in one Azure datacenter or region.

First of all you need a Recovery Services Vault which is used for Azure Backup and Azure Site Recovery. When configuring Site Recovery you will realize that the caption in the configuration dialog has changed.

Changed caption in Azure Portal
Changed caption in Azure Portal

You cannot protect VMs from the same region as of the vault or vault’s resource group. In the event of a datacenter disruption, the vault or resource group also might not be available. Create (or use) a vault in a different region to protect these VMs.

Make sure to put your VMs and Recovery Services Vault into two different Azure Regions.
Make sure to put your VMs and Recovery Services Vault into two different Azure Regions.

It’s important to understand that you cannot use the same Azure region as source location and replication target so make sure to put your Recovery Services Vault to a different Azure region. Your VMs need to be in running state and have the Azure VM agent provisioned successfully.

Make sure your VMs are running and have the Azure VM agent provisioned successfully.
Make sure your VMs are running and have the Azure VM agent provisioned successfully.

After you have selected the VMs you want to protect to another Azure Region you need to create the target resources in the secondary Azure Region. By default the service will mirror your source environment and add an ‘-asr’ suffix to the resource names of resources that are created in this step. You will have a mirror for your Resource Group(s), VNet(s), Storage Account(s) and Availability Set(s) but you can also customize those settings. After you’ve created the target resources you’re ready to go and you can enable replication. Replication status can always be checked in the replicated items list.

Replication status
Replication status
Plan your failover

A disaster recovery strategy without having a recovery concept is not useful and neither is replicating VMs without having a failover plan. This is when Recovery Plans come into play as a second configuration step. All you need to do is to select source and target Azure Regions and which items (meaning VMs) the plan should contain.

Create recovery plan
Create recovery plan

After you have created a recovery plan there is one thing left to configure: Your VMs target network settings. So make sure not to miss that point and start a planned failover or a test failover.

Lessons learned

I often try new features by myself before looking for or reading documentations – my bad. First of all I wanted to protect one of my demo VMs and deployment failed. After analyzing the error log I knew: Windows Server 2016 ain’t the best guest OS to use within the scope of Azure 2 Azure ASR. So I created a new test VM and as I wanted to save some money I decided to use A1 with a Standard Managed Disk – don’t do that because neither Managed Disks nor VMs with less than 2 CPU Cores or less than 1 GB RAM are supported. In addition to that make sure that your subscription is enabled to create the same virtual machine sizes in your secondary region which you have configured for your source VM. There are some more limitations that all have been written down by Microsoft. So learn from my mistakes and RTFM!

You see as of now it’s quite easy to plan for geo-redundancy within the Azure ecosystem. Make sure not to miss my talk on this topic at Azure Saturday 2017 in Munich and try the new solution until then – I’m pretty sure you’ll like it.

Bye for now and stay tuned,
Tom

Author: Thomas Janetscheck

Architect for Microsoft Cloud and Messaging Solutions, community leader, Azure and PowerShell enthusiast working for Data One GmbH

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s