Storage Replica

Author by Mitchell Grande

Storage Replica is a new feature in Windows Server 2016 that does block-level replication between Windows Servers in a few different configurations.  Although it isn't the solution to every replication scenario, it is a versatile technology that helps in a few different cases.

Supported Scenarios

Storage Replica enables replication in the following supported configurations
  • Between different groups of servers within a single Windows failover cluster (in a stretched multi-site cluster environment)
  • Between two different clusters, either single-site or multi-site
  • Between two different standalone servers with no cluster involved
 Each of these have different use cases, but we are going to focus on the Server to Server solution in this article.

Server to Server - Use Cases and Requirements

Server to server storage replication provides synchronous or asynchronous block-level replication between two different Windows Server 2016 servers in the same or different locations.  This can be used to replace DFS Replication in certain scenarios, such as replicating to a DR site where users don't need ongoing access on the destination server.  It's also perfect for general disaster recovery of specific volumes of data.
 
The following are some of the requirements:
  • Both servers must be in the same AD domain
  • Server 2016 Datacenter edition is required
  • ICMP, SMB, and WS-MAN network traffic must be allowed between servers
  • A network connection with 5ms latency or less for synchronous replication
    • There is no latency requirement for asynchronous replication
  • The volume(s) you are replicating cannot contain the OS
  • Dedicated volumes for replicated data and replication logs, initialized as GPT disks, that are the same size on the source and the destination
When configuring replication, you have to choose between synchronous or asynchronous replication.  Synchronous replication ensures that data written to the source is copied and committed to the replica server before returning the IO call as successful.  This guarantees that the source and destination are always in sync, but requires low latency between the two servers.  Asynchronous replication on the other hand, allows the source server to write and complete IO calls immediately, and then queue the changes for the replica server.  This has lighter latency requirements, but it allows for some data loss during a failover.

Server to Server - Configuration

Configuring Server to Server replication isn't too difficult, but it does require PowerShell.  Once you have the servers and required storage in place, here are the steps to configure replication:
  • Install the "Storage Replica" feature on both servers with the GUI or this PowerShell command: Install-WindowsFeature Storage-Replica -IncludeManagementTools
    • A reboot will be required after installation
  • Run the New-SRPartnership PowerShell command to configure the replication between the two servers.  For example:
    • New-SRPartnership -SourceComputerName <primary-server-name> -SourceRGName rg01 -SourceVolumeName <primary-volume-letter> -SourceLogVolumeName <log-drive-on-primary-server> -DestinationComputerName <replica-server-name> -DestinationRGName rg02 -DestinationVolumeName <replica-volume-letter> -DestinationLogVolumeName <log-drive-on-secondary-server>
    • New-SRPartnership -SourceComputerName my-server-1 -SourceRGName rg01 -SourceVolumeName E: -SourceLogVolumeName L: -DestinationComputerName my-server-2 -DestinationRGName rg02 -DestinationVolumeName E: -DestinationLogVolumeName L:
    • Warning: All content on the destination replication volume will be deleted when you run this command.  Since Storage Replica is block-level replication, the destination volume will cleared so the volumes can match up perfectly on both ends.
  • Run the Get-SRGroup cmdlet to view the status of replication.  When first configured, the replication status will be "InitialBlockCopy".  Once initial replication is complete and the volumes are replicating normally, the replication status will be "ContinuouslyReplicating".

    replica-1.png

    replica-2.png
  • When replication begins, the replica volume on the destination server will be dismounted.  This is to prevent any changes being made to the volume.  Any writes would invalidate the block-level consistency between the source and destination servers.
    replica-3.jpg
  • When needed, use the Set-SRPartnership command to reverse the roles of the primary and replica servers. For example, if you need to reverse the replication of the above example:
    • Set-SRPartnership -NewSourceComputerName my-server-2 -SourceRGName rg02 -DestinationComputerName my-server-1 -DestinationRGName rg01
    • Shortly after running this command, the replicated data volume will be unlocked on the original destination server and will be available for use.  The related volume on the original source will be dismounted, and replication will then reverse direction.
  • If you need to stop and disable replication, the Remove-SRPartnership and Remove-SRGroup cmdlets will remove all related configurations from the servers

Additional Information

Storage Replica can be monitored in one of two ways.  There are a number of PerfMon statistics available at \Storage Replica Partition I/O Statistics(*)\ and \Storage Replica Statistics(*)\.  Additionally, major events are logged to Applications and Services Logs > Microsoft > Windows > Storage Replica > Admin.
 
For a GUI to manage Storage Replica, the new Windows Admin Center can be used.  This is the management tool that used to be known as Project Honolulu.  Here's how managing Storage Replica with Windows Admin Center looks:

replica-4.jpg
 
For more information about Storage Replica, see the official documentation.

Author

Mitchell Grande

Systems Engineer

Tags in this Article