Load-balancing Methods (I prefer to call Teaming Methods) --> 1) Originating Port ID Based 2) MAC Hash Based 3) IP Hash Based - Which is best, in real & what supports Actual Load Balance????

Now that we understand the basics, we will move on to the topic at hand, NIC Teaming. Although you can team vNIC's within a VM, we are not going to discuss OS vNIC teaming, but rather physical NIC teaming. You may be wondering why someone would want to team physical NIC's? Well why not! Teaming the NIC's will not only eliminate the single point of failure associated with a single physical NIC, but also provide better overall network throughput - what's not to like!?!

ESX offers 3 different methods for load balancing. However, not all methods are created equal, and only one method offers true load distribution. The 3 load-balancing methods include:

• Route based on the originating port ID (this is the default if not defined otherwise) - Also know as vSwitch port-based load-balancing, this method chooses an uplink based on the virtual port where the traffic entered the virtual switch.

• Route based on source MAC hash - This method chooses an uplink based on a hash of the source Ethernet address.

• Route based on IP hash - This method chooses an uplink based on a hash of the source and destination IP address of each packet.

Click below --> Read More for Full Article (Which one will give Real Load Balancing)



So which one of these actually performs true load distribution? You guessed it, Route based on IP hashes. This is the only method for a single-vNIC virtual machine that looks at each packet exiting the vSwitch, thus utilizing the bandwidth of multiple physical network adapters.

The other two methods will not evenly distribute traffic and could suffer from network congestion if the NIC chosen for communication is already at or near max capacity due to other traffic entering/exiting the ESX host.

So why offer the other methods if they don't provide true load distribution? Well, a very good question indeed.

With vSwitch port-based load-balancing, a virtual machine's outbound traffic is mapped to a specified physical NIC based on ID of the virtual port to which the virtual machine is connected. This means no matter how busy the NIC becomes, even if there is another completely idle NIC, the traffic will never use the idle adapter, but will continue to use the overloaded NIC. However, because the calculation for the network adapter is done only once, this method uses very little CPU time. Additionally, because this is port based, if a virtual machine has been configured with multiple vNIC's, you can be assured the vNIC's will use different physical NIC's for outbound communications so long as the vSwitch is bound to multiple physical network adapters.

With the source MAC-based method, each virtual machine's outbound traffic is mapped to a specific physical NIC based on the vNIC's MAC address. This behaviour is almost identical to port-based load-balancing expect multi-vNIC enabled virtual machines are NOT guaranteed the use of different physical NIC's. This option should almost never be used.

Now all of this sounds well and good, but why is the IP hash based method not the default? Although this method is the only one that distributes traffic evenly, it comes at a cost. Each packet that exits the vSwitch must be inspected by the vmkernel in order to make routing decisions. Therefore, this inspection process uses CPU time to calculate which physical NIC it will use. A general rule of thumb is that for every one bit per second of network data processed, one hertz of a CPU cycle is required. So in order for ESX to drive a single one Gigabit Ethernet card at line rate, you would have to dedicate a full 2GHz of CPU processing power.

Additionally, in order for ESX to use IP hash based load balancing, the physical switch you plug your network adapters into must also support and be configured for 802.3ad link aggregation. Typically, 802.3ad is disabled by default on most switches and must be configured before it may be used. Not to worry though, we've included a sample how-to on 802.3ad configuration on a Cisco 3560 in the following pages.
One final note worth mentioning about NIC teaming. ESX Server 2 currently supports between 2 and 10 physical NIC's in a bond.

Now that we understand the different load balancing methods and their implications, lets continue on with the good stuff, how to configure it!

Source : www.tcpdump.com