Windows Server 2016: DFS-R vs. Storage Replica

In today’s Ask the Admin, I’ll look at the key differences between Distributed File System Replication (DFS-R) and Storage Replica (SR), and why you might want to upgrade to Storage Replica if you’re using DFS for server-to-server replication.

 

 

Storage Replica is a new feature in Windows Server 2016 Datacenter Edition that uses the Server Message Block (SMB) 3.1.1 protocol to enable volume-based synchronous replication at block level for disaster recovery, stretch clusters, and high availability. SR supports the following three scenarios:

• Server-to-server storage replication
• Storage replication in a stretch cluster
• Cluster-to-cluster storage replication

Synchronous vs. Asynchronous Replication

Synchronous replication mirrors data on low-latency high-bandwidth networks to ensure zero data loss at the file-system level in the case of a failure. Data must be written to both volumes in a replication set before an I/O operation is marked as complete. SR in synchronous replication mode uses logs to ensure data consistency, so write operations are likely to be slower than asynchronous replication, and low latency high-bandwidth networks are required to minimize performance overhead. As such, synchronous replication is best reserved for mission-critical applications.

SR also supports asynchronous replication, which is designed for use across high-latency networks, but can’t guarantee that both volumes in a replication set will have the same data after a failure. Although unlike DFS-R, SR in asynchronous mode does provide near zero data loss. Microsoft’s implementation of asynchronous replication doesn’t use snapshots like most third-party solutions. Instead, it works like synchronous replication but doesn’t wait for acknowledgment of successful write operations on both volumes in a replication set. Additionally, block-level replication ensures that file locking doesn’t prevent files being replicated or used.

Distributed File System

DFS in Windows Server allows administrators to provision namespaces, providing users with a logical way to access files without needing to know their physical location. A DFS namespace is a hierarchy of UNC paths that don’t use fileserver names but transparently redirect users to the nearest copy of the data. Part of this technology is DFS-R, or Distributed File System Replication, which can be used in conjunction with DFS namespaces or as a standalone file replication solution.

For more information on DFS, see Create a Distributed File System Namespace in Windows Server 2012 R2 and Configure Distributed File System Replication in Windows Server 2012 R2 on the Petri IT Knowledgebase.

DFS Replication was designed for use over low-bandwidth networks, and sometimes the high-latency involved means that replicas are hours or even days out of sync with each other. DFS-R also requires that files be closed before they can be replicated, meaning that the newest files are the least likely to replicated in a timely manner.

Storage Replica

Because SR works at block-level, it can replicate open files. Furthermore, it replicates all VSS snapshots, enabling administrators to run application-aware, point-in-time restore operations using backups created by Windows Backup or third-party backup solutions that use Microsoft’s APIs. SR can use volumes comprising any kind of fixed disk, although the geometry of the volumes should be the same due to the use of block-level replication, and is compatible with any disk fabric supported by Windows Server, such as Fibre Channel and iSCSI.

In an upcoming article on Petri, I’ll show you how to set up server-to-server replication in Windows Server 2016 using Storage Replica.