Conventional wisdom dictates that one of the best ways to protect your virtual machines (VMs) is to have standby...
copies of your VMs in a secondary data center. These VM copies can be powered up at a moment's notice in an effort to ensure continuity of business in times of disaster. Of course, the devil is often in the details. Replicating VMs to a secondary data center has historically been an expensive and complex undertaking, making the approach feasible for only the largest organizations.
Recently, Microsoft has sought to simplify this process by providing Disaster Recovery as a Service (DRaaS) through Windows Azure Hyper-V Recovery Manager. But before you use Azure as a Hyper-V replication target for DR, there are some things you need to know.
The first thing that you need to know about Windows Azure Hyper-V Recovery Manager is that it provides you with two main choices for private cloud replication. In System Center, the term "private cloud" refers to a special type of Active Directory container object. Think of it as an isolation boundary within a virtualization infrastructure. The first option is to replicate from one private cloud to another. The private clouds can exist within the same datacenter, but from a disaster recovery standpoint, it would be more beneficial to replicate the private cloud to a remote site.
The other option is to replicate your private cloud to Windows Azure. In this scenario, replicas of your VMs will reside on Azure storage.
In either case, the Microsoft Azure Site Recovery Manager acts as an orchestration component. It coordinates the replication process, but the replication data does not flow through the Azure Site Recovery Manager.
The fact that Microsoft is recommending the use of Windows Azure Hyper-V Recovery Manager as a solution for replicating VMs between private clouds raises at least one big question. In Windows Server 2012 R2, Microsoft introduced extended replication for Hyper-V, which allows a VM to be replicated to two different replication targets (typically an on-premises target and a cloud target). So why would you use Windows Azure Hyper-V Recovery Manager instead of Hyper-V's native extended replication capabilities?
The reason for this has to do with scalability. Native Hyper-V replication is primarily designed to provide disaster recovery capabilities for SMBs. The feature doesn't scale well to larger environments. In contrast, Windows Azure Hyper-V Recovery Manager is intended to be a solution for replicating private clouds from one data center to another.
Although replicating VMs from one private cloud to another sounds like a complex undertaking, Microsoft has actually made the process relatively easy to set up. The first step in the process is to create a Recovery Manager vault within Windows Azure. This vault is used by the replication process and can be created with a few mouse clicks.
Once the vault is in place, the next thing that must be done is to establish trust between the two private clouds and Windows Azure. Once again, Microsoft has made this process relatively easy. Rather than requiring you to set up the Active Directory Federation Services, Windows Azure simply requires you to upload a digital certificate. This shared certificate is to authenticate the private clouds when they access the vault.
Once the certificate is in place, Windows Azure provides you with an agent that you can download and install onto your System Center Virtual Machine Manager servers. When you install the agent, you must register it for use with the Recovery Manager vault by linking the agent to the certificate that is being used for Recovery Manager Vault authentication.
The next thing that you will have to do is to specify the private cloud that you want to protect. The agent makes your private clouds visible through the Windows Azure management interface so you can simply select a private cloud and then click "Configure" without ever having to leave Windows Azure.
Windows Azure allows you to select a destination private cloud and a replication target within that cloud. You can also specify how often you want to create application-consistent snapshots, as well as the overall replication frequency and the initial replication method (you can seed the replica over the network or offline). The various options that are offered within this interface are cloud-level settings. They apply globally to the private cloud that you have selected, so that you do not have to define specific replication parameters for individual VMs. You do, however, have to specify which VMs you want to enable for protection.
The last thing that you have to do is to create a recovery plan. Recovery plans organize the VMs into groups. You can then specify the order in which groups fail over. Recovery plans also offer the ability to perform test failovers so that you can verify that the reliability of the recovery process.
Although Microsoft makes it relatively easy to set up Windows Azure Recovery Manager, there are important considerations prior to using it. One is cost. Obviously, a Windows Azure subscription is required, but Windows Azure's pricing model is also based on resource consumption, so that must be a consideration for anyone who is planning to store replication data on Azure.
Another consideration is bandwidth consumption. Replicating VMs to the cloud can be a bandwidth-intensive process if there are a lot of VMs being replicated or if the VMs have a high rate of change.
Given these two factors, it is a good idea to test the replication feature by initially protecting a small group of VMs in order to see how the replication process impacts your costs and bandwidth usage.
Replication for Hyper-V high availability
Hypervisor-based replication in VMware and Hyper-V
Use caution with Hyper-V replication over low bandwidth