Tag: Windows Server 2012

Assuming that you converge all fabrics (including iSCSI and that may require DCB for NICs and physical switches) then my recent work in the lab has found me another reason to like converged fabrics, beyond using fewer NICs.

If I am binding roles (parent, live migration, etc) to physical NICs then any host networking configuration scripts that I write must determine what NIC is correct.  That would not be easy and would be subject to human cabling error, especially if hardware configurations change.

If however, I bind all my NICs into a team, and then build a converged fabric on that team, I have completely abstracted the physical networks from the logical connections.  Virtual management OS NICs and trunking/VLAN bindings mean I don’t care any more … I just need 2 or 4 NICs in my team and connected to my switch.

Now that physical bindings don’t matter, I have simplified my configuration and I can script my depoyments and configuration to my heart’s content!

The only question that remains … do I really converge my iSCSI connections?  More to come …

My lesson from the lab is this …  If you are implementing WS2012 Hyper-V hosts with converged fabrics then you need to realise that all of your NICs for RDP access will be committed to the NIC team and Hyper-V switch.  That means that while implementing or troubleshooting the switch and converged fabrics you will need some alternative to RDP/Remote Desktop.  And I’m not talking VNC/TeamViewer/etc.

In my lab, I have LOTS of spare NICs.  That won’t be true of field implementation.  I temporarily fired up an “RDP” NIC, configure my team, switch, and a virtual NIC for the Parent.  Then I RDPd into the Parent virtual NIC and disabled the “RDP” NIC.

In the field, I strongly advise using the baseboard management controller (BMC) to remotely log into the host while implementing, re-configuring or troubleshooting the converged fabrics setup.  Why?  Because you’ll be constantly interrupted if relying on RDP into one of the converged or virtual NICs.  You may even find NICs switching from static to DHCP addressing and it’ll take time to figure out what their new IPs are.

You’ll be saving money by converging fabrics.  Go ahead and cough up the few extra quid to get a BMC such as Dell DRAC or HP iLO fully configured and onto the network so you can reliably log into the server.  Plus it gives you other features like power control, remote OS installation, and so on.

We continue further down the road of understanding converged fabrics in WS2012 Hyper-V.  The following diagram illustrates a possible design goal:

Go through the diagram of this clustered Windows Server 2012 Hyper-V host:

• In case you’re wondering, this example is using SAS or FC attached storage so it doesn’t require Ethernet NICs for iSCSI.  Don’t worry iSCSI fans – I’ll come to that topic in another post.
• There are two 10 GbE NICs in a NIC team.  We covered that already.
• There is a Hyper-V Extensible Switch that is connected to the NIC team.  OK.
• Two VMs are connected to the virtual switch.  Nothing unexpected there!
• Huh!  The host, or the parent partition, has 3 NICs for cluster communications/CSV, management, and live migration.  But … they’re connected to the Hyper-V Extensible Switch?!?!?  That’s new!  They used to require physical NICs.

In Windows Server 2008 a host with this storage would require the following NICs as a minimum:

• Parent (Management)
• VM (for the Virtual Network, prior to the Virtual Switch)
• Cluster Communications/CSV
• Live Migration

All that accumulation of NICs wasn’t a matter of bandwidth. What we really care about in clustering is quality of service: bandwidth when we need it and low latency. Converged fabrics assume we can guarantee those things. If we have those SLA features available to us (more in later posts) then 2 * 10 GbE physical NICs in each clustered hosts might be enough, depending on business and technology requirements of the site.  4 NICs per host … and that’s without NIC teaming.  Double the NICs!

The amount of NICs go up.  The number of switch ports goes up.  The wasted rack space cost goes up.  The power bill for all that goes up.  The support cost for your network goes up.  In truth, the complexity goes up.

NICs aren’t important.  Quality communications channels are important.

In this WS2012 converged fabrics design, we can create virtual NICs that attach to the Virtual Switch.  That’s done by using the Add-VMNetworkAdapter PowerShell cmdlet, for example:

Add-VMNetworkAdapter -ManagementOS -Name “Manage” -SwitchName External1

… where Manage will be the name of the new NIC and the name of the Virtual Switch is External1.  The –ManagementOS tells the cmdlet that the new vNIC is for the parent partition or the host OS.

You can then:

• Configure the vNIC using Set-VMNetworkAdapter
• Specify the VLAN for the vNIC using Set-VMNetworkAdapterVLAN
• Configure IPv4/IPv6

I think configuring the VLAN binding of these NICs with port trunking (or whatever) would be the right way to go with this.  That will further isolate the traffic on the physical network.  Please bear in mind that we’re still in the beta days and I haven’t had a chance to try this architecture yet.

Armed with this knowledge and these cmdlets, we can now create all the NICs we need that connect to our converged physical fabrics.  Next we need to look at securing and guaranteeing quality levels of communications.

Before we looks at this new networking feature of W2012 Hyper-V, lets look at what we have been using in Windows Server 2008/R2.  Right now, if you create a VM, you give it one or more virtual network cards (vNICs).  Each vNIC is connected to a virtual network (basically a virtual unmanaged switch) and each switch is connected to one physical NIC (pNIC) or NIC team in the host.  Time for a visual:

Think about a typical physical rack server for a moment.  When you connect it to a switch the port is a property of the switch, right?  You can configure properties for that switch port like QoS, VLANs, etc.  But if you move that server to another location, you need to configure a new switch port.  That’s messy and time consuming.

In the above example, there is a switch port.  But Microsoft anticipated the VM mobility issue and port configuration.  Instead of the port being a property of the virtual network, it’s actually a property of the VM.  Move the VM, you move the port, and you move the port settings.  That’s clever; configure the switch port once and now it’s a matter of “where do you want your workload to run today?” with no configuration issues.

OK, now let’s do a few things:

• Stop calling it a virtual network and now call it a virtual switch.
• Now you have a manageable layer 2 network device.
• Introduce lots of new features for configuring ports and doing troubleshooting.
• Add certified 3rd-party extensibility.

We have different kinds of Virtual Switch like we did before:

• External – connected to a pNIC or NIC team in the host to allow VM comms on the physical network.
• Internal – Allows VMs to talk to each other on the virtual switch and with the host parent partition.
• Private – An isolated network where VMs can talk to each other on the same virtual switch.

Although I’m focusing on the converged fabric side of things at the moment, the extensibility is significant.  Companies like Cisco, NEC, Five9, and others have announced how they are adding functionality.  NEC are adding their switch technology, Five9 are adding a virtual firewall, and Cisco have SR-IOV functionality and a Cisco Nexus 1000v that pretty much turns the Hyper-V Switch into a Cisco switch with all the manageability from their console.  The subject of extensibility is a whole other set of posts.

With a virtual switch I can do something as basic as this:

It should look kind of familiar   I’ve already posted about NIC teaming in Windows Server 2012.  Let’s add a team!

With the above configuration, the VMs are now connected to both the NICs in the host.  If one NIC dies, the team fails over and the VMs talk through the other NIC.  Depending on you load distribution setting, your VMs may even use the aggregation of the bandwidth, e.g. 2 * 10 GbE to get 20 Gbps of bandwidth. 

With NIC teaming, we have converged two NICs and used a single pipe for VM communications.  We haven’t converged any fabrics just yet.  There’s a lot more stuff with policies and connections that we can do with the Virtual Switch.  There will be more posts on those topics soon, helping us get to the point where we can look at converging fabrics.