Good day to all!

Today I would like to tell you about a very interesting feature, which will be presented in the new version of Windows Server vNEXT, and which is already available for testing and testing in the preliminary version of Technical Preview, namely, replication at the volume level. In WS vNEXT, this feature is now called Storage Replica. What is this beast and what it is - the details under the cut.

Replication options and features

Storage Replica (Storage Replica (SR)) is a new feature in Windows Server that allows block synchronous (and in some cases asynchronous) replication at the volume level between clusters or Windows Server vNEXT servers. SMB3 protocol is used as a transport.
')
Currently supported replication options are Server-Server and Elastic Cluster (Stretch Cluster). Replication of the “Cluster-Cluster” level is not yet implemented, but is present in the plans. Since replication occurs at the block level, the mechanism does not have much to do with the type of equipment on which the file system is deployed. Replication can be both synchronous and asynchronous (currently only in the Server-Server scenario). TCP / IP or RDMA can be used as a network communication mechanism. Data deduplication and BitLocker-based encryption can be applied over the replica. This miraculous catastrophic and fault-tolerant technology miracle is being configured exclusively through PowerShell. To carry out the process, it is also necessary to have TCP 445 or TCP 5445 ports open, to be members of the same domain (the target object from this point of view is the host, and volumes are replicated between the hosts, and scenarios of replication of volumes within the same host are possible). It is also important to remember that replication is possible only for data volumes, but not for the system volume — in other words, replicating "Disk C:" does not technically work, and this technology was not developed for this purpose. This technology is designed to provide a zero level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario).

I also want to immediately note that the requirements for the channel are also present here: at least one 10 Gbit / s connection on each file server. For reliability, it would be nice to make sure that sending an unfragmented ICMP packet with a size of 1472 bytes is successful without loss during the 5-minute interval.



It is also worth noting that it is impossible to use for replication both as a target and as a source, removable media a la USB drive. You will also need permissions at the level of the built-in administrator group.
For testing purposes, you can try out all the mechanisms on a VM — just remember that virtual disks in such a scenario should be of a fixed type, and not dynamically expandable.

Configuring Server-to-Server Replication

Well, after reading the introduction to the process of configuring volume replication, let's set up replication "Server-Server". Just remind you that the server in the preview - and you should not use this mechanism for combat data now. On each member server, the “File Server” role and the “Storage Replica” or “Windows Volume Replication” functions must be installed (depending server.

After that, on one of the participating servers, execute the PowerShell cmdlet with admin rights:

New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName d: -SourceLogVolumeName e: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName d: -DestinationLogVolumeName e: -LogSizeInBytes 8gb ;
In my example, there are two servers involved: sr-srv05 and sr-srv06, a separate volume is allocated for log files (it should be one gigabyte smaller than the replication volume and source and target volumes.
To test the success of the replication setup, execute the following cmdlet sequentially on both participating servers:

Get-WinEvent -LogName *WVR/admin -max 20 | fl

The presence of events 2200, 5005, 5015, 5001 and 5009 will be a sign of success.
If you need more detailed data on counters (Get-Counter) , then here is a list of them:

• \ Storage Replication Statistics (*) \ Total Bytes Received
• \ Storage Replication Statistics (*) \ Total Bytes Sent
• \ Storage Replication Statistics (*) \ Avg. Network send latency
• \ Storage Replication Statistics (*) \ Replication State
• \ Storage Replication Statistics (*) \ Avg. Network Receive Latency
• \ Storage Replication Statistics (*) \ Last Recovery Elapsed Time
• \ Storage Replication Statistics (*) \ Number of Flushed Recovery Transactions
• \ Storage Replication Statistics (*) \ Number of Recovery Transactions
• \ Storage Replication Statistics (*) \ Number of Flushed Replication Transactions
• \ Storage Replication Statistics (*) \ Number of Replication Transactions
• \ Storage Replication Statistics (*) \ Max. Log Sequence Number
• \ Storage Replication Statistics (*) \ Number of Messages Received
• \ Storage Replication Statistics (*) \ Number of Messages Sent
• \ Storage Replication Application I / O Statistics (*) \ Number of Received App Write Irps
• \ Storage Replication Application I / O Statistics (*) \ Avg. Number of Irps / IoContext
• \ Storage Replication Application I / O Statistics (*) \ Avg. App Write Latency
• \ Storage Replication Application I / O Statistics (*) \ Avg. App Read Latency

It is also worth adding that in Windows Server Preview it is impossible to set up replication on volumes where it was and then it was disabled.

The processes of displaying the course of events may be inaccurate and not display the full reality - it is better to look at the counters.

Well, in principle - that's all!

Basic and simple configuration of volume replication in Windows Server looks like this!
Try and see you again on the IT front.

With respect,

Fireman
George A. Gadzhiev