Kevin Remde's IT Pro Weblog
IT Pro Resources
TechNet EventsMicrosoft Security Response CenterTechNet IT Manager Community HubMicrosoft Virtual AcademyKevin’s Evaluation Download Center
IT Pro Evangelist Blogs
Blain Barton Blain Barton's Blog@BlainBar
Brian LewisMy Thoughts on IT...@BrianLewis_
Dan Stolts IT Pro Guru Blog@ITProGuru
Jennelle Crothers TechBunny@jkc137
Keith MayerIT Pros ROCK!@KeithMayer
Kevin Remde Full of I.T.@KevinRemde
Matt Hester Matthew Hester's WebLog@MatthewHester
Tommy PattersonVirtually Cloud 9@Tommy_Patterson
Yung Chou Yung Chou on Hybrid Cloud@YungChou
In today’s article in the “Why Windows Server 2012 R2” series, I’d like to show off a new feature in Hyper-V; something I like to call the “Replica Replica”.
As many of you know, Microsoft introduced a new, powerful tool for your disaster recover (DR) tool belt called Hyper-V Replica back in Windows Server 2012 Hyper-V and Hyper-V Server 2012. For those of you who are not yet familiar with it, a Hyper-V Replica is an easily created and up-to-date offline copy of a virtual machine. On some other host – either in your local or in some remote datacenter – you have a copy of a virtual machine that can be available in case of disaster. If something bad happens to the production machine, you can failover to the replica virtual machine very quickly.
For a most-excellent description of Hyper-V Replica is and how to set it up in Hyper-V in Windows Server 2012 Hyper-V, check out this blog post from the series “31 Days of our Favorite Things” -
Windows Server 2012 and Hyper-V Replica (Part 5 of 31)
Windows Server 2012 and Hyper-V Replica (Part 5 of 31)
“So, what’s new in R2? What’s this ‘Replica Replica’ you talk about?”
We’ve added the ability to create yet another replica. It’s a replica of the replica. It’s an additional offline copy of a virtual machine and its configuration, made available, synchronized and automatically kept up-to-date on yet another Hyper-V host. Interestingly the request was from our many hosting providers, and it makes a great deal of sense in their scenario, where they are the ones hosting a replica on behalf of their customers. It only makes sense that they would love to have a backup of the replica they’re hosting.. so why not make it a replica of the replica?
Yeah, I thought so, too.
“How does it work?”
It’s very simple. After you’ve created the first replica, you right-click on the replica machine and select “Extend Replication…”. In my example, I have already set up a replica of my domain controller, and I’m going to extend the replication and put a replica of the replica on my Hyper-V Server named HVSR2-1…
The wizard looks and works very much like setting up the initial replication does. Once you get past the Before You Begin screen…
…you choose or browse to the server you want to put the replica on (the Replica server)…
You pick the type of authentication you want to use (based on what has been enabled in the Replication Settings on the Hyper-V Host settings)…
You pick a replication frequency.
NOTICE that I have two choices here, because I had selected the primary replica as sending changes every 5 minutes. Your choices will depend upon what you selected for the first replica frequency.
You may not know this (yet), but Hyper-V Replica in Server 2012 R2 allows for more than just the 5 minute intervals that were in the original Hyper-V Replica in Server 2012. You can have replication send changes every 30 seconds, 5 minutes, or 15 minutes for the first replica. For the extended replica, you must replicate at an interval that is less-or-equally-frequent to the first replica; with the exception being that you cannot replicate the to the extended replica at the 30 second interval.
Here’s a quick chart that shows the extended replication interval options available based on the first replica interval selected:
Getting back to our wizard; now we select how many recovery points we want to maintain of the extended replica…
We select an initial replication method, plus when to launch the initial replication if requested…
Check the summary…
And Finish. We’re done. And the first extended replication is now going over the wire.
Pretty cool, huh?
“Pretty cool. So now I can failover to either of my two replicas?”
Now, if I right-click on the first replica…
I see that I have similar options to what I had back in Hyper-V 2012. But now I have an additional “Pause Extended Replication” option as well.
Here’s a failover scenario for you…
Let’s say I have a virtual machine “DukeN” running on Host A, with replica on Host B and extended replica on Host C.
Host A goes down. So I right-click on the “DukeN” machine and select Failover…, and DukeN fires up and is now running on Host B.
If I right click the newly running VM and look at the Replication options I have now on the failover machine, it’s pretty interesting…
I can “Reverse Replication”, which means I can now treat this running (but still considered a replica) machine as the primary machine, and begin replication back to what was the primary location. Note: if you do this, it essential "orphans” the old extended replica. You’ll have to re-extend the replication if you want to.
I can “Remove Recovery Points..”, which does cleanup of this replica of any other points still saved.
I can “Cancel Failover”, which will shut this replica down and assumes that the original machine is now available and can be started.
I can “Resume Extended Replication”. This one is interesting to me. It assumes that Host C (containing the extended replica) is still available. When selected from Host B, then Host B becomes the main VM and the copy on Host C becomes the first replica. Once a synchronization process is completed, you can then go to the VM on Host C and Extend Replication to another host (Host D?).
Good stuff? Try it out yourself by downloading the evaluations of either Windows Server 2012 R2 or Hyper-V Server 2012 R2. And let me know if you have any comments or questions by posting them in the comments section.
Can we force the Replica to use a dedicated network between two hyper-v hosts?
I have two adapters teamed together, the virtual switch is created on top as converged network (MangementOS, LiveMigratrion, etc...)
Each network with a specific VLAN to isolate the traffic.
The two Hyper-V boxes are in the same LAN.
It is do-able, but involves the Hyper-V Replica Broker for a cluster, certificates, and adding entries to the HOSTS file to resolve DNS to use that special network at the proper time. Check out Chris Crampton's blog post on how to do this: chriscrampton.blogspot.com/.../hyper-v-replica-over-dedicated-network.html