Hyper-V and Storage Replicas (Part 3)
If you would like to read the other parts in this article series please go to:
In the previous article in this series, I walked you through the creation of a pair of virtual machines that we are going to use in an effort to demonstrate guest level storage replication. As you may recall, each of these virtual machines contains three identical volumes. There is an operating system volume (C:), a data volume (D:), and a log file volume (L:). Although we can use the drive letters to differentiate between the volumes, I also created custom volume labels that should help to further clarify the purpose of each volume.
One more thing that we did in the previous article was to install the File Server role and the Storage Replica feature. In that article, I used the Server Manager to install the required components, although I could have just as easily used PowerShell. Even so, there does not seem to be a way to progress any further into the process of configuring server to server replication through the GUI, at least not without delving into the Server Manager Tools (https://blogs.technet.microsoft.com/servermanagement/2016/02/09/introducing-server-management-tools/), which are a set of Web based management tools for Windows Server 2016. Given the complexity of deploying these tools, I am going to work through the process of configuring server to server replication through PowerShell.
It is actually fairly easy to set up storage replication through PowerShell. When you install the Storage Replica feature, there is a PowerShell module that gets installed. This module gives you everything that you need in order to enable, test, and monitor storage replication.
Enabling server to server storage replication requires you to create a storage replication partnership. There are several pieces of information that you are going to need in order to form this partnership and begin replicating content across servers.
First, you will need to know the name of each server. For the purposes of this article series, I am assuming that DNS name resolution works between the two servers. The next thing that you will need is the drive letter for the data volume and the log volume on each server. In my case, the data volume is D: and the log volume is L:. The last thing that you will need is a replication group name. The replication group name is just a friendly name that can be used to identify the servers used in the replication process. You will need one replication group name for the source server and a different replication group name for the destination server. So with that said, here are the naming conventions that I will be using:
So with that said, here is the command syntax that you will need to use. You will have to run this command in an elevated PowerShell window.
New-SRPartnership -SourceComputerName <source computer name> -SourceRGName <source replication group name> -SourceVolumeName <source volume drive letter> -SourceLogVolumeName <source log file volume drive letter> -DestinationComputerName <destination computer name> -DestinationRGName <destination replication group name> -DestinationVolume <Destination volume drive letter> -DestinationLogVolume <destination log file volume drive letter>
This is obviously a long command, but the sample syntax shown above is actually a little bit longer than the real command would typically be, simply because of the descriptive text that it includes. So here is what the same command would look like, using the naming conventions that I provided earlier:
New-SRPartnership -SourceComputerName StorageRep1 -SourceRGName SourceRG -SourceVolumeName D: -SourceLogVolumeName L: -DestinationComputerName StorageRep2 -DestinationRGName DestinationRG -DestinationVolume D: -DestinationLogVolume L:
You can see what this command looks like in action in Figure A.
This is how you establish a storage replication partnership.
So now that storage replication has been set up, the real question is how you can tell whether or not it worked. Unfortunately, this isn’t quite as simple as placing a few files on the source computer’s data volume, and then watching to see if those files are copied to the destination computer’s data volume. The reason for this is that File Explorer prevents access to the data volume on the destination computer, so you can’t easily take a peek at the volume’s contents. What you can do however, is to use PowerShell to take a look at the state of the replication process.
One easy way to test the replication process is to copy some files to the data volume on the source computer, and then track the number of bytes that are replicated. Replication can sometimes occur quickly, so you will have to be sure to select a folder that is large enough that the synchronization process won’t complete before you have a chance to monitor it.
Once the file copy process begins, open an elevated PowerShell window and enter the following command:
(Get-SRGroup).Replicas | Select-Object NumOfBytesRemaining
Now, repeat the command several times as the replication process occurs. If everything is working properly, then you should see the number of bytes remaining steadily decrease. It is worth noting that this method could prove to be a bit tedious, because replication may not happen right away. That being the case, there are a few other things that you can do.
One option is to type Get-SRGroup. Doing so will cause Windows to display information such as the log size and the date and time of the most recent synchronization. You can see what this looks like in Figure B.
Pay attention to the log file size and the date and time of the last synchronization.
One more way that you can keep tabs on what is going on is through the Windows Event Viewer. Open the Event Viewer and navigate through the console tree to Application and Service Logs | Microsoft | Windows | StorageReplica | Admin. The events in this log will allow you to monitor the replication process.
In this article, I have explained how to get storage replication up and running. In the next article in this series, I want to talk about replication within a failover cluster.