Getting started with Storage Replica in Windows Server 2016

So Storage Replica is a new feature which will make its introduction in Windows Server 2016 (Datacenter only!) but it is a volume based storage replication feature which can work in two manners, either synchronous or asynchrounous. This feature also opens up for a bunch of different use cases, the biggest one is the ability to now deploy streched cluster!

Synchronous

Will looks like this, when an application will write to a Storage Replica volume the SR feature will write it into log files (on a dedicated log volume) on the primary host. When the data is written to the log the data will also be replicated across to the other host/cluster in the setup, where it will also be written to the log volume. When the data is written to the remote host, there will be sent an acknowledgement back to the primary host and back to the application, and allows is to continue its buisness.

image

Using synchronous replication has some recommendations in terms of infrastructure.
Network:

  • Bandwidth! Remember that if you do not have sufficient bandwidth between sites, it will become the bottleneck and slow down the services running. Even if the compute / storage power in the primary site has more then enough horsepower.
  • Latency! should be no more then 5 MS latency

Disks and Storage, for a storage replica setup regardless of deployment mode there are some disk/storage requirements as well

  • Four disks are required: a source data disk, a source log disk, a destination data disk and a destination log disk.
  • The data disks must be formatted as GPT, not MBR.
  • The data disks must be of identical size.
  • The log disks should be of identical size.
  • The log disk should use SSD storage using mirrored Storage Spaces, RAID 1, RAID 10 or similar resiliency.
  • The data disks can be on HDD, SSD or tiered, using mirror Storage Spaces, parity Storage Spaces, RAID 1, RAID 10, RAID 5, RAID 50 or equivalent configurations.
  • The data disks should be no larger than 10TB. We recommend testing with than 1TB to reduce initial replication time.
  • The log volumes must be at least 10% of the size of the data volumes or at least 2GB, whichever is larger.

So why should the log disks be SSD?? Think about it when we get outages having a fast log disk allowes for faster recovery. Also larger logs allow faster recovery from larger outages and less rollover, but cost more disk space!

Asynchrounous

now asynchrounous works almost the same way, but with a major difference. Which is that data is written locally and after is has been added to the log it will then send an acknowledgement back to the application running, and then data will be replicated across to the other site.

image

So this does not have the same network requirements as syncronous because for instance if the link goes down, applications will still be able to run (The log file is going to grow, but when the link comes back up again it will be able to replicate again.

Now Storage Replica can also be deployed in different fashions depending on the need. For instance we can have

  • Server-to-server replica
  • Server-to-self (From one Volume to another)
  • Cluster-to-cluster (Two seperate clusters, DR scenario)
  • Streched Cluster (Single cluster, automatic failover)

So how to setup this stuff? As an example I have two virtual machines (server-to-server replica)

First of we need to install the server roles on each of the servers

$Servers = ‘DEMO01′,’DEMO02’

$Servers | ForEach { Install-WindowsFeature –ComputerName $_ –Name Storage-Replica,FS-FileServer –IncludeManagementTools -restart }

Then make sure that the disks are configured as they should as pr requirements further above. Simple way is to use diskpart to check if they are GPT.

image

Then after the disks are configured as they should (Note that they should have a form of redundancy!)

There is an cmdlet for storage replica that we are going to use which is Test-SRtopology, which is going to perform test against the different disks we are going to use.

Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeNames e: -SourceLogVolumeName f: -DestinationComputerName SR-SRV06 -DestinationVolumeNames e: -DestinationLogVolumeName f: -DurationInMinutes 30 -ResultPath c:\temp –verbose

NOTE: If you encountering any issues, reference the KB article here –> https://technet.microsoft.com/en-us/library/mt126101(v=ws.12).aspx

image

After the test is complete we can configure the Storage replica partnership.

New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName e: -SourceLogVolumeName f: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName e: -DestinationLogVolumeName f:

After the configuration you can use the command Get-SRgroup to see the properties of the replication

image

What we also will notice now is that that the log file disk will be filled up with about 8 G (Which is the default size of the log file) and note also that the replication mode is synchronous
NOTE: If you want to setup Asynchronous use the ( New-SRPartnership –ReplicationMode Asynchronous)
(Primary node)

image

On the secondary node however, you will notice that the data disk is unaccessable

image

And if I place data on the E: volume on the primary node, it will automatically get replicated across to the other side. Now If I eventually remove the replication group

image

I will get access to my disks again with the replicated data intact on the E: folder on both nodes.

And eventually you  will need to clean up the metadata which before we needed to use diskpart, but now we can use the commands

Clear-SRMetadata -AllPartitions

So stay tuned for more about cluster setup and advanced configurations