CN101610283B - Method for balancing dynamic receiving load under network card binding state - Google Patents

Abstract

The present invention provides a method for dynamic receiving load balancing in a network card binding state. The method is to solve the problem of receiving load balancing in the network card binding state. It is necessary to make statistics on the data flow received by each slave, and perform regular detection on the flow. When it is detected that the receiving flow of the network card is unbalanced, some clients are required to change the MAC address corresponding to the server IP in their ARP cache by sending an ARP reply packet to the client, and the flow distribution from the client to each network card of the server is changed to achieve dynamic receiving load balancing. By regularly performing statistical analysis on the IP packet flow received by each slave in bonding, an ARP reply packet is sent to some clients in the case of unbalanced slave flow, so that they are required to change the MAC address corresponding to the server IP in the ARP cache, thereby achieving dynamic balancing of the receiving flow of the network card bound to the server.

Description

A method of dynamically receiving load balancing in the state of network card binding

technical field

The invention relates to the field of computer systems and communication technologies, in particular to a method for dynamic load balancing in a network card binding state. the

technical background

There are usually multiple network cards installed on the server. In order to improve the transmission bandwidth and link redundancy, the network card binding technology is usually used to bind multiple network cards into a virtual device and set a unified IP to provide external services. In the Linux system, the kernel itself has its own network card binding function, with 6 binding modes, and the Adaptive load balancing (alb) mode is widely used because it has no special requirements for the switch and can achieve the balance of sending and receiving. the

In the bonding module of the linux kernel, in Adaptive load balancing (alb) mode, the sending device is selected by making statistics on the amount of data sent, so the effect of sending balancing is ideal. According to its documentation, it also has the ability to balance the receiving traffic, but in actual use, for example, when two network cards are bound, only one network card will receive data. Analyzing its code, it can be found that the bonding module receives data by assigning different network cards to each client, but does not make statistics on the received traffic. It is difficult to achieve real receiving load balancing when the client traffic varies greatly. . the

Contents of the invention

The purpose of the present invention is to provide a method for dynamically receiving load balancing in the network card binding state. the

The purpose of the present invention is achieved in the following manner. In order to solve the problem of receiving load balance under the network card binding state, it is necessary to make statistics on the data traffic received by each slave, and perform regular detection of the traffic. When the traffic is unbalanced, send arp reply packets to the client to make some clients change the mac address corresponding to the server ip in their arp cache, and change the traffic distribution from the client to each network card of the server to achieve dynamic receiving load balancing . the

By statistically analyzing the flow of IP packets received by each slave in bonding, and sending arp reply packets to some clients when the flow of the slave is unbalanced, it will change the mac address corresponding to the server IP in the arp cache, thereby Realize the dynamic balance of the received traffic of the network card bound on the server, the specific steps are as follows:

1) Add a traffic analysis process in the receiving function ip_rcv of the ip layer, count the traffic of ip_src, ip_dst, and slave triplets, and extract the source ip, destination ip, and slave receiving the packet from skb. The traffic in ip_src, ip_dst, and slave is accumulated;

2) In the bonding module, the timer processing function bond_alb_monitor in the alb mode judges whether the receiving traffic of each slave is balanced according to the traffic statistics of ip_src, ip_dst and slave, and sends arp reply packets to some clients unbalanced, so that The client changes the mac corresponding to the server ip in its arp cache to realize the redistribution of client traffic on each slave. the

The beneficial effect of the invention is: in the case of relatively large differences in client flow, real receiving load balancing can be achieved. the

Description of drawings

Attached Figure 1 is a storage structure diagram of rlb_client_recv_info;

Accompanying drawing 2 is the flow chart of calculating and adjusting the unbalance degree in the timer processing function of alb. the

Detailed ways

The method of the present invention is described in detail below with reference to the accompanying drawings. the

In order to facilitate statistics on traffic, the following data structures need to be defined:

c) The data structure rlb_client_recv_info that records traffic received from each client includes the following members:

ip_src /*client ip address*/

ip_dst /*server ip address*/

mac_src /* client mac address */

load /*Data traffic received in a detection cycle*/

slave /*The network card assigned to this client to receive data*/

The traffic information of the same slave client is organized in the form of a two-way linked list, so each bond has the same number of linked lists as its slaves to record the traffic information received from all clients. the

d) Record the array rlb_slave_recv_info of each slave traffic in a period, and the traffic of each slave is obtained by accumulating the traffic of the same slave in the rlb_client_recv_info structure. the

In order to perform statistics and dynamic balance on traffic, the following processes are required:

(3) Add the traffic statistics process in the receiving function ip_rcv of the ip layer, and accumulate the lengths of the received ip packets. the

You can get the source ip, destination ip, ip packet length of the ip packet from the parameter skb of ip_rcv, and the network card that receives this packet, and then accumulate the received traffic load in the corresponding rlb_client_recv_info. the

(4) In the timer processing function bond_alb_monitor of the alb balance method, the traffic of each slave is counted every 10 seconds (can be specified by the user when loading the module), and the traffic is checked to see if the traffic is balanced. The slave allocated by each client adjusts and sends an arpreply packet to this client. the

●Accumulate the received traffic of rlb_client_recv_info of the same slave to calculate the received traffic rlb_slave_recv_info of each slave, and calculate its imbalance as follows:

i Find the average value of the cumulative sum of all slave received traffic rlb_slave_recv_average_load

ii Find the absolute value of the difference between each slave and the above average value, and sum the absolute difference of each slave, and then average the sum

iii Divide the average difference in ii by the average in i to calculate its percentage, if it exceeds the threshold of 20%, it needs to be adjusted. This threshold can be adjusted through testing. the

If there is no need to adjust the traffic, clear the received traffic in each rlb_client_recv_info for the next statistical calculation. the

If adjustment is required, adjust the receiving slave assigned by each client as follows:

(i) Sort the rlb_client_recv_info elements in the doubly linked list of the same slave according to the received traffic from large to small, and delete the elements with zero traffic. the

(ii) Delete the rlb_client_recv_info element in the doubly-linked list of the slave that receives traffic exceeding rlb_slave_recv_average_load from the minimum traffic, and add it to a temporary linked list temp_client_list until the cumulative load value of the remaining rlb_client_recv_info elements of the slave just exceeds rlb_slave_recv_average_load, if Remove one more element below this value. the

(iii) Sort the elements in the tmp_client_list from large to small according to the load value, and then add its elements to the linked list of slaves whose received traffic is lower than rlb_slave_recv_average_load (starting from the slave with the smallest received traffic)

(iv) According to the adjusted rlb_client_recv_info linked list of each slave, use the method of step 1 to calculate its unbalanced degree. If the unbalanced degree meets the requirements, proceed to the next step. Otherwise, continue to adjust the maximum iterations based on the adjusted result 3 times, if it still does not meet the balance requirements, then give up the adjustment and go directly to the next step

(v) Send an arp reply packet to each client whose assigned slave changes, so that the Mac corresponding to the server ip in the client's arp cache points to the newly assigned slave. The mac address of each client has been recorded in the original alb implementation and can be used directly without additional acquisition. Finally, clear the received traffic in each rlb_client_recv_info. the

Claims (1)

1. A method for dynamically receiving load balancing under a network card binding state, characterized in that, by regularly performing statistical analysis on the ip packet traffic received by each slave in the bonding, some customers will be provided under the unbalanced situation of the slave traffic The terminal sends an arp reply packet to change the mac address corresponding to the server ip in the arp cache, so as to realize the dynamic balance of the received traffic of the network card bound on the server. The specific steps are as follows: 1) Add a traffic analysis process in the receiving function ip_rcv of the ip layer, count the traffic of ip_src, ip_dst, and slave triplets, and extract the source ip, destination ip, and slave receiving the packet from skb. The traffic in ip_src, ip_dst, and slave is accumulated; 2) In the bonding module, the timer processing function bond_alb_monitor in the alb mode judges whether the receiving traffic of each slave is balanced according to the traffic statistics of ip_src, ip_dst and slave, and sends arp reply packets to some clients unbalanced, so that The client changes the mac corresponding to the server ip in its arp cache to realize the redistribution of client traffic on each slave; 3) Define the following data structures: a) Record the data structure rlb_client_recv_info of traffic received from each client, including the following: ip_src /*client ip address*/ ip_dst /*server ip address*/ mac_src /* client's mac address */ load /*Data traffic received in a detection cycle*/ slave /*The network card assigned to this client to receive data*/ Organize the traffic information of the same slave client in the form of a two-way linked list, and each bond will have the same number of linked lists as its slaves to record the traffic information received from all clients; b) Record the array rlb_slave_recv_info of each slave traffic in a period, and the traffic of each slave is obtained by accumulating the traffic of the same slave in the rlb_client_recv_info structure; 4) Statistical and dynamic balancing of traffic requires the following process: (1) add the traffic statistics process in the receiving function ip_rcv of the ip layer, and accumulate the length of the received ip packets; Obtain the source ip, destination ip, ip packet length of the ip packet from the parameter skb of ip_rcv, and the network card that receives this packet, and then accumulate the received traffic load in the corresponding rlb_client_recv_info; (2) In the timer processing function bond_alb_monitor of the alb balance method, every 10 seconds or specified by the user when loading the module, the traffic of each slave is counted, and whether the traffic is balanced is detected. Adjust the slave assigned by each client and send an arp reply packet to this client; Accumulate the received traffic of rlb_client_recv_info of the same slave to calculate the received traffic rlb_slave_recv_info of each slave, and calculate its imbalance as follows: i Calculate the average value of the cumulative sum of all slave received traffic rlb_slave_recv_average_load; ii Find the absolute value of the difference between each slave and the above average value, and sum the absolute difference of each slave, and then average the sum; iii Divide the average difference in step ii by the average value in i, and calculate its percentage. If it exceeds the threshold of 20%, it needs to be adjusted. This threshold is adjusted by testing, and the steps are as follows: 1) If there is no need to adjust the traffic, clear the received traffic in each rlb_client_recv_info for the next statistical calculation; 2) If adjustment is required, adjust the receiving slave assigned by each client in the following manner: (i) Sort the rlb_client_recv_info elements in the doubly linked list of the same slave according to the received traffic from large to small, and delete the elements with zero traffic; (ii) Delete the rlb_client_recv_info element in the doubly-linked list of the slave that receives traffic exceeding rlb_slave_recv_average_load from the minimum traffic, and add it to a temporary linked list tmp_client_list until the cumulative load value of the remaining rlb_client_recv_info elements of the slave just exceeds rlb_slave_recv_average_load, if One more element removed is lower than this value; (iii) Sort the elements in the tmp_client_list from large to small according to the load value, and then poll their elements and add them to the linked list of the slave whose traffic is lower than rlb_slave_recv_average_load; (iv) According to the adjusted rlb_client_recv_info linked list of each slave, use the method of step (i) to calculate its unbalanced degree. If the unbalanced degree meets the requirements, proceed to the next step. Otherwise, continue to adjust the maximum iterations based on the adjusted result 3 times, still does not meet the balance requirements, then give up the adjustment and go directly to the next step; (v) Send an arp reply packet to each client whose assigned slave has changed, so that the Mac corresponding to the server ip in the client's arp cache points to the newly assigned slave, and the mac address of each client has been recorded in the original alb implementation , direct use without additional acquisition, and finally clear the received traffic in each rlb_client_recv_info. the

Images