Worldwide Locations
Abstract
One of the most significant new features in Microsoft Windows Server 2012 is the Hyper-V Replica (HVR) capability. Whether you are considering this for your own organization or just prepping for your Windows Server 2012 MCSA, this white paper presents the essentials of deploying this disaster recovery feature.
Sample
Hyper-V Replicas make it possible to copy Hyper-V virtual machines across a LAN or WAN even if you don't have a failover cluster or shared storage between the virtual machines. Hyper-V fault tolerance and disaster recovery are therefore cheaper and simpler than ever before.
I. The Hyper-V Replica Concept
One of the most significant new features in Windows Server 2012 is the Hyper-V Replica (HVR) capability. Whether you are considering this for your own organization, or just prepping for your Windows Server 2012 MCSA, this white paper presents the essentials of deploying this disaster recovery feature.
A. How Replicas Work
HVR allows you to designate a remote host to which a Hyper-V virtual machine is replicated. Once the replication relationship has been established and the initial replication has occurred, writes to the source virtual machine (VM) are collected in a log file and sent asynchronously to the destination VM on a designated schedule. Because the writes are "deltas" (i.e., differences), the bandwidth may not be prohibitive, even across a WAN link, although some initial monitoring is probably advisable. Because the replication is asynchronous, a link with variable latency does not present problems.
B. How HVR is Different
HVRs serve a different purpose than either Hyper-V live migration or storage migration. The latter operations are intended for use in the normal course of business, and presume availability of source VMs. HVRs, however, are meant for use during a disaster or other unplanned failure, when the source VMs are unavailable.
Comparing HVR to failover clusters, the requirements for HVR are less onerous. Basically all you need is Server 2012 or Server 2012 R2 on the Hyper-V hosts, and hardware that supports Hardware-Assisted Virtualization (Intel VT or AMD-V) as well as Data Execution Prevention (DEP)-that is to say, just about any server built in the last few years. Note that although Second Level Address Translation (SLAT) is required for Client Hyper-V on Windows 8.x, this CPU technology (included for example in Intel i3, i5, and i7 processors) is not required for the server flavor of Hyper-V, even though it should improve performance. Note also that you do not need identical hardware for the primary and replica servers.
HVR technology does not guarantee that there will be zero data loss in all circumstances. We'll look at the different types of failover scenarios shortly, but for now just note that there could be some data loss in the "unplanned failover" situation. (No data loss occurs in the "test failover" and "planned failover" scenarios.)
HVR host machines do not need to be in the same domain, and they can even be workgroup machines. As of mid-2014, they can also be in the Microsoft cloud. Initially you had to have System Center Virtual Machine Manager (SCVMM), but at the very end of 2014, Microsoft opened up Azure-based replication to non-System-Center customers, calling it "Disaster Recovery to Azure for Branch offices." For more, see the links at the end of this paper.
C. Scenarios where Replicas Make Sense
HVRs make sense in various scenarios, but perhaps the most common is when you need to provide the ability to quickly "fail over" a virtual machine to an alternate site across a WAN link in the event the VM becomes unavailable in a primary site. For example, you could use replicas to provide fault tolerance for branch office VM deployments by replicating branch VMs to the central headquarters. A service provider could also provide VM replication hosting as a service. Such hosting can be cloud-based using Azure.
It is true that Server 2012 provides a multi-site failover cluster capability, but this requires a pre-existing SAN-to-SAN replication capability, as well as Microsoft logo-certification of cluster hardware and the passing of cluster validation tests. Also, a multi-site failover cluster is significantly more complex to implement than HVR.