The load balancing feature of NIC teaming does not function like the load balancing feature of advanced routing protocols. Load balancing across a NIC team is not a product of identifying the amount of traffic transmitted through a network adapter and shifting traffic to equalize data flow through all available adapters. The load balancing algorithm for NIC teams in a vSwitch is a balance of the number of connections --- not the amount of traffic.
NIC teams on a vSwitch can be configured with one of the following four load balancing policies:
* vSwitch port-based load balancing (default)
* Source MAC-based load balancing
* IP hash-based load balancing
* Explicit failover order
vSwitch Port-based Load Balancing
The default vSwitch policy for port-based balancing uses an algorithm that ties (pins) each virtual switch port to a specific uplink associated with the vSwitch. The algorithm attempts to maintain an equal number of port-to-uplink assignments across all uplinks to achieve load balancing. This policy setting ensures that traffic from a specific virtual network adapter connected to a virtual switch port will consistently use the same physical network adapter. In the event that one of the uplinks fails, the traffic from the failed uplink will fail over to another physical network adapter.
Although this policy does not provide the best dynamic load balancing, it does provide redundancy. Because the port for a VM does not change, each VM is tied to a physical network adapter until failover or vMotion occurs regardless of the amount of network traffic.
In the unlikely scenario of there being more number of physical adapters than the number of VMs, some physical adapters will end up not being used and not carrying any traffic at all. Which is an inefficient way of load balancing traffic.
Source MAC-based Load Balancing
The Source MAC-based load balancing policy is susceptible to the same pitfalls as the vSwitch port-based policy simply because the static nature of the source MAC address is the same as the static nature of a vSwitch port assignment. The source MAC-based policy is also best used when you have more virtual network adapters than physical adapters.
IP Hash-based Load Balancing
This policy addresses the static-like limitations of the two previous policies. The IP hash-based policy uses the source and destination IP addresses to calculate a hash. The hash determines the physical network adapter to use for communication. Different combinations of source and destination IP addresses will, quite naturally, produce different hashes. Based on the hash, then, this algorithm could allow a single VM to communicate over different physical network adapters when communicating over different physical network adapters when communicating with different destinations, assuming that the calculated hashes select a different physical NIC.
Unfortunately, the IP hash-based load balancing does not provide a benefit for large data transfers occurring between the same source and destination systems. Because the source-destination hash will be the same for the entire duration of the data load, it will flow through only a single physical network adapter rather than round-robin alternating through all available adapters servicing the port group.
Also, unless the physical hardware supports it, a vSwitch with the NIC teaming load balancing policy set to use the IP-based hash must have all the physical network adapters connected to the same physical switch. Some newer switches support link aggregation across physical switches but otherwise all the physical network adapters will need to connect to the same physical switch.
Explicit Failover Order
Failover detection with NIC teaming can be configured to use either a link status method or a beacon-probing method.
The link status failover-detection method works just as the name suggests. The link status of the physical network adapter identifies the failure of an uplink. In this case failure is identified for events like removed cables or power failures on a physical switch. The downside to the setting for link status failover-detection is its inability to identify misconfigurations or pulled cables that connect the switch to other networking devices, like a cable connecting one switch to an upstream switch.
Some network switch manufacturers have added features into their network switches that assist in detecting upstream network failures. In Cisco, a feature called link state tracking exists that enables the switch to detect when an upstream port has gone down and react accordingly. This feature can reduce or even eliminate the need for Beacon probing.
The beacon-probing failover-detection setting, which includes link status as well, sends Ethernet broadcast frames across all physical network adapters in the NIC team. These broadcast frames allow the vSwitch to detect upstream network connection failures and will force failover when STP blocks ports, when ports are configured with the wrong VLAN, or when a switch-to-switch connection has failed. When a beacon is not returned on a physical network adapter, the vSwitch triggers the failover notice and reroutes the traffic from the failed network adapter through another available network adapter based on the failover policy.
NIC teams on a vSwitch can be configured with one of the following four load balancing policies:
* vSwitch port-based load balancing (default)
* Source MAC-based load balancing
* IP hash-based load balancing
* Explicit failover order
vSwitch Port-based Load Balancing
The default vSwitch policy for port-based balancing uses an algorithm that ties (pins) each virtual switch port to a specific uplink associated with the vSwitch. The algorithm attempts to maintain an equal number of port-to-uplink assignments across all uplinks to achieve load balancing. This policy setting ensures that traffic from a specific virtual network adapter connected to a virtual switch port will consistently use the same physical network adapter. In the event that one of the uplinks fails, the traffic from the failed uplink will fail over to another physical network adapter.
Although this policy does not provide the best dynamic load balancing, it does provide redundancy. Because the port for a VM does not change, each VM is tied to a physical network adapter until failover or vMotion occurs regardless of the amount of network traffic.
In the unlikely scenario of there being more number of physical adapters than the number of VMs, some physical adapters will end up not being used and not carrying any traffic at all. Which is an inefficient way of load balancing traffic.
Source MAC-based Load Balancing
The Source MAC-based load balancing policy is susceptible to the same pitfalls as the vSwitch port-based policy simply because the static nature of the source MAC address is the same as the static nature of a vSwitch port assignment. The source MAC-based policy is also best used when you have more virtual network adapters than physical adapters.
IP Hash-based Load Balancing
This policy addresses the static-like limitations of the two previous policies. The IP hash-based policy uses the source and destination IP addresses to calculate a hash. The hash determines the physical network adapter to use for communication. Different combinations of source and destination IP addresses will, quite naturally, produce different hashes. Based on the hash, then, this algorithm could allow a single VM to communicate over different physical network adapters when communicating over different physical network adapters when communicating with different destinations, assuming that the calculated hashes select a different physical NIC.
Unfortunately, the IP hash-based load balancing does not provide a benefit for large data transfers occurring between the same source and destination systems. Because the source-destination hash will be the same for the entire duration of the data load, it will flow through only a single physical network adapter rather than round-robin alternating through all available adapters servicing the port group.
Also, unless the physical hardware supports it, a vSwitch with the NIC teaming load balancing policy set to use the IP-based hash must have all the physical network adapters connected to the same physical switch. Some newer switches support link aggregation across physical switches but otherwise all the physical network adapters will need to connect to the same physical switch.
Explicit Failover Order
Failover detection with NIC teaming can be configured to use either a link status method or a beacon-probing method.
The link status failover-detection method works just as the name suggests. The link status of the physical network adapter identifies the failure of an uplink. In this case failure is identified for events like removed cables or power failures on a physical switch. The downside to the setting for link status failover-detection is its inability to identify misconfigurations or pulled cables that connect the switch to other networking devices, like a cable connecting one switch to an upstream switch.
Some network switch manufacturers have added features into their network switches that assist in detecting upstream network failures. In Cisco, a feature called link state tracking exists that enables the switch to detect when an upstream port has gone down and react accordingly. This feature can reduce or even eliminate the need for Beacon probing.
The beacon-probing failover-detection setting, which includes link status as well, sends Ethernet broadcast frames across all physical network adapters in the NIC team. These broadcast frames allow the vSwitch to detect upstream network connection failures and will force failover when STP blocks ports, when ports are configured with the wrong VLAN, or when a switch-to-switch connection has failed. When a beacon is not returned on a physical network adapter, the vSwitch triggers the failover notice and reroutes the traffic from the failed network adapter through another available network adapter based on the failover policy.
No comments:
Post a Comment