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.
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.
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.
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.
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.
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.
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,