Disaster recovery for Azure IaaS VMs


Every organization needs a business continuity and disaster recovery (BCDR)  strategy to keep data safe and react to unplanned or planned outage in the best way. Azure Site Recovery (ASR) significantly simplifies these processes providing replication, failover and failback functionalities for your major IT systems.

azure site recovery for azure vms_6

ASR can be used in the following scenarios:

  • VMware VMs replication to Azure w/CSP (uses InMage Scout software)
  • Physical servers to Azure (uses InMage software as well)
  • VMware VMs/Physical servers to a secondary site (through InMage Scout)
  • On-premises Hyper-V VMs without VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to a secondary site (Hyper-V Replica inside)
  • Multi-Tier applications (uses SQL AlwaysOn AG, for instance)

But yesterday Microsoft officially extended this list by adding possibility to replicate Azure IaaS VMs running on Windows/Linux to another region within the same geographic cluster.

Now, you may ask, why we need this if Azure already provides high-availability and reliability for every business critical workloads. Official statement says that it’s required by ISO 27001 and it’s compliance requirements.

Furthermore if you’d like to be able to completely meet BCDR strategy in the event of disaster and you are not happy with built-in Azure protection features – new option can also help (seamless failover and failback between different regions to keep RTO/RPO very low)

TIP: this ASR scenario is in public preview state for now.

azure site recovery for azure vms_1

Demo

As usual, you need to create ASR vault  and enable replication for workloads. You should place ASR Vault at the TARGET location/region to make it work (wizard also checks it automatically).

It’s simple..if source location is down, ASR vault and resource groups will be also offline and your BCDR strategy will be failed –> ASR vaults should be always in the target region

I‘m using ASR created in UK West region and my workloads are running in West Europe DCs. Regions are in the same geographical cluster (Europe).

TIP: new managed disks and VMs scale sets are not supported + temporary disks always excluded from replication

azure site recovery for azure vms_3

You don’t need to prepare target infrastructure. ASR does almost all “dirty”” work by itself (network mapping, target networks/groups and storage/cache accounts + availability sets if they are in use in the source region)

azure site recovery for azure vms_5

Replication policy settings by default:

  • RPO – 24 Hours
  • App-Consistent replication – 4 hours

At the next step, ASR enables protection for workloads and initiates replication for them

image

If you are receiving error “Site recovery configuration failed” or “Connection cannot be established to Azure Site Recovery service endpoints” during “Enable protection” and NRG is presented , try creating NRG rules for outbound connectivity using this script.

Be ready to provide NSG Name, NSG resource group name, subscription ID and target/source regions. Script will create all required NSG rules for every Azure IP range then

TIP: A security group cannot have more than 200 security rules by default. You need to ask Azure support team to extend this limit in order to add all required rules. You can also delete or dissociate NSG from VM subnet or network adapter but it’s not recommended for production systems (test/labs – ok)

image

Script in action:

Configure NSG Rules for Azure Site Recovery

We have still the same services behind the scenes (InMage based, running on every source azure workload).

image

When VM becomes protected you can verify test failover (recommended step before standard failover and for checking replica health. I’d say we need to create them regularly), do failover and failback then to test completely the new ASR scenario.

image

Thanks for reading!

Leave a Reply

Fill in your details below or click an icon to log in:

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