- Integrated Systems
- About Us
- Integrated Systems
- About Us
08-28-2012 07:39 AM
What load balancing method does VC use?
A VC question from John:
What load balancing method does VC use when you have multiple uplinks for a SUS in an LACP port channel- so that all of the uplinks are active. How is the traffic coming from the servers load balanced across all the active uplinks?
From Sharad and Sanjeev:
Details are available in “ Virtual connect for Cisco Administrator “ guide http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01386629/c01386629.pdf
Sharad already provided the document with most of the information but I’ll answer both of your questions below.
What load balancing method does VC use when you have multiple uplinks for a SUS in an LACP port channel?
Virtual Connect utilizes a deterministic load balancing algorithm for frames load balanced across a single LACP channel and VC provides a deterministic algorithm for determining active vs. standby LACP channels assigned to the same Virtual Connect network (vNET).
VC’s algorithm for frame load balancing within a LAG (port trunk/channel) is automatic based on the protocol information in the frame. If the frame contains Layer 4 information (for example, TCP, UDP), Virtual Connect will use it and Layer 3 information (source and destination IP addresses) to determine conversation streams and statistically load balance individual streams on different ports in the LAG. If a frame only contains Layer 3 information (IP addresses), Virtual Connect will use the source and destination IP addresses to determine the conversations to load balance. For all Layer 2 only frames, VC simply uses the Source and Destination MAC addresses to determine conversations to load balance across the different ports in the LAG.
When multiple LAGs are configured in a single vNet, VC determines the active LAG based on LAG bandwidth. The LAG with the most bandwidth (port speed + number of active ports) becomes the active LAG. All other LAGs in the vNet are put in standby mode (like NIC Teaming). If all LAGs are equal, VC Enet module ID (MAC address) and uplink port numbers are used to break the tie.
Since VC automatically load balances traffic across the ports in a port channel using the most conversation-specific information available (TCP/UDP, then IP, then MAC), VC does not provide a user configurable setting for this feature. Also, the load balancing algorithm does not have to match on both sides of the same port channel.
How is the traffic coming from the servers load balanced across all the active uplinks?
When you configured the Multiple Shared Uplink Sets (SUS) with active/active option you passing the network from both the VC modules. But when you configured the SUS advance network enable the smartlink option too.
HP best practice suggests that active/active network pairs should have SmartLink enabled. SmartLink turns off downlink ports within Virtual Connect, if ALL available uplinks to a vNet or Shared Uplink Set (SUS) are down.
Enabling SmartLink configures the network so that if all external links lose their link to external switches, Virtual Connect drops the Ethernet link on all local server blade Ethernet ports connected to that network. This feature can be useful when using certain server network teaming (bonding) configurations.
Blade1 is BL460c with dual port NIC in mezzanine 2
- VC modules in bays 1,2,5, and 6
- Network_A, uplink VC bay1 port X1 (with SmartLink enabled)
- Network_B, uplink VC bay2 port X1 (with SmartLink enabled)
- Blade1 has ports 1 and 3 assigned to Network_A, and ports 2 and 4 assigned to Network_B.
– In the above scenario, if port X1 on Network_A fails, only port1 on Blade1 will be set to not linked. Port 3 on Blade1 will still have a linked status.
– Active/active VC network pairs should have SmartLink enabled. When SmartLink is implemented, VC will detect the upstream link failure and notify NICs that are associated with that active network of the failure, and the NIC team or bond will manage the failover.
Note: In an Active/Standby configuration with a single SUS the uplinks from one module are active and the uplinks from the other module are standby. Since Smart Link requires all uplinks in a Shared Uplink Set to fail in order to disable the server facing downlink. Smart Link offers no benefit in this scenario. If all uplinks fail (which is the trigger for Smart Link), there is nothing to fail over to, as all paths for that particular SUS are down.
Caution: Under some circumstances you might want servers within an enclosure to be able to communicate through the network even though all the uplinks are down. For instance, if you have a group of servers that need to talk amongst themselves within the VC domain (maybe VMotion or a heartbeat link) and the vNet has an uplink attached, if the uplink fails and SmartLink kicks in, all the server NICs will be disconnected and now internal communications are also broken.
Other comments or questions?