Data forwarding method and apparatus for layer 4 load balancer, device, and storage medium
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- CHINA TELECOM CLOUD TECH CO LTD
- Filing Date
- 2025-11-20
- Publication Date
- 2026-06-11
Smart Images

Figure CN2025136450_11062026_PF_FP_ABST
Abstract
Description
Data forwarding methods, devices, equipment, and storage media for Layer 4 load balancers
[0001] Cross-references to related applications
[0002] This application claims priority to Chinese Patent Application No. 202411753679.1, filed on December 2, 2024, entitled “Data forwarding method, apparatus, device and storage medium for a four-layer load balancer”, the entire contents of which are incorporated herein by reference. Technical Field
[0003] This application relates to the field of CDN acceleration technology, and in particular to a data forwarding method for a four-layer load balancer, a data forwarding device for a four-layer load balancer, a computer device, and a storage medium. Background Technology
[0004] In the field of Content Delivery Network (CDN) acceleration, to achieve efficient traffic distribution and accelerated services, multiple backend servers (RealServer, RS) are typically deployed, and a Layer 4 load balancer (Linux Virtual Server, LVS) is used to evenly forward traffic to different backend servers. When forwarding traffic to backend servers, the Layer 4 load balancer saves the current forwarding information to ensure that the same flow is forwarded to the same backend server, thereby maintaining connection stability and consistency.
[0005] To ensure that the same connection can be forwarded to the same Resource Server (RS), the Layer 3 switch needs to forward requests for the same connection to the same Layer 4 load balancer, and the Layer 4 load balancer needs to forward requests for the same connection to the same RS based on its locally stored forwarding table information. However, in practice, when the OSPF (Open Shortest Path First) protocol of the Layer 4 load balancer is restarted (e.g., due to Layer 4 load balancer removal, expansion, or failure), the number of Equal-Cost Multi-Path (ECMP) routes on the Layer 3 switch changes. This means that the Layer 4 load balancer assigned to the same connection after reaching the Layer 3 switch may change based on the switch's IP (Internet Protocol) hash. Since each Layer 4 load balancer currently only retains its own forwarding table information, when the Layer 3 switch forwards the traffic of the same connection to different Layer 4 load balancers, the Layer 4 load balancers cannot forward the connection to the original RS, resulting in abnormal client requests.
[0006] The common approach to address this is to fully synchronize the forwarding table information of the Layer 4 load balancers, meaning each Layer 4 load balancer stores a copy of the forwarding table information of the other Layer 4 load balancers. However, when there is a large amount of forwarding table information, it consumes significant resources such as bandwidth, CPU (Central Processing Unit), and memory of the Layer 4 load balancers, impacting system performance and making it unsuitable for high-bandwidth service scenarios such as CDN. Summary of the Invention
[0007] In view of the above problems, this application proposes a data forwarding method, apparatus, device and storage medium for a Layer 4 load balancer to solve the problem of high resource consumption required for LVS to achieve data forwarding consistency in the prior art.
[0008] To address the aforementioned issues, this application discloses a data forwarding method for a Layer 4 load balancer, applied to a first Layer 4 load balancer. The first Layer 4 load balancer and multiple second Layer 4 load balancers form a network group. The method includes:
[0009] Receive connection requests and parse the message information of the connection requests;
[0010] Based on the message information, query whether the local forwarding table and the synchronous forwarding table have the first forwarding rule corresponding to the connection request. The local forwarding table is the forwarding table created locally by the first layer 4 load balancer, and the synchronous forwarding table is the forwarding table synchronized from multiple layer 4 load balancers to the first layer 4 load balancer.
[0011] If neither the local forwarding table nor the synchronous forwarding table has a first forwarding rule, then the backend information corresponding to the first RS backend is obtained from the RS hash tree based on the hash value calculated from the packet information. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers.
[0012] Based on the backend information, create a second forwarding rule corresponding to the connection request and save it to the local forwarding table, and forward the message information to the first RS backend.
[0013] In some embodiments, after querying the local forwarding table and the synchronous forwarding table to see if a first forwarding rule corresponding to the connection request exists based on the message information, the method further includes:
[0014] If a first forwarding rule is found in the local forwarding table, it is determined whether the first sequence value of the first forwarding rule is consistent with the second sequence value of the RS hash tree. The second sequence value is the cumulative count value corresponding to each update of the RS hash value, and the first sequence value is the latest sequence value of the RS hash tree when the first forwarding rule is created.
[0015] If the first sequence value is inconsistent with the second sequence value, then determine whether the time difference between the last update time of the RS hash tree and the current time is greater than the preset time.
[0016] If the time difference is greater than the preset duration, the forwarding rules in the local forwarding table that are inconsistent with the sequence value of the RS hash tree will be synchronized to multiple second and fourth layer load balancers, and the packet information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0017] In some embodiments, after determining whether the first sequence value of the first forwarding rule matches the second sequence value of the RS hash tree, the method further includes:
[0018] If the first sequence value matches the second sequence value, the message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0019] In some embodiments, after determining whether the time difference between the last update time of the RS hash tree and the current time is greater than a preset duration, the method further includes:
[0020] If the time difference is not greater than the preset duration, the message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0021] In some embodiments, after querying the local forwarding table and the synchronous forwarding table to see if there are forwarding rules corresponding to the connection request based on the message information, the method further includes:
[0022] If the local forwarding table does not contain the first forwarding rule, but the synchronous forwarding table does contain the first forwarding rule, then the connection request message will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0023] In some embodiments, the method includes:
[0024] When the first and fourth layer load balancers restart, add RS backend information, and then fully synchronize the RS backend information to multiple second and fourth layer load balancers.
[0025] Receive full RS information and target forwarding rules from multiple Layer 2 and Layer 4 load balancers. The target forwarding rules are forwarding rules from multiple Layer 2 and Layer 4 load balancers that are inconsistent with the sequence values of the RS hash tree.
[0026] Save all RS information to the target local RS linked list, update the RS hash tree and synchronize the target forwarding rules. The target local RS linked list is the RS linked list corresponding to the second and fourth layer load balancers and stored locally on the first and fourth layer load balancers.
[0027] If the target forwarding rules are synchronized, the OSPF protocol is started to direct traffic to the first-level Layer 4 load balancer.
[0028] In some embodiments, prior to the restart of the first Layer 4 load balancer, the following is also included:
[0029] When the first and fourth layer load balancers exit, the RS backend information is removed;
[0030] The exit information is synchronized to multiple Layer 2 and Layer 4 load balancers so that the multiple Layer 2 and Layer 4 load balancers clear the RS backend information of the Layer 1 and Layer 4 load balancers stored locally. The exit information includes the RS backend information.
[0031] This application embodiment also provides a data forwarding device for a Layer 4 load balancer, applied to a first Layer 4 load balancer, wherein the first Layer 4 load balancer and multiple second Layer 4 load balancers form a network group, and the device includes:
[0032] The parsing module is used to receive connection requests and parse the message information of the connection requests;
[0033] The query module is used to query whether the local forwarding table and the synchronous forwarding table have the first forwarding rule corresponding to the connection request based on the message information. The local forwarding table is the forwarding table created locally by the first layer 4 load balancer, and the synchronous forwarding table is the forwarding table synchronized from multiple layer 4 load balancers to the first layer 4 load balancer.
[0034] The acquisition module is used to obtain the backend information corresponding to the first RS backend from the RS hash tree based on the hash value calculated from the packet information if the first forwarding rule is not found in either the local forwarding table or the synchronous forwarding table. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers.
[0035] The module is used to create a second forwarding rule corresponding to the connection request based on the backend information and save it to the local forwarding table, as well as forward the packet information to the first RS backend.
[0036] This application also provides a computer device, including:
[0037] One or more processors; and
[0038] One or more machine-readable media having instructions stored thereon, which, when executed by one or more processors, cause a computer device to perform the methods of the embodiments of this application.
[0039] This application also provides a computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the methods of this application.
[0040] The embodiments of this application have the following advantages:
[0041] This application receives connection requests and parses the message information of the connection requests. Based on the message information, it queries the local forwarding table and the synchronous forwarding table to see if there is a first forwarding rule corresponding to the connection request. The local forwarding table is a forwarding table created locally by the first Layer 4 load balancer, and the synchronous forwarding table is a forwarding table synchronized to the first Layer 4 load balancer by multiple second Layer 4 load balancers. This allows each Layer 4 load balancer to store one copy of the local forwarding table and one copy of the forwarding table synchronized by the other Layer 4 load balancers. This facilitates the use of a hash consistency algorithm to determine the RS backend that the connection request needs to be forwarded to. Therefore, when traffic for the same connection is forwarded to different Layer 4 load balancers, the Layer 4 load balancers can still forward it to the original RS backend, avoiding client request anomalies. If neither the local forwarding table nor the synchronous forwarding table contains a first forwarding rule, the application will proceed accordingly. Based on the hash value calculated from the message information, the backend information corresponding to the first RS backend is obtained from the RS hash tree. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers, so that all Layer 4 load balancers use the RS hash tree to ensure the synchronization of RS backend information. Based on the backend information, the second forwarding rule corresponding to the connection request is created and saved to the local forwarding table, and the message information is forwarded to the first RS backend. All Layer 4 load balancers collaboratively update the RS hash tree based on the same RS information, ensuring that new connections create forwarding rules based on the same RS hash tree. This eliminates the need for real-time full synchronization of the forwarding table information of multiple Layer 4 load balancers, significantly reducing the consumption of bandwidth, CPU, and memory resources of the Layer 4 load balancers, and thus meeting the needs of high-bandwidth business scenarios such as CDN. Attached Figure Description
[0042] Figure 1 is a flowchart of the steps of a data forwarding method for a four-layer load balancer provided in an embodiment of this application;
[0043] Figure 2 is a schematic diagram of connection request distribution based on the relevant technology provided in the embodiments of this application;
[0044] Figure 3 is a synchronization diagram of adding an RS backend to a four-layer load balancer provided in an embodiment of this application.
[0045] Figure 4 is a schematic diagram of the synchronization when the RS backend is removed from the four-layer load balancer provided in the embodiment of this application.
[0046] Figure 5 is a flowchart of another data forwarding method for a four-layer load balancer provided in an embodiment of this application;
[0047] Figure 6 is a flowchart of the synchronization steps during the restart of a four-layer load balancer provided in an embodiment of this application.
[0048] Figure 7 is a structural block diagram of a data forwarding device for a four-layer load balancer provided in an embodiment of this application. Detailed Implementation
[0049] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0050] As described in the background section, when multiple Layer 4 load balancers exist, a primary + backup mode can be used to improve system reliability, or a primary + primary mode can be used to improve system load capacity. When multiple Layer 4 load balancers operate in primary + primary mode, each Layer 4 load balancer can provide services externally. Layer 4 load balancers are mainly implemented using Keepalived (an open-source software) + OSPF.
[0051] As shown in Figure 2, 1. Multiple clients initiate access to the VIP (10.0.10.100); 2. When the access traffic reaches the Layer 3 switch, the Layer 3 switch distributes the traffic accessing the VIP to different Layer 4 load balancers through ECMP equal-cost routing; generally, a fixed IP hash method is used to select which Layer 4 load balancer the traffic should be sent to. When the number of ECMP equal-cost routes remains unchanged, the same connection request will hash to the same Layer 4 load balancer; 3. After receiving the request, the Layer 4 load balancer selects an RS backend information according to the backend RS information issued by Keepalived, and forwards the traffic to the corresponding RS. At the same time, the Layer 4 load balancer records the RS backend information forwarded for this connection. When the same connection request is received later, the request will be directly forwarded to the same RS backend.
[0052] As can be seen, to ensure that the same connection can be forwarded to the same RS, the Layer 3 switch needs to forward requests for the same connection to the same Layer 4 load balancer, and the Layer 4 load balancer needs to forward requests for the same connection to the same RS based on its locally stored forwarding table information. However, when the OSPF protocol of the Layer 4 load balancer restarts, traffic for the same connection forwarded to different Layer 4 load balancers cannot be forwarded to the original RS. To address this, related methods perform a full synchronization of the Layer 4 load balancer's forwarding table information. When there is a large amount of forwarding table information, it consumes significant bandwidth, CPU, and memory resources of the Layer 4 load balancer, impacting system performance and making it unsuitable for high-bandwidth service scenarios such as CDN.
[0053] To address the above issues, one of the core concepts of this application's embodiments is that the Layer 4 load balancer uses an RS Hash consensus algorithm to calculate the backend RS that a connection request needs to be forwarded to. By synchronizing RS backend information in real time, each Layer 4 load balancer stores a copy of the RS backend information of the other Layer 4 load balancers. The Layer 4 load balancers collaboratively update the RS Hash tree based on the same RS information, ensuring that new connections create forwarding rules based on the same RS Hash tree. In this way, it is not necessary to fully synchronize the forwarding table information.
[0054] One of the core concepts of this application is to maintain a sequence number on the forwarding rule and the RS Hash tree. When the RS Hash tree is updated, the sequence number of the RS Hash tree is updated synchronously. When a forwarding rule is created, the sequence number of the current RS Hash tree is recorded on the forwarding rule. When the Layer 4 load balancer accesses a forwarding rule, it can determine whether the forwarding rule is calculated based on the latest RS Hash tree by using the sequence number, thereby determining whether the forwarding rule needs to be synchronized, which greatly reduces unnecessary synchronization scenarios.
[0055] One of the core concepts of this application is that when the Layer 4 load balancer restarts, it ensures the consistency of the RS backend by fully synchronizing the RS backend information. At the same time, after the restarted Layer 4 load balancer senses that the other Layer 4 load balancers have completed synchronizing the forwarding rules, it starts the OSPF protocol to ensure that when the switch schedules traffic to the restarted load balancer, the forwarding rules have been synchronized.
[0056] A Layer 4 load balancer is a device or software responsible for distributing and balancing network traffic at the transport layer (Layer 4). It can distribute incoming connection requests to multiple backend servers according to specific rules to achieve load balancing and high availability.
[0057] ECMP (Equal-Cost Multipath) is a network routing technology used to achieve load balancing among multiple paths with equal costs. It allows traffic to be distributed across multiple paths with similar costs, improving network bandwidth utilization and fault tolerance.
[0058] OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) used to exchange routing information and calculate the shortest path between routers within an Autonomous System (AS).
[0059] Keepalived is an open-source software used to implement high availability (HA) and load balancing (LB) on Linux systems. It provides a simple and effective way to monitor and manage the status of multiple servers.
[0060] RS (RealServer) is the backend server that provides the actual service. The Layer 4 load balancer forwards request data to RS to provide services to the outside world.
[0061] LIP (local IP address) represents the server's local IP address.
[0062] VIP (virtual ip address) represents a virtual IP address, which is the IP address used by a business component to provide services to the outside world.
[0063] LVS (Linux Virtual Server) is a high-performance, scalable load balancer based on Linux. It is an open-source software project designed to provide a reliable load balancing solution for distributing network traffic to multiple backend servers to improve system availability and performance.
[0064] A CDN (Content Delivery Network) is a distributed network architecture designed to provide efficient content delivery services. Its main goal is to enable users to access and retrieve online content faster by storing content on edge servers distributed globally.
[0065] Referring to Figure 1, which illustrates a flowchart of a data forwarding method for a Layer 4 load balancer according to an embodiment of this application, the method is applied to a first Layer 4 load balancer, which, together with multiple second Layer 4 load balancers, forms a network group. It should be understood that the first and second Layer 4 load balancers in this application are not specifically designated, but rather any one of the Layer 4 load balancers within the network group is designated as the first Layer 4 load balancer, and the other Layer 4 load balancers are designated as the second Layer 4 load balancers.
[0066] As shown in Figure 1, the method includes steps S101 to S104, which are described in detail below:
[0067] Step S101: Receive a connection request and parse the message information of the connection request.
[0068] In this step, the connection request is initiated by the client and distributed by the Layer 3 switch. The message information is the message's key information, which includes, but is not limited to, the protocol type (TCP (Transmission Control Protocol) / UDP (User Datagram Protocol)), source IP address, source port, destination IP address, and destination port.
[0069] In some embodiments of this application, the process of parsing the message information of a connection request includes: determining the protocol type used in the connection request, such as HTTP (Hypertext Transfer Protocol), TCP, UDP, WebSocket (a network communication protocol), etc., where different protocols have different standards and message formats; extracting the message header, where the TCP message header contains information such as source port, destination port, sequence number, acknowledgment number, and flags; and the IP message header contains information such as source IP address, destination IP address, and protocol type; and parsing the specific content of the message according to the protocol type: for HTTP, parsing the request line and header fields, and extracting information such as URL (Uniform Resource Locator), method, and user agent; for TCP / IP, parsing information such as source port, destination port, and IP address; and for WebSocket, parsing the handshake request, and extracting fields such as Sec-WebSocket-Key (a string) and Sec-WebSocket-Version (used to specify the protocol version number).
[0070] Step S102: Based on the message information, query whether there is a first forwarding rule corresponding to the connection request in the local forwarding table and the synchronous forwarding table. The local forwarding table is the forwarding table created locally by the first Layer 4 load balancer, and the synchronous forwarding table is the forwarding table synchronized from multiple Layer 4 load balancers to the first Layer 4 load balancer.
[0071] In this step, the forwarding table contains forwarding rules. The system checks the local forwarding table for the existence of a first forwarding rule based on the packet information to determine if the RS backend information to be forwarded by the connection request is in the local forwarding table of the first Layer 4 load balancer. If the local forwarding table does not contain the first forwarding rule, the system then checks the synchronous forwarding table for the existence of the first forwarding rule to determine if the RS backend information to be forwarded by the connection request is in the forwarding table of the second Layer 4 load balancer. This ensures that when traffic for the same connection is forwarded to different Layer 4 load balancers, the Layer 4 load balancer can still forward it to the original RS backend, preventing client request anomalies.
[0072] Layer 4 load balancers locally store a copy of the RS backend information for the other Layer 4 load balancers. When the RS backend information in a Layer 4 load balancer changes, it is synchronized to the other Layer 4 load balancers in real time via multicast messages. When all Layer 4 load balancers have a certain RS backend information, the Layer 4 load balancers add that RS backend information to their RS hash trees. When one Layer 4 load balancer removes a certain RS backend information, all Layer 4 load balancers need to remove that RS backend information from their local RS hash trees.
[0073] In some embodiments of this application, as shown in Figure 3, which illustrates the synchronization when adding an RS backend to a Layer 4 load balancer, a new RS (RSn) is added to Layer 4 load balancer 2. After adding RSn to the RS linked list corresponding to Layer 4 load balancer 2, if it is determined that both Layer 4 load balancer 1 and Layer 4 load balancer 3 also have RSn, then RSn is added to the RS hash tree (RS hash consistency tree). Then, a multicast message is sent to notify Layer 4 load balancer 1 and Layer 4 load balancer 3 to also add RSn synchronously. After receiving the synchronization add message, Layer 4 load balancer 1 and Layer 4 load balancer 3 add RSn to the RS linked list of Layer 4 load balancer 2 stored locally in Layer 4 load balancer 1, and add RSn to the RS linked list of Layer 4 load balancer 2 stored locally in Layer 4 load balancer 3. Then, RSn is also added to the RS hash trees of Layer 4 load balancer 1 and Layer 4 load balancer 3.
[0074] In some embodiments of this application, as shown in Figure 4, which illustrates the synchronization when a Layer 4 load balancer removes an RS backend, Layer 4 load balancer 2 receives a Keepalived notification to remove RSn, removes RSn from its RS linked list, and then removes RSn from its RS hash tree. After removal, the RSn removal information of Layer 4 load balancer 2 is synchronized via multicast messages. After receiving the message from Layer 4 load balancer 2 to remove RSn, Layer 4 load balancers 1 and 3 remove RSn from their local RS linked lists and, in turn, remove RSn from their local RS linked lists. Finally, they remove RSn from their local RS hash trees.
[0075] Step S103: If the first forwarding rule is not found in either the local forwarding table or the synchronous forwarding table, the backend information corresponding to the first RS backend is obtained from the RS hash tree based on the hash value calculated from the message information. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers.
[0076] In this step, the Layer 4 load balancer uses the RS Hash consensus algorithm to select which RS backend to distribute the traffic of the connection request to. The Layer 4 load balancer maintains an RS hash tree and adds RS backend information to the RS hash tree based on the hash value calculated by the IP address of the RS. When the Layer 4 load balancer receives a new connection request, it retrieves the RS backend information to be forwarded from the RS hash tree according to the hash value of the source IP and source port of the connection request.
[0077] If neither the local forwarding table nor the synchronous forwarding table contains a first forwarding rule, it indicates that the connection request is for a new connection. Therefore, a forwarding rule needs to be created for this new connection to allocate the corresponding RS backend. To reduce resource consumption, an RS hash tree is used to ensure the consistency of RS backend hash values.
[0078] In some embodiments of this application, a hash value is calculated using the source IP and source port of the connection request, and based on the hash value, the RS backend information that is closest to the hash value on the RS hash tree is selected.
[0079] Step S104: Based on the backend information, create a second forwarding rule corresponding to the connection request and save it to the local forwarding table, and forward the packet information to the first RS backend.
[0080] In this step, when the Layer 4 load balancer receives a new connection request, it creates a new forwarding rule for the new connection request based on the current RS hash tree. The sequence value of the current RS hash tree is recorded on the forwarding rule so that the sequence value between the forwarding rule and the RS hash tree can be compared later to determine whether the forwarding rule is calculated based on the latest RS hash tree, thereby determining whether synchronization is needed, which greatly reduces unnecessary synchronization scenarios.
[0081] This application embodiment receives a connection request and parses the message information of the connection request. Based on the message information, it queries the local forwarding table and the synchronous forwarding table to see if there is a first forwarding rule corresponding to the connection request. The local forwarding table is a forwarding table created locally by the first Layer 4 load balancer, and the synchronous forwarding table is a forwarding table synchronized to the first Layer 4 load balancer by multiple second Layer 4 load balancers. This allows each Layer 4 load balancer to store one copy of the local forwarding table and one copy of the forwarding table synchronized by other Layer 4 load balancers. This facilitates the use of a hash consistency algorithm to determine the RS backend that the connection request needs to be forwarded to. Therefore, when traffic for the same connection is forwarded to different Layer 4 load balancers, the Layer 4 load balancers can still forward it to the original RS backend, avoiding client request anomalies. If neither the local forwarding table nor the synchronous forwarding table contains the first forwarding rule, the process is reversed. Based on the hash value calculated from the message information, the backend information corresponding to the first RS backend is obtained from the RS hash tree. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers, so that all Layer 4 load balancers use the RS hash tree to ensure the synchronization of RS backend information. Based on the backend information, the second forwarding rule corresponding to the connection request is created and saved to the local forwarding table, and the message information is forwarded to the first RS backend. All Layer 4 load balancers collaboratively update the RS hash tree based on the same RS information, ensuring that new connections create forwarding rules based on the same RS hash tree. This eliminates the need for real-time full synchronization of forwarding table information of multiple Layer 4 load balancers, significantly reducing the consumption of bandwidth, CPU, and memory resources of the Layer 4 load balancers, and thus meeting the needs of high-bandwidth business scenarios such as CDN.
[0082] In some embodiments, as shown in FIG5, after step S102, the method further includes:
[0083] If the local forwarding table does not contain the first forwarding rule, but the synchronous forwarding table does contain the first forwarding rule, then the connection request message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0084] If a first forwarding rule is found in the local forwarding table, it is determined whether the first sequence value of the first forwarding rule is consistent with the second sequence value of the RS hash tree. The second sequence value is the cumulative count value corresponding to each update of the RS hash value, and the first sequence value is the latest sequence value of the RS hash tree when the first forwarding rule is created.
[0085] If the first sequence value matches the second sequence value, the message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0086] If the first sequence value is inconsistent with the second sequence value, then determine whether the time difference between the last update time of the RS hash tree and the current time is greater than the preset time.
[0087] If the time difference is greater than the preset duration, the forwarding rules in the local forwarding table that are inconsistent with the sequence value of the RS hash tree will be synchronized to multiple second and fourth layer load balancers, and the packet information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0088] If the time difference is not greater than the preset duration, the message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0089] In some embodiments, since the RS information between different Layer 4 load balancers is synchronized in real time, the RS hash trees among multiple Layer 4 load balancers will remain consistent after synchronization. However, the forwarding rules are not synchronized in real time. Therefore, the Layer 4 load balancer only synchronizes forwarding rules that are not created based on the latest RS hash tree. Forwarding rules created based on the same RS hash tree select the same RS backend, so synchronization is not required. By associating the RS information between multiple Layer 4 load balancers through the RS hash tree, and without the need for real-time synchronization of the forwarding table, unnecessary synchronization scenarios are greatly reduced.
[0090] Some embodiments use sequence values to record updates to the RS hash tree (including adding and removing RS backend information). Specifically, the Layer 4 load balancer adds a sequence value counter to the RS hash tree. When the RS hash tree is updated, its sequence value is incremented by 1. When the Layer 4 load balancer receives a new connection request, it creates a connection forwarding rule based on the current RS hash tree and records the latest sequence value of the current RS hash tree on the forwarding rule. By comparing the sequence value between the forwarding rule and the RS hash tree, it can be determined whether the forwarding rule is calculated based on the latest RS hash tree. This allows it to determine whether a specific forwarding rule needs to be synchronized, thus avoiding the need for full synchronization of all forwarding rules. This significantly reduces the resource consumption of the forwarding rule synchronization process by requiring only synchronization of a few forwarding rules.
[0091] When the local forwarding table does not have a first forwarding rule, but the synchronous forwarding table does, it means that the connection request is the same connection previously allocated by the second layer 4 load balancer. Therefore, according to the synchronous forwarding table, the connection request packet information is forwarded to the second RS backend corresponding to the first forwarding rule.
[0092] When the local forwarding table contains a first forwarding rule, it indicates that the connection request is for the same connection previously allocated by the first Layer 4 load balancer. Therefore, according to the local forwarding table, the connection request packet information can be forwarded to the second RS backend corresponding to the first forwarding rule. However, to determine whether the first forwarding rule was created based on the latest RS hash tree, it is verified whether the first sequence value of the first forwarding rule is equal to the second sequence value of the RS hash tree. If the first sequence value is not equal to the second sequence value, it indicates that the first forwarding rule was not created based on the latest RS hash tree. Therefore, it is further determined whether the RS hash tree has exceeded a preset time interval since its last update. If the RS hash tree has exceeded a preset time interval since its last update, the first forwarding rule is synchronized to the second Layer 4 load balancer via multicast packets. When the second Layer 4 load balancer receives the message of synchronization of the first forwarding rule, it saves it in the synchronization forwarding table. See Figure 3 for the synchronization process. If the first sequence value is equal to the second sequence value, it indicates that the first forwarding rule was created based on the latest RS hash tree, so synchronization is not required.
[0093] In some embodiments, the method includes:
[0094] When the first and fourth layer load balancers exit, the RS backend information is removed;
[0095] Synchronize exit information to multiple Layer 2 and Layer 4 load balancers so that multiple Layer 2 and Layer 4 load balancers clear the RS backend information of the Layer 1 and Layer 4 load balancers stored locally. The exit information includes the RS backend information.
[0096] When the first and fourth layer load balancers restart, add RS backend information, and then fully synchronize the RS backend information to multiple second and fourth layer load balancers.
[0097] Receive full RS information and target forwarding rules from multiple Layer 2 and Layer 4 load balancers. The target forwarding rules are forwarding rules from multiple Layer 2 and Layer 4 load balancers that are inconsistent with the sequence values of the RS hash tree.
[0098] Save all RS information to the target local RS linked list, update the RS hash tree and synchronize the target forwarding rules. The target local RS linked list is the RS linked list corresponding to the second and fourth layer load balancers and stored locally on the first and fourth layer load balancers.
[0099] If the target forwarding rules are synchronized, the OSPF protocol is started to direct traffic to the first-level Layer 4 load balancer.
[0100] In this embodiment, when the first Layer 4 load balancer restarts, it needs to fully synchronize the RS backend information. The second Layer 4 load balancer needs to fully synchronize the forwarding rules that are not created based on the latest RS hash tree to the restarted first Layer 4 load balancer. After the other Layer 4 load balancers have completed the synchronization, the restarted first Layer 4 load balancer starts the OSPF protocol component, and then the Layer 3 switch schedules traffic to the restarted first Layer 4 load balancer.
[0101] As shown in Figure 6, the synchronization process during the restart of Layer 4 Load Balancer 1:
[0102] When Layer 4 load balancer 1 exits, Keepalived notifies Layer 4 load balancer 1 to remove RS information. After all RS information is removed, Layer 4 load balancer 1 multicasts an exit message. When other Layer 4 load balancers (such as Layer 4 load balancer 2) receive the exit message from Layer 4 load balancer 1, they clear all the RS information of Layer 4 load balancer 1 stored locally.
[0103] When Layer 4 Load Balancer 1 restarts, Keepalived sends a full notification to Layer 4 Load Balancer 1 to add RS information. After the full addition is complete, Layer 4 Load Balancer 1 synchronizes the RS information to the other Layer 4 Load Balancers 2 via multicast. After receiving the full RS synchronization from Layer 4 Load Balancer 1, Layer 4 Load Balancer 2 saves the RS information to its local RS linked list of Layer 4 Load Balancer 1, updates its RS hash tree, and simultaneously replies with its own full RS information to Layer 4 Load Balancer 1. After receiving the full RS information from Layer 4 Load Balancer 2, Layer 4 Load Balancer 1 saves the RS information to its local RS linked list of Layer 4 Load Balancer 2 and updates its RS hash tree. Layer 4 Load Balancer 2 synchronizes the forwarding rules that need to be synchronized locally to Layer 4 Load Balancer 1. After determining that all Layer 4 Load Balancers have completed the forwarding rule synchronization, Layer 4 Load Balancer 1 starts the OPSF protocol, causing the Layer 3 switch to redirect traffic to Layer 4 Load Balancer 1.
[0104] When the Layer 4 load balancer in this embodiment restarts, it ensures the consistency of the RS backend by fully synchronizing the RS backend information. At the same time, the restarted Layer 4 load balancer detects that the other Layer 4 load balancers have completed synchronizing the forwarding rules before starting OPSF, ensuring that the forwarding rules have been synchronized when the switch schedules traffic to the restarted load balancer.
[0105] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.
[0106] Referring to Figure 7, a structural block diagram of a data forwarding device for a Layer 4 load balancer according to an embodiment of this application is shown. This data forwarding device is applied to a first Layer 4 load balancer, which, together with multiple second Layer 4 load balancers, forms a network group. The data forwarding device specifically includes the following modules:
[0107] The parsing module 701 is used to receive connection requests and parse the message information of the connection requests;
[0108] The query module 702 is used to query whether the local forwarding table and the synchronous forwarding table have the first forwarding rule corresponding to the connection request based on the message information. The local forwarding table is the forwarding table created locally by the first layer 4 load balancer, and the synchronous forwarding table is the forwarding table synchronized by multiple layer 4 load balancers to the first layer 4 load balancer.
[0109] The acquisition module 703 is used to obtain the backend information corresponding to the first RS backend from the RS hash tree based on the hash value calculated from the packet information if the first forwarding rule is not found in the local forwarding table and the synchronous forwarding table. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers.
[0110] Module 704 is used to create a second forwarding rule corresponding to the connection request based on the backend information and save it to the local forwarding table, as well as forward the packet information to the first RS backend.
[0111] In some embodiments, the apparatus further includes:
[0112] The first judgment module is used to determine whether the first sequence value of the first forwarding rule is consistent with the second sequence value of the RS hash tree if a first forwarding rule is found in the local forwarding table. The second sequence value is the cumulative count value corresponding to each update of the RS hash value, and the first sequence value is the latest sequence value of the RS hash tree when the first forwarding rule is created.
[0113] The second judgment module is used to determine whether the time difference between the last update time of the RS hash tree and the current time is greater than a preset duration if the first sequence value and the second sequence value are inconsistent.
[0114] The synchronization module is used to synchronize forwarding rules in the local forwarding table that are inconsistent with the sequence values of the RS hash tree to multiple second and fourth layer load balancers if the time difference is greater than a preset time. It also forwards the packet information to the second RS backend corresponding to the first forwarding rule.
[0115] In some embodiments, the apparatus further includes:
[0116] The forwarding module is used to forward the message information to the second RS backend corresponding to the first forwarding rule if the first sequence value is consistent with the second sequence value.
[0117] In some embodiments, the forwarding module is further configured to:
[0118] If the time difference is not greater than the preset duration, the message information will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0119] In some embodiments, the forwarding module is further configured to:
[0120] If the local forwarding table does not contain the first forwarding rule, but the synchronous forwarding table does contain the first forwarding rule, then the connection request message will be forwarded to the second RS backend corresponding to the first forwarding rule.
[0121] In some embodiments, the apparatus further includes:
[0122] Add a module to add RS backend information when the first and fourth layer load balancers restart, and then fully synchronize the RS backend information to multiple second and fourth layer load balancers.
[0123] The receiving module is used to receive the full RS information and target forwarding rules from multiple Layer 2 and Layer 4 load balancers. The target forwarding rules are the forwarding rules from multiple Layer 2 and Layer 4 load balancers that are inconsistent with the sequence values of the RS hash tree.
[0124] The update module is used to save the full RS information to the target local RS linked list, and update the RS hash tree and synchronize the target forwarding rules. The target local RS linked list is the RS linked list corresponding to the second and fourth layer load balancers and stored locally on the first and fourth layer load balancers.
[0125] The startup module is used to start the OSPF protocol to direct traffic to the first-level Layer 4 load balancer if the target forwarding rules are synchronized.
[0126] In some embodiments, the apparatus further includes:
[0127] The removal module is used to remove RS backend information when the first or fourth layer load balancer exits.
[0128] The synchronization clearing module is used to synchronize exit information to multiple Layer 2 and Layer 4 load balancers, so that multiple Layer 2 and Layer 4 load balancers clear the RS backend information of the Layer 1 and Layer 4 load balancers stored locally. The exit information includes the RS backend information.
[0129] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.
[0130] This application also provides a computer device, including:
[0131] One or more processors; and
[0132] One or more machine-readable media having instructions stored thereon, which, when executed by one or more processors, cause a computer device to perform the methods of the embodiments of this application.
[0133] This application also provides a computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the methods of this application.
[0134] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0135] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM (Compact Disc-Read-Only Memory), optical storage, EEPROM (Electrically Erasable Programmable Read-Only Memory), Flash memory, and eMMC (embedded MultiMediaCard), etc.) containing computer-usable program code.
[0136] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.
[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.
[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable terminal equipment, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.
[0139] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.
[0140] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the element.
[0141] The data forwarding method and device for a Layer 4 load balancer provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A data forwarding method for a Layer 4 load balancer, characterized in that, The method, applied to a first-level Layer 4 load balancer, wherein the first-level Layer 4 load balancer and multiple second-level Layer 4 load balancers form a network group, includes: Receive connection requests and parse the message information of the connection requests; Based on the message information, query whether the local forwarding table and the synchronous forwarding table have the first forwarding rule corresponding to the connection request. The local forwarding table is a forwarding table created locally by the first Layer 4 load balancer. The synchronous forwarding table is a forwarding table synchronized from multiple Layer 4 load balancers to the first Layer 4 load balancer. If the first forwarding rule is not found in either the local forwarding table or the synchronous forwarding table, the backend information corresponding to the first RS backend is obtained from the RS hash tree based on the hash value calculated from the message information. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers. Based on the backend information, a second forwarding rule corresponding to the connection request is created and saved to the local forwarding table, and the message information is forwarded to the first RS backend.
2. The data forwarding method for a four-layer load balancer according to claim 1, characterized in that, After querying the local forwarding table and the synchronous forwarding table for the existence of the first forwarding rule corresponding to the connection request based on the message information, the method further includes: If the first forwarding rule is found to exist in the local forwarding table, it is determined whether the first sequence value of the first forwarding rule is consistent with the second sequence value of the RS hash tree. The second sequence value is the cumulative count value corresponding to each update of the RS hash value, and the first sequence value is the latest sequence value of the RS hash tree when the first forwarding rule is created. If the first sequence value is inconsistent with the second sequence value, then determine whether the time difference between the last update time and the current time of the RS hash tree is greater than a preset time. If the time difference is greater than the preset duration, the forwarding rules in the local forwarding table that are inconsistent with the sequence value of the RS hash tree are synchronized to multiple second-fourth layer load balancers, and the packet information is forwarded to the second RS backend corresponding to the first forwarding rule.
3. The data forwarding method for a four-layer load balancer according to claim 2, characterized in that, After determining whether the first sequence value of the first forwarding rule is consistent with the second sequence value of the RS hash tree, the method further includes: If the first sequence value is consistent with the second sequence value, the message information is forwarded to the second RS backend corresponding to the first forwarding rule.
4. The data forwarding method for a four-layer load balancer according to claim 2, characterized in that, After determining whether the time difference between the last update time and the current time of the RS hash tree is greater than a preset duration, the method further includes: If the time difference is not greater than the preset duration, the message information is forwarded to the second RS backend corresponding to the first forwarding rule.
5. The data forwarding method for a four-layer load balancer according to claim 1, characterized in that, After querying the local forwarding table and the synchronous forwarding table for the existence of the forwarding rule corresponding to the connection request based on the message information, the method further includes: If the first forwarding rule is not found in the local forwarding table, but exists in the synchronous forwarding table, then the connection request message information is forwarded to the second RS backend corresponding to the first forwarding rule.
6. The data forwarding method for a four-layer load balancer according to claim 1, characterized in that, The method includes: When the first layer 4 load balancer restarts, add RS backend information, and then fully synchronize the RS backend information to multiple second layer 4 load balancers. Receive full RS information and target forwarding rules from multiple Layer 2 and 4 load balancers, wherein the target forwarding rules are forwarding rules from multiple Layer 2 and 4 load balancers that are inconsistent with the sequence values of the RS hash tree; The full RS information is saved to the target local RS linked list, and the RS hash tree is updated and the target forwarding rules are synchronized. The target local RS linked list is the RS linked list corresponding to the second layer 4 load balancer and stored locally on the first layer 4 load balancer. If the target forwarding rules are synchronized, the OSPF protocol is started to direct traffic to the first Layer 4 load balancer.
7. The data forwarding method for a four-layer load balancer according to claim 6, characterized in that, Before the first Layer 4 load balancer restarts, the following is also included: When the first fourth-layer load balancer exits, the RS backend information is removed; The exit information is synchronized to multiple Layer 2 and Layer 4 load balancers so that the multiple Layer 2 and Layer 4 load balancers clear the RS backend information of the first Layer 4 load balancer stored locally. The exit information includes the RS backend information.
8. A data forwarding device for a four-layer load balancer, characterized in that, An application to a first-level Layer 4 load balancer, wherein the first-level Layer 4 load balancer and multiple second-level Layer 4 load balancers form a network group, the device includes: The parsing module is used to receive connection requests and parse the message information of the connection requests; The query module is used to query whether the first forwarding rule corresponding to the connection request exists in the local forwarding table and the synchronous forwarding table according to the message information. The local forwarding table is a forwarding table created locally by the first layer 4 load balancer, and the synchronous forwarding table is a forwarding table synchronized to the first layer 4 load balancer by multiple second layer 4 load balancers. The acquisition module is used to obtain the backend information corresponding to the first RS backend from the RS hash tree based on the hash value calculated from the message information if the first forwarding rule does not exist in either the local forwarding table or the synchronous forwarding table. The RS hash tree is a hash tree that records the consistency of the RS backend hash values of all Layer 4 load balancers. A creation module is used to create a second forwarding rule corresponding to the connection request based on the backend information and save it to the local forwarding table, and to forward the message information to the first RS backend.
9. A computer device, characterized in that, include: One or more processors; and One or more machine-readable media having instructions stored thereon, which, when executed by the one or more processors, cause the computer device to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-7.