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.
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 volumes have to be the same 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.
- It is recommend testing with than 1TB to reduce initial replication time, but it can be as large as we want as long as we have bandwidth and I/O to handle our requirements.
- The log volumes should be atleast 8 GB (larger for longer outtages or it can be as small as 512 MB, but by default it is 8 GB
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! and of course the SSD will in case act as a write cache for all incoming I/O to the storage.
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.
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.
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
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
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)
On the secondary node however, you will notice that the data disk is unaccessable
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
I will get access to my disks again with the replicated data intact on the E: folder on both nodes.
Now if it by chance get broken the replication and you need to remove the metadata now we can use the command
Clear-SRMetadata -AllPartitions
So stay tuned for more about cluster setup and advanced configurations