8 September 2015 blogs MVP Peter de Tender 3 min read
When talking about “disaster recovery” with any of my customers, a small SMB or a large enterprise, they all put disaster recovery as a top priority on their IT budgets. Disaster recovery should not be seen as an “IT Pro” business enabler, but something that is of vital importance to any organization.
All the above is valid when talking about local datacenters, MPLS networking connections, fibre channel interfaces between servers and storage solutions… but what happens when your virtual machines are “somewhere in the cloud”? How do you deal with disaster recovery in that case? Or even better, what about using “the cloud” as your disaster-recovery solution?
That’s exactly where Azure Site Recovery comes in play.
Azure Site Recovery (ASR) saw the light about two years ago, when it was still called Azure Hyper-V Recovery manager. The key functionality at that time was using Azure Hyper-V Manager as an orchestrator to initiate and control failover between two Hyper-V datacenters, the current version of ASR provides the following disaster-recovery scenarios:
Supported replication Azure.
Supported replication Secondary Datacenter.
In my opinion, it could be interpreted as “there is always a business scenario available that can benefit from the features of Azure Site Recovery”.
Now, you have a clear understanding of the different scenarios where Azure Site Recovery can help you in building your disaster-recovery plan, it’s about time I explain to you “how” it actually works.
While there are a few (minor) differences, based on what source system you are starting from (Hyper-V hosts, Virtual Machine Manager clouds, VMware, or physical servers without a hypervisor), overall, the base idea remains the same; allowing for virtual machine system and data information, which gets replicated from the on-premises datacenter to Azure. This replication goes over encrypted https port 443 traffic, so your data is secured in transit.
Once your on-premises datacenter or host is being protected using the ASR provider and data gets replicated through the Azure Site Recovery, every virtual machine or physical host is configured as a VHD-virtual disk, which gets linked to a virtual-machine profile. It is important to note is that the virtual machines themselves are not running, as long as the recovery process itself is not initiated. Basically you are only consuming Azure storage, which makes this solution great from a budget perspective. It’s only when the recovery process starts (your VM or VMs boot up), that it will start to cost consumption.
When in failover mode (your machines are not available on-premises anymore and running in Azure), you have two possibilities to recover the environment. You can either initiate a failback scenario from Azure back to the datacenter once the services are restored on that side, or you leave the VMs running in Azure, and use Azure as the primary datacenter from now on.
Knowing this DR mechanism is supported between two datacenters, where ASR acts as an orchestrator for failover/failback, as well as between on-premises Hyper-V hosts, VMware hosts or physical machines with no hypervisor running, is what makes it one of the best solutions available in the market today to build your enterprise disaster recovery plan.
If you want to know more about Azure Site Recovery, I have written a whitepaper called “Leveraging the power of Azure to build your Hyper-V disaster recovery plan”.
In addition, stay tuned for my upcoming webinars, where I will elaborate on the whitepaper and demonstrate the full configuration and failover process, as well as showcasing how Savision Live Maps provides you with detailed dashboards on the overall health state of the Azure Site Recovery infrastructure.