Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge
Find out how HCI cuts down virtualization costs and complexity

How to Protect your Data on Nano Server using Storage Replica?

  • October 10, 2016
  • 23 min read
Charbel Nemnom
Microsoft MVP Charbel Nemnom is an accomplished technical professional with over 13 years of broad IT project management and infrastructure experience serving on and guiding technical teams to optimize performance of enterprise systems. He has practical knowledge of complex systems builds, network design and virtualization. Charbel has extensive experience in various systems, focusing on Microsoft Cloud Platform, Hyper-V, Datacenter Management, Cloud Computing, security, data protection, and many types of monitoring tools as well as a solid knowledge of technical reporting.
Microsoft MVP Charbel Nemnom is an accomplished technical professional with over 13 years of broad IT project management and infrastructure experience serving on and guiding technical teams to optimize performance of enterprise systems. He has practical knowledge of complex systems builds, network design and virtualization. Charbel has extensive experience in various systems, focusing on Microsoft Cloud Platform, Hyper-V, Datacenter Management, Cloud Computing, security, data protection, and many types of monitoring tools as well as a solid knowledge of technical reporting.

sim card

Introduction

With the release of Windows Server 2016, there’s a lot of new features that have been added to increase availability and security. One hot feature that will add a lot of benefits for small, medium and enterprise business environments is Storage Replica (SR). Be sure that’s going to help you in your Disaster Recovery Plan and protect your data against catastrophic losses.

A while ago, I wrote a step by step blog posts around Storage Replica based on Windows Server 2016 Technical Preview 4. Please make sure to check them before you continue reading this post.

https://www.starwindsoftware.com/blog/how-to-configure-storage-replication-using-windows-server-2016-part-1

https://www.starwindsoftware.com/blog/how-to-configure-storage-replication-using-windows-server-2016-part-2

There are a lot of enhancements and additional features that have been added to Storage Replica since Windows Server 2016 TP4.

In this article, I will cover all the SR features that will be shipped in Windows Server 2016 at GA including how to protect your data with Storage Replica on top of Nano Server.

Storage Replica in Windows Server 2016

The main purpose of SR is to protect your data and allow you to survive for disasters, in other term, it’s referred to Disaster preparedness’. According to Wikipedia, Disaster preparedness refers to measures taken to prepare for and reduce the effects of disasters. That is, to predict and, where possible, prevent disasters, mitigate their impact on vulnerable populations, and respond to and effectively cope with their consequences.

Storage Replica supports Synchronous and Asynchronous replication either in a short distance like between buildings on the same campus or in a long distance like different neighborhood in a city, or longer distance like different county in a state, or even longer distance like different countries.

Storage Replica will help you to set your Recovery Point Objective (RPO) to zero data loss with Synchronous replication, or Asynchronous replication if you can tolerate to lose some amount of data. Storage Replica is a block-based replication technology, and the replication is continuous all the time compared to other replication technology in the market today.

Storage Replica in Windows Server 2016 will support the following four scenarios:

  • Storage replication in a stretch cluster. Stretch cluster scenario is a single cluster as showing in the following diagram, the cluster could be stretched across two different geographical locations and using Asymmetric shared storage such as (SAN, iSCSI, Shared SAS with JBODs). As of this writing, stretch cluster with Storage Spaces Direct (S2D) is not supported yet, this is coming in future updates. The Synchronization could be Synchronously and An important point to mention is, even if you choose to replicate Synchronously, the initial synch will be Asynchronous until the replication is completed, thus will avoid performance impact on the primary site. The management of stretch cluster will be with PowerShell, with Failover Cluster Manager or with Azure Site Recovery (ASR). ASR will orchestrate everything for you. As of this writing, ASR is in preview mode, and how much will cost if you want to use ASR? It’s free! Yes, it’s totally free.

Scretched cluster

  • Cluster-to-cluster storage replication. Cluster-to-cluster scenario is a two separate two nodes clusters as showing in the following diagram, the two clusters could be in two separate geographical locations, and each cluster in each location has its own Symmetric shared storage such as (SAN, iSCSI, Shared SAS with JBODs including Storage Spaces Direct). The Synchronization could be Synchronously and Asynchronously. The management of cluster to cluster will be with PowerShell, Failover Cluster Manager, System Center Virtual Machine Manager or with Azure Site Recovery (ASR). ASR will orchestrate everything for you. As of this writing, ASR is in preview mode, and it’s totally free.

cluster to cluster image

  • Server-to-server storage replication. Server-to-server scenario is a two different servers as showing in the following diagram, they don’t need to be clustered, the two server could be in two different geographical locations or in the same location and can use any type of storage such as (Raid controllers, Storage Spaces, etc.). Server-to-server could be physical or virtual machine. The management of server to server will be with PowerShell only.

Server to server image

  • Server-to-self to replicate between volumes. Server-to-self scenario is to replicate (copy) from one volume to another volume on the same server, they could be two different media type. The primary scenario is, if you have a large amount of data, you can do the initial Synch locally, and then take the drives out and ship them to the other location and continue the replication from there, this is called Seeded Sync. The second scenario is, if you want to seed data to a different volume that you don’t want to replicate, why do you want to do this? because Storage Replica is so much faster than Robocopy. How much faster? For more information, please check the following article written by Ned Pyle (Principal Program Manager for Storage Replica):

https://blogs.technet.microsoft.com/filecab/2015/07/09/storage-replica-versus-robocopy-fight/

The management of server to self will be with PowerShell only.

Server to itself image

Note: As of this writing, Cluster to Server is not a supported scenario.

Storage Replica features in Windows Server 2016

In Windows Server 2016, Storage Replica will support the following features:

  • RoCE V2, iWARP and InfiniBand RDMA networks are supported.
  • Network Constraint (you can control which Networks are used for Replication Traffic even down to the volume).
  • Integrated Storage Replica with Storage Spaces Direct Cluster Health service.
  • Delegation (delegate access by adding users to the Storage Replica group without being an Administrators on the server).
  • Thin provisioning storage is supported.
  • Resize of Data Volumes (grow only) that are in a Replication.
  • Resize of Log Volumes (grow and shrink) that are in a Replication.
  • Change from Synchronous to Asynchronous Replication and vice versa without breaking the storage replication.

Infrastructure Overview

 We have the following servers installed in our environment:

  • Domain controller, DNS, DHCP.
  • Storage Space Direct Nano Cluster A “NANOS2D-SR-A” and Cluster B “NANOS2D-SR-B“, each S2D cluster has the following configuration:
    • 4 Nodes
    • 4 X SSD = 960GB (Cache)
    • 4 X HDD = 2TB (Capacity)
    • Storage Net1 = 10.11.0.X/24
    • Storage Net2 = 10.11.0.X/24
    • StorageReplica Net = 10.13.0.X/24
    • Management Net = 172.16.20.X/24
    • Cluster and Live Migration using IPv6 network
    • 4 Cluster Data Volumes @ 3TB each
    • 4 Cluster Log Volumes @ 13GB each

Requirements

There are some requirements we need to be aware of before start using SR:

  • You need to have two volumes available on each location, one for data and one for logs.
  • Log and Data Volumes need to be configured as GPT and be the same (identical) size at the source and destination as shown in the following screenshot.
  • The log volume must be at least 8GB. The log volumes should use flash-based storage, such as SSD or NVMe.
  • Data volumes should not be higher than 10 TB.
  • Windows Server 2016 Datacenter Edition as the source and as the target as well.

Failover Cluster Manager

In this example, we will demonstrate Cluster-to-cluster storage replication scenario on top of Nano Servers.

Install Storage Replica on Nano Server

Before you start installing Storage Replica on Nano Server, you need to make sure that the Storage package (Microsoft-NanoServer-Storage-Package) is already added to the Nano server image.

To install Storage Replica feature including the management tools, open Windows PowerShell from a management machine and run the following command:

In this example, we assume that the management machine is joined to the same domain as Nano Server, otherwise, you want to set Windows Remote Management on the management computer by running the following command:

Test Storage Replica on Nano Server

After we have installed SR feature on Nano server, you can start testing Storage Replica to determine if you meet all the Storage Replica requirements.

In order to do so, you need to do the following on each cluster:

1)
On Cluster A, you need to move all available storage to NANOS2D-SR-A01 (in this example).
2)
Click Create Empty Role in the Roles section of Failover Cluster Manager.
3)
Move the empty New Role to NANOS2D-SR-A01.
4)
Assign all online storage to that empty role named New Role as shown in the following screenshot and then change drive letter of the volume.

Datadisk information

5)
On Custer B, you need to move all available storage to NANOS2D-SR-B01 (in this example).
6)
Click Create Empty Role in the Roles section of Failover Cluster Manager.
7)
Move the empty New Role to NANOS2D-SR-B01.
8)
Assign all online storage to that empty role named New Role as shown in the following screenshot and then change drive letter.

DataDisk information

Now that you have mounted all your storage with drive letters, you can evaluate the cluster with Test-SRTopology, and because Test-SRTopology cmdlet with Nano Server requires remote script invocation with CredSSP, thus Test-SRTopology requires to run locally on the source Nano server.

In order to enable CredSSP on Nano server and on the management machine, you need to run the following commands (through a remote PowerShell Session):

When CredSSP is set, you can now run Test-SRTopology locally on Nano Server through a remote PowerShell Session by running the following command:

The Storage Replica Test Report will look something like this:

Storage Replica Test Report

As you noticed, I have two warnings around Physical Memory Requirement. The Total physical memory available on NANOS2D-SR-A01 is 2GB. Though that meets the minimum physical memory requirement (2GB) to deploy Storage Replica, however, it is recommended that the system has at least 4GB of physical memory for optimal Storage Replica performance.

Configure Cluster to Cluster Replication

After we successfully ran Test-SRTopology, we can start setting up our replication configuration.

Before you create the replication, you need to do the following on Cluster A and on Cluster B:

1)
Remove all the storage data and log disk(s) from the “New Role” that we created in above step to test SR topology.
2)
Remove the “New Role” from each cluster.
3)
If you have more than one Log disk, please make sure to assign each one with a drive letter on each cluster.
4)
Add each data disk to Cluster Shared Volumes. You can use the following PowerShell command to automate the process. In this example, I have four data volumes.

5)
Grant Cluster A full access to Cluster B by running the Grant-ClusterAccess cmdlet below on any node in the S2D Cluster A.

6)
Grant Cluster B full access to Cluster A by running the Grant-ClusterAccess cmdlet below on any node in the S2D Cluster B.

7)
Last but not least, you can configure the cluster-to-cluster replication by specifying the source (CSV) and destination (CSV) volumes, the source and destination log disks, the source and destination cluster S2D names, and the log size by adding -LogSizeInBytes parameter. If you don’t specify the Log Size, the default will be 8GB. Open Windows PowerShell and run the following script using a remote management computer.

In this example, I am configuring the cluster replication for three CSV volumes.

The output in Failover Cluster Manager will look something like this:

Cluster A:
Replication information

Cluster B:

Replication information

As you noticed, the log volume has been brought in as a Clustered Shared Volume automatically as part of creating this new partnership.

8)
To get replication source and destination state, you can use Get-SRGroup and Get-SRPartnership as showing below:

The output will look something like this:

PowerShell command

9)
After we have successfully configured the cluster to cluster replication, you can start creating virtual machines on the source cluster. The following script, will help you to create three clustered virtual machines on Cluster A and distribute them across three nodes, and each VM will be placed on different Clustered Shared Volume as well.

This example assumes that you already have the VM images ready and copied to the CSV volumes.

The output in Failover Cluster Manager will look something like this:

Roles window

Validate Cluster to Cluster Replication

After we have successfully configured the cluster to cluster replication, you can start verifying the replication on the source and destination Nano S2D clusters.

1)
To determine the replication progress, you can run the following command on the source cluster, in my case it’s Cluster A.

The output will look something like this:
PowerShell command

2)
To confirm if the replication has been completed, you can run the following command targeting the destination cluster and look for event ID 1215.

The output will look something like this:

PowerShell command

3)
If you want to reverse the direction of the replication, so the destination Cluster B will now be the source and the data volume will be accessible, the source Cluster A will be the destination and the data volume will NOT be accessible. You can use the following script to do so:

The output in Failover Cluster Manager for Cluster B will look something like this:

output in Failover Cluster Manager

4)
If you want to reverse back the direction of the replication, you can use the following script:

Conclusion

Congratulations! you have successfully configured Storage Replica using cluster-to-cluster Storage replication on top of Nano Server and accomplished the following tasks:

1)
Created a replication partnership between Cluster A and Cluster B.
2)
Created three virtual machines on top of Cluster A.
3)
Validate the cluster replication.
4)
Reversed the replication from Cluster B and Cluster A and vice versa.

Until next time…

Thanks for reading!

Related materials:

Tags
Found Charbel’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!