Hyper-V Cluster with failover - NETWORKING
We are looking to setup a 3 node Hyper-V cluster with live migration and failover using:
- 3 x Dell R710's with dual quad core Xeon & 128 GB RAM & 6 NICs in each
- 1 x Dell MD 3220i SAN
We will be running this setup from a data center and so co-locating our kit.
Can anybody explain how we should setup the network connections to make the system redundant?
We have looked into this great article but are not sure how to get a 3 server setup correctly and reliably: http://faultbucket.ca/2011/01/hyper-v-failover-cluster-setup/.
I believe we need network connections for: live migration, heartbeat, management, hyper-v etc.
I assume as we are running it from a DC all IPs will have to be public IPs?
Are AD servers will be VMs. One on each Hyper-V server and setup not to be HA.
Solution 1:
I've been there! Last year I set up a similar cluster (except my boxes were Fujitsu) using an iSCSI SAN for Hyper V.
Actually it's not that hard, but there are going to be snags along the way. If you are colocating, I would definitely be rehearsing your installation in a server rack on your own premises before moving it to the datacentre (I used a soundproofed server cabinet for this).
Oh, one other thing in preparation, you don't mention this, but one thing I wouldn't bother with is iSCSI boot which is offered on some iSCSI systems. It's a pain to set up and it doesn't always work with redundnancy. It's always better to have one or two physical boot disks on the nodes so that if you have a network configuration problem or iSCSI issue, you can still boot them up. I use small (40GB) solid state drives in each of my servers for boot disks.
You definitely need a separate AD DC. In fact I started with a 3 node cluster and then limited this to 2 nodes, plus an unclustered 'master node' which runs backups on DPM 2010 and a virtualised DC.
You mention 6 ports, this may be enough. But allow me to illustate my node configutation which has 10 ports:
- You will always need 2 ports per node for the iSCSI network (each one belongs to a different subnet for MPIO redundancy and should be on separate NICs)
- 1 port for heartbeat that doesn't have any other traffic on it
- 1 port for live migration and transfers (this is the only one that you might want to upgrade to 10g or infiniband, but unless you are provisioning 10s of VMs per day it is not worth it)
- 1 port for remote desktop access
- 1 port for server management card
- 1 set of teamed ports that constitutes the main access network*
- 1 set of team ports that consitutes a DMZ network (optional)*
*It is often pointed out by detractors that Microsoft does not officially support port teaming (whereas VMWare does) but actually official word is that they don't discourage it, but simply feel that support is in the hands of the NIC vendors. I use Intel NICs that are of the ET generation, which have specific virtual network features and I find work very well with Hyper V. They actually allow you to split a team between switches so that if one of the switches fails you have consistent team access, a bit like MPIO but for virtual machines.
Hyper V is actually really resilient and good to use. I would approach your job in this sequence:
1) Set up the nodes individually, install iSCSI initiator, install MPIO, give your iSCSI ports, transport and heatbeat ports, management ports different subnet addresses.
2) Set up Hyper V and assign your chosen ports to your virtual network
3) Then run the cluster validation wizard and form the cluster.
You should always assign ports to your virtual network first, because this prevents them from being used by the cluster. This sounds counter-intuitive, but basically you are going to be keeping your virtual network agnostic to your cluster network. This still gives you redundancy, so don't worry. But to achieve this (and there is no other way) you are going to have to have either a separate set of switches for your cluster and hyper V (two each for redunancy) or you will need to set up VLANs on your switches. I do the latter (using untagged VLANS) and it works great.
Some other posts here have suggested that you use a consultant to do this work. If they are familiar with Hyper V, this may be a good idea. It doesn't give you the indepth knowledge that you'd otherwise acquire from DIY, but it will save you time. I had plenty of time last year, and I'm not embarassed to admit that it took me several months of work and figuring things out to get it all up and running.
Good luck!
Solution 2:
Welcome in a world of pain. YOu make one mistkake that will ruin your experience in a momnent when you are in a world of pain for not thinking things through.
Are AD servers will be VMs. One on each Hyper-V server and setup not to be HA
THINK what you do there. Windows clustering needs AD to start, as the config is in AD. IF for anyy reason power fails in the data center, when it comes back up the clsuter will not start as there are no AD servers ready. YOu have to be 100% carefull with this.
I strongly suggest you keep an additional small machine (Atom based if it has t obe) as acting as controlling AD (i.e. important roles) with a separate USV. CLustering works nice, but having all AD controllers in VM's asks for trouble.
http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx
has the guide you need. On top of that, consider using a fast network backbone. No, not 10g... too slow, too expensive. Get a nice set of Infiniband cards, an Infiniband switch and be habppy with FAST transfers.
The SAN may also be too small in IOPS. If you talk 100% load on two machines (one in reserve) That is a LOT of VM's. You have to amke sure your IOPS budgets are in line for this. I have problems with a 6 10k Raptor Raid 10 on a single 64gb host at times - you run 4 times the memory budget, so I would expect 4-6 times th IOPS needs (and I have no databases there, those are separate). Make sure you know the SAN side is good enough.