The webpage of Stoyan Varlyakov

So Hyper-V boosts another neat feature, also known as replicas.

Why would one need that? How exactly does it differ from HA Cluster and Backup?

I’ll try to answer those questions in a really quick-and-dirty way.

HA vs Replicas

HA means Clustering. Clustering means CSV (or SMB 3.0 file shares, but for the sake of full cluster solution, CSV is the way to go). This all copes well with the enterprise business model, where SAN is already in place or still something that can be bought. But for small/medium firms in the Bulgarian reality, where resources are scarce and requirements ridiculously high, SANs are not always preferred. Sometimes the OS Licenses needed for a HA deployment alone will cost more than the budget for the project.

So what can we do to avoid that? Microsoft aimed replication technology for data center fail-over functionality, but there is this aspect which can cope quite well in small deployments – replication.

What does this do? Once replication is enabled (very good Technet article ) you will see the VM in both primary and secondary Hyper-V hosts.

Here is a quick overview:

Primary host:

Secondary host:

But if you try to start the machine on the secondary replica server, you will get this error:

Over LAN environments, replication speed is nothing short of impressive. I managed to saturate 1 Gb dedicated NIC for Replication on a very outdated hardware (AMD opteron dual core) with less than 30% cpu util.

Now this is not miraculous, but still quite a good figure.

From my observations, I can see that replication cycles occur every 5-10 minutes and for file-share servers this is near-CDP performance “out-of-the-box”. A further advantage for the Replication over traditional CSV is that one could keep a few versions back (thanks to VSS) and have an option to quickly bring a central file server back in production from a different server or even site within minutes.

Imagine you have 1,5 Tb of data and you need to be able to provide 99.999% uptime? On the first crash/outage of HW and the need to recover from a backup, you are already missing your SLA. So you have no options but to replicate.

If you are talking SQL however, you have no options but to run HA cluster OR use the standard master-slave SQL model. I am strongly advising against replication implementation in a SQL environment.

Again from the perspective of a small/medium company, it is doable to host the SQL on Microsoft Azure for example and delegate the management to the “cloud guys”. Why? Just calculate 20 perpetual SQL Standard 2012 licenses and you will see what will that cost you.

Again it always comes down to this – budget, goals, implementation.

But because Hyper-V server 2012 is freeware, and you don’t need to pay OS*nodes licesnes, you could easily build a small/medium cluster-like solution using really way less single points of failure while retaining performance.

Replicas vs Backup

Now I’ll start this with the following statement, so take it seriously:

Nothing is more important than a good backup

Snapshots and replica versions are not a backup, and they will never be. A backup is transportable, can be stored off or online, can be restored on a different machine etc….

Replicas offer some of the functionality of a backup, because they will provide independent snapshots, that are accessible up to a certain version back in time. But they are not transportable, nor to be stored offline, so you might use replicas for quick restore of the service, or VSS like primary recovery point for non VSS enabled guests (linux), but replicas alone should not be counted on for data recovery.

Replicas will do the job for a disaster recovery point in case something happened with the physical host. But in case of a VM corruption, it is highly likely that the problem would have replicated too, so a good backup strategy is a must.

Ok, as I said this one will be a quick one, but keep an eye for an update on the topic, as I dig in further into replica options and Powershell scripting on Hyper-V core hosts.