Книга: Mastering VMware® Infrastructure3

IP Hash Load Balancing 

IP Hash Load Balancing 

The third load-balancing policy available for NIC teams is the IP hash-based policy, also called the out-IP policy. This policy, shown in Figure 3.26, addresses the limitation of the other two policies that prevents a virtual machine from accessing two physical network adapters without having two virtual network adapters. The IP hash-based policy uses the source and destination IP addresses to determine the physical network adapter for communication. This algorithm then allows a single virtual machine to communicate over different physical network adapters when communicating with different destinations.

Figure 3.25 The source MAC-based load-balancing policy, as the name suggests, ties a virtual network adapter to a physical network adapter based on the MAC address.

A vSwitch with a NIC team set to use the IP hash-based load-balancing policy should have all physical network adapters connected to the same physical switch to support link aggregation. ESX Server supports standard 802.3ad teaming in static (manual) mode, but does not support the Link Aggregation Control Protocol (LACP) or Port Aggregation Protocol (PAgP) commonly found on switch devices. Link aggregation will increase throughput by combining the bandwidth of multiple physical network adapters for use by a single virtual network adapter of a virtual machine. 

Follow these steps to alter the load-balancing policy of a vSwitch with a NIC team:

1. Use the VI Client to establish a connection to a VirtualCenter server or an ESX Server host.

2. Click the hostname in the inventory panel on the left, select the Configuration tab from the details pane on the right, and then select Networking from the Hardware menu list. 

3. Click the Properties for the virtual switch, select the name of virtual switch from the Configuration list, and then click the Edit button.

4. Select the NIC Teaming tab and then select the desired load-balancing strategy from the Load Balancing drop-down list.

5. Click OK and then click Close.

Figure 3.26 The IP hash-based policy is a more scalable load-balancing policy that allows virtual machines to use more than one physical network adapter when communicating with multiple destination hosts.

Now that the load-balancing policies are explained, let's take a deeper look at the failover and failback of uplinks in a NIC team. Failover detection in a NIC team can be configured to use either a link status method or a link status and beacon probing method.

The link status failover detection method works just as the name suggests. Failure of an uplink is identified by the link status provided by the physical network adapter. In this case, failure is identified for events like removed cables or power failures on a physical switch. The downside to the link status failover detection setting is its inability to identify misconfigurations or pulled cables that connect the switch to other networking devices (i.e., a cable connecting one switch to another switch.)

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 ports are blocked by a spanning tree, are configured with the wrong vLAN, or 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. Consider a vSwitch with a NIC team consisting of four physical network adapters, where each adapter is connected to a different physical switch and each physical switch is connected to a single physical switch, which is then connected to a router, as shown in Figure 3.27. When the NIC team is set to the beacon probing failover detection method, a beacon will be sent out over all four uplinks.

Figure 3.27 The beacon probing failover detection policy sends beacons out across the physical network adapters of a NIC team to identify upstream network failures or switch misconfigurations.

Once a failure has been detected, the vSwitch will use either a Rolling Failover or a Failover Order policy setting to continue passing traffic through another physical network adapter. By default, a NIC team is set to use a Rolling Failover policy of No, as shown in Figure 3.28. When the Rolling Failover policy is set to No, the NIC team not only provides a failover policy but also applies a fail-back policy. This means that if a failed physical network adapter is repaired and brought back online, the NIC team will reroute the traffic back to the adapter and relieve the standby adapter that assumed its role during failover. When the Rolling Failover policy is set to Yes, the NIC team will not perform a failback. In this case, the physical network adapter that assumed responsibility for the failed adapter will continue to process the traffic. Meanwhile, the failed adapter that is not back online will function as a standby until another adapter experiences failure.

Figure 3.28 By default, a NIC team is configured with a Rolling Failover policy setting of No.

As an alternative to the Rolling Failover policy, a Failover Order policy can be manually configured. The Failover Order policy involves an administrative assignment of priority to each of the physical network adapters in the NIC team. As shown in Figure 3.29, a vSwitch with a NIC team set to use a Failover Order policy can have physical network adapters designated as active and standby.

Perform the following steps to configure the Failover Order policy for a NIC team:

1. Use the VI Client to establish a connection to a VirtualCenter server or an ESX Server host.

2. Click the hostname in the inventory panel on the left, select the Configuration tab from the details pane on the right, and then select Networking from the Hardware menu list.

3. Click the Properties for the virtual switch, select the name of virtual switch from the Configuration list, and then click the Edit button.

4. Select the NIC Teaming tab.

5. Use the Move Up and Move Down buttons to adjust the order of the network adapters and their location within the Active Adapters, Standby Adapters, and Unused Adapters lists, as shown in Figure 3.30.

6. Click OK and then click Close.

Figure 3.29 The Failover Order policy allows for the designation of active, standby, and unused network adapters for a NIC team.

Figure 3.30 Failover order for a NIC team is determined by the order of network adapters as listed in the Active Adapters, Standby Adapters, and Unused Adapters lists.

When a failover event occurs on a vSwitch with a NIC team, the vSwitch is obviously aware of the event. The physical switch that the vSwitch is connected to, however, will not know immediately. As shown in Figure 3.31, a NIC Team includes a Notify Switches configuration setting which, when set to Yes, will allow the physical switch to immediately learn of any of the following changes:

? A virtual machine is powered on (or any other time a client registers itself with the vSwitch)

? A VMotion occurs

? A MAC address is changed

? A NIC team failover or failback has occurred

Figure 3.31 The Notify Switches option allows physical switches to be notified of changes in NIC teaming configurations.

In any of these events, the physical switch is notified of the change using the Reverse Address Resolution Protocol (RARP). RARP updates the lookup tables on the physical switches and offers the shortest latency when a failover event occurs.

Although the VMkernel works proactively to keep traffic flowing from the virtual networking components to the physical networking components, VMware recommends taking the following actions to minimize networking delays:

? Disable Port Aggregation Protocol (PAgP) and Link Aggregation Control Protocol (LACP) on the physical switches

? Disable Dynamic Trunking Protocol (DTP) or trunk negotiation

? Disable Spanning Tree Protocol (STP)

Оглавление книги