Introducing

There are many options for the New-SRPartnership cmdlet, including creating asynchronous
replication. You also can create replication in a more granular fashion by running New-SRGroup on
each server and tying them together by using New-SRPartnership. You can add additional volumes to
a replication group by using Set-SRGroup, and you can run more than one replication group on a
server at a time. Storage Replica will include more cmdlets before the final release, including a cmdlet
to determine how well replication will perform between two servers over a given network, how to
optimally size the replication logs, and what the current write I/O load is on a server you propose for
replication—all without the need to install or configure Storage Replica beforehand.
Storage Replica in Windows Server 2016
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
53 CHAPTER 2 | Software-defined datacenter