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 5)
- Working With Replicas in Hyper-V 3.0 (Part 6)
Introduction
In the previous article in this series, I walked you through the process of setting up a simple Hyper-V replica. Now that the replica has been created, I want to take a step back and show you what the replica looks like and how you can work with the replica.
Verifying Replication Health
The first thing that I recommend doing after enabling Hyper-V replication is to verify the health of the replication process. The easiest way to accomplish this is to open the Hyper-V Manager, select the virtual machine that you created a replica of, and then click the Replication tab. When you do, you’ll see information about the replication state and the replication health, as shown in Figure A.
Figure A: The Replication tab displays the replica health.
If you look at the figure above, you will notice that the replication state reflects that there has been a replication error and that the replication health is listed as critical. This is actually fairly common. Shortly after Hyper-V 3.0 was released, I set up replication for my primary file server. The replication process failed several times during the initial synchronization, resulting in errors like the ones that you see in the screen capture above. My experience has been that replication is relatively trouble-free once the initial replica has been created. I manually triggered the error shown in the screen capture by shutting down the replica server. The reason why I did that was because I wanted to demonstrate the process for recovering from a replication error.
In a situation like the one shown in the screen capture, you obviously need to return the replication process to a healthy state. Before we do that though, it would be a good idea to get a little bit more information about the reason why the replica is in a critical state. Rather than hunting through the event logs for clues to the source of the problem, right click on the virtual machine and choose the Replication | View Replication Health commands from the resulting shortcut menu. When you do, you will see a dialog box similar to the one shown in Figure B.
Figure B: Choosing the View Replication Health option causes a health summary to be displayed.
If you look at the figure above, you can see that no data has been replicated for at least the last 18 hours and thirty minutes. We can also see that the last 221 replication cycles have failed and that there is 28.49 GB of data that has not yet been replicated.
All of this is good information, but it may not always be enough to help you to fix the problem. If you look at the first line of text in the dialog box shown above, you will see that there is a View Events link. Clicking on this link opens the Event Viewer and takes you to the Hyper-V VMMS | Admin log, where you can look for clues as to the reason for the error.
When you track down and correct the condition that led to the error, it is a good idea to go back to the Replication Health dialog box and click the Reset Statistics button. That way, any new error conditions that may occur will stand out and will not be confused with old error messages.
If you think that the troubleshooting process might end up taking a while then you might consider using the Save As button to save the contents of the Replication Health dialog box. That way, you will have a permanent copy of the error messages and won’t have to worry about the errors and warnings being overwritten.
After you have corrected the conditions that led to the replication error, you will have to manually restart the replication process. To do so, open the Hyper-V Manager, right click on the virtual machine with the failed replication and then choose the Replication | Resume Replication options from the shortcut menu, as shown in Figure C.
Figure C: You will have to manually restart the replication process.
When the replication restarts, you should see the replication state change to reflect that replication is enabled. The replication health should change from Critical to Warning, as shown in Figure D.
Figure D: The replication health changes from Critical to Warning.
You should also see the virtual machine begin replicating the changed data. For example, if you look at Figure E, you will notice that the virtual machine’s status now says Replicating Changes. If you right click on the virtual machine and pick the Replication option, you can see that we now have an option to pause the replication (which indicates that the replication process is active).
Figure E: The virtual machine’s status indicates that replication is occurring.
If you switch over to the replica server and open the Hyper-V Manager, you should be able to verify that the replica is receiving the changes that are being replicated, as shown in Figure F. Notice that the replica virtual machine should remain off throughout this process.
Figure F: The replica virtual machine should be receiving the changes.
Failing Over
As I mentioned in the first article in this series, Hyper-V replicas are not a substitute for backups, and they are not a true form of failover clustering. Even so, replicas are useful in failover situations. There are actually three different types of failovers that are supported by Hyper-V replicas. These include:
- Test failover
- Planned failover
- Unplanned failover
Test Failover
As the name implies, a test failover is a failover situation that allows you to validate the health and functionality of your Hyper-V replicas. Testing can be done in a nondisruptive manner that does not require you to take your production environment off-line or to halt the ongoing replication process.
Failover testing is done solely on the replica server, so as not to impact the production server. If you want to test a Hyper-V replica virtual machine then the easiest way to do so is to open the Hyper-V Manager, right click on the virtual machine, and choose the Replication | Test Failover commands from the resulting shortcut menu. Upon doing so, you will be asked to choose the recovery point that you want to test. In most cases, you will choose the Latest Recovery Point option and then click the Test Failover button. When you do, Hyper-V will actually create a brand-new virtual machine. Its name will mimic the virtual machine that you are testing, but with the word test appended to the end of the virtual machine name. The testing process creates this new virtual machine in a way that isolates it from the rest of the network, which means that you can safely bring the virtual machine online for testing purposes. After you have finished testing the virtual machine, you can right click on the virtual machine replica and choose the Stop Test Failover command from the shortcut menu.
Conclusion
In this article, I have discussed virtual machine health and I have begun discussing virtual machine failover testing. In the next article in this series, I want to continue the discussion by talking more about the failover testing process.
If you would like to read the other parts in this article series please go to:
