Getting started with Windows Volume Replication (Storage Replica) to Azure Configuration does it Work ? #winserv #SR #Azure #WVR #MVPBuzz

As in my previous blog post I named Storage Replication and Storage Spaces Shared nothing. This item is all about Storage Replication.

As there are many blog post all about this item I will show you not the easy part but a Hybrid Replication to Azure. As machines are getting faster in Azure I guess this will do for my Storage Replication.

Storage Replica (SR) is a new feature that enables storage-agnostic, block-level, synchronous replication between servers for disaster recovery, as well as stretching of a failover cluster for high availability. Synchronous replication enables mirroring of data in physical sites with crash-consistent volumes ensuring zero data loss at the file system level. Asynchronous replication allows site extension beyond metropolitan ranges with the possibility of data loss.

see the Windows Server Technical Preview Step-by-Step Guide for Storage Replica.

Disaster Recovery (DR) refers to a contingency plan for recovering from site catastrophes so that the business continues to operate. Data DR means multiple copies of production data in a separate physical location. For example, a stretch cluster, where half the nodes are in one site and half are in another. When using synchronous replication this is also known as a metro-cluster; when using asynchronous replication, it is often referred to as a geo-cluster.

Service level agreements (SLAs) define the availability of a business’ applications and their tolerance of down time and data loss during planned and unplanned outages. Recovery Time Objective (RTO) defines how long the business can tolerate total inaccessibility of data. Recovery Point Objective (RPO) defines how much data the business can afford to lose.

Storage Replication is:

The destination volume is not accessible while replicating

The Microsoft implementation of asynchronous replication is different than most.

SR is not DFSR

SR is not backup

SR is not Hyper-V Replica or SQL AlwaysOn

WVR is SR.

You will find many instances of the terms “WVR” or “Windows Volume Replication” in the Windows Server Technical Preview.

The Setup

The Setup between on-premise and Azure is based on a Azure VPN for Site-to-Site Described in this blog post :  How to setup Azure VPN for Site-to-Site Cross-Premises or Create a Virtual Network for Point-to-Site 

All my servers are running windows Server Technical Preview

The Nodes are named win2015-3,win2015-4 and in azure win2015-6 All the machines are domain joined and pingable

Appropriate firewall and router rules to allow ICMP, SMB (port 445) and WS-MAN (port 5985) bi-directional traffic between all cluster nodes.

A network between the two sets of servers with at least 8Gbps throughput and average of ≤5ms round trip latency when sending non-fragmented 1472-byte ICMP packets for at least 5 minutes. ( I do not have this in this configuration )

The problem is when you dan’t have a connection that is fast enough the replica will drop the connection and you will see this in the eventlog

So testing the the Line holds : But I know I’m in trouble with this.

ping win2015-6.mvp.local -4  -l 1472 -n 300

Ping statistics for

Packets: Sent = 300, Received = 300, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 4ms, Maximum = 54ms, Average = 6ms

This should be something like this:

To test If the Disk Holds use DISKSPD or copy a large file to generate some write load on the source server volume.

The goal is to keep 95th percentile latency under 50ms

My sample line diskspd.exe -c10G -d120 -t4 -o8 -h -w100 -b32K -r32k -L H:\testfile.dat > c:\win2015-3base.txt

  %-ile |  Read (ms) | Write (ms) | Total (ms)
    min |        N/A |      0.275 |      0.275
   95th |        N/A |     32.694 |     32.694

IOPS are important but latency is a true indicator of application performance.


To install All the options that are needed in the cluster you can use PowerShell or do this by hand in the GUI.

my $servers holds all the nodes and then I install the Features. ( a reboot in needed )

$Servers = ‘win2015-3′,’win2015-4′,’win2015-5′,’win2015-6’

$Servers | ForEach { Install-WindowsFeature –ComputerName $_ –Name WVR,Failover-Clustering,Multipath-IO,Hyper-V –IncludeManagementTools -restart }


Now that all the bits are in place we can create a new cluster Or if you already have a cluster you can use that one. ( see my blog post 15 minute install )

New-Cluster -Name HybridClu -Node ‘win2015-3′,’win2015-4′,’win2015-5′,’win2015-6’ StaticAddress

Configure a File Share Witness or Cloud (Azure) witness ( see my blog post Configuring cloud witness quorum Windows Server Cluster Azure Files ) 

Now that the Cluster is in place We can start with the Storage I have attached 3 extra disk to my Azure VM

And Several Disks to my on-premises Cluster nodes all small disk as I just want to test this and all is just as an Sample.

There are several options in the Configuration As shown in the Guides see the Windows Server Technical Preview Step-by-Step Guide for Storage Replica.

So this Config is not the basic and see If I can find the Borders of the Configuration. Remember IOPS and Latency is important to get this done ( Express route to the Home will be the best Christmas gift )

I build a Storage Pool off 3 disks and created here 2 disk on with the Exact same Size.

Keep in mind that the Disk needs to be GPT and you can set this in the Disk manger but also with diskpart





But This is not always  enough when you see Event ID 10381 in the WVR then you need to set Microsoft Reserved (MSR) partition

Status: Unknown NTSTATUS Error code: 0xc0530191

A serious problem has been identified with the contents of the disk partitioning layout resulting from a missing Microsoft Reserved (MSR) partition. WVR requires that the disk have an MSR partition prior to the creation of the WVR partition database. Without the MSR partition, WVR cannot create the WVR partition database which prevents the disk, or any of the partitions or volumes contained by the disk, being involved in replication. To correct the problem, the MSR partition must be created on the disk. This is typically achieved by (re-)initializing the disk. Note that initializing the disk will involve the destruction of all the contained partitions and volumes on that disk. To use the disk for WVR, the disk must have been initialized with the GPT (GUID Partition Table) layout. Once this has been done, the required partitions and volumes can be created, and the partitions and/or volumes can be provisioned for replication as normal.

So clean the partition and start over. Create Partition with MSR and GPT. Only then the Disk will work for Storage Replication ( WVR )




Create Partition MSR Size=32


So I created 4 disk with the exact same size and GPT and MSR this should do the Trick. In my case I use only 3GB disks as this is the minimal specs for most things.

Now Create and Place Holder for your Disk in the Cluster Name it and place One disk in this Role


Now the easy part just run one-liner in PowerShell you can do this in the GUI but this is not the best method now in the Technical Preview.

In PowerShell you will see Quickly if it is working

What We will need :

Two node names Source :win2015-3  and Destination : win2015-6

Create Two Replication groups Azure_group08 & Azure_group09  ( tested this a lot and broke all Replica’s )

Pick the Drive Letters

Source Data : H

Source LOG :  E

Destination Data : I

Destination LOG : W

And Pick a Logsize


To create the Windows Volume Replication all in one PowerShell

New-SRPartnership -SourceComputerName win2015-3 -SourceRGName Azure_group08 -SourceVolumeName h: -SourceLogVolumeName e: -DestinationComputerName win2015-6 -DestinationRGName Azure_group09 -DestinationVolumeName i: -DestinationLogVolumeName w: -LogSizeInBytes 2gb

This will trigger the Cluster and this will create the Groups and it will add the Log disk to the Data Disk group after a bit of ping pong with the disk they will failover and come on/offline failover the disks and the Cluster Layout will be something like this

My Resource Group Hybrid Repl and the Replication has created the WVR Azure_group09

now with all Running you can see what is my Group and Partnership




You can also reverse the Replication if needed

but looking at the Events in WVR you can see if the Replication is ok  Ensure that events 5002, 2200, 5015 , 5005, 5001, and 5009


Event logs Source and Destination

If you want to change the Logsize  “ LogSizeInBytes 2gb “ then you have to rebuild the Replica there is currently no option for that.


Last Part is the Removal of the Replica , It make sense that in the Cluster Failover manager you can delete the replica but If you do this the replica is not totally removed this is a bug. so best to remove the replica is by PowerShell.

Get-SRPartnership | Remove-SRPartnership

Get-SRGroup | % { Remove-SRGroup -Name $ }


Removing the Replica will give the disk the status Available Storage.

As I meshed up my other Replication on deleting this in the Cluster Failover Manager GUI, This is hard To fix and you have to go deep to fix this.

Diskpart is you best friend on this.

Hopefully this walk true is helpful and see what you can do with the hybrid environment. If you need more help here is the Forum

Other Options for storage Replication : While Windows “Shared Disk Failover Cluster” is not yet supported for Microsoft Azure Virtual
Machines, 3rd-party software SIOS Datakeeper can be used as an alternative:

Source :


My next blog post will be : How does DAS-only storage work in a failover cluster?  at [11:00]: ( Storage Spaces Shared Nothing )

If you want more info about Windows Server Technical Preview get here the Guides that you can use to start with the new Stuff

Guides :

Happy clustering

Robert Smit


Technorati Tags: Windows Azure,Azure File service,Windows,Server,Clustermvp,Blob,cloud witness