Storage Replica on Windows Server 2016

The author of the article is Mikhail Komarov, MVP in Hyper-V

The purpose of this article is to tell about a new component of Storage Replica, which appeared in Windows Server vNext . The emergence of this technology was expected, since the last few years, Microsoft has been paying close attention to storage systems. The first sign was the new implementation of the SMB 3.0 protocol, which appeared with the release of Windows Server 2012 and was improved by new features for the release of Windows Server 2012 R2.







Next, in our piggy bank, add a new type of file cluster, the so-called SOFS

')





We also mention such pleasant things as inline timing, RDMA support, InfiniBand adapters, Storage Space for pooling disk pooling, Storage Tiering, which allows efficient use of a combination of SDD and HDD pools. There are already solutions of disk JBOD-shelves that can be connected directly to servers and make storage systems. There are industrial solutions Dell CPS, which use these technologies.







After all this, we could expect volume replication, as in other storage systems, and with the release of Windows Server vNext TP this was implemented.



Storage Replica is a block-level Windows volume replication technology using the SMB protocol. Currently there are two volume replication scenarios implemented: elastic cluster and replication between simple servers.











Management is implemented as follows: from the Failover Cluster Manager snap-in for an elastic cluster, as well as Windows PowerShell and WMI. Please note that only non-removable drives are supported. I would like to emphasize that Storage Replica is not DFSR, and that replication occurs at the block level. The figure below shows that the implementation mechanism for Storage Replica is below the file system, so block replication does not depend on the type of the NTFS / CSVFS / ReFS file system.







Consider the process of synchronous replication in more detail. The first step is the arrival of data on the source server. The second step is to log to a separate volume and transfer to the target server. The third step is logging on the target server. The fourth step is to transfer information to the source server about successful logging on the target server. The fifth step is to notify the application that the data has been processed. Further, at time t1, data will be written from the log volume to the data volume on both servers.







Consider the process of asynchronous replication in more detail. The first step is the arrival of data on the source server. The second step is to write to the journal on a separate volume. On the third - the notification of the application that the data is processed. The fourth step is to transfer information to the target server. The fifth step is to log the target server. The sixth step is to inform the source server about successful logging. Further, at time t1, data will be written from the log volume to the data volume on both servers.







We finish the theory and begin to move on to practice.



Let's start with the requirements.



Windows Server Edition - Datacenter Edition. Both computers must be members of a domain. GPT discs are required, not MBR. No removable media - external USB arrays, flash drives, tape drives, 5.25-inch floppy disks, etc. The same disk geometry (between logs, between data) and data partitions are also needed. Free space for logs on a Windows NTFS / ReFS volume (fixed-size log, it does not increase or decrease). No replication of% SystemRoot%, paging files, sleep files, DMP files. It is also necessary to open ports SMB, WS-MAN on the firewall.



Packet exchange delays



On average ≤ 5 ms in both directions. If you take the ideal option - the speed of light in a vacuum, then 5 ms is about 1,500 km when exchanging in both directions. In reality, fiber reduces speed by about 35%, and there are also switches, routers, firewalls, etc. The bottom line: most customers are limited to a distance of 30-50 km.



Network bandwidth



The initial requirement is a network ≥ 1 Gbps - when a node-to-node connection is established between servers (for Windows Server, 1 Gbps network cards are required). It all depends on I / O operations and channel sharing intensity (perhaps SR is not the only function that will generate traffic to the disaster recovery area). Determine the number of I / O operations (125 MB / s I / O volume = ~ 1 Gbit / s load on the network).



Log capacity and size



Flash Drives (SSD, NVME, etc.). Larger logs allow you to quickly restore the system after a major failure and switch more quickly. But the price for this is disk space.



There is a Test-SRTopology cmdlet that checks the requirements and recommendations for network bandwidth, log size, I / O operations per second, etc. Works for a specified time and creates a neat report with html recommendations.



Please note that the target volume is always disabled. Script for target-read-only or read-only volume is not used. Connect only "one to one." You can always use other replication features (for example, Hyper-V Replica for AB, and SR for AC). When you change the size of the volume replication is interrupted.



Consider a demonstration in which two identical virtual machines with the names SR1 and SR2 participated, they were members of the domain. To begin with, on each machine we enable the rules on firewalls using the following command:

Enable-NetFirewallRule -CimSession SR1,SR2 -DisplayGroup "Remote Desktop","File and Printer Sharing" 

The result of her work is given below. You can do this from the console.







Check server availability:

 ping SR2.contoso.com -4 -f -l 1472 -n 300 

In the next step, we will connect 2 disks to each server and select the GPT partition during initialization. Next, format it in NTFS and assign letters to the disks. For the demonstration, I used dynamic disks. And the disk for the magazine is limited to 15GB.







Enable the feature using the PowerShell command and reboot the hosts.

 $Servers = { } $Servers | ForEach { Install-WindowsFeature –ComputerName $_ –Name WVR –IncludeManagementTools -restart } 

Or using a graphical interface







Now enable replication using PowerShell, the wizard is only available in the version for the failover cluster.

 New-SRPartnership -SourceComputerName SR1 -SourceRGName rg01 -SourceVolumeName Q: -SourceLogVolumeName T: -DestinationComputerName SR2 -DestinationRGName rg02 -DestinationVolumeName Q: -DestinationLogVolumeName T: -LogSizeInBytes 8gb 

This command enables replication on servers SR1, SR2. Defines the Q replication volumes on which the data will lie, and also sets the volumes for the T logs and sets the log size to 8 GB.

The result of the team we see below.







I would like to note that after turning on replication, an additional section appears on the volume, as well as a new event log that contains information about replication.















This graph shows how initial initialization occurs after replication is turned on. Note the set of performance counters that are associated with replication.







For example, copy the data to the replicated volume and immediately see the network traffic.







Although the volume with the log file is partially full, there is no data visible. Use the dir command with extensions.







As we said earlier, the data server is not available on the second server. It is in RAW format and will be available after disabling or switching replication.







If there is a need to disassemble replication, remember the additional partition on the disks on the two servers and delete them.



Run DISKPART, select our disk (x, for example)

 DISKPART LIST DISK SELECT DISK X attribute disk clear readonly 

Find a partition (Y “unknown” size 512KB)

 LIST PARTITION SELECT PARTITION Y 

Checking the partition (GUID 558d43c5-a1ac-43c0-aac8-d1472b2923d1)

 DETAIL PARTITION 

Remove section

 DELETE PART OVERRIDE 

This concludes a brief overview of this technology, which appeared in Windows Server vNext.



Resources

Storage Replica in Windows Server Technical Preview