Hi Stephen,

>>>Not only does this increase the amount of VHD storage space required, but the level of disk IO goes through the roof making server performance unacceptable.

Replication engine just “tracks” the changes on all VHDs. Think of the replication engine running as a TSR program. Tracking the change in TSR mode does not require much I/O. But, of course, you will see performance issues if there are a number of changes taking place at the same time for multiple VHDs. That is acceptable since the current version of Replication Engine does not implement the “multi-threading” concept.

Thanks!
Nirmal

Simply put, I’ve found that replication IO speed necessary to keep an acceptable level of server performance negates the use of a couple of cheapo servers.

Consider how this mechanism works – each replicated VHD snapshots, then the snapshots are copied to the replicated peer host, then each peer host merges the snapshot. Rinse and repeat every 5 minutes for each guest.

Not only does this increase the amount of VHD storage space required, but the level of disk IO goes through the roof making server performance unacceptable. End users using the services provided by these replicated guests would experience pauses or lags every few minutes. Yes, this is even after trying every hyper-v / replication performance tweak I could find – Jumbo frames, ReFs file systems, non-replicating VHD’s for swap & temp files, etc, etc.

Try snapshotting a few VHD’s on your guest, and then merge them all concurrently while using your guest to get an idea of what the performance penalty is like.

Of course, if you were able to dedicate one spindle to each one or two VHD’s or had a super fast RAID array, performance could be acceptable. But then there goes your cheapo servers.

In the end having a duplicate cheapo server on standby, ready to restore a backup made by a strong backup product such as Altaro backup is a much better solution.

Stephen

Hi Stephen, Thank you for reading the article!

Yes, it is possible. I will cover your scenario in part III of this article series.

Stay tuned!

Thanks!
Nirmal

With Server 2012 installed on both, I’d like server #1 to run several virtual machines, and have them replicate to server #2. On server #2, I’d like to run several different virtual machines and have them replicate to server #1.

If one of the servers should fail, I could light up the replicated virtual machines on the remaining server, and have all of the virtual machines up and running. Sure performance may be constrained if this occurs, but this is far better than being down.

Is this possible??

Thanks,
Stephen

Thanks Brian for the feedbacks!

I’m going to address your queries/feedbacks in the Part III of this article series!

Cheers,
Nirmal

I would add an addendum that the replication target server can ALSO run only Hyper-V Server 3.0 – the free hypervisor only system that Microsoft shipped concurrently with Server 2012. I have this configuration in production.

Because there is no requirement for similar hardware for replication to work, only sufficient storage, this new feature means even the SMALLEST small business can use advanced disaster recovery capabilities without a huge increase in hardware and licensing costs.

I would suppose that Hyper-V 3.0 to Hyper-V 3.0 replication would work, as well, but I have not tested that configuration. Since you have to buy the Server 2012 licenses anyway, the benefits aren’t apparent to me.

I would also note that self-generated SSL certificates work perfectly between non-domain (workgroup only) Hyper-V servers.

Finally (I can’t remember WHERE I picked this up, or I would give attribution) – put your VM pagefiles on a separate partition/VHDX and don’t replicate them. The traffic from pagefiles is NOT WAN friendly.

Regards,
Brian