LVS balanced scheduling method and device, equipment and storage medium

Abstract

The invention discloses an LVS balanced scheduling method and device, equipment and a storage medium. The method is used in a load balancing system, the load balancing system comprises an NIC, a kernel module and an LVS module, the NIC is arranged in a physical layer, the LVS module is arranged in an L3 layer of a kernel layer, and the kernel module is registered on an L2 hook of a Netfilter of the kernel layer; the method comprises the steps that a kernel module obtains a first data packet delivered by an NIC and performs protocol analysis, the kernel module allocates a virtual IP to the first data packet and completes packaging to form a second data packet, an LVS module schedules the second data packet to form a third data packet, and the kernel module analyzes the third data packet and changes the IP into a current device IP. According to the invention, all users in the LAN can be ensured to be reasonably dispersed and scheduled to different back-end servers, and the native integrity of the LVS is ensured.

Description

Technical Field

[0001] The present invention relates to the field of communication control, and more particularly, to an LVS load balancing scheduling method, apparatus, device, and storage medium. Background Art

[0002] With the rapid development of the Internet and cloud computing, highly available and high-performance network services have become a key requirement for modern enterprise-level applications. To meet this demand, load balancing (LB) technology has emerged, aiming to improve the system's response speed, reliability, and resource utilization by reasonably allocating traffic. LVS (Linux VirtualServer), with its excellent performance and flexibility, has been widely used in many fields and is often used as the underlying infrastructure for other LBs.

[0003] Currently, almost all NAT types of routers are NAT3 and NAT4, which enable devices within a LAN to share one or more export IPs to complete services. If the "source address hashing scheduling" is used, all users within the LAN will be scheduled to the same or a fixed number of backend Servers, thus failing to achieve balanced scheduling of the backend server cluster. If "round-robin scheduling", "weighted round-robin scheduling", "least-connection scheduling", etc. are used, although the backend server cluster is balancedly scheduled, the two consecutive data packets of the same user within the LAN are very likely to be scheduled to different backend Servers, which obviously does not meet the requirements for server usage.

[0004] Currently, there are two solutions to this problem:

[0005] 1. By modifying the LVS source code, implement a hashing scheduling algorithm for source IP: source port + protocol;

[0006] 2. By using an LB device above L4, distinguish different users within the service types at the application layer, thereby achieving balanced scheduling.

[0007] However, both of these solutions have their respective drawbacks:

[0008] The first solution implements a customized LVS, which makes LVS lack generality, increases the deployment and migration costs of LB devices on different platforms and different systems, and increases the maintenance difficulty; secondly, other technologies and tools in the kernel that interact with LVS may no longer communicate with the "customized LVS"; the biggest drawback is that each time LVS is modified or updated, the kernel needs to be recompiled and the entire system needs to be restarted, which has a great impact on the business.

[0009] The second solution is to use an "application layer LB device" to meet a "kernel layer LB requirement". This is an overkill. The performance and stability of the application layer LB are weaker than the kernel layer LVS. Summary of the Invention

[0010] In order to overcome at least one of the above-mentioned defects of the prior art, the present invention provides an LVS balanced scheduling method, device, equipment and storage medium. The technical solution adopted by the present invention is as follows.

[0011] In a first aspect, the present invention provides an LVS balancing scheduling method, which is used in a load balancing system. The load balancing system includes: a NIC, a kernel module, and an LVS module.

[0012] Among them, NIC is set in the physical layer, LVS module is set in the L3 layer of the kernel layer, and the kernel module is registered on the L2 hook of Netfilter in the kernel layer;

[0013] The LVS balanced scheduling method includes:

[0014] The NIC receives the data and delivers it to the data link layer;

[0015] The kernel module obtains the first data packet delivered by the NIC, performs protocol parsing, and obtains a Tuple Node, wherein the Tuple Node includes the following items: source IP address, source port number, destination IP address, destination port number, and protocol type.

[0016] The kernel module allocates a virtual IP to the first data packet and generates a VirtualNode according to the Tuple Node, wherein the VirtualNode changes the content in the source IP entry of the Tuple Node to the allocated virtual IP;

[0017] The kernel module rewrites the content of the VirtualNode into the data packet according to the protocol standard, completes the protocol encapsulation, and forms a second data packet;

[0018] The LVS module schedules the second data packet, keeps the content in the source IP entry of the second data packet unchanged, and changes the content in the destination IP entry to form a third data packet;

[0019] The kernel module parses the third data packet and generates a Device Node based on the Virtual Node. The module then performs subsequent protocol encapsulation and sends the packet to the corresponding server via the NIC. The Device Node then changes the source IP address of the received Virtual Node to the current device IP address.

[0020] Among them, the process of the kernel module allocating a virtual IP to the first data packet includes:

[0021] Check the Tuple Node of the first data packet, and determine whether a virtual IP has been allocated for the source IP and source port according to the Tuple Node of the first data packet;

[0022] If a virtual IP has been allocated, re-allocate the allocated virtual IP; otherwise, allocate a new virtual IP.

[0023] In an implementation, the process of determining whether a virtual IP has been allocated for the source IP and source port according to the Tuple Node of the first data packet is replaced by: determining whether a virtual IP has been allocated for a Tuple Node that is the same as the Tuple Node of the first data packet.

[0024] In an implementation, it further includes: establishing a mapping record of "Tuple Node to Virtual Node" and storing it in Table A.

[0025] In an implementation, it further includes: establishing a mapping record of "Virtual Node to Device Node" and storing it in Table B.

[0026] In an implementation, it further includes:

[0027] When the NIC receives the original reply data packet from the server, the kernel module performs verification, protocol parsing, and decapsulation on the reply data packet to obtain the Device Node;

[0028] The kernel module queries the corresponding mapping record in Table B according to the Device Node to obtain the VirtualNode;

[0029] The kernel module rewrites the Virtual Node into the data packet according to the protocol standard, completes the protocol encapsulation, and forms a second reply data packet;

[0030] The LVS module schedules the second reply data packet, keeps the content in the source IP entry of the second reply data packet unchanged, changes the content in the destination IP entry, and forms a third reply data packet;

[0031] The kernel module parses the third reply data packet to obtain the Virtual Node;

[0032] The kernel module queries the corresponding mapping record in Table A according to the VirtualNode to obtain the Tuple Node;

[0033] The kernel module completes data rewriting and protocol encapsulation according to the content of the Tuple Node and sends it through the NIC.

[0034] In one implementation, the process of the kernel module allocating a virtual IP to the first data packet further includes:

[0035] When a virtual IP is allocated, increment the count of this virtual IP by one;

[0036] After a virtual IP is allocated, if there is no data connection within a preset time, decrement the count of this virtual IP by one;

[0037] Allocate a virtual IP to the first data packet according to the count values of each virtual IP in the virtual IP pool.

[0038] In one implementation, the load balancing system further includes: an MGR module, and the MGR module is set in the user layer;

[0039] Before the kernel module allocates a virtual IP to the first data packet, it further includes:

[0040] The kernel module matches the Tuple Node and the MGR in the Tuple Table in the kernel module, and when the match is successful, allocates a virtual IP to the first data packet.

[0041] In a second aspect, the present invention provides an LVS load balancing scheduling device, including: a NIC, a kernel module, and an LVS module,

[0042] wherein, the NIC is set in the physical layer, the LVS module is set in the L3 layer of the kernel layer, and the kernel module is registered on the L2 hook of Netfilter in the kernel layer;

[0043] The NIC is used to receive data and deliver the data to the data link layer;

[0044] The kernel module is used to obtain the first data packet delivered by the NIC, perform protocol parsing to obtain a Tuple Node, where the Tuple Node includes entries: source IP, source Port, destination IP, destination Port, protocol type; and allocate a virtual IP to the first data packet, and generate a Virtual Node according to the Tuple Node. In the Virtual Node, the content in the source IP entry of the Tuple Node is changed to the allocated virtual IP; rewrite the content of the Virtual Node into the data packet according to the protocol standard to complete protocol encapsulation and form a second data packet;

[0045] The LVS module is used to schedule the second data packet, keep the content in the source IP entry of the second data packet unchanged, change the content in the destination IP entry, and form a third data packet;

[0046] The kernel module is further used to parse the third data packet and generate a DeviceNode according to the Virtual Node to complete subsequent protocol encapsulation. Among them, the content in the source IP entry of the received Virtual Node in the Device Node is changed to the current device IP

[0047] The NIC is also used to send the data encapsulated by the kernel module to the corresponding server;

[0048] Among them, the process of the kernel module allocating a virtual IP for the first data packet includes:

[0049] Check the Tuple Node of the first data packet, and judge whether a virtual IP has been allocated for the source IP and source port according to the Tuple Node of the first data packet;

[0050] If a virtual IP has been allocated, then allocate the allocated virtual IP again; otherwise, allocate a new virtual IP.

[0051] In a third aspect, the present invention provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the method of any of the above embodiments is implemented.

[0052] In a fourth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored, characterized in that when the program is executed by a processor, the method of any of the above embodiments is implemented.

[0053] In the present invention, without changing the originality of LVS, by setting a kernel module for efficient data processing in the data link layer of the kernel, the kernel module generates a virtual IP pool, generates different virtual IPs according to different users' data, and then allows LVS to generate different destination IPs and ports according to the virtual IPs, so as to ensure that all users within the LAN will be reasonably and dispersedly scheduled to different backend servers, and at the same time ensure that the front and back two data of the same user within the LAN are scheduled to the same backend server, and ensure the original integrity of LVS, and ensure the high efficiency of data processing in the kernel, and can also achieve dynamic loading, quick update, without recompiling the kernel or restarting the system. Description of the Drawings

[0054] Figure 1 It is a network topology diagram of LB deployment in Embodiment 1 of the present invention.

[0055] Figure 2 It is the framework diagram of the load balancing system according to the first embodiment of the present invention.

[0056] Figure 3 It is the schematic diagram of the judgment process of an implementation manner according to the first embodiment of the present invention.

[0057] Figure 4 It is the schematic diagram of the node of the data packet scheduling according to the first embodiment of the present invention. Detailed implementation manners

[0058] Hereinafter, the exemplary embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art.

[0059] It should be noted that the terms "first / second / ..." involved in the embodiments of the present invention are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first / second / ..." can be interchanged in a specific order or sequence when allowed. It should be understood that the objects distinguished by "first / second / ..." can be interchanged under appropriate circumstances so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein.

[0060] First embodiment

[0061] Figure 1 It is a network topology diagram for a common LB deployment. User is mapped by Router to the same source IP and different source ports. The access reaches the LB and is evenly scheduled to the servers in the backend cluster after being processed by the kernel module and LVS of the LB server. The reply data of the servers in the cluster returns to the LB through routing. After the LVS and kernel module processing are completed in the LB, the original network layer information is restored and finally returns to the User through the Router. Neither the User, LVS, nor the cluster servers are aware during the entire link. This method is used in Figure 2 the LB of.

[0062] Figure 2 It is the framework diagram of this load balancing system. This load balancing system LB is deployed on a physical machine or a virtual machine. The load balancing system includes: NIC, kernel module, and LVS module; wherein, the NIC is set at the physical layer, the LVS module is set in the L3 layer of the kernel layer, and the kernel module is registered on the L-2 hook of Netfilter in the kernel layer.

[0063] In the LVS (Linux Virtual Server) processing, L2 and L3 at the kernel layer are usually related to the network protocol layer, and their specific meanings are as follows:

[0064] L2 (Layer 2): L2 refers to the second layer of the network, that is, the data link layer. In the data link layer, network communication is mainly forwarded based on MAC addresses. The working mode of LVS at the L2 layer is similar to that of a switch, and it realizes load balancing by operating on the MAC addresses of data packets. For example, in the DR (Direct Routing) mode of LVS, the load balancer will modify the MAC address of the data packet and forward the request to the backend server while keeping the IP address unchanged.

[0065] L3 (Layer 3): L3 refers to the third layer of the network, that is, the network layer. In the L3 layer, network communication is routed and forwarded based on IP addresses. The working mode of LVS at the L3 layer is similar to that of a router, and it realizes load balancing by modifying IP addresses. For example, in the NAT (Network Address Translation) mode of LVS, the load balancer will modify the destination IP address of the data packet and forward the request to the backend server.

[0066] The NIC receives the physical frame, first delivers it to the kernel module to complete verification, protocol parsing, virtual IP allocation, mapping construction, data rewriting, and protocol encapsulation, then delivers it to LVS for processing, and then, after the kernel module performs Device IP replacement, mapping construction, data rewriting, and protocol encapsulation, the NIC completes the sending. Similarly, when receiving the response packet from the server, it will go through a series of operations such as Virtual IP restoration, LVS processing, and Real IP restoration by the kernel module, and the NIC completes the sending and finally reaches the user. The administrator only needs to configure the Tuple {destination IP, destination PORT, protocol type} to be scheduled through the MGR, which supports dynamic configuration, and can also expand functions such as user whitelist filtering and data rate limiting.

[0067] Please refer to Figure 3 , Figure 3 which is a schematic flowchart of an LVS load balancing scheduling method provided in Embodiment 1 of the present invention. The method includes steps S110, step S120, step S130, step S140, step S150, and step S160. It should be noted that steps S110, S120, S130, S140, S150, and S160 are only reference numerals used to clearly explain the correspondence between the embodiments and the Figure 3 accompanying drawings, and do not represent a limitation on the order of each step in this embodiment.

[0068] Step S110: The NIC receives data and delivers the data to the data link layer;

[0069] Step S120: The kernel module obtains the first data packet delivered by the NIC, performs protocol parsing, and obtains a Tuple Node. Among them, the Tuple Node includes entries: source IP, source Port, destination IP, destination Port, and protocol type;

[0070] Step S130: The kernel module assigns a virtual IP to the first data packet and generates a VirtualNode according to the Tuple Node. In the Virtual Node, the content in the source IP entry of the Tuple Node is changed to the assigned virtual IP;

[0071] Step S140: The kernel module rewrites the content of the Virtual Node into the data packet according to the protocol standard, completes protocol encapsulation, and forms a second data packet;

[0072] Step S150: The LVS module schedules the second data packet, keeps the content in the source IP entry of the second data packet unchanged, and changes the content in the destination IP entry to form a third data packet;

[0073] Step S160: The kernel module parses the third data packet, generates a DeviceNode according to the Virtual Node, completes subsequent protocol encapsulation, and the NIC sends it to the corresponding server. Among them, the content in the source IP entry of the received Virtual Node in the Device Node is changed to the current device IP.

[0074] Among them, the process of the kernel module in step S130 assigning a virtual IP to the first data packet includes: step S131 and step S132.

[0075] Step S131: Check the Tuple Node of the first data packet, and judge whether a virtual IP has been assigned for the source IP and source port according to the Tuple Node of the first data packet;

[0076] Step S132: If a virtual IP has been assigned, then re-assign the assigned virtual IP; otherwise, assign a new virtual IP.

[0077] The NIC receives a data frame, and the packet is normally delivered to the data link layer. The kernel module obtains the data packet. After completing various checks at the data link layer and network layer, it performs protocol parsing, obtains the destination IP, destination Port, and transport layer protocol type, sets Tuple = {destination IP, destination Port, protocol type}, and then performs virtual IP assignment and subsequent processing.

[0078] The kernel module generates a Virtual IP Pool. When each new Tuple arrives, a Virtual Node {source IP, source Port, destination IP, destination Port, protocol type} is generated for this Tuple, and a Virtual IP Address is allocated. Among them, the source IP and source port before allocation are the real addresses of the User, called RealIP and Real Port.

[0079] Figure 4 It is a schematic diagram of nodes for data packet scheduling.

[0080] Among them, upstream: User -> A -> B -> C -> D -> Server;

[0081] Downstream: Server -> d -> c -> b -> a -> User.

[0082] According to the technical solution provided by this patent, assume that the IP of the User is 50.1.1.1, the access IP of the LB is 60.6.6.6, the IP for communicating with the cluster is 172.16.100.100, and the IP of a certain server in the cluster is 172.16.15.10.

[0083] The data flow of the User accessing the service in each path of the system is as follows:

[0084]

[0085] In the above table, path B is the process of step S130, and the source IP: source Port changes from 50.1.1.1:23456 to 10.10.10.2:23456.

[0086] In the process of the kernel module allocating a virtual IP for the first data packet in step S130, when the data packet comes in, look up the virtual IP address allocation record table to determine whether it is the same user as the user served before. If it is the same user, then the source IP and source port are the same. If it is the same user, continue to allocate the previously used virtual IP address; if this data packet enters for the first time, allocate a new virtual IP address. In this way, it can be ensured that the previous and subsequent data packets of the same user can be scheduled to the same backend Server.

[0087] In one implementation, the process of the kernel module allocating a virtual IP for the first data packet further includes: step S133, step S134, and step S135.

[0088] In step S133, when a virtual IP is allocated, increment the count of this virtual IP by one;

[0089] Step S134, after a virtual IP is allocated, if there is no data connection within a preset time, decrement the count of this virtual IP by one.

[0090] Step S135, allocate a virtual IP for the first data packet according to the count values of each virtual IP in the virtual IP pool.

[0091] A section of IP addresses can be taken, or the entire 32-bit (IPv4) or 128-bit (IPv6) can be allocated. Increment the count for each allocated Virtual IP Address by 1. When this User has no data connection within a certain time, it is determined that this User has been released, so the count of this Virtual IP Address is decremented by 1. When the count reaches 0, it is released and recycled into the Virtual IP Pool. According to different service types, the timeout for the User can be flexibly set and set to the kernel module through the MGR.

[0092] During the first allocation, each Virtual IP Address is not reallocated after being allocated, that is, a new and unused Virtual IP Address is allocated backward. When all Virtual IP Addresses have been allocated, in the order of front and back, each Virtual IP Address is reallocated, and the counter of this Virtual IP Address is incremented by 1, which should be 2 at this time, and so on. This ensures balanced allocation. The source address balance here will guide LVS to also perform balanced allocation.

[0093] In one implementation, the process of determining whether a virtual IP has been allocated for the source IP and source port according to the Tuple Node of the first data packet is replaced by: determining whether a virtual IP has been allocated for a Tuple Node that is the same as the Tuple Node of the first data packet.

[0094] In this implementation, when a data packet comes in, look up the virtual IP address allocation record table to determine whether it is the same task as the previous task. If it is the same task, then the Tuple Node is the same. If it is the same task, continue to allocate the previously used virtual IP address; if this data packet enters for the first time, allocate a new virtual IP address. This way, it can be ensured that the front and back two data packets of the same user can be scheduled to the same backend Server.

[0095] Then, in step S140, the kernel module rewrites the obtained Virtual IP into the data packet according to the protocol standard. After completing the protocol encapsulation, it returns to the kernel protocol stack. In the subsequent step S150, LVS performs normal scheduling on these data packets, that is, changes the destination IP while keeping the source IP unchanged. The data packets are passed to the data link layer and then enter the kernel module for processing. At this time, Figure 4 in path C in the above table, it can be seen that the destination IP: destination Port changes from 60.6.6.6:12340 to 172.16.15.10:12340.

[0096] In the process before the data packet enters LVS, a Virtual IP is allocated to it. When it is found that this data packet is exactly the one with the Virtual IP, in step S160, the kernel module parses it again and changes its source IP to the current device IP. At this time, Figure 4 in path D in the above table, it can be seen that the source IP: source Port changes from 10.10.10.2:23456 to 172.16.100.100:23456, and then the subsequent protocol encapsulation is completed and sent by the NIC.

[0097] In one implementation, the LVS load balancing scheduling method further includes: establishing a mapping record from "Tuple Node to Virtual Node" and storing it in Table A.

[0098] In one implementation, the LVS load balancing scheduling method further includes: establishing a mapping record from "Virtual Node to Device Node" and storing it in Table B.

[0099] In one implementation, the LVS load balancing scheduling method further includes: step S210, step S220, step S230, step S240, step S250, step S260, and step S270.

[0100] In step S210, when the NIC receives the original reply data packet from the server, the kernel module verifies, parses the protocol, and decapsulates the reply data packet to obtain the Device Node;

[0101] In step S220, the kernel module queries the corresponding mapping record in Table B according to the Device Node to obtain the Virtual Node;

[0102] In step S230, the kernel module rewrites the Virtual Node into the data packet according to the protocol standard, completes the protocol encapsulation, and forms a second reply data packet;

[0103] Step S240: The LVS module schedules the second reply packet, keeps the content in the source IP entry of the second reply packet unchanged, changes the content in the destination IP entry, and forms a third reply packet.

[0104] Step S250: The kernel module parses the third reply packet and obtains the Virtual Node.

[0105] Step S260: The kernel module queries the corresponding mapping record in Table A according to the Virtual Node and obtains the Tuple Node.

[0106] Step S270: The kernel module completes data rewriting and protocol encapsulation according to the content of the Tuple Node and sends it through the NIC.

[0107] Figure 4 It is a schematic diagram of the packet scheduling node. Among them, downstream: Server -> d -> c -> b -> a -> User.

[0108] The data stream of the cluster response is:

[0109]

[0110]

[0111] If the LB receives the reply packet from the Server, similarly, it is received at the data link layer. At this time, the kernel module checks, protocol analyzes, and decapsulates the packet to obtain the Device Node {source IP, source Port, destination IP, destination Port, protocol type} information. At this time, a record can definitely be queried in Table B to obtain the VirtualNode. At this time, the Device IP is restored to the Virtual IP according to the mapping record.

[0112] The packet is delivered to the LVS. After completing the relevant work, it will be sent to the data link layer. Similarly, the kernel module protocol analyzes and decapsulates the packet to obtain the Virtual Node {source IP, source Port, destination IP, destination Port, protocol type} information. A mapping record can definitely be queried in Table A. At this time, the Real IP corresponding to the Virtual IP is queried according to the mapping record, and data rewriting and protocol encapsulation are completed according to the Real IP value, and finally it is sent through the NIC.

[0113] Finally, the packet is successfully received by the User.

[0114] In one embodiment, the load balancing system further includes: an MGR module, and the MGR module is arranged in the user layer;

[0115] Before the kernel module assigns a virtual IP to the first data packet, it further includes: step S170.

[0116] In step S170, the kernel module matches the Tuple Node with the MGR in the Tuple Table in the kernel module, and when the match is successful, it assigns a virtual IP to the first data packet.

[0117] Not all data needs to be scheduled by LVS. The LB administrator sets the IP, Port, and protocol open to user access during deployment. These {destination IP, destination Port, protocol type} are set to the kernel module through the MGR and inserted into the Tuple Table. The kernel module matches the Tuple of this packet with the Tuple Table in the kernel module set by the MGR. If the match fails, it returns it to the kernel protocol stack. If the match is successful, it performs virtual IP assignment and subsequent processing.

[0118] In this method, without changing the native nature of LVS, by setting a kernel module for efficient data processing in the data link layer of the kernel, this kernel module generates a virtual IP pool, generates different virtual IPs according to different users' data, and then allows LVS to generate different destination IPs and ports according to the virtual IPs, so as to ensure that all users within the LAN will be reasonably and dispersedly scheduled to different backend servers, and at the same time ensure that the previous and subsequent data of the same user within the LAN are scheduled to the same backend server, and ensure the native integrity of LVS, ensure the efficiency of data processing in the kernel, and can also achieve dynamic loading, quick update, without recompiling the kernel or restarting the system.

[0119] Embodiment 2

[0120] Corresponding to the method of Embodiment 1, the present invention further provides an LVS balanced scheduling device 5, including: a NIC, a kernel module, and an LVS module,

[0121] wherein, the NIC is arranged in the physical layer, the LVS module is arranged in the L3 layer of the kernel layer, and the kernel module is registered on the L2 hook of Netfilter in the kernel layer;

[0122] The NIC is used to receive data and deliver the data to the data link layer;

[0123] The kernel module is used to obtain the first data packet delivered by the NIC, perform protocol parsing to obtain a Tuple Node, where the Tuple Node includes entries: source IP, source Port, destination IP, destination Port, and protocol type; and assign a virtual IP to the first data packet, and generate a Virtual Node according to the Tuple Node. In the Virtual Node, the content in the source IP entry of the Tuple Node is changed to the assigned virtual IP; the content of the Virtual Node is rewritten into the data packet according to the protocol standard to complete protocol encapsulation and form a second data packet.

[0124] The LVS module is used to schedule the second data packet, keep the content in the source IP entry of the second data packet unchanged, and change the content in the destination IP entry to form a third data packet.

[0125] The kernel module is also used to parse the third data packet and generate a DeviceNode according to the Virtual Node to complete subsequent protocol encapsulation. In the Device Node, the content in the source IP entry of the received Virtual Node is changed to the current device IP.

[0126] The NIC is also used to send the data encapsulated by the kernel module to the corresponding server.

[0127] Among them, the process of the kernel module assigning a virtual IP to the first data packet includes:

[0128] Check the Tuple Node of the first data packet, and judge whether a virtual IP has been assigned to the source IP and source port according to the Tuple Node of the first data packet.

[0129] If a virtual IP has been assigned, then re-assign the assigned virtual IP; otherwise, assign a new virtual IP.

[0130] In one implementation, the process of judging whether a virtual IP has been assigned to the source IP and source port according to the Tuple Node of the first data packet is replaced by: judging whether a virtual IP has been assigned to a Tuple Node that is the same as the Tuple Node of the first data packet.

[0131] In one implementation, the kernel module is also used to establish a mapping record of "Tuple Node to Virtual Node" and store it in Table A.

[0132] In one embodiment, the kernel module is further configured to establish a mapping record of "Virtual Node to DeviceNode" and store it in Table B.

[0133] In one embodiment, the NIC is further configured to receive the original reply packet of the server;

[0134] The kernel module is further configured to verify, parse the protocol, and decapsulate the reply packet to obtain the DeviceNode; query the corresponding mapping record in Table B according to the Device Node to obtain the VirtualNode; rewrite the VirtualNode into the packet according to the protocol standard, complete the protocol encapsulation, and form the second reply packet;

[0135] The LVS module is further configured to schedule the second reply packet, keep the content in the source IP entry of the second reply packet unchanged, change the content in the destination IP entry, and form the third reply packet;

[0136] The kernel module is further configured to parse the third reply packet to obtain the Virtual Node; query the corresponding mapping record in Table A according to the VirtualNode to obtain the Tuple Node; complete data rewriting and protocol encapsulation according to the content of the Tuple Node;

[0137] The NIC is further configured to send the data encapsulated by the kernel module to the corresponding client.

[0138] In one embodiment, the process of the kernel module allocating a virtual IP to the first packet further includes:

[0139] When a virtual IP is allocated, increment the count of the virtual IP by one;

[0140] After a virtual IP is allocated, if there is no data connection within a preset time, decrement the count of the virtual IP by one;

[0141] Allocate a virtual IP to the first packet according to the count values of the virtual IPs in the virtual IP pool.

[0142] In one embodiment, the load balancing system further includes: an MGR module, and the MGR module is set in the user layer;

[0143] The MGR module is configured to configure the Tuple Table in the kernel module, so that before the kernel module allocates a virtual IP to the first packet, the Tuple Node is matched with the Tuple Table, and when the match is successful, the first packet is allocated a virtual IP.

[0144] In this device, without changing the native nature of LVS, by setting a kernel module for efficient data processing in the data link layer of the kernel, this kernel module generates a virtual IP pool, generates different virtual IPs according to the data of different users, and then enables LVS to generate different destination IPs and ports based on the virtual IPs. Thus, it can ensure that all users within the LAN will be reasonably and dispersedly scheduled to different backend servers, and at the same time ensure that the previous and subsequent data of the same user within the LAN are scheduled to the same backend server. Moreover, it ensures the native integrity of LVS, guarantees the high efficiency of data processing in the kernel, and can also achieve dynamic loading, rapid update, without recompiling the kernel or restarting the system.

[0145] Embodiment III

[0146] The embodiment of the present invention also provides a storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the LVS balanced scheduling method of any of the above embodiments is implemented.

[0147] Those skilled in the art can understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps including the above method embodiments; and the foregoing storage medium includes: removable storage devices, random access memory (RAM), read-only memory (ROM), magnetic disks or optical disks and other various media that can store program codes.

[0148] Alternatively, if the above integrated unit of the present invention is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present invention essentially or the part that contributes to the related technology can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a terminal, or a network device, etc.) to execute all or part of the methods of the various embodiments of the present invention. And the foregoing storage medium includes: removable storage devices, RAM, ROM, magnetic disks or optical disks and other various media that can store program codes.

[0149] Corresponding to the above computer storage medium, in an embodiment, a computer device is also provided. This computer device includes a memory, an encoder, and a computer program stored on the memory and executable on the encoder. Among them, when the encoder executes the program, it implements any one of the LVS balanced scheduling methods in the above embodiments.

[0150] The above computer device, without changing the originality of LVS, sets a kernel module for efficient data processing in the data link layer of the kernel. This kernel module generates a virtual IP pool, generates different virtual IPs according to the data of different users, and then enables LVS to generate different destination IPs and ports according to the virtual IPs, so as to ensure that all users within the LAN can be reasonably and dispersedly scheduled to different backend servers, and at the same time ensure that the previous and subsequent data of the same user within the LAN are scheduled to the same backend server. Moreover, it ensures the original integrity of LVS, the high efficiency of data processing in the kernel, and can also achieve dynamic loading, quick update, without recompiling the kernel or restarting the system.

[0151] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0152] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, rather than limitations on the implementation manners of the present invention. For those of ordinary skill in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to enumerate all implementation manners here. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present invention shall be included in the protection scope of the claims of the present invention.

Claims

1. An LVS load balancing scheduling method, characterized in that, The stated scheduling method is used in a load balancing system, which includes: NIC, kernel module, and LVS module. Among them, the NIC is set at the physical layer, the LVS module is set in the L3 layer of the kernel layer, and the kernel module is registered on the L2 hook of Netfilter in the kernel layer. The LVS load balancing scheduling method includes: The NIC receives data and delivers it to the data link layer. The kernel module obtains the first data packet delivered by the NIC, performs protocol parsing, and obtains a Tuple Node. Among them, the Tuple Node includes entries: source IP, source Port, destination IP, destination Port, and protocol type. The kernel module assigns a virtual IP to the first data packet and generates a VirtualNode according to the Tuple Node. In the Virtual Node, the content in the source IP entry of the Tuple Node is changed to the assigned virtual IP. The kernel module rewrites the content of the VirtualNode into the data packet according to the protocol standard, completes protocol encapsulation, and forms a second data packet. The LVS module schedules the second data packet, keeps the content in the source IP entry of the second data packet unchanged, and changes the content in the destination IP entry to form a third data packet. The kernel module parses the third data packet and generates a Device Node according to the VirtualNode, completes subsequent protocol encapsulation, and the NIC sends it to the corresponding server. Among them, in the Device Node, the content in the source IP entry of the received Virtual Node is changed to the current device IP. Among them, the process of the kernel module assigning a virtual IP to the first data packet includes: Check the Tuple Node of the first data packet and determine whether a virtual IP has been assigned for the source IP and source port according to the Tuple Node of the first data packet. If a virtual IP has been assigned, then assign the assigned virtual IP again; otherwise, assign a new virtual IP.

2. The LVS load balancing scheduling method according to claim 1, wherein The process of determining whether a virtual IP has been assigned for the source IP and source port according to the TupleNode of the first data packet is replaced by: determining whether a virtual IP has been assigned for a Tuple Node that is the same as the Tuple Node of the first data packet.

3. The LVS load balancing scheduling method according to claim 1 or 2, characterized in that It also includes: Establish a mapping record of "Tuple Node to Virtual Node" and store it in Table A.

4. The LVS load balancing scheduling method according to claim 3, characterized in that It also includes: ​ 5. The LVS load balancing scheduling method according to claim 4, characterized in that, ​ ​ ​ The kernel module rewrites the Virtual Node into the data packet according to the protocol standard, completes the protocol encapsulation, and forms the second reply data packet; The LVS module schedules the second reply data packet, keeps the content in the source IP entry of the second reply data packet unchanged, changes the content in the destination IP entry, and forms the third reply data packet; The kernel module parses the third reply data packet and obtains the Virtual Node; The kernel module queries the corresponding mapping record in Table A according to the Virtual Node and obtains the Tuple Node; The kernel module completes data rewriting and protocol encapsulation according to the content of the Tuple Node and sends it through the NIC.

6. The LVS load balancing scheduling method according to claim 5, wherein: The process of the kernel module allocating a virtual IP to the first data packet further includes: When a virtual IP is allocated, the count of the virtual IP is incremented by one; After a virtual IP is allocated, if there is no data connection within a preset time, the count of the virtual IP is decremented by one; Allocate a virtual IP to the first data packet according to the count values of the virtual IPs in the virtual IP pool.

7. The LVS load balancing scheduling method according to claim 4 or 5, characterized in that The load balancing system further includes: an MGR module, and the MGR module is set in the user layer; Before the kernel module allocates a virtual IP to the first data packet, it further includes: The kernel module matches the Tuple Node and the MGR in the Tuple Table in the kernel module, and when the match is successful, allocates a virtual IP to the first data packet.

8. An LVS load balancing scheduling device, characterized in that, Including: NIC, kernel module and LVS module, wherein, the NIC is set in the physical layer, the LVS module is set in the L3 layer of the kernel layer, and the kernel module is registered on the L2 hook of Netfilter in the kernel layer; The NIC is used to receive data and deliver the data to the data link layer; The kernel module is used for the kernel module to obtain the first data packet delivered by the NIC, perform protocol parsing to obtain the Tuple Node, where the Tuple Node includes entries: source IP, source Port, destination IP, destination Port, protocol type; and allocate a virtual IP to the first data packet, and generate a Virtual Node according to the Tuple Node, and change the content in the source IP entry of the Tuple Node in the Virtual Node to the allocated virtual IP; rewrite the content of the Virtual Node into the data packet according to the protocol standard, complete the protocol encapsulation, and form the second data packet; The LVS module is used to schedule the second data packet, keep the content in the source IP entry of the second data packet unchanged, change the content in the destination IP entry, and form the third data packet; The kernel module is further configured to parse the third data packet, generate a Device Node according to the Virtual Node, and complete subsequent protocol encapsulation. In the Device Node, the content in the source IP entry of the received Virtual Node is changed to the current device IP. The NIC is further configured to send the data encapsulated by the kernel module to the corresponding server. Among them, the process of the kernel module allocating a virtual IP for the first data packet includes: Checking the Tuple Node of the first data packet, and judging whether a virtual IP has been allocated for the source IP and source port according to the Tuple Node of the first data packet; If a virtual IP has been allocated, the allocated virtual IP is allocated again; otherwise, a new virtual IP is allocated.

9. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, the method described in any one of claims 1-7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, the method described in any one of claims 1-7 is implemented.

Images