If you would like to read the other parts in this article series please go to:
- Working With Replicas in Hyper-V 3.0 (Part 1)
- Working With Replicas in Hyper-V 3.0 (Part 2)
- Working With Replicas in Hyper-V 3.0 (Part 3)
- Working With Replicas in Hyper-V 3.0 (Part 4)
- Working With Replicas in Hyper-V 3.0 (Part 5)
Introduction
At the very beginning of this article series, I explained that Hyper-V replicas are provided primarily as a mechanism for creating relatively up to date copies of virtual machines. Replicas do not provide the automatic failover capabilities that you get if you deploy a true Hyper-V cluster. Likewise, Hyper-V replicas are not a high availability solution. Even so, Hyper-V replicas do provide some limited disaster recovery capabilities. In this article, I want to conclude the discussion of Hyper-V replicas by showing you how to use Hyper-V replicas to perform failovers.
Planned Failovers vs. Unplanned Failovers
Hyper-V replicas provide for two different types of failovers. You can perform a planned failover or you can perform an unplanned failover.
Performing a Planned Failover
Ideally, a planned failover is the only type of replica based failover that you should ever perform. Planned failovers are completely safe, whereas unplanned failovers almost always result in at least some degree of data loss.
Planned failovers are usually done in situations in which a Hyper-V host needs to be taken offline for maintenance. You can fail over the virtual machines to the replica copy so that you can take the host offline without impacting virtual machine availability. In this way, a planned failover is somewhat similar to performing a live migration. The difference is that because replicas are being used, a full copy of the virtual machine already exists in the host to which you are going to be failing over.
The first step in performing a planned failover is to make sure that the replication process is healthy. The easiest way to accomplish this is to open the Hyper-V Manager on the server that is currently hosting the primary copy of the virtual machine. From there, you must select the virtual machine and then click on the Replication tab at the bottom of the screen. If the Replication Health field indicates a status of Healthy then you are good to go. Otherwise, you will have to do a little bit of work prior to performing the failover.
If the Replication Health status indicates that a replication error has occurred then the replicas are not in sync. You can usually force the replicas back into sync by right clicking on the virtual machine and selecting the Replication | Resume Replication commands from the shortcut menus.
If the Replication Health has a status of Warning then you might not actually have a problem. This is especially true if you have recently recovered from a replication error. Hyper-V holds on to replication statistics for a long time. Therefore if there was previously a replication failure and you have since corrected the problem then you might see a status of Warning. In this type of situation, the Warning is generated because replication seems to be working at the moment, but it has had some problems in the past.
If you do have a Warning status then I recommend resetting all of the replication statistics and then waiting for about half an hour for some more recent statistics to accumulate. Doing so will help you to better evaluate the health of the virtual machine.
You can reset a virtual machine’s replication health statistics by right clicking on the virtual machine and choosing the Replication | View Replication Health commands from the shortcut menus. When the Replication Health dialog box appears, click the Reset Statistics button, as shown in Figure A. If you want to save the current statistics prior to deleting them, you can do so by clicking the Save As button. This will allow you to export the replication statistics to a CSV file.
Figure A: If you are receiving a replication warning then it is a good idea to reset the replication statistics so that you can view the most recent replication health data.
Once you are able to verify that the replication process is healthy, it is time to perform the planned failover. To do so, right click on the virtual machine and choose the Replication | Planned Failover commands from the shortcut menus, as shown in Figure B.
Figure B: Right click on the virtual machine and choose the Replication | Planned Failover commands from the shortcut menus.
At this point, you will see a dialog box similar to the one that is shown in Figure C. This dialog box explains that the failover process will replicate any changes to the primary virtual machine that have not yet been replicated. The dialog box also provides a list of prerequisites checks and actions that have to occur as a part of the failover process. To perform the failover, make sure that the Start the Replica Virtual Machine After Failover check box is selected and then click the Failover button.
Figure C: Click Failover to perform a planned failover.
Unplanned Failovers
As I previously mentioned, unplanned failovers should be used as a last resort option for bringing your virtualization hosts back online. Unplanned failovers almost always result in at least some data loss because any data that has not yet replicated to the replica server is lost during the failover process.
As you saw in the previous section, a planned failover is initiated on your primary virtualization host. In contrast, an unplanned failover is initiated on the replica server instead.
Under normal circumstances, replica virtual machines remain powered off unless they are being tested. Performing an unplanned failover brings the replica virtual machine online and then designates it as the primary VM. Of course this type of operation could be very problematic if the primary host server is still online when an unplanned failover occurs. In order to prevent split brain syndrome and other similar problems, Hyper-V automatically checks to see if the primary host is still online. If the primary host is online then the unplanned failover operation is prevented.
To perform an unplanned failover, open the Hyper-V Manager on your replica server. When the console opens, right click on the virtual machine that you want to fail over and then choose the Replication | Failover commands from the resulting shortcut menus, as shown in Figure D.
Figure D: To perform an unplanned failover, open the Hyper-V Manager on the replica server, right click on the virtual machine that you want to failover, and choose the Replication | Fail Over commands from the shortcut menus.
As you might recall from earlier in the series, when you enable Hyper-V replication you are given the option of maintaining multiple recovery points on the replica server (but doing so consumes additional storage space). If you opted to store multiple recovery points then an unplanned failover will provide you with the option of reverting to a previous recovery point. Doing so is similar to performing a point in time restoration. This functionality could prove to be handy if you need to revert a server to a state as it existed prior to a malware infection.
Conclusion
As I said at the very beginning of this article series, replicas are probably my favorite of all the new Hyper-V features. It’s nice to be able to maintain standby copies of virtual machines without having to break the bank in the process.
If you would like to read the other parts in this article series please go to:
