In the previous article in this series, I explained that storage replication can be performed synchronously or asynchronously. Synchronous replication is always preferred, because it happens in near real time. Even so, synchronous replication is not always an option because synchronous replication is sensitive to latency.
Fortunately, Microsoft provides a tool that you can use to validate your systems and ensure that you have met the requirements of synchronous replication. The tool is a PowerShell cmdlet called Test-SRTopology.
As mentioned in the previous article, the Test-SRTopology cmdlet is not installed by default, but it is included with Windows Server 2016. To get access to this cmdlet, you will need to install the Storage Replica Module for Windows PowerShell. This module is a part of the Feature Administration Tools. I showed the process of installing this module in the previous article.
The nice thing about the Test-SRTopology cmdlet is that it lets you validate the communications between two servers that you are considering configuring as replication partners. In other words, the servers do not have to currently be replication partners. You can test the connectivity between the two servers prior to enabling replication.
Test-SRTopology cmdlet syntax
The Test-SRTopology cmdlet’s syntax is relatively straightforward. In fact, using it reminds me a lot of the process used for enabling replication. So with that said, here is the basic command syntax:
Test-SRTopology -SourceComputerName <source computer name> -SourceVolumeName <source volume> -SourceLogVolumeName <log volume> -DestinationComputerName <destination computer name> -DestinationVolumeName <destination volume name> -DestinationLogVolumeName <destination log volume name> -DurationInMinutes <test duration> -ResultPath <destination path for the test results>
Admittedly, this is a long command, but thankfully there isn’t anything overly difficult about the cmdlet’s required parameters. I have actually covered some of these parameters in an earlier article when I showed you how to set up replication. Even so, there are a few things that I want to take the time to point out.
First, this cmdlet has changed a bit from the time that Windows Server 2016 was in its technical preview release. As such, some of websites that list the command syntax use plural versions (with an S on the end) of the SourceVolumeName and DestinationVolumeName parameters. However, the current version of the cmdlet uses singular parameters (the parameter names do not end in S). Some of the early documentation also referenced a parameter called IntervalInSeconds that allowed you to specify the testing interval. However, this parameter was removed from the final version of the command.
If you want to view the command’s current syntax, then type:
Get-Help Test-SRTopology
You can see this command’s results below.
Another thing I want to point out about the Test-SRTopology cmdlet: It will not work if the systems are already replication partners. If you try to run this command on a system that is already replicating with another system, then you will receive an error that the destination system has an invalid file system.
If you want to try out the Test-SRTopology cmdlet on the servers that you set up as replication partners earlier in this series, then you will need to disable the replication partnership. You can do this by executing the Remove-SRPartnership cmdlet, and then supplying values for the SourceRGName, DestinationRGName, and DestinationComputerName.
One more thing that I need to point out before showing you how to run the topology test is that the test duration is somewhat misleading. During my tests, I initially set the test duration for one minute. However, the process actually took several minutes to complete, because the Test-SRTopology cmdlet ran a number of tests, for a minute each.
Putting it all together
So let’s take a look at how this command works. For the purpose of this article, I set up two servers, which I named Repl1 and Repl2. Repl1 represents my intended source server, and Repl2 represents my destination server. I mapped the drives on these servers in the same way as before, with D: being used for data, and L: being used for the logs. As such, the command that I used was:
Test-SRTopology -SourceComputerName Repl1 -SourceVolumeName D: -SourceLogVolumeName L: -DestinationComputerName Repl2 -DestinationVolumeName D: -DestinationLogVolumeName L: -DurationInMinutes 1 -ResultPath C:\Data
You can see what the testing process looks like below.
Here is what it looks like when you run the test.
As you can see in the figure, the test results were saved to an HTML report in the C:\Data folder. You can see samples of the report in the two screenshots below.
As you can see in the screenshot above, the Test-SRTopology cmdlet tests more than just the latency between the two servers. It tests the volumes to make sure that they are suitable for use with storage replication, and it even tests the amount of memory that is installed onto the servers.
As you scroll further down into the report, you will find a number of charts displaying storage latency and network latency. These charts reflect changes in latency over a period of time. When I ran my test, I set up a test duration of one minute. However, testing the systems for one minute does not provide a realistic sample of the conditions that might be expected in the real world. Network activity is known to peak during certain times of the day and on certain days of the week. As such, it is a good idea to run this test for as long as you can. For instance, you might specify a duration of several days or more.
The Test-SRTopology cmdlet can help you to make sure that your servers are well equipped for storage replication. These tests should be performed before replication is enabled.
If you would like to read the other parts in this article series, please go to:
Photo credit: Microsoft
