Author: Ed Baker, Windows Server Instructor at Firebrand Training
Until now if you wanted to implement High Availability in Virtual Machines (VM), you would have to invest in cluster technology and some shared storage. Now the arrival of Windows Server 2012 brings with it a perfectly acceptable disaster recovery solution for Virtual Machines that is free, built into the product and easy to implement.
A replica is just what it says, a copy of a live VM stored on a remote server that is updated every five minutes with any changes. At any point in time you can failover to the replica and bring the virtualised workload back online.
What you need to get started
Hyper-V Replicas can be implemented if you have any two physical Windows Server 2012 servers. These must both have the Hyper-V role installed. The location of the servers is not important – they can be in the same rack or on different continents. The only other requirements are that they can be connected by an IP network, they have sufficient storage to host the virtualized workloads to be replicated, and that the network bandwidth is sufficient to cope with the initial transfers.
Replication is very flexible: in or out of domains, and in or out of failover clusters (same cluster or not). It also allows a completely standalone non-domain single replication model – which is the scenario that this article deals with.
Where to begin
First install the Hyper-V role on both machines (using Server Manager, or PowerShell 3.0 if you are a command-line guru). To prepare for replication, set-up an External Replication network using the virtual switch manager. This needs to be done on both servers, with the network name being the same on each. The only other step to prepare for the use of replicas is to have a Virtual Machine (VM) configured on each server. This is because we are going to set both servers up to replicate each other.
We now have two physical servers acting as Hosts or Parents to a VM, using the same replication network.
On Server One, open Hyper-V manager and select the VM you wish to replicate. Right-click on the VM, and select “Enable Replication”. Unsurprisingly, this fires-up a wizard. In the Specify Replica Server Box, enter the FQDN of your second server. You will receive an error stating that the server is not ready to host replicas. There is a convenient Configure Server button – click this.
This opens the Hyper-V Settings window for the second server, with the focus on the Replication configuration section. Check the Enable this Server for Replication box. Depending on your requirements, these settings allow for unencrypted HTTP traffic (port 80) or encrypted HTTPS communication (port 443). It also allows for authentication from a single server, a group or from any server.
You then want to check the Use Kerberos (HTTP) box, and the Allow Authentication From Any Server Radio button. Apply these settings. A warning points you to the correct firewall rules to enable. This screenshot shows which rule to set on both servers:
Simply accept all the defaults for the rest of the wizard. There are also many areas for configuration, to allow for more flexible use of replication.
Now do it all over again
Replication is now enabled, and the initial replication has started. If this is a small machine and the network is quick, go to the second server and see if the replicated VM has appeared. If it has, in the bottom section of Hyper-V manager, you will see there is now a Replication tab. Select the replicated VM and click that Replication tab. You will see it is listed as a replica.
Repeat the above steps for the VM on Server Two.
Provided that you set the Firewall rules correctly, you now have a cross-replicated system, where each server hosts a primary and a replica VM. There is no cluster, no SAN, no shared storage, just replicas as shown below.
It’s possible to select a time period for replication – and whether it starts manually or automatically. VHDs can be included and excluded from the replication if required. Recovery points can be maintained, and the number of these to be stored is also configurable (between 1 and 15). The transmitted data can be compressed and encrypted if required.
All of these settings can be managed in the VM Settings window.
Hyper-V replication allows for several different failover scenarios. From the replica copy itself, these options are available:
While from the Primary VM, the below are available:
So there are: Test Failover, Failover and Planned Failover…
1. Test Failover
This option ensures that your replica VM starts correctly, and is a viable DR solution. By selecting this, a new VM is created which allows the administrator to confirm its status:
To ensure that your Test Failover doesn’t interfere with your production machines, Hyper-V now has the ability to inject a different IP addressing scheme into your Replica. It can also start it using an entirely different network, using the virtual switch.
In the VM Settings – under Network Adaptor – the configuration options cater for IPv4 , IPv6 and advanced options and test failover for networks. This flexibility allows an administrator to carry out failover tests regularly – this is best practice!
Once tested, right-click the original replica VM and click Replication. Stop Test Failover, and the test VM will be deleted.
This is the one to use when the Primary VM has failed, and you need to get your virtualised workload up and running as soon as possible. Simply select Replication and Failover. The standard warning appears, select your recovery point and click Failover. The replica remains the replica, but is the active VM. The Replication tab highlights the completed failover, and the warning that the primary is offline.
Once the Primary VM is up and running there are several options to return to normal. Though these are outside the scope of a short article. Microsoft has published an 82-page Understanding and Troubleshooting guide for Hyper-V replicas, which will assist with this and any other unanswered questions.
3. Planned Failover
This is carried-out from the primary VM. When selecting the option from the Replication sub-menu, a prerequisite check is carried-out to ensure that the replica can take over in the absence of the primary. And that all the necessary action is then set in motion; including reversing the replication to ensure the original primary is kept up-to-date when it comes back online.
This has been a short toe-dipping into what is set to be one of Windows Server 2012 ‘Big Five’ areas of functionality. The ability to carry out failovers and high-availability on a tiny budget is something small businesses have been crying-out for, and can now embrace with zero additional costs.