Code Library

The following are some of the key things to know concerning Storage Replica as of the Windows
Server 2016 release:

 Network bandwidth and latency with fastest storage There are physical limitations to synchronous replication. Because Storage Replica implements an I/O filtering mechanism using logs and requiring network roundtrips, synchronous replication is likely to make application writes slower. By using low-latency, high-bandwidth networks as well as high-throughput drive subsystems for the logs, you can minimize performance overhead.

 The destination volume is not accessible while replicating When you configure replication, the destination volume will dismount and no longer be visible in any normal GUI tools or accessible to any writes by users until you remove replication, or the volume becomes the source due to failover. Block-level replication technologies are incompatible with allowing access to the destination’s mounted file system in a volume; NTFS and ReFS do not support users writing data to the volume
while blocks change underneath them.

 Different implementation of asynchronous replication The Microsoft implementation of asynchronous replication is different than most industry implementations of asynchronous replication that rely on snapshot-based replication, whereby periodic differential transfers move to the other node and merge. In contrast, Storage Replica asynchronous replication operates just like synchronous replication, except that it removes the requirement for a serialized synchronous acknowledgment from the destination. This means that Storage Replica theoretically has a lower RPO as it continuously replicates. However, this also means it relies on internal application consistency guarantees rather than using snapshots to force consistency in application files. Storage Replica guarantees crash consistency in all replication modes.

 Storage Replica is not Distributed File System Replication Volume-level block storage replication is not a good candidate for use in branch-office scenarios. Branch-office networks tend to be highly latent, highly utilized, and lower bandwidth, which makes synchronous replication impractical. A branch office often replicates data in a one-to-many with read-only destinations, such as for software distribution, and Storage Replica is not capable of this in the first release. When replicating data from a branch office to a main office, Storage Replica dismounts the destination volume to prevent direct access. It is important to note, nevertheless, that many customers use Distributed File System Replication (DFSR) as a DR solution even though it is often impractical for that scenario—DFSR cannot replicate open files and is designed to minimize bandwidth usage at the expense of performance, leading to large recovery-point deltas. Storage Replica might make it possible for you to retire DFSR from some of these types of DR duties.

 Storage Replica is not backup Some IT environments deploy replication systems as backup  solutions due to their zero-data-loss options when compared to daily backups. Storage Replica replicates all changes to all blocks of data on the volume, regardless of the change type. If a user deletes all data from a volume, Storage Replica replicates the deletion instantly to the other volume, irrevocably removing the data from both servers.

 Storage Replica is not Hyper-V Replica or SQL AlwaysOn Storage Replica is a general purpose, storage-agnostic engine. By definition, it cannot tailor its behavior as ideally as application-level replication. This might lead to specific feature gaps that encourage you to deploy or remain on specific application replication technologies.

Source of Information : Microsoft Introduction Windows Server 2016