This post is about Microsoft Storage Replica – a disaster recovery tool, introduced by Microsoft in Windows Server 2016. It is a part of series about this technology, which is all featured on this blog. Basically, the post is a practical guide for building a “Shared Nothing” Scale-Out File Server, prepared by StarWind engineers after they did it themselves. The “Shared Nothing” is an architecture, which implies that each node is self-sufficient and completely independent, which makes the system more reliable. It got its name because the nodes don’t have a shared storage at all, moving closer to eliminating the single point of failure. The architecture is almost infinitely scalable, becoming popular with use cases where unpredictable and explosive growth is typical.
2nd Test Scenario – This time we wanted to configure and run Storage Replica in Windows Server Technical Preview, but using SOFS role. Having encountered the same things we had with the 1st scenario, we formed this report – have a look…
Storage Replica: “Shared Nothing” Hyper-V Guest VM Cluster
Storage Replica: “Shared Nothing” Hyper-V HA VM Cluster
Storage Replica: “Shared Nothing” SMB3 Failover File Server
Introduction
As soon as Microsoft introduced Storage Replica, we decided to check if it’s true that convenient (to get detailed info, try these links: http://technet.microsoft.com/en-us/library/dn765475.aspx and http://blogs.technet.com/b/filecab/archive/2014/10/07/storage-replica-guide-released-for-windows-server-technical-preview.aspx). Microsoft claims it can create clusters without any shared storage or SAN. In order to test this interesting feature, we decided to try Storage Replica with Microsoft Failover Cluster. We chose the Scale-Out File Server role for this example.
Content
A total of 4 servers are used in this configuration:
- First cluster node for Storage Replica
- Second cluster node for Storage Replica
- The server with the MS iSCSI Target, which provides iSCSI storage (not shared – for the sake of testing the capabilities of Storage Replica) for the cluster nodes. We also have to create SMB 3.0 share to use as a witness (because Storage Replica cannot fulfill this task).
- Server with the Hyper-V role.
Cluster nodes are first joined into the domain.
Note: Though the manual says that SSD and SAS disks are supported for Storage Replica, I couldn’t get them connected. As the same thing went with virtual SAS disks, emulated by Microsoft Hyper-V or VMware ESXi, I tried to connect the iSCSI devices created in the MS Target. It seems like the only option that managed to work somehow.
I’m starting MS iSCSI Target on a separate machine and create 2 disks for each node (4 disks total). As this is not a shared storage, the first and the second disks are connected to the first node, while the third and the fourth – to the second node. One disk from the first pair will be used as a replica source, while the other one – as a source log disk. On the second pair, the disks will be respectively – replica destination and destination log. The log disk must be at least 2 Gb or a minimum of 10% of the source disk.
The screenshot shows the two 35 Gb disks, created for source and destination, as well as two 10 Gb disks for the source log and destination log.
Now we’re all set.
Connecting the devices through the initiator on both the nodes, where I’m going to test Storage Replica. Initializing them, choosing GPT (this is important!) and formatting the disks. For both the nodes, I choose the same letters (this is important too!).
Using Add Roles and Features wizard, I’ll add Failover Clustering, Multipath I/O and Windows Volume Replication on the nodes.
Reboot. After it’s complete, I will create a cluster.
Going to the Storage->Disks in the cluster, adding disk by clicking Add Disk. Here’s what we see in the next window (2 disks on each node). If the replica destination node is set as the disks owner, change the owner to the replica source node.
Adding source disk to Cluster Shared Volumes.
Setting the owner of the destination disk as the disk owner here.
Now we can begin disk replication.
Select the log source disk for our replica in the appearing wizard.
The next step is selecting the replica destination disk.
Note: if you don’t see the disk, it means you didn’t set the right owner in the previous steps.
Selecting the disk for log-disk replication as well.
Now we’ll synchronize the disks. As the data isn’t synced, we’re selecting the second option.
The next step will display our configuration – a good time to check it.
Now we’re going to create the replica.
Done – replica is successfully created.
Now we’ve got our replica.
Adding the Scale-Out File Server role.
Select File Server
Set the file server type as Scale-Out File Server for application data
Adding a share to our File Server.
Selecting SMB Share – Applications
Select the volume on the Storage Replica (NOT the log-disk).
Name the share.
If required – go through additional settings.
Again, if required, you can manage permissions for access.
Having checked everything, click Create.
Wait through the share creation process and close the wizard.
Hyper-V configuration.
Let’s take a Hyper-V server and create a virtual machine. Then we place the VM on the share created earlier in SOFS.
Selecting the generation.
Assigning the memory.
Configuring the networking here.
Creating a new virtual disk for the VM, setting the share on SOFS as location.
Select the OS installation method.
Having checked everything, click Finish.
Now we’re starting the VM and installing the OS, improving the settings if needed.
If one of the cluster nodes involved in Storage Replica “disappears”, the VM won’t “feel a thing” and works normally.
Conclusion
Basically, everything worked well. Transparent failover occurred and the operation wasn’t disrupted.
