Shulou(Shulou.com)06/01 Report--

The following brings you how to achieve network load balancing and redundancy through bonding technology, hoping to give you some help in practical application. Load balancing involves more things, there are not many theories, and there are many books on the Internet. Today, we will use the accumulated experience in the industry to do an answer.

The second mode: mod=1, namely: (active-backup) Active-backup policy (master-backup strategy) feature: only one device is active, when one goes down and the other is immediately switched to the primary device by backup. The mac address is externally visible, and from the outside, the MAC address of the bond is unique to avoid confusion in the switch (switch). This mode only provides fault tolerance; thus it can be seen that the advantage of this algorithm is that it can provide high availability of network connections, but its resource utilization is low, only one interface is working, and when there are N network interfaces, the resource utilization rate is 1max N

The third mode: mod=2, namely: (balance-xor) XOR policy (balancing strategy)

Features: data packets are transmitted based on the specified transmission HASH policy. The default policy is: (source MAC address XOR destination MAC address)% number of slave. Other transport policies can be specified through the xmit_hash_policy option, which provides load balancing and fault tolerance

The fourth mode: mod=3, namely: broadcast (broadcast strategy)

Features: transmitting each packet on each slave interface, this mode provides fault tolerance

The fifth mode: mod=4, namely: (802.3ad) IEEE 802.3ad Dynamic link aggregation (IEEE 802.3ad dynamic link aggregation)

Features: create an aggregation group that shares the same speed and duplex settings. Multiple slave work under the same active polymer according to the 802.3ad specification.

The slave election for outbound traffic is based on the transport hash policy, which can be changed from the default XOR policy to other policies through the xmit_hash_policy option. It should be noted that not all transmission strategies are 802.3ad adaptive, especially considering the packet disorder mentioned in section 43.2.4 of 802.3ad standard. Different implementations may have different adaptations. Necessary conditions:

Conditional 1:ethtool supports getting the rate and duplex settings for each slave

Conditional 2:switch (switch) supports IEEE 802.3ad Dynamic link aggregation

Condition 3: most switch (switches) require specific configuration to support 802.3ad mode

The sixth mode: mod=5, namely: (balance-tlb) Adaptive transmit load balancing (Adapter Transport load balancing)

Features: do not need any special switch (switch) support channel bonding. Outbound traffic is allocated on each slave based on the current load (based on speed). If the slave that is receiving data fails, another slave takes over the MAC address of the failed slave. A necessary condition for this mode: ethtool supports getting the rate of each slave

The seventh mode: mod=6, namely: (balance-alb) Adaptive load balancing (Adapter Adaptive load balancing)

Features: this mode includes balance-tlb mode, plus receiving load balancing (receive load balance, rlb) for IPV4 traffic, and does not require any switch (switch) support. Receiving load balancing is implemented through ARP negotiation. The bonding driver intercepts the ARP reply sent by the local machine and rewrites the source hardware address to the unique hardware address of a slave in the bond, so that different peers use different hardware addresses to communicate.

The received traffic from the CVM will also be balanced. When the local ARP request is sent, the bonding driver copies and saves the IP information of the peer from the ARP package. When the ARP reply arrives from the peer

The bonding driver extracts its hardware address and initiates an ARP reply to a slave in the bond. One of the problems with using ARP negotiation for load balancing is that every time an ARP request is broadcast, the hardware address of bond will be used, so after the peer learns this hardware address, the received traffic will be all the current slave of Liu Xiang. This problem is solved by sending updates (ARP replies) to all peers, which contain their unique hardware addresses, resulting in a redistribution of traffic. Received traffic is also redistributed when a new slave is added to the bond, or when an inactive slave is reactivated. The received load is sequentially distributed (round robin) on the fastest slave in the bond

When a link is reconnected, or a new slave is added to the bond, received traffic is redistributed across all currently active slave, and an ARP reply is initiated for each client using the specified MAC address. The updelay parameter described below must be set to a value greater than or equal to the switch (switch) forwarding delay to ensure that ARP replies sent to the peer will not be blocked by switch (switch). Necessary conditions:

Conditional 1:ethtool supports getting the rate of each slave

Condition 2: the underlying driver supports setting the hardware address of a device so that there is always a

Slave (curr_active_slave) uses the hardware address of bond while ensuring that the slave in each bond has a unique hardware address. If curr_active_slave fails, its hardware address will be taken over by the newly selected curr_active_slave

In fact, the difference between mod=6 and mod=0: mod=6, first fill up eth0 traffic, then occupy

If you use eth3,....ethX; and mod=0, you will find that the traffic of both ports is very stable, basically the same bandwidth. On the other hand, mod=6 will find that the first port has a high traffic flow, and the second port accounts for only a small part of the traffic.

2. Bonding driver options

The options for the Bonding driver are set by specifying parameters at load time. It can be specified through the command line arguments of the insmod or modprobe command, but it is usually specified in the / etc/modprobe.conf configuration file, or in another configuration file

The available bonding driver parameters are listed below. If the parameter is not specified, the driver uses the default parameter. When you first configure bond, it is recommended that you run "tail-f" in a terminal window

/ var/log/messages "to observe the error message of the bonding driver [Note: / var/log/messages generally prints debugging information in the kernel]

Some parameters must be set correctly, such as miimon, arp_interval and arp_ip_target, otherwise it will lead to serious network performance degradation in the event of link failure. Very few devices do not support miimon, so there is no reason not to use them.

Some options support not only text value setting, but also numerical setting for compatibility reasons. For example, "mode=802.3ad" and "mode=4" have the same effect.

Specific parameter list: 1) primay

Specify which slave is the master device (primary device), with a value of a string, such as eth0,eth3, etc. As long as the specified device is available, it will always be the active slave. Devices are switched only when the primary device (primary device) is disconnected. This is useful in situations where you want a slave device to be preferred, for example, a slave device has a higher throughput

Note: the primary option is only valid for active-backup mode

2) updelay

Specifies the wait time, in milliseconds, before activating a link when a link is found to be restored. This option is valid only for miimon link snooping. The updelay should be an integral multiple of the miimon value, and if not, it will be rounded down to the nearest integer. The default is 0

3) arp_interval

Specifies the frequency of ARP link monitoring in milliseconds (ms). If APR monitoring works in Ethernet compatibility mode (mode 0 and mode 2), the switch (switch) needs to be configured to distribute network packets evenly on all links. If the switch (switch) is configured to distribute network packets in XOR mode, all replies from the ARP destination will be received by other devices on the same link, which will cause other devices to fail. ARP monitoring should not be used in conjunction with miimon. Setting to 0 disables ARP monitoring. The default is 0

4) arp_ip_target

Specify a set of IP addresses for ARP monitoring destinations, which are valid only when arp_interval > 0. These IP addresses are the targets of ARP requests and are used to determine whether the link to the destination address is functioning properly. The setting is in ddd.ddd.ddd.ddd format. Multiple IP addresses are separated by commas. Specify at least one IP address. You can specify up to 16 IP addresses. The default value is no IP address

5) downdelay

Specify a time, in milliseconds (ms), to wait for a link failure and then disable an slave. This option is valid only for miimon monitoring. The downdelay value should be an integral multiple of the Miimon value, otherwise it will be rounded to the nearest integer multiple. The default is 0

6) lacp_rate

Specify the rate at which we want the link to transfer LACPDU packets from end to end in 802.3ad mode. Possible options:

(1) slow or 0

Request the peer to transmit LACPDU (2) fast or 1 every 30 seconds

The default value of LACPDU (3) for every 1s transmission of the requesting peer is slow.

7) max_bonds

Specifies the number of bonding devices to create for the bonding driver. For example, if the max_bonds is 3 and the bonding driver has not been loaded, then the bond0,bond1,bond2 will be created. The default is 1

6) miimon

Specifies the frequency of MII link monitoring in milliseconds (ms). This will determine the frequency at which the driver checks each slave link state.

0 disables MII link monitoring. 100 can be used as a good initial reference. Below.

The use_carrier option will affect if the link state is detected. For more information, please refer to the "High Reliability" section. The default is 0

8) mode

Specifies the policy for bonding. The default is balance-rr (round robin, round robin). The optional mode includes: 0, 1, 2, 3, 4, 5, 5, 6.

3. Bonding link monitoring method.

The official document says that there are two methods of link monitoring (note: these two monitoring cannot be used at the same time)

The first: miimon (this is the most common method, which uses the system's mii-tool command for monitoring)

Module load setting (/ etc/modprobe.conf): # Start of bonding configure alias bond0 bonding

Options bond0 miimon=100 mode=1

Note: using cat / proc/net/bonding/bond0, you can view the Bonding Mode: load balancing (round-robin) status

Options bond0 miimon=100 mode=0

Note: using cat / proc/net/bonding/bond0, you can view the status of Bonding Mode: load balancing ((active-backup))

Root@Web:~# mii-tool

Eth0: negotiated 100baseTx-HD, link ok eth3: negotiated 100baseTx-HD, link ok

Missing points: this method can only monitor the link between the switch and the network card; if the link outside them is down and there is no problem with the switch itself, that is to say, your network card and the switch are still in UP state, it will not think that the network is interrupted. Unless your network card is in DOWN state, it will transfer the link to another network card, just like unplugging the network cable, or shutdown the switch port.

Second: arp (this method is more practical, you can think of it as the ping of arp (layer 2 ping), but it may put some pressure on the gateway)

Module loading:

Alias bond0 bonding

The options bond0 arp_interval=100 arp_ip_target=192.168.1.1 mode=active-backup primary=eth0 is parsed as follows:

Arp_interval=100, which indicates the detection time of arp, which is equivalent to the function of miimon=100

Arp_ip_target=192.168.1.1, which indicates the target IP detected by arp, must be the same IP address range, preferably the gateway

Note: if you can't use arp to ping the gateway, you will down and up in / proc/net/bonding/bond0.

Advantages: using the arp method, if there is a problem on the switch and the network is blocked, it will transfer the link to another network card, but either way, if there is a problem on the first network card, the link will be transferred to

After the second block, if the first block returns to normal, the link itself will not recover.

Binding of multiple network cards:

Help multiple network cards into a virtual network card, and use the virtual network card for data transmission, the speed is N times faster than the network card in theory.

Eth0---\

-bond010.1.1.21->

Eth3---/

Physical connection diagram:

Eth0---\

-switch

Eth3---/

Must:

Bind the network card model, the speed should be the same.

Rhel6:

1. Load the driver module used by the corresponding binding network card.

# modprobe bonding mode=0 miimon=100

Mode sets the working mode

0 load balancing mode (two network cards are used at the same time, so the bandwidth is doubled in theory)

1 High availability mode (one network card works, the other network card is standby)

Miimon=100 detects the network card every 100ms.

2. Activate the virtual network card (the bound logical network card, which will be configured with IP later. The physical network card does not need to be configured with IP).

Rhel6 must first turn off NetworkManager:

# service NetworkManager stop

# chkconfig NetworkManager off

# ifconfig bond0 10.1.1.28netmask 255.255.255.0 up

# ifenslave bond0 eth0 eth3

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.