Windows Server 2012 Virtualization - Hyper-V Replica

Hyper-V in Windows Server 2012 includes some new capabilities. Today I want to walk through the setup of one of those capabilities called Hyper-V Replica. Hyper-V Replica provides a way to replicate a Virtual Machine to another Hyper-V server in case the primary Hyper-V hosts fails. The best part about Hyper-V replica is that it doesn’t require shared storage; just two 2012 Servers running Hyper-V. This video discusses replication from one Hyper-V Server to another Hyper-V server. You could of course also replicate from one 2012 Hyper-V Cluster (or stand alone 2012 Hyper-V Server) to a second 2012 Hyper-V Cluster (or stand alone 2012 Hyper-V Server) as well.

There is a great whitepaper written by Chuck Timon, one of our Senior Support Escalation Engineers. Chuck does a good job of walking through all of the details around Hyper-V Replica here.

From Chuck’s Whitepaper, there are four primary deployment scenarios he considers for Hyper-V Replica:

· Head Office and Branch Office (HO-BO)

· Enterprise Datacenter

· Hosting Provider Datacenter

· Customer Office and Hosting Provider Datacenter (Cross-Premise)

If you’re not up for the details of Chuck’s Whitepaper, there is a good TechNet article on Hyper-V Replica here.

This session is one part of a whole series of screen casts around Hyper-V in Windows Server 2012, you can go this link to access the whole series.

I was just wondering using Hyper-V Replica could I replicate from multiple hyper v host to one off site host. The Idea is to have a copy of our main servers off site that could be spun up i at least on a limited base until the host or data center could be rebuilt.

Aside from the fact that the process requires the manual rigor, how does the cost associated with these backups (the bandwidth to stream the deltas, the general unused condition of the backups host/vm backups) scale?

For instance; you have a handful of VMs on a set of hosts. You configure those hosts to back up the VMs to a backup host or two. Now those two backup hosts are in "hopefully never have to use" condition. What is the cost associated with this? At what point is this strategy intractable?

If the backup host is not dedicated to backup, but is otherwise serving VMs, and the host it is backing up dies or needs mainteance, how can you be sure that the backup host will have the headroom to run the backup vms? What if it doesn't?

In the end, what I'm wondering is, if it's better to think in terms of software defined control. If a host serving a VM dies, the control would see this, and bring the VM up via a template on another host that has the available headroom. Loading it's data from the datastore, you'd now be up and running again. Same goes for maintenance; put the first host in maintenance mode, let the VMs be moved to where the control sees it makes sense to move them, perform the maintenance, turn it back on, and let the control redistribute the environment optimally.

Fixed point-to-point replication would seem, in many ways, to be contrary to the notion of really utilizing cloud technology to the fullest.

Any merit to that? If the answer is, "this is mostly for small environments with a few VMs", that's fair, but in a large environment, this would seem to top out fast.