OK, I’m going to ramble just a little bit here. Before I dive deep into how I might monitor replication for a collection of Hyper-V hosts (this is without the benefits of System Center, which would be better, of course…just showing you how it works), I wanted to go over one of the awesome scenarios that companies are using Hyper-V Replica to enable.
Here in the U.S. it is now the post-Thanksgiving, Christmas season…what does that mean? SHOPPING!
Remember that Thanksgiving has a long tradition here in the U.S. of supporting retail sales – that’s why the date changed back in the last Century...to give stores more time to sell before Christmas!
Reliance on systems for price lookups, tax calculations, and credit card processing are critical, time sensitive functions that cannot be offline for long during this season, or revenue will be lost! Modern retail store locations rely on at least one server and often times multiple servers to provide these functions.
The struggle is that margins are thin in retail. Any cost must be weighted against the value it provides…so how much is the right amount to spend to protect time sensitive transaction processing?
Retailers have struggled with reducing the cost of store infrastructure for many years, and virtualization has helped by allowing multiple servers to be combined onto fewer physical servers. Really every industry with smaller, remote branch locations has similar challenges - banking, education, food service, manufacturing, distribution.
Often the next logical step in protecting processing is to introduce VM High Availability (HA) which has traditionally been delivered through clustering (with Hyper-V or VMware). The problem with HA is that it usually requires storage that can be shared between multiple physical servers…like a SAN, and that type of storage is expensive for a retail store!
It doesn’t matter what virtualization technology you use…shared storage and traditional clustering add cost and complexity to a deployment.
I’m not knocking SANs, shared storage, or clustering – I use all of them and REALLY like them, it’s just a struggle to cost justify shared storage and clustering for say 1000 sandwich shops or 100 schools in a school district. Is there enough value in the added expense?
What do retailers (and organizations with branch offices) want from clustering? They want availability. They want to protect processing from hours or days of downtime when there’s a hardware failure. They may also want the flexibility to perform planned hardware maintenance without unplanned downtime.
Clustering offers planned migration of VMs between physical servers without unplanned downtime as well as the automated restart of VMs when there’s a hardware failure (on another host), but that expensive shared storage is still a single point of failure. Yes you can throw more money at it to make it redundant, but that’s not the solution.
You can’t eliminate all risk and downtime – but you can reduce risks. The big question is how much down time could a store / branch tolerate?
What if you could move VMs between hosts with little or no downtime - WITHOUT shared storage (you know you can already with Hyper-V, right?).
Hyper-V Replica allows you to shutdown a running VM, and fail over to it’s replica with only a tiny amount of down time. That’s great for hardware related maintenance if you don’t need to Live Migrate the VM
What if you could replicate VMs to alternate hardware that could be started quickly in the event of a hardware failure WITHOUT shared storage? When a physical server at a branch goes down, what if you could start the same VMs on another host at that location in a matter of minutes without an investment in shared storage? THAT’S WHAT YOU CAN DO WITH HYPER-V REPLICA!
Remember that Hyper-V Replica is included in Windows Server 2012 / Windows Server 2012 R2 and the associated versions of Hyper-V Server (which is a completely free download!). I’ll say it again, ASNYCRONOUS REPLICATION OF VMS ON HYPER-V IS FREE! Your VMs need to be properly licensed (Windows / Linux / applications / other), but this awesome feature is built in to a completely free product!
The big differences are that you don’t have any single set of storage that needs to be connect to multiple hosts, and you don’t have cluster server watching to make sure that the VMs are available (to fail a VM from one box to another when there is a hardware failure). Because there is no cluster service using Hyper-V Replica, the VMs do not “out of the box” automatically fail over to the alternate physical host as they might with a cluster. You can certainly automate any failover if you want that to happen, but do you really need the VMs to do that? If you did, then you would deploy a cluster, right?
If you (the administrator) need to poke around and see what’s up first (as you typically would if you were performing planned maintenance or had been notified of a failure), is it really that big a deal for you to “right click” and “Fail Over” the VMs? (Note that there are a bunch of ways to failover…we’ll get to Hyper-V Recover Manager later this Winter – I hope, be patient).
Perhaps you could add a button to the store managers desktop that did the failover for them when they have an issue (you know that would be a snap to automate with PowerShell).
Back to the big question - how much down time could a store / branch tolerate? If your branch VMs were already on another server and ready to start up, is that good enough to get the operation back on line?
What about protecting data and services when the whole site goes down? There’s something that’s harder (and move expensive) to do with a cluster or VMware (ESX doesn’t come with replication).
Remember that 2012 R2 includes a tertiary replica… you can extend the replica to a third Hyper-V host that could be in back at a central data center!
OK, so that’s one of the values offered by Hyper-V Replica – rapid recovery / migration of branch services without the cost or complexity of clustering.
Can you do that with what’s included with ESXi? I think not!
I’ll get into some PowerShell tricks in my next post.