Storage Replication in Windows Server 2016

Storage Replica is a new Windows Server technology feature on Windows Server 2016. This facilitates the replication of volumes between clusters for discovery or servers. It also allows the users to craft stretch failover clusters which span at least two sites, and with all the nodes kept in sync.

Note: This feature is only available in the Datacenter edition of Windows Server 2016.

Storage Replica reinforces asynchronous and synchronous replications.

Asynchronous replication mirrors the data across sites which lie beyond metropolitan ranges over the network links which have higher latencies, minus any guarantee that both sites have any identical copies of data by the instance of failure.
Synchronous replication has the duty of reflecting the data within the low-latency network site which have crash-consistent volumes to make certain that there is zero data loss at the file-system level amid the failure.

Why You Need Storage Replication

The storage replica is an ideal tool for the modern requirement for disaster recovery alongside the preparedness abilities in Windows Server 2016 Datacenter Edition. The Windows Server, for the first time, offers the users with a peace of mind of no data loss, an ability to synchronously safeguard data on various floors, racks, building, cities, counties, and campuses.

After a disaster strikes, the data will be accessible elsewhere without any data loss. The same principle applies prior to the striking of the disaster; the storage replica allows the users to switch workloads to much safer locations before catastrophes are served with a few moments warning (again, without any data loss).

The storage replica is also reliable as it reinforces the asynchronous replication for extended ranges and networks of higher latency. Since it is not a check-point, the delta of adjustments will be somehow much lower as compared to the snapshot-based outputs. Again, the storage replica mainly operates at the partition layer, and is therefore able to replicate all VSS snapshots modelled by the Windows Server and backup software. This permits the application of unstructured operator data synchronously replicated.

The storage replica can also permit users to decommission the existing file replication systems like DFS replication which were pressed into the duty as the low-end disaster recovery remedy. The DFS replication works quite perfectly over very low bandwidth networks, though its latency is relatively higher most of the time. This is majorly contributed by its need for files to close and also its artificial throttles which are meant to eradicate the network congestion.

Supported Configurations

The Stretch Cluster allows the users to configure storage and computer in one cluster, where other nodes share a set of symmetric storage whole, some nodes share the other, and then asynchronously or synchronously replicate with the site awareness. This instance can leverage storage spaces with the shared SAN, SAS Storage and ISCSI-attached LUNs. It is regulated with the PowerShel and Failover manager graphical gadget, and permits for the automated failover.

Cluster to Cluster permits the replication in between two separate clusters, where a single cluster asynchronously or synchronously replicates with another cluster. Ideally, the instance can permit the utilization of storage spaces directly, SAN and ISCSI-attached LUNs and Storage Spaces with shared SAS storage. It is naturally managed by the PowerShell and demands manual intervention for the failover. There is an inclusion of support for Azure Site recovery of this instance.

Server to Server permits both asynchronous and synchronous replication between at least two standalone servers leveraging the Storage Spaces with the shared SAS storage, ISCSI-attached LUNs and SAN. This is also managed by the PowerShell, alongside the server manager tool and demands a manual intervention for the failover.

The Key Features of Storage Replication

Simple Management and Deployment
The storage replica has a model mandate for an ease of use. The crafting of the replication affiliation between two servers demands only one PowerShell command. The deployment stretch clusters leverages the intuitive wizard in the Failover Cluster Manager gadget.

Host and Guest
All abilities of Storage Replica are in both virtualized guest and host-based deployments. This implies that the guests are able to replicate their data volumes if running on non-Windows virtualization platforms even in public clouds, so long as Windows Server 2016 Datacenter Edition in the guest is utilized.

Block-Level Replication, Zero Data Loss
With the help of synchronous replication, there is zero possibility of any data being lost. With the block-level replication, there is no probability of any file getting blocked.

User Delegation
The operators can delegate the permissions to manage the replication without being an affiliate of the built-in Administrators team on the replicated modes, hence reducing their access to the unrelated sections.

Network Constraint
The storage replica can at times be limited to the individual networks server and by the replicated volumes, with the aim of providing backup, application, and management software bandwidth.

High Performance Initial Sync
The storage replica reinforces the seeded initial sync, where there is already a subset of data on a target from the initial backups, copies, or shipped rives. The initial application can only copy the differing blocks, possibly reducing the initial sync time and regulating data with an aim of preventing the data from utilizing the limited bandwidth.

Use of SMB 3 as the transport protocol which is also supported via the TCP/IP model.

Prerequisites

Two servers with two volumes on each server or location. One location will be for storage of data and the other for storage of logs.
Volumes need to be of the same size both at the main server and remote server.
Log volumes should also be of identical sizes across the two volumes.
Data volumes should not exceed 10TB and should be of NTF
Both servers need to be running Windows Server 2016.
There must be at least 2GB of RAM alongside two cores for every server.
There must be one TCP/Ethernet connection on each of the server for synchronized replication, but most preferably RDMA.
The network between the servers with a reliable amount of bandwidth to accommodate the user’s IO write workload and an average of 5ms round-trip latency for an effective synchronous replication.

How it Works

The above diagram depicts how storage replication works in synchronous configuration.

The application will write data onto the File System volume labelled Data. This will be intercepted by I/O (input/output) filtering and be written onto the Log Volume located on the same server. This data will then be replicated across to the remote server’s log volume. When this data is written on the log volume, an acknowledgement is sent back to the primary server and to the application. On the remote server, data will be flushed from the Logs volume to the Data volume.

Note: The purpose of the Log Volume is to record and verify all the changes that occur across both blocks. Furthermore, in synchronous model configuration, the primary server needs to await acknowledgement from the remote server. If network latency is high, this will lead to a degraded network and slow down the replication process. Consider using RDMA which has a low network latency.

In asynchronous replication model, data would be written to the Log Volume located on the main server and thereafter, an acknowledgement sent to the application. Data would then be replicated from the Log Volume on the primary server to the Log Volume on the remote server. Should the link deteriorate between the two servers, the primary server will block all changes until the link is restored whereupon replication of changes will continue.

Setting Up Storage Replication

Import-module StorageReplica
Launch Windows PowerShell and verify the presence of Storage Replica Module.
Test-SRTopology -SourcheComputerName CHA-SERVER1 -SourceVolumeName f: -SourceLogVolumeName e: -DestinationComputerName CHA-SERVER2 -DestinationVolumeName f: -DestinationLogVolumeName e: -DurationInMinutes 30 -ResultPath c:\temp
Test the storage replica Volume by running the command above.
PowerShell will then generate an HTML report that will give an overview of the requirements met.
NewSRPartnership -SourceComputerName CHA-SERVER1 -SourceRGName SERVER1 -SourceVolumeName e: -SourceLogVolumeName f: -DestinationComputerName CHA-SERVER2 –DestinationRGName SERVER2 –DestinationVolumeName e: -DestinationLogVolumeName f:
Begin setting up the replication configuration using the command above.
Set-SRPartnership –ReplicationMode Asynchronous.
Run Get-SRgroup to generate a list of configuration properties. It is set to run on synchronous replication by default & Log file set to 8GB. This can be set to asynchronous using the command above.

When we head out to the remote server and open File Explorer, Local Disk E will be inaccessible, while Logs will be stored on Volume F.

When data is written on the source server, it will be replicated block by block to the destination or remote server.

Prevent Unauthorized Access to Sensitive Windows Folders!

No more unauthorized access to sensitive data
No more unclear permission assignments
No more unsafe data
No more security leaks

Get your free trial of the easiest and fastest NTFS Permission Reporter now!