Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the next couple months we are looking to add Failover and Load Balancing to our environment. We will have 2 servers that are Hyper V Hosts. We are looking to have an IIS App server and SQL Database server on both of the hosts. That way if one box fails, the other will be there to take it's place. Now my confusion comes from some google searches I have been making. From what I can tell, there seems to be SQL clustering / Peer to Peer transaction setup, as well as Hyper-V clustering. I'm not sure what would work best in this situation. The hosts will also have random other servers such as system center, our ticket server, Exchange Admin server, and several others split between the two. So I'm not sure if now the Hyper-V cluster will be the worst option.

Thank you.

share|improve this question
up vote 4 down vote accepted

With Hyper-V clustering you have a pool of Hyper-V servers (2+) all attached to the same set of network storage, so that the LUNS are available to all servers in the Hyper-V cluster. You must have network storage for this setup. With Hyper-V Live Migration, you can move a running VM from one Hyper-V host to another. This allows the workload from one server to shift over to another if the sever fails. This gives you physical redundancy if your remaining servers are capable of handling the load of the additional VMs. This setup does not protect you from corruption of the VM's OS and applications themselves. (See for details about this setup.)

SQL has its own redundancy available with several different clustering options. You can either do traditional active/passive clustering, with an active node and one or more passive nodes. This setup requires a shared disk between the servers and is only mounted on the active node. SQL also supports serveral types of replication which allows multiple active nodes. This method does not require shared storage and keeps a separate copy of the database on each server. (See for SQL 2008 high availability options)

Clustering at the SQL level protects from a failed OS or application on an individual node, allowing automatic failover in that scenario. If each instance is on a different Hyper-V server you are also protected from hardware failures. Additionally, some of the clustering methods for SQL server protect against corruption of the database on individual nodes. Using a Hyper-V cluster and only a single instance of the SQL server does not protect you from OS/software failure in the VM. If downtime is not a big issue you could restore from a VM snapshot in a short amount of time.

Edit: Forgot the IIS load balancing part.

For load balancing IIS you can use Window Network Load Balancing, which creates a virtual IP that is shared between both hosts. (See

The same rules apply with the IIS server as the SQL server for whether Hyper-V clustering or NLB is the right option. In addition for your other VMs, unless they are clustered/load balanced as well, they are not protected from an issue with the Hyper-V host without Hyper-V clustering.

share|improve this answer

If you are going to mirror virtual guests between two hosts, then avoid HyperV clustering. That lets the virtual guests start up on another host when one fails, and lets you balance loads at the host level.

If you are doing SQL clustering, you can have the backup SQL step in much quicker and start handling requests. And for web load balancing use NLB (get your network guy involved in doing it right, read up on multicast NLB). And use Exchange clustering between two Exchange virtuals. You'll be much happier.

share|improve this answer
Thank you for your help. So is the Hyper V cluster only beneficial in my scenario if we were to perform a live migration, which wouldn't really be necessary? I will start reading up on the SQL cluster and NLB. It does seem like doing this at the application level would be a better idea. I wish I could go to our network guy, but I'm him as well=). server admin, net admin, and help desk, learning as I go. – Patrick Oct 18 '12 at 17:29
Right, you got it. HyperV clustering helps you survive losing a host. SQL clustering, mirroring, or replication helps you survive losing a SQL server or storage system. Exchange clustering and NLB for lightweight services like IIS let you spread the load over multiple servers and collapse down to just one when there is a failure. You can fool with HyperV clustering when you have 3 or more Hosts and care about one-shot guests surviving an outage. Protect your big assets with focused solutions. – Mark Oct 18 '12 at 20:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.