In this article series, I have shown you how to perform storage replication between two servers. Now, I want to turn my attention to storage replication within a failover cluster.
There are two ways to use storage replication within a cluster. Microsoft supports a stretch-cluster configuration, and it supports cluster-to-cluster replication.
Stretch clusters have existed in one form or another for quite some time now. Whereas a failover cluster typically exists within a single datacenter, a stretch cluster is a single cluster that spans multiple physical locations.
In the past, stretch clusters have been tricky to create due to the need for a cluster shared volume, and due to the need for the cluster to maintain quorum. Often times, a stretch cluster spanned two datacenters, with the cluster storage residing in a third location. The reason why this topology was used was that if the storage was located in one of the two datacenters, and that datacenter dropped offline, then the storage within the datacenter would not be accessible to the cluster nodes within the other datacenter, thereby causing the cluster to fail.
Placing the storage in its own dedicated facility effectively isolated the storage from any datacenter level failures. Even so, this particular topology was not without its drawbacks. For starters, the cluster storage could still become a single point of failure. Performance may also suffer because the storage was not in close proximity to the nodes that were using it.
The previously mentioned example is not the only way of building a stretch cluster, but it is at least one of the stretch cluster designs that have sometimes been used in Windows Server environments.
The Windows Server Storage Replica feature works well for use with stretch clusters. Storage replication eliminates the need for placing cluster storage in an independent location, and also helps to improve storage-related performance. The reason for this: Storage Spaces Direct eliminates the need for a centrally accessible cluster-shared volume. Instead, each site has its own cluster-shared volume, and changes are replicated between the two sites. In essence, this means that each site has its own cluster-shared volume that is locally within the datacenter, thereby potentially improving performance and greatly reducing the chances of storage connectivity being interrupted.
I mentioned earlier that there were a number of different ways to create a stretch cluster. It is worth noting that storage hardware vendors have supported storage replication for many years. The Windows Server 2016 approach is a good solution for organizations whose storage hardware does not natively support replication.
In order to use storage replication within a stretch cluster, there are some requirements that must be met. Among the most important of these is the Active Directory topology. The two sites need to belong to a common Active Directory forest, and the site boundaries should be defined at the Active Directory level. Incidentally, even though storage replication is a Windows Server 2016 feature, there is no requirement for the Active Directory to be operating at a Windows Server 2016 functional level.
Windows Server 2016 is required for use on the cluster nodes. Furthermore, Microsoft only supports storage replication in Windows Server 2016 Datacenter Edition. The feature is not found in Standard Edition.
Consider the number of cluster nodes
As would be the case for any other failover cluster, it is important to carefully consider the number of cluster nodes that you want to use. The stretch cluster supports as few as two nodes, or as many as 64 nodes. Even so, a two-node cluster is not suitable for anything more than a proof-of-concept deployment, because a two-node cluster would greatly limit your ability to cope with a disaster. If, for example, you had a two-node stretched cluster with one node at each site, then there would be no capacity for failover within a site, because there are no redundant nodes within the individual datacenters. At a bare minimum, your stretched clusters should have four nodes, with two in each datacenter. In a production environment however, it is usually desirable to have even more nodes.
It is important to carefully consider the number of cluster nodes that you want to use. At a bare minimum, your stretched clusters should have four nodes, with two in each datacenter.
Another requirement that must be taken into account with regard to a stretched cluster is that of network latency. Remember, in a stretched cluster, a cluster-shared volume exists in both locations, and those cluster-shared volumes are kept in sync with one another.
Windows Server’s Storage Replica feature supports both synchronous and asynchronous replication. Asynchronous replication should be used in environments in which there is high latency between the two sites. Synchronous replication requires that the round-trip latency average about 5 milliseconds. There is no latency requirement for asynchronous replication.
Synchronous replication is always preferable to asynchronous replication, because synchronous replication occurs in near real time. Even so, some administrators might be apprehensive about trying to enable synchronous replication because it is latency sensitive. Thankfully, Microsoft provides a tool that can help you to find out how well the Storage Replica feature will work in your environment, without you actually having to set up storage replication.
The Server Manager provides the option of installing a feature called the Remote Server Administration Tools. This feature has been around for many years and allows administrators to install tools such as the Failover Cluster Manager, or the IP Address Management Client. Microsoft has added a new tool in Windows Server 2016. This tool, which you can see in the screenshot below, is called the Storage Replica Module for Windows PowerShell.
You can install the Storage Replica Module for Windows PowerShell from Server Manager.
The Storage Replica Module for Windows PowerShell includes a helpful cmdlet called Test-SRTopology. When executed, this cmdlet produces a report detailing how well your organization will handle storage replication.
I will show you how to use the Test-SRTopology tool in the next article in this series.
If you would like to read the other parts in this article series please go to:
- Hyper-V and Storage Replicas (Part 1)
- Hyper-V and Storage Replicas (Part 2)
- Hyper-V and Storage Replicas (Part 3)
Photo credit: Microsoft