Azure Site Recover–Part I : Planning

Azure Site Recovery is the Microsoft Cloud Solution for disaster recovery. It can have multiple flavors, like On-Prem to On-Prem, On-Prem to Azure or VMWare/Physical to Azure. Each one will have specific dependencies and features.

In a recent project, I was assigned with the heroic task of onboarding as many machines in to ASR as possible. A few challenges arose from that, among them. Besides reading the whole guide here, I recommend you to pay special attention to some aspects that follow below.

– Not all Hyper-V hosts are running 2012 R2

In companies that are Hyper-V users for a log time, it will be likely to find older versions of hosts, including some lost Virtual Server 2005 hosts, as it was the case in my project. So, in this case, a planning for migrating the hosts to Windows Server 2012 R2 must be put in place. However, it may not be that straight forward. One of the reasons to have older hosts is that you may have older operating systems in the VMs themselves that are not supported by the hosts. For example, Hyper-V 2012 R2 will only support the following operating systems:

  • Windows Server 2012 R2
    Windows Server 2012
    Windows Server 2008 R2 with Service Pack 1 (SP 1)
    Windows Server 2008 with Service Pack 2 (SP 2)
    Windows Home Server 2011
    Windows Small Business Server 2011
    Windows Server 2003 R2 with Service Pack 2 (SP2)
    Windows Server 2003 with Service Pack 2

If you have older operating systems, you may need to maintain these hosts for a while.

– Not all VMs are running Azure supported OSs

As you may have noticed, OS compatibility is a major concern, for the OS, VMs and for Azure as well. Not all VM Operating Systems can be protected in Azure. Currently, Windows Server 2008 R2 and on are supported only, as well various Linux distros.

– Current VMM Infrastructure may not be up to date

Customer may not have a current VMM installed. You will need to either upgrade it or install a fresh one. Customer may not even have VMM, so, it is a good opportunity to design the network properly.

– The networking configuration of the hosts won’t likely be compatible with Azure

If you haven’t ever configured the networking or if you have only imported automatically from VMM, there is a lot of work to do. I suggest you read some articles about it: here and here. But in a nutshell, you’ll need to have a cloud setup with available networks to be mapped when the failover plans kick in on Azure.

– The workload may be sensitive and not able to be immediately on-boarded.

Some workload may be dependent on local resources that can’t be failed-over to Azure, so, unlikely candidates. A plan to properly classify each workload and when and how it is going to be migrated needs to be created.

 

As I’ve mentioned, you still need to check the whole guide and make sure every aspect is covered, but he items above will likely be the bulk of the work, since the actual ASR configuration is relatively straightforward.

 

hope this helps