Month: May 2012

I must be nuts; we’re a nearly month from the release candidate and I’m attempting to blog on this stuff

I’ve been thinking a lot about DR and how to approach it with Windows Server 2012 Hyper-V.  There is no one right solution.  In fact, we have lots and lots of options thanks to VMs just being files.  Yup, thanks to VHDX scaling out to 64 TB, the last reasonable reason to use passthrough disk (other than to get that last 2 or so percentage points of performance) are dead.  That makes even the biggest of VMs “easy” to replicate.

Let’s look at 2 approaches from a very high altitude level.  An approach I’m seeing quite a bit for cross-campus or short range DR plans is to build a stretch cluster.  The usual approach is to use something like a HP P4000 SAN and stretch it between two sites.  A single Hyper-V cluster is built, stretching across the WAN link.

SAN-SAN replication

It’s not a cheap solution and it comes with complexities – and that’s true no matter what virtualisation you use:

• You have to choose a storage solution that stretches across sites and can do active/active.  You are locked into a single spec across both sites, making the hardware sales people very happy.
• You probably need a witness for the storage and the virtualisation cluster in a 3rd site, with site A and site B having independent network access to the witness site to avoid split brain when the link between A and B fails (and it will fail).
• Some high end storage solutions won’t like CSV for this and you might need to so 1 VM per LUN
• The networking (IP redirect, stretched VLANs, routers, switches, and all that jazz) is messy.
• The WAN for this is mega pricey.
• Honestly, a stretch Hyper-V cluster doesn’t play well with System Center Virtual Machine Manager – VMM just sees a single cluster and doesn’t care about the WAN link or the impact on backup, client/server app interaction, and so on.
• If you want to replicate to a hosting company then you need colo hosting and to place hardware in rented rackspace.
• Once a VM is created in a replicate LUN, it’s replicated to site B.  That’s pretty nice in a cloud.
• When everything works it’s a pretty fine solution, capable of having 0 data loss.  But corruption in site A will replicate to site B because this SAN likely has synchronous replication.

The above solution is something I see more and more, even in medium sized sites.  It’s complex, it’s pricey, and very often they are struggling with getting it to work even in testing, let alone in the worst day of their professional careers.

I recently listed to a RunAs Radio podcast where the guest spoke about his preference for VMware SRM for DR replication.  I can understand why.  Software replication can stretch much greater distances.  You aren’t as beholden to the storage vendor as before.  Hyper-V Replica is surely going to have the same impact … and more … without costing you hundreds of dollars/euros/pounds/etc on a per VM basis like SRM does:

Hyper-V Replica

• Hyper-V is hardware independent.  You can replicate from a host to a host, from a cluster to a host, or from a host to a cluster.  You can replicate from a HP cluster with a P4000 to a bunch of Dell hosts with a Compellent.
• Hyper-V Replica is built for unstable WAN connections.  It cannot automatically failover … in fact, many of us prefer a manual decision on failover.  We can reduce the RTO by automating VM start up using PowerShell and/or Orchestrator in the DR site.  The storage ni both sites is independent.  No need for 3rd party witnesses and their networking.
• VMs are replicated instead of LUNs, therefore CSV is fully supported.  You can replicate VMs from a CSV in site A to a CSV or a normal LUN in site B.
• Networking is easy!  And you have options!  The pipe for the replica probably either should be dedicated or have QoS to allow replication without impacting normal Internet connectivity.  Because the replication is asynchronous, the WAN doesn’t need massive bandwidth and low latency.  You can choose to stretch VLANs, or you might not.  You might use Network Virtualisation in site B or you might use IP address injection to change the VMs’ IP addresses for the destination network.  By the way, you can also dedicate a virtual switch(es) for firing up test copies of your VMs for DR testing.
• Hyper-V Replica is built for commercial broadband.  Remember that your upload speed is the important factor.  Sizing is tricky … I’ve been saying that you could take your incremental backup and divide it by the number of 5 minute windows there are in your workday to figure out how much bandwidth Hyper-V Replica will require to replicate every 5 minutes … but that’s worst case because there is pre-transmit compression going on.
• Hyper-V Replica is not a stretch cluster … therefore systems management solutions such as VMM will play nice by keeping it’s placement of VMs local in site A.
• Your hardware options are very flexible.  You could replicate to hardware you own in a branch/head office or datacenter, you could rent rackspace and put hardware in colo hosting, or you could replicate to a hosting partner that hosts Hyper-V Replica.
• There just aren’t as many delicate moving parts in this architecture.  You pretty much have 2 simple independent infrastructures where 1 copies compressed differential data to another.
• Hyper-V Replica is configured on a per-VM basis.  PowerShell can do this – I’ve already seen examples posted online.  You could probably make this a part of the Orchestrator runbook in a cloud implementation.  So a little more work is requires but you can fire it and forget.
• Best of all, Hyper-V Replica is a tick box away in Hyper-V.  Yup, zero dollars, nada, keine kosten, gratuito, free.  Of course, you are free to continue wearing a tinfoil hat and paying vTax ….

Clinging to his overpriced DR with his cold dead hands because he thinks Stevie B. wants to steal his brainwaves