Virtual IP address switching method and device, electronic equipment and medium

Abstract

The invention discloses a virtual IP address switching method and device, electronic equipment and a medium. The method comprises the following steps: in the process of establishing communication connection with a client through a virtual IP address and providing service, acquiring connection state information of the communication connection; synchronizing the connection state information to middleware in real time; wherein the connection state information is used for a second node to acquire from the middleware, so that after the virtual IP address is switched to the second node, the second node provides services for the client based on the connection state information. According to the method, when the virtual IP address switches the node equipment, the standby second node does not need to establish TCP connection with the client again, and the session with the client can be directly recovered based on the connection state information obtained by the middleware, so that the reconnection time is shortened, seamless connection taking-over is realized, the continuity of the network is kept in a high-concurrency scene, and the user experience is improved. And the high availability, the stability and the response speed of the system are greatly improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of network communication, and in particular to a virtual IP address switching method and device, electronic equipment and medium. BACKGROUND

[0002] In current high-availability network deployment, in a virtual IP failover scenario, Keepalived technology can be used to achieve high-availability configuration between multiple servers. When one of the machines is down, the virtual IP will automatically drift to another standby machine to ensure service continuity.

[0003] The drift of the virtual IP will cause the TCP (Transmission Control Protocol) connection established to be disconnected. For example, when the virtual IP falls on machine A, the client establishes a TCP connection with machine A. If machine A fails at this time, the virtual IP drifts to machine B, and the subsequent traffic of the client will be directed to machine B. However, since the TCP connection state information only exists on machine A, the connection information between the client and machine A will not be inherited by machine B, and machine B cannot recognize the original connection state. Therefore, the client must re-initiate the connection establishment request, causing the existing connection session to be forced to disconnect. This affects business continuity, and in some high-concurrency or low-latency scenarios, it may cause the service to crash or the response to be significantly delayed. SUMMARY

[0004] In view of the above problems, embodiments of the present application are proposed to provide a virtual IP address switching method, device, electronic equipment and medium that overcome the above problems or at least partially solve the above problems.

[0005] In a first aspect, embodiments of the present application disclose a virtual IP address switching method applied to a first node, the method comprising: In the process of establishing a communication connection with a client through a virtual IP address and providing services, obtaining connection state information of the communication connection; synchronizing the connection state information to an intermediate in real time; The connection state information is used for a second node to obtain from the intermediate, so that the second node provides services for the client based on the connection state information after the virtual IP address is switched to the second node.

[0006] In a second aspect, embodiments of the present application disclose a virtual IP address switching method applied to a second node, the method comprising: obtaining connection state information from an intermediate; the connection state information is synchronized to the intermediate by a first node; In response to a switching event that the virtual IP address is switched from the first node to the second node, based on the connection state information, a communication connection with a client is taken over and service is provided.

[0007] In a third aspect, the embodiments of the present application disclose a virtual IP address switching method, applied to middleware, the method comprising: receiving connection state information from a first node; distributing the connection state information to one or more second nodes; The connection state information is used for the second node to resume a communication connection with a client and provide service for the client after taking over a virtual IP address.

[0008] In a fourth aspect, the embodiments of the present application disclose a virtual IP address switching device, applied to a first node, the device comprising: A first obtaining module is configured to obtain connection state information of a communication connection in a process of establishing the communication connection with a client through a virtual IP address and providing service. A synchronizing module is configured to synchronize the connection state information to middleware in real time. The connection state information is used for a second node to obtain from the middleware, so that the second node provides service for the client based on the connection state information after the virtual IP address is switched to the second node.

[0009] In a fifth aspect, the embodiments of the present application disclose an electronic device, comprising: a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method of the first aspect to the third aspect.

[0010] In a sixth aspect, the embodiments of the present application disclose a computer readable storage medium, when instructions in the computer readable storage medium are executed by a processor of an electronic device, the electronic device can execute the method of any one of the first aspect to the third aspect.

[0011] In the embodiments of the present application, a virtual IP address switching method is disclosed, applied to a first node, the method comprising: In the process of establishing a communication connection with a client through a virtual IP address and providing services, connection state information of the communication connection is acquired; the connection state information is synchronized to middleware in real time; wherein the connection state information is used for a second node to acquire from the middleware, so that after the virtual IP address is switched to the second node, the second node provides services for the client based on the connection state information. The method of the application, when the first node fails, the virtual IP is taken over by the second node, the first node synchronizes the connection state information with the client to the middleware, and the second node can acquire the connection state information with the client from the middleware, so that after the second node takes over the virtual IP address, the communication state with the client can be restored based on the connection state information acquired from the middleware, and the services for the client can be continued. The method of the application, when the virtual IP address is switched to the node device, the standby second node does not need to reestablish a TCP connection with the client, and can directly restore the session with the client based on the connection state information acquired from the middleware, reduces the reconnection time, realizes seamless takeover of the connection, maintains the continuity of the network in a high concurrency scene, and greatly improves the high availability, stability and response speed of the system. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 is a step flow chart of a virtual IP address switching method provided by an embodiment of the application, applied to a first node; Figure 2 is a step flow chart of a virtual IP address switching method provided by an embodiment of the application, applied to a second node; Figure 3 is a step flow chart of a virtual IP address switching method provided by an embodiment of the application, applied to middleware; Figure 4 is an implementation architecture diagram provided by an embodiment of the application; Figure 5 is a schematic diagram of communication between a kernel mode and a user mode provided by an embodiment of the application; Figure 6 is a block diagram of a virtual IP address switching device provided by an embodiment of the application, applied to a first node; Figure 7 is a block diagram of a virtual IP address switching device provided by an embodiment of the application, applied to a second node; Figure 8 is a block diagram of a virtual IP address switching device provided by an embodiment of the application, applied to middleware; Figure 9 is a block diagram of an electronic device provided by an embodiment of the application; Figure 10 is another schematic diagram of an electronic device provided by an embodiment of the application. DETAILED DESCRIPTION

[0013] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0015] The concepts involved in this application are explained below.

[0016] VIP (Virtual IP): A type of IP address that can move between multiple servers. It is typically used in high-availability clusters so that clients can access the server through the IP address regardless of how the actual backend server they are accessing changes.

[0017] Keepalived is an open-source service for achieving high availability and load balancing in a Linux environment. It uses the Virtual Router Redundancy Protocol (VRRP) to manage the migration of virtual IP addresses, thereby automatically switching the virtual IP address to another node when the server fails.

[0018] A five-tuple is a set of five parameters in the TCP / IP protocol stack that identify each connection session, including the source IP address, destination IP address, source port, destination port, and protocol type. The five-tuple is used to uniquely identify each session.

[0019] TCP State: The current state information of a TCP connection, including connection establishment (such as SYN), connection transmission (such as ACK), and connection termination (such as FIN), which are used to identify the lifecycle of the connection.

[0020] Middleware: A component used to manage and synchronize TCP session data and TCP state between servers. Middleware stores session data and state information and synchronizes it with other standby machines to achieve seamless connection failover.

[0021] Kernel Flow Table: A table in the operating system kernel used to record network traffic information, including routing information for network connections. The flow table is used for fast packet forwarding, and in this application, it is used to identify client traffic when a standby machine takes over.

[0022] Netlink component (Netlink): A communication mechanism provided by the Linux system kernel for passing messages between user space and kernel space. In this application, Netlink is used to write middleware-synchronized session data and state information into the kernel's flow table and TCP state table.

[0023] Existing high-availability technologies (such as Keepalived) can achieve virtual IP address migration, but they have problems handling existing TCP connections: when the VIP migrates between multiple nodes, the established connection between the client and the server will be forced to close. The client needs to re-establish the connection, increasing the system load and causing business interruption. Since the state information of the TCP connection is only stored on the currently active server, once that server goes down, other backup servers cannot inherit this state information, resulting in high connection reconstruction costs. In some scenarios, TCP connection reconstruction may also lead to data transmission interruption, especially for applications that require maintaining long-term connections (such as real-time communication, video streaming, etc.), which will seriously affect the user experience. Based on the above problems, this application discloses a virtual IP address switching method, as follows.

[0024] refer to Figure 1 , Figure 1 This application provides a virtual IP address switching method, applied to a first node, the method comprising: Step 101: During the process of establishing a communication connection with the client through the virtual IP address and providing services, obtain the connection status information of the communication connection; Step 102: Synchronize the connection status information to the middleware in real time; The connection status information is used by the second node to obtain from the middleware so that, after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information.

[0025] In this embodiment, the switching of virtual IP addresses can be achieved using Keepalived technology. Keepalived implements virtual IP migration based on VRRP (Virtual Router Redundancy Protocol). The process is as follows: nodes in the cluster first elect a master node and a standby node according to priority. The master node is used to bind the virtual IP address and respond to client requests. Simultaneously, the master node periodically sends VRRP announcements. The master node monitors its own service status in real time. When the master node fails and the standby node does not receive VRRP announcements, the standby node is switched to bind the virtual IP, completing the virtual IP switching. In this application, the first node serves as the master node, and the second node serves as the standby node.

[0026] Specifically, virtual IP addresses can be mapped to different servers in the cluster, and the servers establish communication connections with clients through these virtual IP addresses. For example, a client first establishes a communication connection with the first node based on the virtual IP address. After establishing a connection with the client, the first node provides the corresponding functions to the client according to the client's request. During the process of providing services to the client, the first node can obtain various connection status information in real time, including but not limited to the connection establishment time, the current connection status, the client's IP address, and port number. The first node can synchronize the connection status information to the middleware in real time when the connection status information changes, ensuring that the middleware can obtain the latest connection status information in a timely manner and reducing latency.

[0027] The middleware can be deployed on a separate server to store and manage connection state information. After the first node sends the connection state information to the middleware, other backup nodes, such as the second node, can obtain the connection state information by querying the middleware. As a backup node, the second node can access the middleware at regular intervals to obtain the connection state information promptly. After the virtual IP address is switched to the second node, the second node can provide services to the client based on the connection state information. That is, when the first node fails or needs to switch the virtual IP address to the second node for other reasons, the second node can obtain the connection state information of the previous connection between the first node and the client from the middleware, and then continue to provide services to the client based on the connection state information, thereby ensuring that the client session is not lost during the virtual IP address switch and guaranteeing service continuity. Alternatively, the middleware can be deployed on both the first and second nodes to implement the above method; this embodiment does not limit the scope of the application.

[0028] Optionally, the connection status information includes at least one of the following: connection quintuple, communication connection status, and sequence number.

[0029] In this embodiment, at least one of the following is used: a connection 5-tuple, a communication connection status, and a sequence number. The connection 5-tuple is a core set of information that uniquely identifies a network communication connection, specifically including: source address, destination address, source port, destination port, and transport layer protocol (e.g., TCP). The 5-tuple information can be used to locate a specific connection between the client and the server. In a virtual IP address migration scenario, the second node obtains the connection 5-tuple through middleware. The 5-tuple allows it to identify the target connection that needs to be continued and continue providing services to the client. The communication connection status refers to the TCP connection status between the client and the first node, which can include established connection, data transmission in progress, and disconnection. The communication connection status reflects the real-time operation of the connection, such as whether it is in a normal communication state or whether it is processing data. After obtaining the communication connection status, the second node can directly continue providing services to the client according to the current status, without requiring the client to re-initiate a connection request with the second node, thus avoiding connection interruption and improving response speed. The sequence number can include the sender's sending sequence number and the receiver's acknowledgment sequence number. After the virtual IP address switches and drifts, the second node can determine the current data transmission progress by obtaining the sequence number, and thus continue to send or receive data based on the current progress, avoiding data loss or out-of-order transmission, and ensuring the continuity and reliability of communication.

[0030] Optionally, step 102 includes: Sub-step 1021: After establishing a communication connection with the client via the virtual IP address, and when the status of the communication connection is updated, the connection status information is synchronized to the middleware in real time.

[0031] In this embodiment of the application, after establishing a communication connection with the client through a virtual IP address, and when the status of the communication connection is updated, the connection status information can be synchronized to the middleware in real time to ensure that the middleware stores the latest status and achieve seamless switching of the virtual IP address.

[0032] Specifically, when the first node establishes a TCP communication connection with the client, it synchronizes the connection state information to the middleware. During data transmission between the client and the first node after the connection is established, the connection state continuously changes; for example, the state changes from "establishing connection" to "data transmission in progress," and the sequence number increments as data is sent and received. When the connection state is updated, the first node synchronizes the latest connection state information to the middleware in real time, ensuring that the middleware stores the latest state data. In other words, the middleware stores the latest connection state data throughout the process of establishing a communication connection and transmitting data between the client and the first node. When the virtual IP address migrates to the second node (the backup node), the second node obtains the latest connection state from the middleware, allowing it to directly continue providing services to the client and avoiding connection interruption or data loss.

[0033] This application can be applied to high availability scenarios. When a virtual IP address drifts, it can achieve seamless connection switching between multiple machines by synchronizing TCP connection session data, avoiding the forced disconnection of existing connections due to VIP drift, and ensuring the continuity of data transmission and high reliability of services.

[0034] In one embodiment: When the virtual IP address falls on machine A, the client establishes a TCP connection with machine A. Machine A records the session data of this TCP connection using a 5-tuple (source address, destination address, source port, destination port, and protocol) and synchronizes the TCP connection status and sequence number to the middleware. The middleware synchronizes the TCP session data so that the standby machine (machine B) can directly inherit the session after taking over the VIP, avoiding data transmission interruption due to connection reconstruction. Machine B periodically synchronizes the TCP session data of machine A from the middleware, including the 5-tuple, connection status, sequence number, etc. The synchronized session data is then communicated from machine B's user space to machine B's kernel space to update the flow tables and TCP connection status in the kernel, ensuring that machine B can recognize and take over subsequent data packets of the original connection after the VIP migrates. When machine A fails or crashes, and the VIP migrates to machine B, machine B has already established the corresponding flow tables and TCP connection status in its kernel, enabling it to directly recognize data packets from the client and seamlessly take over the connection. This means that subsequent data packets sent by the client will no longer require re-establishing a connection and can continue transmission using machine B's synchronized session data.

[0035] This invention effectively solves the problem of forced TCP connection interruption caused by VIP drift in existing high-availability networks. By synchronizing session data and updating the kernel flow table of the standby machine through middleware, a seamless connection switch from the client to the standby machine is achieved during VIP drift. This allows for: eliminating the need for connection reconstruction during VIP drift by automatically inheriting TCP session information, reducing connection latency and reconstruction costs; enabling the standby machine to directly recognize and process client data packets, avoiding data transmission interruption and maintaining data transmission continuity; and ensuring business continuity in high-concurrency and low-latency application scenarios, providing users with a more stable service experience, and improving system reliability and user experience.

[0036] In summary, this application discloses a virtual IP address switching method applied to a first node. The method includes: acquiring connection status information of the communication connection during the process of establishing a communication connection with a client and providing services through a virtual IP address; and synchronizing the connection status information to middleware in real time. The connection status information is used by a second node to obtain it from the middleware, so that after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware, and the second node can obtain the connection status information with the client from the middleware. Therefore, after the second node takes over the virtual IP address, it can restore the communication status with the client based on the connection status information obtained from the middleware and continue to provide services to the client. When switching node devices using a virtual IP address, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0037] refer to Figure 2 , Figure 2 This application provides a virtual IP address switching method, applied to a second node, the method comprising: Step 201: Obtain connection status information from the middleware; the connection status information is synchronized from the first node to the middleware. Step 202: In response to the switching event where the virtual IP address is switched from the first node to the second node, take over the communication connection with the client and provide services based on the connection status information.

[0038] In this embodiment, the second node is a backup node, and there can be multiple second nodes. After the first node fails, the target second node to actually take over the virtual IP address can be determined according to the priority order of the multiple backup second nodes. Connection status information is used to reflect the original communication connection status between the first node and the client, and the connection status information is synchronized from the first node to the middleware. The second node can access the middleware to obtain connection status information at preset intervals.

[0039] When a failure is detected in the first node and the virtual IP address is switched from the first node to the second node, the switchover event directly triggers the second node to perform a takeover operation. At this time, the second node has already obtained the connection status information between the client and the first node, and can quickly take over the virtual IP address. The second node does not need to re-establish a connection with the client, but seamlessly replaces the first node to provide services to the client based on the connection status information obtained from the middleware, achieving seamless switching and improving response efficiency.

[0040] Optionally, step 201 includes: Sub-step 2011: Query the middleware based on a preset time interval to obtain connection status information; Sub-step 2012: Write the connection state information into the kernel flow table, and update the state of the communication connection based on the connection state information.

[0041] In this embodiment, for sub-steps 2011 and 2012, the second node can proactively initiate query requests to the middleware at preset time intervals to obtain the latest connection status information. The preset time interval can be in the millisecond or second range to ensure real-time status synchronization; this embodiment does not limit the time interval.

[0042] Connection status information is synchronized to the middleware by the first node after establishing a connection with the client and during connection status updates. This information includes a five-tuple, communication connection status, sequence number, etc. By periodically querying the middleware, the second node continuously synchronizes the latest data. When a virtual IP address switch is triggered, the second node is guaranteed to have the latest connection status information, preventing takeover failure due to information discrepancies after the virtual IP address switch to the second node.

[0043] After obtaining the connection status information, the second node can write it into its own kernel flow table. The kernel flow table is a core module in the operating system kernel that stores network connection rules and states. It can directly interface with the data transmission process, ensuring that subsequent data transmission can quickly match the target connection. Simultaneously, the second node can update the communication connection status (i.e., the TCP connection status) based on the obtained connection status information, such as updating the sequence number to the latest send / acknowledge sequence number, ensuring its connection status is consistent with that before the first node's interruption. When the virtual IP address switches to the second node, the kernel can directly process client data based on the information in the flow table, achieving seamless takeover.

[0044] This application not only achieves seamless takeover of VIP drift by synchronizing the kernel flow table, but also ensures the consistency of the client's connection state during VIP drift by updating the communication connection state, i.e., real-time synchronization of the TCP state. This mechanism is suitable for complex multi-node scenarios, such as drifting between multiple backup servers (e.g., B, C, D, etc.), guaranteeing the consistency of the TCP connection state. Compared to traditional solutions that only synchronize session data, this application ensures the consistency of the TCP connection state on multiple backup machines by synchronizing TCP state data, avoiding connection reset problems caused by state asynchrony. This application's solution can be seamlessly extended to large-scale cluster environments, ensuring that any node can seamlessly take over existing connections in multi-node high-availability deployments. Through communication components such as netlink, after obtaining the connection state information (TCP session data and state information) synchronized by the middleware, the backup machine can directly write this data from user space to the flow table and TCP state table in kernel space, ensuring that the kernel can recognize the connection state and continue data transmission during VIP drift. Compared to traditional user-space processing schemes, this application interacts directly with the kernel through communication components such as netlink, enabling efficient synchronization of TCP state and flow tables, reducing context switching overhead, and improving synchronization speed and processing efficiency. By directly updating the kernel's TCP state and flow tables, the latency of handling connections after VIP drift is reduced, ensuring rapid recovery between the client and server.

[0045] Optionally, step 202 includes: Sub-step 2021: Receive data packets sent by the client based on the virtual IP address; Sub-step 2022: Verify the data packet based on the kernel flow table, and if the verification is successful, process the data packet based on the state of the communication connection.

[0046] In this embodiment, regarding sub-steps 2021 and 2022, after the virtual IP address is switched from the first node to the second node, the client continues to send subsequent data packets to that virtual IP address. After receiving the data packets from the client, the second node replaces the original first node and continues interacting with the client. Upon receiving the data packets, the second node first queries its own kernel flow table to verify the packets. It determines whether the connection 5-tuple of the data packet matches the connection state information stored in the kernel flow table, confirming whether the data packet belongs to a synchronized communication connection to avoid processing erroneous data packets. Once verification is successful, the second node processes the data packets based on the updated communication connection state and sequence number. For example, if the client sends business data, it continues processing and provides feedback on the result, continuing with the original transmission progress; if it sends control data related to the connection state, it synchronously updates the local connection state to ensure the orderliness and reliability of subsequent communication. The entire process requires no additional client operation, achieving seamless takeover.

[0047] In summary, this application discloses a virtual IP address switching method applied to a second node. The method includes: obtaining connection status information from middleware; synchronizing the connection status information from a first node to the middleware; and, in response to a switching event where the virtual IP address is switched from the first node to the second node, taking over the communication connection with the client and providing services based on the connection status information. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware, and the second node can obtain the connection status information with the client from the middleware. Therefore, after taking over the virtual IP address, the second node can restore the communication status with the client based on the connection status information obtained from the middleware and continue to provide services to the client. When switching node devices using the virtual IP address, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0048] refer to Figure 3 , Figure 3 This application provides a virtual IP address switching method, applied to middleware, the method comprising: Step 301: Receive connection status information from the first node; Step 302: Distribute the connection status information to one or more second nodes; The connection status information is used by the second node to restore the communication connection with the client after taking over the virtual IP address, so as to provide services to the client.

[0049] In this embodiment, the middleware receives and distributes connection status information, enabling second nodes (standby nodes) to obtain this information and seamlessly take over the virtual IP address, ensuring uninterrupted connection after VIP migration. The first node can be the master node currently bound to the virtual IP address, establishing a communication connection with the client, and providing services. After connection establishment or status update, the first node synchronizes the connection status information to the middleware in real time, which receives and stores the information. When a second node queries or requests connection status information, the middleware can transmit the received information to one or more standby second nodes in the cluster. This ensures that all potential second nodes participating in service takeover can obtain the latest connection status information in advance, avoiding delays during virtual IP address switching. By synchronizing connection status information to the second nodes through the middleware, the second nodes can quickly restore their original communication connection with the client using the pre-obtained connection status information, seamlessly continuing service and ensuring service continuity.

[0050] Furthermore, in more complex scenarios, such as multi-node high-availability cluster environments, VIP migration involves not only two machines but may also switch between multiple backup nodes. This application's solution supports multiple backup machines (e.g., machines B, C, D, etc.) synchronizing middleware session data, avoiding connection interruptions when the VIP migrates between different backup machines. The implementation steps include: T1, Multi-node data synchronization Session data on machine A will be simultaneously synchronized to multiple backup machines (B, C, D), and each backup node will periodically obtain the latest session information from the middleware.

[0051] T2, Flow table updates at each backup node Each backup node writes synchronized session data into its kernel flow table, ensuring seamless takeover when the VIP switches to any node.

[0052] T3, VIP drifts to backup node When machine A fails and the VIP migrates to any backup node (such as machine C), machine C seamlessly takes over the client connection through pre-synchronized session data, ensuring business continuity.

[0053] By synchronizing TCP session data across multiple backup nodes, this approach ensures that no connection rebuilding is required after VIP migration, guaranteeing client connection continuity, preventing data transmission interruptions, and ensuring business continuity. It is suitable for high-concurrency scenarios. Traditional VIP migration schemes require re-establishing TCP connections after a break. This application avoids the cost of re-establishing connections through seamless session switching, reduces network latency, and improves user experience. In multi-node scenarios, the multi-backup node synchronization mechanism enhances the cluster's fault tolerance, ensuring that the VIP can take over client connections even when migrating to any node, thus improving system reliability.

[0054] refer to Figure 4 and Figure 5 This application relates to TCP connection session management in a high-availability network environment, applied to seamless connection switching between multiple network element devices (servers). In a Keepalived-deployed VIP failover scenario, middleware synchronizes TCP session data from machine A to machine B, thereby achieving seamless takeover of client connections after VIP migration. This method can be used in service systems with high availability requirements. Typical deployment environments include: Network element devices: Multiple servers (such as machines A and B) jointly participate in VIP migration management within a Keepalived environment. VIPs are dynamically switched between servers to ensure high availability. Middleware: As a core component for data synchronization, such as etcd or redis, it is responsible for transmitting TCP session data between machine A and machine B, including the five-tuple (source IP, destination IP, source port, destination port, and protocol), TCP connection status, sequence number, and other key information. Kernel flow table: In the kernel of each server, the TCP session data provided by the middleware is written from user space to the kernel flow table through communication methods such as the netlink component, so that subsequent data packets from the client can be directly identified when the VIP migrates to machine B. The specific implementation process is as follows: S1, The client establishes a connection with machine A: When the VIP is on machine A, the client establishes a TCP connection with machine A, and machine A records the session data of this connection using a 5-tuple. When the client sends a connection request to the VIP for the first time, the following operations are triggered: machine A generates a TCP connection state and uploads the connection state and sequence number to the middleware. This ensures that the session information between the client and machine A is created on machine A and synchronized to the middleware.

[0055] S2, Machine A synchronizes session data to the middleware: Machine A synchronizes information such as the 5-tuple, TCP connection status, and sequence number to the middleware in real time, ensuring that machine B can obtain the session data. When a client connection is established or the connection status is updated, machine A is triggered to push the latest session data to the middleware through an interface, allowing the middleware to save the connection status data for access by the backup machine B.

[0056] S3, B machines periodically synchronize data from the middleware and update the kernel flow table and TCP connection status: Machine B periodically queries the middleware for session data from machine A and writes this data into its own kernel's flow table and updates the TCP connection state. When machine B's scheduled task is triggered, or when a VIP is detected on machine A, communication components such as netlink write the obtained 5-tuple and state information into machine B's kernel flow table and update the TCP connection state. Machine B's kernel establishes a corresponding TCP flow table, enabling it to take over the connection in the event of a failure in machine A.

[0057] S4, VIP drift and seamless takeover: When machine A fails and the VIP migrates to machine B, subsequent data packets from the client will be sent to machine B. Machine B directly identifies and takes over the connection using pre-synchronized session data, i.e., connection state information. If machine A fails, Keepalived triggers VIP migration. Machine B's kernel flow table identifies the five-tuple of the client's data packets and continues transmission according to existing session information. After the VIP migrates to machine B, the client can continue data transmission without rebuilding the connection.

[0058] In this application, when a client establishes a TCP connection with machine A, machine A not only synchronizes TCP session data (such as 5-tuples, sequence numbers, etc.) to the middleware, but also synchronizes the TCP connection state (such as SYN, ACK, FIN, etc.). This session data and state are shared in real time with the backup machine (such as machine B) through the middleware to ensure seamless takeover of the existing connection after VIP migration. Compared to existing technologies that can only process TCP packets to rebuild the connection after VIP migration, this application enables the backup machine to fully take over the current state of the connection after VIP migration by synchronizing the TCP state, without having to reprocess the connection handshake or termination state, thus ensuring connection continuity. Furthermore, synchronizing TCP state data can avoid connection reset or data loss problems caused by VIP migration, which is particularly suitable for long-term connection scenarios (such as video streaming, file transfer, etc.). Backup machines such as machine B can periodically synchronize the session data and TCP connection state of machine A from the middleware, and update this information from user space to their own kernel flow table and TCP state table through components such as netlink. In this way, when the VIP migrates to machine B, machine B can immediately recognize the data packets sent by the client and continue processing them according to the synchronized TCP state. By synchronizing the kernel's TCP state table and flow table, the standby machine can not only identify the routing rules of data packets but also the exact state of the current connection (such as whether to wait for an ACK), ensuring connection integrity. By synchronizing the state table in advance, there is no need to wait for a new TCP handshake process after VIP migration, avoiding long client wait times or reconnections, and improving network response speed.

[0059] In high-concurrency scenarios, optimized design was implemented for TCP state and flow table synchronization across a large number of concurrent connections. This ensures the middleware can efficiently handle data and state synchronization across multiple connections, maintaining system stability. Improved system concurrency processing capabilities: Efficient synchronization of the TCP state table maintains state consistency across a large number of connections in high-concurrency environments, avoiding the concurrency bottleneck issues associated with traditional VIP drift. In high-concurrency environments, synchronizing TCP state and flow tables avoids the problem of numerous connection reconstructions caused by VIP drift, reducing system resource consumption.

[0060] This application solves the problem of TCP connection interruption caused by VIP drift in existing technologies by synchronizing TCP session data and TCP connection state, combined with the synchronization mechanism of kernel flow tables and state tables. The synchronized TCP state and flow tables enable standby machines to seamlessly take over the connection and maintain network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0061] In summary, this application discloses a virtual IP address switching method applied to middleware. The method includes: receiving connection status information from a first node; distributing the connection status information to one or more second nodes; wherein the connection status information is used by the second node to restore communication with the client after taking over the virtual IP address, in order to provide services to the client. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware. The second node can obtain the connection status information with the client from the middleware, and thus, after taking over the virtual IP address, it can restore communication with the client based on the connection status information obtained from the middleware, continuing to provide services to the client. When switching node devices for virtual IP addresses, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0062] refer to Figure 6 This illustration shows a virtual IP address switching device 40 provided in an embodiment of this application, applied to a first node, the device comprising: The first acquisition module 401 is used to acquire the connection status information of the communication connection during the process of establishing a communication connection with the client through the virtual IP address and providing services; Synchronization module 402 is used to synchronize the connection status information to the middleware in real time; The connection status information is used by the second node to obtain from the middleware so that, after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information.

[0063] Optionally, the connection status information includes at least one of the following: connection quintuple, communication connection status, and sequence number.

[0064] Optionally, the synchronization module includes: The first synchronization submodule is used to synchronize the connection status information to the middleware in real time after establishing a communication connection with the client via a virtual IP address, and when the status of the communication connection is updated.

[0065] In summary, this application discloses a virtual IP address switching method applied to a first node. The method includes: acquiring connection status information of the communication connection during the process of establishing a communication connection with a client and providing services through a virtual IP address; and synchronizing the connection status information to middleware in real time. The connection status information is used by a second node to obtain it from the middleware, so that after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware, and the second node can obtain the connection status information with the client from the middleware. Therefore, after the second node takes over the virtual IP address, it can restore the communication status with the client based on the connection status information obtained from the middleware and continue to provide services to the client. When switching node devices using a virtual IP address, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0066] refer to Figure 7 This application illustrates a virtual IP address switching device provided in an embodiment of the present application, applied to a second node. The device includes: The second acquisition module is used to acquire connection status information from the middleware; the connection status information is synchronized from the first node to the middleware. The takeover module is used to take over the communication connection with the client and provide services based on the connection status information in response to a switching event where the virtual IP address is switched from the first node to the second node.

[0067] Optionally, the second acquisition module includes: The query submodule is used to query the middleware based on a preset time interval to obtain connection status information; The write submodule is used to write the connection state information into the kernel flow table and update the state of the communication connection based on the connection state information.

[0068] Optionally, the takeover module includes: A receiving submodule is used to receive data packets sent by the client based on the virtual IP address; The processing submodule is used to verify the data packet based on the kernel flow table, and when the verification is successful, to process the data packet based on the state of the communication connection.

[0069] In summary, this application discloses a virtual IP address switching method applied to a second node. The method includes: obtaining connection status information from middleware; synchronizing the connection status information from a first node to the middleware; and, in response to a switching event where the virtual IP address is switched from the first node to the second node, taking over the communication connection with the client and providing services based on the connection status information. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware, and the second node can obtain the connection status information with the client from the middleware. Therefore, after taking over the virtual IP address, the second node can restore the communication status with the client based on the connection status information obtained from the middleware and continue to provide services to the client. When switching node devices using the virtual IP address, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0070] refer to Figure 8 This application illustrates a virtual IP address switching device provided in an embodiment of the present application, applied to middleware, the device comprising: The receiving module is used to receive connection status information from the first node; The distribution module is used to distribute the connection status information to one or more second nodes; The connection status information is used by the second node to restore the communication connection with the client after taking over the virtual IP address, so as to provide services to the client.

[0071] In summary, this application discloses a virtual IP address switching method applied to middleware. The method includes: receiving connection status information from a first node; distributing the connection status information to one or more second nodes; wherein the connection status information is used by the second node to restore communication with the client after taking over the virtual IP address, in order to provide services to the client. When the first node fails, the virtual IP address is taken over by the second node. The first node synchronizes the connection status information with the client to the middleware. The second node can obtain the connection status information with the client from the middleware, and thus, after taking over the virtual IP address, it can restore communication with the client based on the connection status information obtained from the middleware, continuing to provide services to the client. When switching node devices for virtual IP addresses, the backup second node does not need to re-establish a TCP connection with the client. It can directly restore the session with the client based on the connection status information obtained from the middleware, reducing reconnection time, achieving seamless connection takeover, and maintaining network continuity in high-concurrency scenarios, greatly improving the system's high availability, stability, and response speed.

[0072] Figure 9 This is a block diagram illustrating an electronic device 600 according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0073] Reference Figure 9 The electronic device 600 may include one or more of the following components: a processing component 602, a memory 604, a power supply component 606, a multimedia component 608, an audio component 610, an input / output (I / O) interface 612, a sensor component 614, and a communication component 616.

[0074] Processing component 602 typically controls the overall operation of electronic device 600, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 602 may include one or more processors 620 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 602 may include one or more modules to facilitate interaction between processing component 602 and other components. For example, processing component 602 may include a multimedia module to facilitate interaction between multimedia component 608 and processing component 602.

[0075] Memory 604 is used to store various types of data to support the operation of electronic device 600. Examples of this data include instructions for any application or method operating on electronic device 600, contact data, phonebook data, messages, pictures, multimedia, etc. Memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0076] Power supply component 606 provides power to various components of electronic device 600. Power supply component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 600.

[0077] Multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 608 includes a front-facing camera and / or a rear-facing camera. When the electronic device 600 is in an operating mode, such as a shooting mode or a multimedia mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0078] Audio component 610 is used to output and / or input audio signals. For example, audio component 610 includes a microphone (MIC) used to receive external audio signals when electronic device 600 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 604 or transmitted via communication component 616. In some embodiments, audio component 610 also includes a speaker for outputting audio signals.

[0079] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0080] Sensor assembly 614 includes one or more sensors for providing state assessments of various aspects of electronic device 600. For example, sensor assembly 614 can detect the on / off state of electronic device 600, the relative positioning of components such as the display and keypad of electronic device 600, changes in position of electronic device 600 or a component of electronic device 600, the presence or absence of user contact with electronic device 600, orientation or acceleration / deceleration of electronic device 600, and temperature changes of electronic device 600. Sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 614 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0081] Communication component 616 facilitates wired or wireless communication between electronic device 600 and other devices. Electronic device 600 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0082] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement a virtual IP address switching method provided in the embodiments of this application.

[0083] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, which can be executed by a processor 620 of an electronic device 600 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0084] Figure 10This is a block diagram illustrating an electronic device 700 according to an exemplary embodiment. For example, the electronic device 700 may be provided as a server. (Refer to...) Figure 10 The electronic device 700 includes a processing component 722, which further includes one or more processors, and memory resources represented by a memory 732 for storing instructions, such as application programs, that can be executed by the processing component 722. The application programs stored in the memory 732 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 722 is configured to execute instructions to perform a virtual IP address switching method provided in embodiments of this application.

[0085] Electronic device 700 may also include a power supply component 726 configured to perform power management of electronic device 700, a wired or wireless network interface 750 configured to connect electronic device 700 to a network, and an input / output (I / O) interface 758. Electronic device 700 may operate on an operating system stored in memory 732, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, or similar.

[0086] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the virtual IP address switching method.

[0087] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0088] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for switching virtual IP addresses, characterized in that, Applied to the first node, the method includes: During the process of establishing a communication connection with the client through a virtual IP address and providing services, the connection status information of the communication connection is obtained; The connection status information is synchronized to the middleware in real time. The connection status information is used by the second node to obtain from the middleware so that, after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information.

2. The method according to claim 1, characterized in that, The connection status information includes at least one of the following: connection quintuple, communication connection status, and sequence number.

3. The method according to claim 1, characterized in that, The step of synchronizing the connection status information to the middleware in real time includes: After establishing a communication connection with the client via a virtual IP address, and when the status of the communication connection is updated, the connection status information is synchronized to the middleware in real time.

4. A method for switching virtual IP addresses, characterized in that, Applied to the second node, the method includes: The connection status information is obtained from the middleware; the connection status information is synchronized from the first node to the middleware. In response to a switching event where the virtual IP address is switched from the first node to the second node, the system takes over the communication connection with the client and provides services based on the connection status information.

5. The method according to claim 4, characterized in that, The step of obtaining connection status information from the middleware includes: The middleware is queried at preset time intervals to obtain connection status information; The connection state information is written into the kernel flow table, and the state of the communication connection is updated based on the connection state information.

6. The method according to claim 5, characterized in that, The takeover of the communication connection with the client and the provision of services include: Receive data packets sent by the client based on the virtual IP address; The data packet is verified based on the kernel flow table, and if the verification is successful, the data packet is processed based on the state of the communication connection.

7. A method for switching virtual IP addresses, characterized in that, Applied to middleware, the method includes: Receive connection status information from the first node; Distribute the connection status information to one or more second nodes; The connection status information is used by the second node to restore the communication connection with the client after taking over the virtual IP address, so as to provide services to the client.

8. A virtual IP address switching device, characterized in that, Applied to the first node, the device includes: The first acquisition module is used to acquire the connection status information of the communication connection during the process of establishing a communication connection with the client through the virtual IP address and providing services; The synchronization module is used to synchronize the connection status information to the middleware in real time; The connection status information is used by the second node to obtain from the middleware so that, after the virtual IP address is switched to the second node, the second node provides services to the client based on the connection status information.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 7.

Images