Hyper-V 2012 R2 Network Architectures Series (Part 5 of 7) – Converged Networks using Dynamic QoS

Part 4 of this series covered the scenario where the Backend QoS had to be Static. Now let’s take a look to what is becoming more common nowadays with Dynamic QoS. Take a look to the following picture…

Today, most vendors already offer Dynamic QoS based on weight or minimum reservations. This allows us to use the entire bandwidth on each of the Multiplexed NICs presented to Windows. This is good because it means that each of the NICs on the Hyper-V Host will be able to reach 10GB if needed while prioritizing traffic in the event of conflict.

This backend solution enables us to have the best of both worlds. We can provide QoS and we can also take advantage of all the Hyper-V Network optimizations like RSS and dVMQ. Of course, it is important how many Multiplexed NICs we present to Windows and the weight assigned to each of them, but remember that the same rules from the Non-Converged network configurations will apply from a Windows perspective.

There are three major points with this configuration to bear in mind.

1. LACP is not exposed to Windows, so Link Aggregation on the Multiplexed NICs will not be possible.
2. QoS in the Backend and QoS from SCVMM 2012R2 on the vSwitch ports may be in conflict if policies are not properly planned and configured.
3. Windows does not know what these backend QoS and Multiplexed NICs are. Support and troubleshooting should be provided by the vendor.

Besides these three caveats, this architecture is one of the best options we have if your hardware supports it. MGMT, CSV and LM networks will be able to reach 10GB throughput when needed enhancing the Host performance while keeping HA and reliability.

Of course, again we are assuming that your storage connections are over FC using HBAs.

Comments

• Anonymous
  February 22, 2014
  Hi Virtualization gurus, Since 6 months now, I’ve been working on the internal readiness about Hyper
• Anonymous
  March 04, 2014
  As an IT guy I have the strong belief that engineers understand graphics and charts much better than
• Anonymous
  March 11, 2014
    ** Newly updated to include 2012 R2 Best Practices. See 11/03/2013 blog regarding R2 updates by
• Anonymous
  July 19, 2014
  There is one thing about this diagram I am not quite understanding. You have a pNIC for LM, and a pNIC for CSV that are not teamed within the OS. Each pNIC is on a separate VLAN in order to segregate the two traffic types. However you've specified that those two networks will benefit from SMB Multichannel. How can those two networks benefit from SMB Multichannel - if I specify in Failover Cluster Manager that I only want LM traffic on the one NIC, wouldn't utilizing SMB Multichannel spill that LM traffic over onto the CSV network - which I don't want? Or am I misunderstanding?
• Anonymous
  August 15, 2014
  I made the assumption from the explanation that both the CSV and the LM networks were configured to handle LM traffic. My assumption would be the LM network is primary and CSV is secondary. If you did not include CSV as a LM network, then LM traffic will not traverse the CSV network. You have control over which networks are used for LM.
  Since it was not explicitly stated in the explanation, it is possible to interpret the configuration either way. I made my assumption of LM on both networks because he stated SMB Multichannel would come into play.