Method for realizing session synchronization of multi-live load balancing system based on lvs

Abstract

The invention discloses a method for realizing session synchronization by a multi-live load balancing system based on lvs, and relates to the field of cloud computing. Comprising the steps of (1) preparing computing resources and deploying load balancing nodes and real server nodes, (2) configuring a mode of issuing a route on a router and realizing an equivalent multi-path route, (3) configuring the load balancing nodes, selecting lvs as a load balancer and deploying by using a dr mode of the lvs, and (4) performing lvs session synchronization configuration, and after session synchronization configuration is completed, sending the load balancing nodes to the router. When a user requests to pass through one of the load balancing nodes, if the load balancing node completes TCP three-way handshake and connection is established, quintuple information of TCP connection and a session state are packaged into a lightweight synchronization message through the load balancing node. Sending the broadcast address to all load balancing nodes in the same cluster through the load balancing nodes according to a pre-configured broadcast address; according to the method, a load balancing node receiving a synchronous message firstly searches whether a connrack table item of the same quintuple exists in the local, if not, a new connection tracking record is directly inserted, and if yes, a strategy merging state is updated by using a later uncovered or timestamp, so that the whole cluster is ensured to be completely consistent with a view of the long connection.

Description

Technical Field

[0001] This invention discloses a method for implementing session synchronization in a multi-active load balancing system based on LVS, which relates to the field of cloud computing. Background Technology

[0002] In modern network architectures, load balancing technology is widely used to improve system availability and processing power. With the explosive growth of cloud computing, microservices, and edge computing, data center outbound traffic is increasing exponentially. Existing "single machine + primary / backup" or "hardware ADC cluster" models are no longer sufficient to simultaneously meet the requirements of horizontal scaling, elastic scaling, and millisecond-level high availability. For example:

[0003] Existing load balancing solutions generally adopt the VRRP master-slave mode, with resource utilization of less than 50%. A single node failure requires 1-3 seconds to converge, resulting in the interruption of long-connection services such as financial transactions and real-time audio and video.

[0004] While ECMP can distribute traffic across multiple load balancing nodes, it lacks a session-level synchronization mechanism. When a node fails, the TCP state table is lost, and the client is forced to re-handshake.

[0005] While hardware load balancers offer high throughput, they are expensive and their scalability is limited by the number of rack slots, making it impossible to expand flexibly as needed. Summary of the Invention

[0006] This invention addresses the problems of existing technologies by providing a method for implementing session synchronization in a multi-active load balancing system based on LVS. This method improves the scalability, availability, and user experience of the load balancing system, enabling a more efficient, horizontally scalable Layer 4 load balancing system, as well as seamless fault migration that is imperceptible to the user.

[0007] The specific solution proposed in this invention is as follows:

[0008] This invention also provides a method for implementing session synchronization in a multi-active load balancing system based on LVS, comprising:

[0009] Step 1: Prepare computing resources by deploying load balancer nodes and real server nodes.

[0010] Step 2: Configure the router to send and receive routes, implementing an equal-cost multi-path routing mode.

[0011] Step 3: Configure the load balancer nodes, select LVS as the load balancer, and deploy using LVS's DR mode.

[0012] Step 4: Configure LVS session synchronization. After configuring session synchronization, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to re-perform the three-way handshake.

[0013] Furthermore, in step 1 of the method for implementing session synchronization in a multi-active load balancing system based on LVS, when deploying the load balancing nodes, two network interface cards (NICs) are set up on each load balancing node: a service management NIC and a tenant service NIC. The service management NIC is used to configure the load balancing node, while the tenant service NIC provides the VIP for external services and communication with the real server node.

[0014] When deploying real server nodes, configure the tenant's service network interface card on each real server node.

[0015] Simultaneously configure the tenant business network interface name and IP address for the load balancer node, as well as the tenant business network interface name and IP address for the real server node.

[0016] Furthermore, step 2 of the method for implementing session synchronization in a multi-active load balancing system based on LVS specifically includes:

[0017] ECMP is distributed via OpenStack.

[0018] If a data packet destined for a VIP has two equivalent next-hop addresses, the system selects either a three-layer or four-layer hash to determine the next-hop address, depending on the system configuration. The default is a three-layer hash. If you want to change to a four-layer hash, execute the corresponding command to modify it.

[0019] Perform a health check on each load balancer node within the load balancer cluster. When a load balancer node failure is detected, immediately remove the next hop of the failed load balancer node from the ECMP equal-cost route on the router.

[0020] After ECMP is deployed, when virtual machines within the tenant's business network access the VIP, they are configured to use ECMP on the router to achieve a multi-active mode. The router performs ARP proxying for the VIP. When a virtual machine within the tenant's business network accesses the VIP, it first makes an ARP request. After the router sends an ARP response, it sends the MAC address of the gateway on the router to the virtual machine. When the virtual machine accesses the VIP, the data packet is sent to the router. The router is configured with flow tables to implement ARP proxying, thus completing the router configuration.

[0021] Furthermore, in step 3 of the method for implementing session synchronization in a multi-active load balancing system based on LVS, the load balancing node is configured, including:

[0022] Configure the VIP to be bound to the local loopback interface.

[0023] Configure the network interface card (NIC) with available address pairs. The source IP of data packets sent from the load balancer node to the real server node should be the client IP. For external network access, when adding available address pairs to the tenant's business network NIC on the load balancer node, add 0.0.0.0 / 0 to allow all IP addresses to pass through.

[0024] Disable VIP ARP responses to prevent VIP conflicts.

[0025] Configure LVS forwarding rules.

[0026] Furthermore, in step 4 of the method for implementing session synchronization in a multi-active load balancing system based on LVS, when configuring LVS session synchronization, the master and backup daemons are started simultaneously on each load balancing node. The syncid parameter is selected from the last segment of VIP, and mcast-interface is set to the first network card. In this way, the broadcast will be within the service management network and will not affect the bandwidth of the tenant's business network.

[0027] Furthermore, the method for implementing session synchronization in a multi-active load balancing system based on LVS also includes step 5, configuring the real server node:

[0028] Bind the VIP to the local loopback interface.

[0029] Configure the network interface card (NIC) with available address pairs. In LVS DR mode, when the real server node returns packets, it directly sends them to the client without going through the load balancer node. The source IP of the data packet is the VIP. Add available address pairs with the VIP IP address to the NIC of the tenant's service network on the real server node.

[0030] Disable VIP ARP responses to prevent VIP conflicts.

[0031] This invention also provides a system for implementing session synchronization based on an LVS-based multi-active load balancing system, including a resource deployment module, a configuration module, and a synchronization module.

[0032] The resource deployment module prepares computing resources, deploying load balancer nodes and real server nodes.

[0033] The configuration module configures the router to send and receive routes, enabling equal-cost multi-path routing.

[0034] The configuration module configures the load balancing nodes, selects LVS as the load balancer, and deploys it using LVS's DR mode.

[0035] The synchronization module configures LVS session synchronization. After session synchronization is configured, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to re-perform the three-way handshake.

[0036] The present invention also provides a device for implementing session synchronization in a multi-active load balancing system based on LVS, comprising: at least one memory and at least one processor;

[0037] The at least one memory is used to store a machine-readable program;

[0038] The at least one processor is used to call the machine-readable program to execute the method for implementing session synchronization in a multi-active load balancing system based on LVS.

[0039] The advantages of this invention are:

[0040] It can be horizontally scaled. The solution of this invention uses ECMP to horizontally distribute traffic to multiple load balancing nodes, so that the throughput increases linearly with the number of nodes. Combined with the real-time synchronization of conntrack sessions for Layer 2 broadcast / multicast, when expanding, only an equivalent next hop needs to be added to ECMP, and the service is unaware of the expansion.

[0041] Uninterrupted fault migration: In fault scenarios, the next hop of the faulty node is removed in ECMP, and the remaining nodes take over subsequent packets immediately with the synchronized complete session table. No handshake is required, long connections are not dropped, and sequence numbers and windows remain consistent, achieving true uninterrupted fault migration. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the loss reduction process of the algorithm in this invention. Detailed Implementation

[0043] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0044] Example 1

[0045] This invention also provides a method for implementing session synchronization in a multi-active load balancing system based on LVS, comprising:

[0046] Step 1: Prepare computing resources by deploying load balancer nodes and real server nodes.

[0047] Network environment preparation involves creating two networks on the OpenStack platform. The first is the service management network, through which the management side configures the load balancer nodes, such as the LVS load balancer and the virtual machine operating system of the load balancer nodes. It is mainly used for management purposes, and business traffic will not pass through this network card. The second is the tenant business network, which is the private virtual network where the backend servers are located. It is used to provide VIP services to the outside world and to communicate with the real servers, mainly carrying business traffic.

[0048] Deploy load balancer nodes, each with two network interface cards (NICs): one for the service management network and the other for the tenant business network. The default route uses the tenant business network. Real server nodes, rs1 and rs2, each require only one NIC for the tenant business network. The number of load balancer nodes and real server nodes can be two or more; this patent embodiment uses two nodes for illustrative purposes only.

[0049] Configure the tenant service network interface card (NIC) on load balancer node 1 as lvs-data1 with IP address 172.31.0.20; the tenant service network interface card (NIC) on load balancer node 2 as lvs-data2 with IP address 172.31.0.21; the VIP of the load balancer is 172.31.0.10; the tenant service network interface card (NIC) on real server 1 node is named rs-data1 with IP address 172.31.0.30; the tenant service network interface card (NIC) on real server 2 node is named rs-data2 with IP address 172.31.0.31.

[0050] Step 2: Configure the router to send and receive routes to achieve equal-cost multi-path routing.

[0051] The following command is used to distribute ECMP on OpenStack:

[0052] openstack router set--routedestination=172.31.0.10 / 32,gateway=172.31.0.20{routerId}

[0053] openstack router set--routedestination=172.31.0.10 / 32,gateway=172.31.0.21{routerId}

[0054] For packets destined for a VIP, there are two equivalent next-hop addresses. Depending on the configuration, you can choose either a three-layer or four-layer hash to determine the next-hop address. The default is a three-layer hash. To change to a four-layer hash, execute the following command on the router:

[0055] echo"1"> / proc / sys / net / ipv4 / fib_multipath_hash_policy

[0056] Perform a health check on each load balancer node in the load balancer cluster. When a load balancer node failure is detected, immediately remove the next hop of that node from the ECMP equal-cost route on the router.

[0057] After distributing ECMP, ensure that virtual machines (VMs) within the tenant's service network access the VIP via the router's ECMP, achieving a multi-active mode: Perform ARP proxying for the VIP on the router. When a VM within the tenant's service network accesses the VIP, it first sends an ARP request. After the router sends an ARP response, it provides the MAC address of the gateway on the router to the VM. When the VM accesses the VIP, the data packets are then sent to the router. Configure flow tables on the router to implement ARP proxying; the command format is similar to the following:

[0058] ovs-ofctl add-flow br-tun'cookie=0x12345,table=21,priority=5,arp,arp_op=1,dl_vlan=34,arp_tpa=172.31.0.10actions=load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NX M_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e8651fc->NXM_NX_ARP_SHA[],load:0xc0a86f7a->NXM_OF_ARP_SPA[],move:NXM_OF_ETH_SRC[]->NX M_OF_ETH_DST[],mod_dl_src:fa:16:3e:86:51:fc,IN_PORT'

[0059] Step 3: Configure the load balancing nodes, select LVS as the load balancer, and deploy using LVS's DR mode.

[0060] After configuring the router, configure the load balancing nodes:

[0061] Configure VIP binding to the local loopback interface:

[0062] ip addr add 172.31.0.10 / 32dev lo

[0063] Network card configuration available address pairs:

[0064] openstack port set lvs-data1--allowed-address ip-address=0.0.0.0 / 0

[0065] openstack port set lvs-data2--allowed-address ip-address=0.0.0.0 / 0

[0066] The source IP of the data packets sent from the load balancer node to the real server node is the client IP. If it is an external network access, the range of client IP addresses cannot be predicted. Therefore, when adding available address pairs to the tenant business network interface card on the load balancer node, 0.0.0.0 / 0 is added to allow all IP addresses to pass through.

[0067] Disable VIP ARP responses to prevent VIP conflicts:

[0068] echo 1> / proc / sys / net / ipv4 / conf / all / arp_ignore

[0069] echo 2> / proc / sys / net / ipv4 / conf / all / arp_announce

[0070] echo 1> / proc / sys / net / ipv4 / conf / lo / arp_ignore

[0071] echo 2> / proc / sys / net / ipv4 / conf / lo / arp_announce

[0072] Configure LVS forwarding rules:

[0073] Add a listener:

[0074] ipvsadm-At 172.31.0.10:80-s wrr

[0075] Add a real server:

[0076] ipvsadm-at 172.31.0.10:80-r 172.31.0.30:80-gw 10

[0077] ipvsadm-at 172.31.0.10:80-r 172.31.0.31:80-gw 10

[0078] Step 4: Configure LVS session synchronization by starting the master and backup daemons on both load balancer nodes simultaneously.

[0079] ip vsad m--star td aemonbacku p--syn cid=10--mc as t-in interface=eth 0

[0080] ip vsad m--star td aemonmaste r--syn cid=10--mc as t-in interface=eth 0

[0081] Select the last segment of the VIP for the syncid parameter, and set mcast-interface to the first network interface eth0. This way, the broadcast will be within the service management network and will not affect the bandwidth of the tenant's service network.

[0082] After configuring session synchronization, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to perform a three-way handshake again.

[0083] Step 5: Configure the real server node:

[0084] Bind the VIP to the local loopback interface: ip addr add 172.31.0.10 / 32dev lo

[0085] Network card configuration available address pairs:

[0086] openstackportsetr sd ata 1--allow e da ddre ssip -a ddress=1 7 2.3 1.0.1 0

[0087] openstackportsetr sd ata 2--allow e da ddre ssip -a ddress=1 7 2.3 1.0.1 0

[0088] In LVS DR mode, when the real server node returns packets, it directly sends them to the client without going through the load balancer node. The source IP of the data packet is the VIP. An available address pair with the VIP is added to the tenant's service network interface card on the real server node.

[0089] Disable VIP ARP responses to prevent VIP conflicts.

[0090] Example 2

[0091] This invention also provides a system for implementing session synchronization based on an LVS-based multi-active load balancing system, including a resource deployment module, a configuration module, and a synchronization module.

[0092] The resource deployment module prepares computing resources, deploying load balancer nodes and real server nodes.

[0093] The configuration module configures the router to send and receive routes, enabling equal-cost multi-path routing.

[0094] The configuration module configures the load balancing nodes, selects LVS as the load balancer, and deploys it using LVS's DR mode.

[0095] The synchronization module configures LVS session synchronization. After session synchronization is configured, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to re-perform the three-way handshake.

[0096] The information interaction and execution process between the modules in the above system are based on the same concept as the method embodiment of the present invention, and the specific details can be found in the description in the method embodiment of the present invention, and will not be repeated here.

[0097] Similarly, the advantages of the system of the present invention are:

[0098] It can be horizontally scaled. The solution of this invention uses ECMP to horizontally distribute traffic to multiple load balancing nodes, so that the throughput increases linearly with the number of nodes. Combined with the real-time synchronization of conntrack sessions for Layer 2 broadcast / multicast, when expanding, only an equivalent next hop needs to be added to ECMP, and the service is unaware of the expansion.

[0099] Uninterrupted fault migration: In fault scenarios, the next hop of the faulty node is removed in ECMP, and the remaining nodes take over subsequent packets immediately with the synchronized complete session table. No handshake is required, long connections are not dropped, and sequence numbers and windows remain consistent, achieving true uninterrupted fault migration.

[0100] It should be noted that not all steps and modules in the above processes and system structures are mandatory; some steps or modules can be omitted as needed. The execution order of the steps is not fixed and can be adjusted as required. The system structures described in the above embodiments can be physical or logical structures. That is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

[0101] Example 3

[0102] The present invention also provides a device for implementing session synchronization in a multi-active load balancing system based on LVS, comprising: at least one memory and at least one processor;

[0103] The at least one memory is used to store a machine-readable program;

[0104] The at least one processor is used to call the machine-readable program to execute the method for implementing session synchronization in a multi-active load balancing system based on LVS.

[0105] The information interaction and readable program execution processes of the processor in the above-mentioned device are based on the same concept as those in the method embodiments of the present invention, and the specific details can be found in the descriptions in the method embodiments of the present invention, and will not be repeated here.

[0106] Similarly, the advantages of the device of the present invention are:

[0107] It can be horizontally scaled. The solution of this invention uses ECMP to horizontally distribute traffic to multiple load balancing nodes, so that the throughput increases linearly with the number of nodes. Combined with the real-time synchronization of conntrack sessions for Layer 2 broadcast / multicast, when expanding, only an equivalent next hop needs to be added to ECMP, and the service is unaware of the expansion.

[0108] Uninterrupted fault migration: In fault scenarios, the next hop of the faulty node is removed in ECMP, and the remaining nodes take over subsequent packets immediately with the synchronized complete session table. No handshake is required, long connections are not dropped, and sequence numbers and windows remain consistent, achieving true uninterrupted fault migration.

[0109] The above-described embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention. The scope of protection of the present invention is defined by the claims.

Claims

1. A method for implementing session synchronization in a multi-active load balancing system based on LVS, characterized by: include: Step 1: Prepare computing resources by deploying load balancer nodes and real server nodes. Step 2: Configure the router to send and receive routes, implementing an equal-cost multi-path routing mode. Step 3: Configure the load balancer nodes, select LVS as the load balancer, and deploy using LVS's DR mode. Step 4: Configure LVS session synchronization. After configuring session synchronization, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to re-perform the three-way handshake.

2. The method for implementing session synchronization in a multi-active load balancing system based on LVS according to claim 1, characterized in that when deploying load balancing nodes in step 1, two network interface cards (NICs) are set on each load balancing node, namely a service management network NIC and a tenant service network NIC. The service management network is used to configure the load balancing node, and the tenant service network is used to provide VIP services to the outside world and to communicate with the real server node. When deploying real server nodes, configure the tenant's service network interface card on each real server node. Simultaneously configure the tenant business network interface name and IP address for the load balancer node, as well as the tenant business network interface name and IP address for the real server node.

3. The method for implementing session synchronization in a multi-active load balancing system based on LVS according to claim 1, characterized in that: Step 2 specifically includes: ECMP is distributed via OpenStack. If a data packet destined for a VIP has two equivalent next-hop addresses, the system selects either a three-layer or four-layer hash to determine the next-hop address, depending on the system configuration. The default is a three-layer hash. If you want to change to a four-layer hash, execute the corresponding command to modify it. Perform a health check on each load balancer node within the load balancer cluster. When a load balancer node failure is detected, immediately remove the next hop of the failed load balancer node from the ECMP equal-cost route on the router. After ECMP is deployed, when virtual machines within the tenant's business network access the VIP, they are configured to use ECMP on the router to achieve a multi-active mode. The router performs ARP proxying for the VIP. When a virtual machine within the tenant's business network accesses the VIP, it first makes an ARP request. After the router sends an ARP response, it sends the MAC address of the gateway on the router to the virtual machine. When the virtual machine accesses the VIP, the data packet is sent to the router. The router is configured with flow tables to implement ARP proxying, thus completing the router configuration.

4. The method for implementing session synchronization in a multi-active load balancing system based on LVS according to claim 1, characterized in that: Step 3 involves configuring the load balancer nodes, including: Configure the VIP to be bound to the local loopback interface. Configure the network interface card (NIC) with available address pairs. The source IP of data packets sent from the load balancer node to the real server node should be the client IP. For external network access, when adding available address pairs to the tenant's business network NIC on the load balancer node, add 0.0.0.0 / 0 to allow all IP addresses to pass through. Disable VIP ARP responses to prevent VIP conflicts. Configure LVS forwarding rules.

5. The method for implementing session synchronization in a multi-active load balancing system based on LVS according to claim 1, characterized in that: When configuring LVS session synchronization in step 4, start the master and backup daemon simultaneously on each load balancer node. Select the last segment of VIP for the syncid parameter and set mcast-interface to the first network interface card. This way, the broadcast will be within the service management network and will not affect the bandwidth of the tenant's business network.

6. The method for implementing session synchronization in a multi-active load balancing system based on LVS according to claim 1, characterized in that: This also includes step 5, configuring the real server node: Bind the VIP to the local loopback interface. Configure the network interface card (NIC) with available address pairs. In LVS DR mode, when the real server node returns packets, it directly sends them to the client without going through the load balancer node. The source IP of the data packet is the VIP. Add available address pairs with the VIP IP address to the NIC of the tenant's service network on the real server node. Disable VIP ARP responses to prevent VIP conflicts.

7. A system for implementing session synchronization based on an LVS-based multi-active load balancing system, characterized in that: It includes a resource deployment module, a configuration module, and a synchronization module. The resource deployment module prepares computing resources, deploying load balancer nodes and real server nodes. The configuration module configures the router to send and receive routes, enabling equal-cost multi-path routing. The configuration module configures the load balancing nodes, selects LVS as the load balancer, and deploys it using LVS's DR mode. The synchronization module configures LVS session synchronization. After session synchronization is configured, when a user request passes through one of the load balancer nodes, if the load balancer node has completed the TCP three-way handshake and the connection has been established, the load balancer node encapsulates the five-tuple information of the TCP connection and the session state into a lightweight synchronization message, and sends it to all load balancer nodes in the same cluster according to the pre-configured broadcast address. The load balancer node that receives the synchronization message first checks whether the conntrack table entry with the same five-tuple already exists locally. If it does not exist, it directly inserts a new connection tracking record. If it exists, it merges the state using the "no overwrite" or "timestamp update" strategy, thereby ensuring that the entire cluster has a completely consistent view of this long connection. When the load balancer node that sent the synchronization message stops forwarding traffic due to failure or manual shutdown, the remaining load balancer nodes seamlessly take over subsequent messages without having to re-perform the three-way handshake.

8. A device for implementing session synchronization in a multi-active load balancing system based on LVS, characterized in that: include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute a method for implementing session synchronization in a multi-active load balancing system based on LVS, as described in any one of claims 1 to 6.

Images