Creating a High-Performance Backup Architecture with Azure Site Recovery

Cloud networking
March 18, 2019

How direct connectivity to Azure’s built-in Disaster Recovery as a Service (**DRaaS**) could solve your business continuity and availability issues.

Business Continuity. Disaster Recovery. Backup and Availability. Do these phrases keep you awake at night? Many enterprise businesses face various challenges when thinking about implementing these strategies. Some think they’re only for organisations with huge IT budgets available. Others have failing or out-of-maintenance on-premises infrastructure and need a quick solution for migrating to the cloud. And, many have issues with connectivity. Whatever your barriers to getting a Business Continuity and Disaster Recovery (BCDR) plan in place may be, it’s now easier than ever to create a high-performance backup architecture with direct connectivity to Azure Site Recovery.

There are many reasons why you would consider moving your disaster recovery (DR) to the cloud, however, there are often a few roadblocks that come up too. These include:

Your internet being too slow
Your on-premises architecture being too difficult to replicate in the cloud
Not having enough capacity to implement your strategy in the cloud

Azure Site Recovery, Microsoft’s Disaster Recovery as a Service actually addresses most of these roadblocks, and together with direct connectivity from Megaport, adopting a fast, secure, and scalable BCDR strategy is more simple than you think.

Azure Site Recovery service was first given general availability back in October 2014 and has made numerous improvements to better support Hyper-V, VMware, as well as non-virtualised servers. Some feature highlights include:

One-click replication
One-click migration and failover and testing failover to simulate DR plan
Lift-and-shift migration to Azure
Free extended security update for Server 2008 migrated

Impressively, with Azure Site Recovery, you can be replicating your on-premises environment in under 30 minutes. Did you know that with Megaport, and an additional 10 minutes, you could have your first virtual machine (60GB), replicated, protected, and operational?

Although once an Azure ExpressRoute circuit is in place, you can’t reduce the bandwidth of that circuit, there is a clever way to get around this. Megaport’s VXCs are billed by the second with no lock-in contract, so you can easily provision a new VXC, cutover the traffic seamlessly, and decommission the old VXC once you’re done.

Azure-Site-Recovery

In our previous blog post, Leveraging Veeam Cloud Tier Storage for Backup and Replication, we discussed how traditional internet connection data transfer speeds affect archiving, and how Megaport solves the bandwidth issue, public IP address challenges, and other challenges more in-depth.

So what does an Azure Site Recovery and Azure Backup service look like with Megaport connectivity? The following example takes into consideration these requirements:

Protect all the files from file server using Azure Backup, with specific retention policy
Protect VM01 (a VM which isn’t critically required to be recovered if there is an incident) using Azure Backup
Protect VM02 (Windows Server) and VM03 (Linux Server) which are business-critical servers with a short RTO (Recovery Time Objective) selecting from different Recovery Points using Azure Site Recovery
Connect to Azure Virtual Network environment ready to consume failover VMs

Scenario 1

Business doesn’t own any public IP or their on-premises infrastructure doesn’t support BGP or doesn’t support IEEE 802.1ad (Q-in-Q). Megaport Cloud Router will assign Megaport owned public IP address and AS number and configure Azure ExpressRoute circuit automatically.

Prerequisites

Customer (on-premises) network equipment supports LX Optical 1Gbps or LR Optical 10Gbps Ports

Megaport Technology Required

How many?

Megaport

1 or (2 in a Link Aggregation/LAG)

Megaport Cloud Router (MCR)

Virtual Cross Connect (VXC)

1 or 2 (HA Design) VXC to Azure and 1 Private VXC

Scenario 2

Business owns public IP that can assign and advertise, on-premises infrastructure also supports BGP, and on-premises infrastructure also support IEEE 802.1ad (Q-in-Q)