Microsoft introduced the concept of replicas into Hyper-V in Windows Server 2012. At the time, Hyper-V replication provided a way of replicating virtual machines (or virtual hard disks) from one Hyper-V host to another. At the time, the replication process was somewhat limited, and it was a bit buggy. Replicas would sometimes fall out of sync, and in some of those cases the only way to reestablish synchronization was to delete the replica and start over.
Over time however, Microsoft’s replication engine got a lot better. Microsoft eventually fixed the replica synchronization problem, and they introduced the concept of extended (three way) replicas in Windows Server 2012 R2.
All of that is great, but Windows Server 2016 brings us a new form of replication – storage replicas. Unlike the Hyper-V replica feature found in Windows Server 2012 and 2012 R2, the storage replica feature is not actually a Hyper-V feature, but rather a Windows Server feature. Even so, it seems to work well with Hyper-V. Incidentally, the Hyper-V replication feature still exists in Hyper-V 2016.
The storage replica feature is exactly what its name might lead you to expect. It refers to the operating system’s ability to clone storage volumes in a way that allows those volume copies to be used by multiple computers. Storage hardware vendors have offered such capabilities for years, but Windows storage replication occurs at the operating system level, without the need for hardware level replication support. The really interesting thing about the way that Microsoft has chosen to implement its storage replica feature, is that replication utilizes SMB.
Microsoft currently supports three different architectures for replicated storage. The simplest of these architectures is server to server. This architecture replicates one server’s storage to another server. The replication process can occur synchronously or asynchronously.
Before I move on and talk about the other two synchronized storage architectures, I want to take a moment and answer one pressing question. Namely, what is the benefit to using replicated storage? The main benefit is business continuity. An organization might for instance replicate a mission critical server’s storage volume to another server in another city. That way, if something were to happen to the organization’s primary datacenter, the replicas could be used to run the business.
This brings up a couple of key points. First, storage replicas do not provide automatic failover in the case of disaster, at least not when server to server replication is being used. It is possible to fail over to a replica, but doing so is a manual process when server to server replication is used.
The second key point that I need to mention is that server to server replication is not a suitable option for making storage contents available to branch offices. The reason for this is that destination volumes are accessible only to the replication process. When replication begins, the destination volume is dismounted, meaning that there is no way for users to read from or write to the volume. As such, server to server storage replicas cannot be used to set up storage mirroring such that branch offices have locally accessible copies of storage arrays that are mirrored from the main office.
A second type of storage replication that is supported within Windows Server 2016 is cluster to cluster storage replication. As its name states, this type of replication allows for the synchronous or asynchronous replication of a cluster shared volume.
The first thing that you need to understand about cluster to cluster replication is that it is not a type of stretched cluster (I will talk about stretched clusters in a moment). Instead, cluster to cluster replication provides a way of achieving cluster redundancy. As you will recall, server to server storage replication essentially results in the creation of a standby server that can be brought online in the event that something happens to the primary server. Cluster to cluster storage replication works similarly. The only difference is that instead of replicating a single server, Windows replicates an entire cluster. It is important to understand however, that cluster to cluster replication is designed to replicate the cluster shared volume, not the cluster nodes. As such, you would have to deal with node redundancy separately.
The third type of storage replication that is natively supported by Windows Server 2016 is a stretch cluster. A stretch cluster is simply a Windows failover cluster that spans more than one site. For instance, half of a cluster’s nodes might exist in Daytona, while the other half exist in St. Augustine.
From a Windows storage replication standpoint, stretch clusters are unique in that they make up the only type of native storage replication that does not require manual intervention for failovers. If for example, the previously mentioned datacenter in Daytona were to drop offline, but the St. Augustine datacenter were still functional, then clustered resources (the highly available workloads) could automatically fail over to the St. Augustine datacenter.
Notice how I phrased that? It is the clustered resources that fail over, not the cluster itself that fails over. The reason for this is that in this situation, we are not failing over to a redundant cluster. The nodes in Daytona and the nodes in St. Augustine are all part of the same cluster.
So where does storage replication come into play for a stretched cluster? Well, imagine that this fictional organization’s primary datacenter was in Daytona, and that the Daytona datacenter contained all of the storage for the cluster. If the Daytona datacenter were to drop offline, then the cluster storage would also fail. It wouldn’t matter that the cluster nodes in St. Augustine were still running because those nodes would be unable to communicate with the cluster shared volume.
Storage replication solves this problem by replicating the cluster shared volume to the secondary datacenter. If a datacenter level failure were to occur, then the remaining datacenter would have access to a local copy of the cluster shared volume.
Conclusion
As you can imagine, storage replication provides an opportunity for smaller organizations to achieve disaster recovery capabilities that were previously out of reach. In the next article in this series, I will show you how to set up storage replication, and I will talk about how storage replication can be used with virtualization.
can we use storage replica between two HyperV Machines? if yes, is it work all vms properly from the replicated HyperV machine. In HyperV replication, there is no synchronous replication.
I have never tried it, but I am guessing that you probably can’t do it. Each VM needs to have exclusive control over its own VHDX files.