[If you are viewing this from the main page the second table appears to be missing text. Just view the post on its own by clicking the title]
[Edit 19/04/2011 - Include more info on Live Migration NIC]
[Edit 19/06/2011 - More info on NICs for cluster communications]
This is a topic that comes up all of the time. Especially when dealing with Hyper-V clusters. The short answer to the question is - it depends.
For this post I will talk about networking requirements for a SAME SITE CLUSTER. Multisite clusters, or stretch clusters, have different networking requirements. I will cover this topic in a different post.
There are some great TechNet articles and blog posts on this topic. However, I believe that most of these posts focus on the logical networking and don't take the physical and risk profiles into account. What do I mean? I've seen people get really hooked on the "avoid the single point of failure" when designing. The problem I find is that the design stops at the logical level and doesn't take the physical hardware into account. Having fault tolerant NIC's for the parent partition isn't much good if both ports are on the same multiport card or backplane. Sometimes you want the cluster to failover its workload. Keeping the workload on node at all costs could just be a case of over engineering. Enterprise Architecture 101 - keep it simple!
First things first, let's just look at the logical minimum requirements for network cards in a Hyper-V cluster.
Recommended Connection Type
Used for the management of the Hyper-V host. Also used by System Centre Virtual Machine Manager
Typically low bandwidth. Can increase when deploying VM's from SCVMM.
iSCSI network connection to SAN
High bandwidth and low latency required
Refer to your storage vendor. Normally private.
Used to provide network access for your VM's
Can vary depending on the workload.
Used for cluster communication to determine the status of other cluster nodes
Low bandwidth and low latency required.
Cluster Shared Volume (CSV)
Used in scenarios when redirected I/O is required
Idle until redirected I/O kicks in. In which case High Bandwidth and low latency required,
Used to transfer the running VM's from one cluster node to another
Idle until Live Migration occurs. In which case High Bandwidth and low latency required,
The table above just deals with the logical requirements for a Hyper-V cluster. I'll deal with single points of failure, combing usage and teaming shortly. So, based on the above, that's 6 different logical networks. Your solution may require one or more NICs per logical network. There are options for combining logical networks as well as options for teaming. But before we get into that ... Do you have the network hardware required to warrant NIC teaming or multipath connections? When you have the answer to this question you can then start to define your networking design in earnest.
I have a couple of observations/comments I'd like to make:
The whole reason behind clustering your Hyper-v solution is to take into account serious component failure. With this in mind, don't over engineer things. Don't get too hooked up on single points of failure in the logical world. Just make sure you have enough capacity in your cluster for your workloads (the N+1 rule applies).
This is how I would setup network cards in a typical Hyper-V cluster.
Number of Network Cards
1 Network Card
2 Network Cards - Not Teamed
1+ Network cards depending on the workload. Teaming is optional. Normally at least 2 cards.
1 Network Card
Notes on the above:
So whats the answer:
Based on the above table and assuming 2 network cards for your VM's external network, this means I recommend EIGHT (8) logical network connections/NICs are required at a minimum for a PRODUCTION Hyper-V cluster. Yes, you could double up on some of the NICs like combining the heartbeat with the CSV NIC but I feel this is the best balance.
I referenced a few TechNet articles when putting this together. Here they are:
Hyper-V: Live Migration Network Configuration Guide
Requirements for Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2
Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2
Designating a Preferred Network for Cluster Shared Volumes Communication
Great and very helpful post!
Nice Blog - I think I'll be referring to this quite a bit!
Thanks Gavin for the post, it has been very helpful