Windows Azure Hyper-V Recovery Manager is a new Microsoft cloud-hosted option that coordinates the protection of...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Hyper-V virtual machines located inside your private cloud for disaster recovery purposes. Sounds scary, right? Without understanding the technology, relying on an external cloud service to act as a critical piece of your disaster recovery plan might sound frightening, but knowing what it can do and how it works should put your mind at ease.
Hyper-V Recovery Manager is an Azure Cloud service running in Microsoft's Azure data centers. It works by relying on System Center Virtual Machine Manager (SCVMM) and building on the free underlying Hyper-V Replica feature in Windows Server 2012 and 2012 R2 Hyper-V. It also monitors the health of protected clouds within SCVMM.
Prerequisites for using Hyper-V Recovery Manager
Let's first a take quick look at the infrastructure you need to put in place. I am only giving a high-level view of the framework of Hyper-V Recovery Manger; you need minimal hardware and the right licensing or subscription to get started.
You also need a Windows Azure account and enough funds to replicate the number of VMs you want to protect. If you currently have an MSDN account, you can test Hyper-V Recovery Manager for free within the monthly allotment of funds based on your MSDN subscription level. Current pricing for protected VMs is $16 per month. Bulk discounts are available as you hit certain thresholds of protected VMs.
In addition, you need two SCVMM servers of the same version -- 2012 SP1 or 2012 R2. Microsoft recommends these servers -- which can be physical or virtual -- be in different data centers or locations.
You could use one SCVMM server, but the graphical user interface gets a little messy as the icons for replicated VMs and live VMs can get confusing. With two SCVMM servers, you can keep each compartmentalized. This, too, can get confusing; if you have not done a full failover of your environment, you will have production VMs running on both sides, making management more difficult.
You need a Hyper-V Recovery Manager agent installed on the SCVMM server(s). You can download this agent from the Dashboard of your first Hyper-V Recovery Manager Vault. Finally, you need an SSL certificate for communications between your SCVMM servers and the HRM services in Azure.
Getting started with setup
Setting up the communications is easy and quick. The harder part is identifying VMs important to your organization and then creating a dependency tree to specify the order in which they should be brought up.
Because this is an Azure cloud service, there is no server to logon to, just an Azure Portal where you manage what are called Recovery Vaults -- nice secure sounding name, kudos to the marketing folks. From within this Recovery Vault, you set up the Resources you want to protect (Hyper-V Hosts and Networks), Configure Protected Items (SCVMM clouds) and set up your actual Recovery Plans (coordination of VM recovery).
After you have your infrastructure in place with successful communication between your SCVMM servers in your private cloud and the Azure Hyper-V Recovery Manger services, you can start the process of protecting your VMs and creating Recovery Plans. These plans allow you to orchestrate the failover of VMs or groups of VMs in any hierarchical configuration.
Below are some of the highlights of what the Hyper-V Recovery Manager does and does not do. Having this information should not only give you the scope of the product, but also subdue some of the fears of using this cloud service.
What it does:
- Provides a structured framework and coordinates your failover recovery plans for complete groups of VMs in a particular order or a single VM.
- Uses a secure connection for communication to Azure Hyper-V Recovery Manager, using an SSL certificate between your SCVMM servers and Azure Recovery Manager services.
- Allows for full failover, partial failover or failover of a single VM and full failover testing.
- Coordinates network changes necessary on the failover location.
- Performs replication cycles as short as 30 seconds.
- Allows for multiple replicas over time to enable multiple potential restore points.
- Coordinates reverse replication once successful failover is completed. This process is kicked off by a manual acceptance prompt after failover has occurred if the infrastructure in the original data center is available.
What it doesn't do:
- Automatically failover VMs. It requires manual intervention to enact your recovery plans.
- Store data from VMs in the cloud. No VM or host server data, other than their names, is stored in the Recovery Vault.
- Make inbound connections from the Azure Cloud. SCVMM initiates status updates and gathers any changes in protection or failovers from the private cloud out to Azure.
- Provide synchronous replication of VMs. Replication intervals are 30 seconds, 5 minutes or 15 minutes.
- Allow for coordination of Recovery Plans from within SCVMM. You can initiate failovers locally, outside of the Azure Portal, if you are completely cut off from any external network where you have replicated VMs.
- Replicate VMs to Azure IaaS. It currently only supports replication between SCVMM private clouds.
- Replicate VMware or XenServer VMs that are managed through SCVMM.
What Hyper-V Recovery Manager is missing
As with any initial release, there is work to be done and features that would round out the product nicely. Some potential additions could sweeten the deal of using a cloud coordinator for disaster recovery scenarios.
On the technology front, SCVMM needs a filter option to remove replicated VMs from view or a Recovery Manager account that can see both live and replicated VMs. It also needs a way to evoke coordination locally when external networks are down at multiple data centers. A local option for Windows Azure Pack integration at an organization's third location or Hyper-V hosting provider would be a good option.
On the administration front, Hyper-V Recovery Manager could use an option to replicate to the Windows Azure public cloud. This would facilitate moving infrastructure to the cloud or moving a third copy of a VM to Azure for greater protection. It would be useful to be able to perform automated scheduled tests on a recovery plan with reporting. Also, an administrator could benefit from being able to initiate multi-step tasks, such as starting a failover, confirming and then reversing replication all in one step. An administrator should be able to define thresholds that would trigger an automated failover.
At its current cost, Hyper-V Recovery Manager does not make sense as an option to protect all your VMs. After a major disaster in one of your data centers, finding the right mix of important Hyper-V VMs in your environment to keep your business viable is the hardest part of the Recovery Plan setup. You also need to develop an auditing process to make sure that important VMs are being replicated between data centers.
Hyper-V Recovery Manager also suffers from the same emotional cloud trust barriers that most cloud services do, but technically the product does a solid job of coordinating a recovery plan that can be thought out well before disaster strikes. If that day ever happens, all you have to do is log on to the Azure portal and set the recovery in motion. That may be wishful thinking because it still requires human configuration, but Hyper-V Recovery Manager is a great step forward, giving the free Hyper-V Replica feature an enterprise-level application.