How to use Hyper-V Replicas in Server 2012 R2 – Part 2
This is part 2 in the series of posts on Hyper-V Replicas where we will explore how and when you should consider implementing them. Part 1 can be found here.
The first and most obvious reason to implement Hyper-V Replicas is for disaster recovery. You likely have key VMs which you depend on to run your business, and using Hyper-V Replicas you can maintain an up-to-date standby copy of those VMs. Business runs normally and delta changes in your VMs are replicated to your Replica site at configured intervals (every 5 minutes is default, but configurable to every 15 seconds or every 30 minutes with Hyper-V 2012 R2).
When disaster strikes the primary site, the VMs at the Replica site are spun up and business continues running from the Replica site until operations are restored at the primary site.
Another helpful but perhaps less frequently considered use for Hyper-V Replicas is testing. Testing prior to OS or application patches and updates is something you typically need to do but often do not have proper test resources. Once you have Replicas setup, however, testing becomes easy. You simply perform a VM failover in test mode either in Hyper-V Manager or by using the PowerShell Start-VMFailover cmdlet:
This creates a copy of the Replica VM without impacting replication to the Replica (Microsoft does this by using a differencing disk on the Replica VM to track the replicated changes from your primary VM during the test). The copy VM is created without networking, however, so you will need to use PowerShell or the Hyper-V Manager to add networking to the test VM. Once you’ve done that, you can apply your patches and updates and perform needed testing. Once you’ve completed your testing, simply power off the test VM, then from the Replica host, take the replica VM out of failover test mode in Hyper-V Manager or with PowerShell Stop-VMFailover. This cmdlet will delete the test VM and allow replication to continue normally.
