Replicating at the storage level provides a solution that works for any workload, and
this is now a feature of Windows Server 2016 with Storage Replica.
Storage Replica supports both synchronous and asynchronous block-level replication.
Synchronous means that data is written and persisted to both the source and replica
before being acknowledged to the requesting application. Asynchronous means that
writes are acknowledged to the requesting application when written to the source
location, and then in the background those writes are sent to the replica, where they
are persisted. With synchronous, there is no risk of data loss, but performance may be
impacted, depending on the latency writing to the replica if it’s in a different location.
With asynchronous, there is no performance impact, but there is some risk of data
loss in unplanned scenarios.
Storage Replica utilizes SMB 3.1.1 as the transport for the data being replicated. It is
enabled at a volume level, and because it is block based, it does not care about the
filesystem used, whether data is BitLocker protected, or whether files are locked.
Storage Replica is completely agnostic to the actual storage and supports any fixed-
disk storage, any storage fabric, shared cluster storage, and even Storage Spaces Direct
storage, which opens up some interesting solutions that I discuss later in this chapter.
Removable devices are not supported, and disks must use GPT instead of MBR. With
Storage Replica, the source for the replica is fully accessible while the replica is offline
and can be used only when a failover is performed, at which point the replication
direction is reversed (if possible). Replication is one to one, and you cannot replicate a
replica. Because SMB is used for the replication, all of the performance and scalability
features of SMB are available, including SMB Multichannel, SMB Direct (RDMA),
encryption, and signing.
Storage Replica can be used in various scenarios because of the replication flexibility,
including replicating between floors, between buildings, between cities, and even
between continents. The longer the distance and the longer the latency, the more
likely you will use asynchronous replication instead of synchronous. In all of the
scenarios, both asynchronous and synchronous can be used for the replication, but
where possible, synchronous is preferred to remove the risk of data loss.
Figure 4.9 shows the key scenarios that leverage Storage Replica. The first is a stretch
cluster with a physical separation between the two partitions of the cluster. Here
Storage Replica is used to replicate the cluster storage from one partition of the
cluster to cluster storage in the other partition, enabling asymmetric storage
configurations. The storage could be Cluster Shared Volumes or role-assigned physical
disk resources (PDRs). In this model, because it is a single cluster, automatic failover
can be performed, and often synchronous is used to eliminate data risk. However, if
you are willing to risk a small amount of data, asymmetric is also available. When
used in this way, it helps make the cluster more disaster resilient, as the cluster can be
expanded beyond a single location. This mode is primarily targeted at Hyper-V
workloads and general-use file servers.