Hyper-V Cluster Networks

[Mr.Ben]

Ok, so I have a my cluster working already

 

Each of the 3 hosts has 12 1Gbe Network Cards:

 

1 Reserved for Management on the 10.6.183.0 network

2 Teamed for Clustering and Live Migration services on a 192.168.10.0/29 network (VLAN'ned on our core switch)

4 Teamed for the Hyper-V Virtual Switch (directly connected to the 10.6.183.0 network)

2 x 2 Teams for MPIO Access via 2 switches to the iSCSI SAN (192.168.20.0/29 and 192.168.30.0/29)

 

FYI The iSCSI SAN is an MD3600i (10Gbe)

 

And a spare!

 

I've been reading that in 2008R2 the Live Migration and CSV networks should be separate, but I can't find anywhere to do this - have they been converged in 2012?

 

 

Kind regards, Ben

[mutindac]

Hi Ben,

 

Sorry I don't have any answers, but I am working on achieving the same configuration as you. My environment is more or less identical but I am issues with getting the Teamed Virtual Switch to connect to the right VLANs. Could you please clarify how the switch was configured? Are the 4 Teamed connections VLAN tagged on the server or switch or both? Do the Guest devices run on the same VLAN as the Host?

 

Thanks,

 

Charles

[Tsonga]

Ok, so I have a my cluster working already

 

Each of the 3 hosts has 12 1Gbe Network Cards:

 

1 Reserved for Management on the 10.6.183.0 network

2 Teamed for Clustering and Live Migration services on a 192.168.10.0/29 network (VLAN'ned on our core switch)

4 Teamed for the Hyper-V Virtual Switch (directly connected to the 10.6.183.0 network)

2 x 2 Teams for MPIO Access via 2 switches to the iSCSI SAN (192.168.20.0/29 and 192.168.30.0/29)

 

FYI The iSCSI SAN is an MD3600i (10Gbe)

 

And a spare!

 

I've been reading that in 2008R2 the Live Migration and CSV networks should be separate, but I can't find anywhere to do this - have they been converged in 2012?

 

 

Kind regards, Ben

 

An impressive setup.

[Mr.Ben]

Ok, so I've found my answers through experimentation!

 

First off, I needed 2 cluster networks, to provide failover and information to the nodes. I've assigned the management network as the secondary cluster network (failover clusting has prioritised the internal cluster network as the primary network for getting it's information and for quick migration).

 

The Live Migration facility can be set to run across any network: I've set mine to only run across the Internal Cluster Network for the moment (Microsoft still say this should be on a separate network, but this is a tiny deployment compared to their ideas). The option is in Neworks and then hidden away to the top right - Live migration settings.

 

To answer mutindac's question, the Hyper-V Teamed devices go directly into our core switch, which has untagged ports for the correct VLAN - I've not done any configuration of the Hyper-V Virtual Switch. IP routing is enabled on the core and traffic seems to be fine.

[Psymon]

We have a setup similar to this

 

3 x HP BL480 Blades (2 x Intel Xeon Quad Core 2.66, 48GB RAM, 8 x 1GB NIC)

HP P4300G2 2 node SAN (2 x 1GB Active / Active controllers per node - LeftHand do things differently than traditional SANs in that there is no head unit to manage comms, making it scalable)

 

2 x host, teamed and running on seperate modules in our core switch (10.0.0.x)

2 x iSCSI, MPIO not teamed as it's not supported (10.0.4.x)

4 x Hyper-V VMs, teamed and split 2/2 to seperatemodules in our core switch (10.0.0.x)

 

Management and live migrations all go over the 2 x host adapters, iSCSI has it's own VLAN. As @Mr.Ben said - the MS deployment scenarios are massive clusters which is why they like to keep things seperate.

 

Simon

[localzuk]

Seems remarkably complicated to be honest.

 

We have a Hyper-V cluster consisting of 2 nodes and another acting as the central storage.

 

We run it all over SMB in 2012. Using a single 10GbE card in each machine.

 

Failover works fine for me!

[Psymon]

Seems remarkably complicated to be honest.

 

We have a Hyper-V cluster consisting of 2 nodes and another acting as the central storage.

 

We run it all over SMB in 2012. Using a single 10GbE card in each machine.

 

Failover works fine for me!

 

It's not as bad as it sounds, but the cluster is then fully redundant from NIC failure, switch failure etc... If you have a NIC or switch die, you lose everything.

Edited March 18, 2013 by Psymon
typo

[localzuk]

It's not as bad as it sounds, but the cluster is then fully redundany from NIC failure, switch failure etc... If you have a NIC or switch die, you lose everything.

 

True. But have to draw the line somewhere. Unless I were to buy a second storage server, a second switch, and extra NICs for each server, I'm not going to get full redundancy. So, we've looked at the likelihood of failures. PSUs, RAM and HDD/SSDs are most likely to fail. So we have dealt with those aspects.

[tmcd35]

Seems remarkably complicated to be honest.

 

We have a Hyper-V cluster consisting of 2 nodes and another acting as the central storage.

 

We run it all over SMB in 2012. Using a single 10GbE card in each machine.

 

Failover works fine for me!

 

Very, very interesting - almost identical to our set up here other than we don't have failover working yet. Is this a new setup using 2012 and failover explicitly implemented from day 1, or did you upgrade from SMB in 2008R2 which didn't support clustering on SMB?

 

We've upgraded from 2008R2, about to update the central storage server to 2012 over Easter. Not sure whether I can/want/need to setup failover clustering once this upgrade is complete. Just moving the host servers to 2012 gave us live migration which was a very welcome and impressive addition, I think that might be all we need anyway.

[localzuk]

Very, very interesting - almost identical to our set up here other than we don't have failover working yet. Is this a new setup using 2012 and failover explicitly implemented from day 1, or did you upgrade from SMB in 2008R2 which didn't support clustering on SMB?

 

Brand new installation, with failover configured from day 1.

 

We've upgraded from 2008R2, about to update the central storage server to 2012 over Easter. Not sure whether I can/want/need to setup failover clustering once this upgrade is complete. Just moving the host servers to 2012 gave us live migration which was a very welcome and impressive addition, I think that might be all we need anyway.

 

You should be able to do it. If you migrated from 2008R2 I imagine you're still on ISCSI? Or have you migrated all the servers into SMB shares?

 

To enable failover, you simply need a witness share. Once you have that set up and enabled, failover is just ticking a couple of boxes.

 

Step-by-Step: Building a FREE Hyper-V Server 2012 Cluster - Part 1 of 2 - IT Pros ROCK! at Microsoft - Site Home - TechNet Blogs

 

I can't find the stuff I used to do it, but the witness share is covered in there - its a couple of lines of powershell code.

[tmcd35]

You should be able to do it. If you migrated from 2008R2 I imagine you're still on ISCSI? Or have you migrated all the servers into SMB shares?

 

Not at all, 2008R2 did work with SMB shares - it was just never officially supported. I wanted iSCSI but cost meant building my own storage server and WSS wasn't available as a separate purchase so I had to use SMB shares and loose live migration and failover clustering. Now 2012 is out and WSS is built in a standard, but SMB's are also fully supported.

 

That was the reason for the question. The SMB share is pre-exiting with live VM's running through it. Didn't know if that would be an issue when coming to set up a failover cluster.

[localzuk]

As far as I know, it shouldn't be an issue at all - you should be able to add the witness at any time.

[_Adam_]

A witness or quorum is only needed if there are an even number of hosts. Although I run 4 x 10Gb fully redundant in our environment, the principles are the same, so going back to the OP setup it looks good for your environment. Clustering is only really used if direct access to your storage is not available from a host (traffic is redirected over the network). This should rarely happen so it is safe to pair it with live migration, but if it does occur and you migrate a server you will see a big slow down.

 

You can create separate networks for clustering and live migration or use the same, with management as the secondary in both cases. Both are in different areas of Hyper-V with tick boxes for selecting the networks to use and then ordering the priority. In 2012 you no longer need to set the metric (well I have not, always seems to be correct when I check).

 

I would probably take the spare NIC and add it to the cluster/live migration team.