Storage Replica is perhaps one of the most overlooked new features in Windows Server 2016. This important disaster-preparedness and recovery feature protects your data by implementing synchronous volume replication between clusters or servers.
It also helps to implement asynchronous replication needed to create failover clusters for two sites, keeping all the nodes in sync.
You’ve got questions? Good, we’ve got answers. Here are some of the most popular FAQs about Storage Replica in Windows Server 2016.
What kind of asynchronous replication does it support?
Storage Replica supports asynchronous replication for higher latency networks and longer ranges. Given the fact that it is not checkpoint based and instead implements continuous replication, the delta of the changes tends to be much lower when compared to snapshots-based products.
This is a significant advantage of Storage Replica. Also, given the fact that Storage Replica executes operations at the partition layer, it replicates the VSS snapshots created by Windows Server or other backup software. This allows for the use of data snapshots that are application consistent for use with point-in-time recovery. This is especially true for unstructured data that is replicated asynchronously.
What kinds of configurations are supported?
Three different configurations are supported – stretch cluster, cluster-to-cluster, and server-to-server configurations. A stretch cluster allows you to create a configuration of storage and computers in a single cluster, with some nodes sharing a particular set of asymmetric storage and some nodes sharing another, which then replicate with site awareness.
A cluster-to-cluster setup permits replication between two separate clusters, with one cluster replicating another. A server-to-server configuration permits asynchronous and synchronous replication to happen across two standalone servers. And no, because they stand alone does not mean they are on strike or rebelling against anything!
What are the key features?
- Block level replication with zero data loss.
- Simple deployment and management with the creation of a replication link between servers needing only one PowerShell command.
- Virtualized guest- and host-based deployments available, which means that guests can replicate data volumes even if running in public clouds or on non-Windows virtualization platforms.
- Support for industry-leading security standards including AES-128, packet signing, and man-in-the-middle attack prevention.
- Seeded initial sync is supported, whereby a small subset of the data can be loaded from backups or older copies. Only the differing blocks are copied during the initial replication, thus shortening sync time and reducing bandwidth usage.
What are the system requirements?
- Active Directory domain services.
- Storage spaces direct and with SAS JBODs, shared VHDX, fiber channel SAN, iSCSI target or local SCSI/SAS/SATA storage.
- A minimum of one TCP/Ethernet connection on each server in order to implement synchronous replication, although RDMA is preferred.
- A minimum of 2GB of RAM and two cores for every server.
- Sufficient bandwidth to contain the IO write workload with a round trip latency of 5ms or lower, as far as synchronous replication goes. There are no latency requirements for asynchronous replication.
How does it support cluster replication?
Windows Server 2016 has made cluster-to-cluster replication extremely versatile―almost as versatile as Magic Johnson used to be or LeBron James is now! While earlier versions of the software have long supported replication via SAN and Hyper-V, the storage spaces feature introduced in the 2012 version has been extended to be storage spaces direct.
Storage spaces direct is specifically designed to be used in hyper-converged situations where cluster nodes are combined with local storage. Although the associated features are targeted at replication inside a cluster, the same feature can also be used to execute storage replication for cluster-to-cluster situations.
To properly execute cluster-to-cluster replication, some key requirements need to be met.
- Both the source and destination clusters should use a CSV.
- The sector size must be constant for disks across both clusters.
- Two virtual disks need to be accommodated within the physical storage of each cluster.
How do I see the progress of replication during initial sync?
The Event 1237 messages in the Storage Replica admin event log on the destination server display the number of bytes copied and the number of bytes remaining at an interval of 10 seconds. You can also alternatively use the Storage Replica performance counter on the destination that shows \Storage Replica Statistics\Total Bytes Received for multiple replicated volumes. The replication group can also be queried using Windows PowerShell.
How to monitor replication performance?
The performance counters can be used to monitor the volume replication performance. Once replication is established, there is an initial period where we see both replication activity and increased CPU that happens during the time when the initial sync happens. In actual practice, this sync should be allowed to be completed before the replicated volume is moved into production.
- Switch to SRV01 and invoke PowerShell.
- Invoke command PerfMon.msc.
- Choose Performance Monitor from monitoring tools. From inside Performance Monitor, click Add.
- From under the list of available counters, choose Storage Replica Statistics, and Add. Then click.
- Modify the type of Graph to be Reported.
- In PowerShell, use copy item with a Recourse option.
- Now notice the variation in numbers in Performance Monitor. It is a recommended practice to wait until the statistics settle down and take it as a sign of replication completing. Given the fact that the sync could still be in progress, this process might take up to a few minutes. Once replication is seen to be completed, the replication needs to be reversed from SRV02 to SRV01.
How to reverse failover replication?
- The first step is to switch to SRV02 and open PowerShell in Administrator mode.
- In PowerShell, use Set -SRPartnership, FCNode2ReplGrp1, and FCNode1ReplGrp1 commands.
- We will now switch to SRV01 to check if the relevant volume is available any more. (No, they will not be taking a break or a vacation in Miami, no worries there).
How to remove volume replication?
The first step in removing volume replication is to open PowerShell in Administrator mode on SRV02.
- To remove the existing replication, use Get -SRPartnership and Remove -SRGroup commands. (Do not worry about SRGroup commands. They do not have feelings and no, you do not need to buy them a thank you card from the store!)
- Now, switch to SRV01, and invoke Remove -SRGroup in administrator mode.
Upon examination (no, this is not a test you need to study for, stop hyperventilating!), we can see if Windows Volume Replication is removed.