Communication method, apparatus, computer device, storage medium and program product

Abstract

The application relates to a communication method, device, computer equipment, storage medium and program product, a plurality of independent IP communication links are configured between CTDB nodes, and service communication and heartbeat communication are separately deployed, when a first IP communication link bearing service is disconnected due to reasons such as network card failure and link interruption, an available link can be quickly selected from a second IP communication link for continuously keeping alive to undertake service flow, the problem of service interruption is avoided, and the availability of overall service of the CTDB cluster is improved.

Description

Technical Field

[0001] This application relates to the field of cluster management technology, and in particular to a communication method, apparatus, computer equipment, storage medium, and program product. Background Technology

[0002] Clustered Trivial Database (CTDB) is a distributed database management system used to build highly available clusters. Nodes that start the CTDB service can form a CTDB cluster by configuring each other's Internet Protocol (IP) addresses. This cluster is typically combined with storage services such as Samba to provide highly available Server Message Block / Common Internet File System (SMB / CIFS) shared storage services.

[0003] In a CTDB cluster, each node synchronizes its cluster status, key metadata, and public resource information through a periodic communication mechanism, thereby ensuring that all nodes reach a consensus and collaboratively present a unified and highly available virtual service to the outside world.

[0004] Currently, the native CTDB software only supports configuring a static IP address for each node for inter-node communication. Once the network card where the IP is located fails or the network link is interrupted, the node will be unable to maintain a connection with other nodes. This node is easily identified as a faulty node and isolated, affecting the overall availability of the CTDB cluster service. Summary of the Invention

[0005] Therefore, it is necessary to provide a communication method, device, computer equipment, storage medium, and program product to address the above-mentioned technical problems and improve the overall availability of CTDB cluster services.

[0006] In a first aspect, this application provides a communication method, including:

[0007] If a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected, a target IP communication link is selected from at least one second IP communication link; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node;

[0008] Business communication is conducted with the second node through the target IP communication link.

[0009] In the above embodiments, multiple independent IP communication links are configured between CTDB nodes, and business communication and heartbeat communication are deployed separately. When the first IP communication link carrying the business is disconnected due to network card failure, link interruption or other reasons, an available link can be quickly selected from the continuously kept-alive second IP communication link to take over the business traffic, avoiding the problem of business interruption and improving the overall service availability of the CTDB cluster.

[0010] In one embodiment, selecting the target IP communication link from at least one second IP communication link includes:

[0011] Identify the target physical network interface card (NIC) corresponding to the first IP communication link;

[0012] Select the target IP communication link from the second IP communication links corresponding to other physical network cards; wherein, the other physical network cards are the network cards in the first node excluding the target physical network card.

[0013] In the above embodiments, when selecting a backup link, the physical network card to which the faulty link belongs is located first, and then the target link is selected from the backup links corresponding to other independent physical network cards. This enables the backup link and the faulty link to be completely isolated at the hardware level, avoiding the problem that the failure of the same physical network card will cause all related links to fail at the same time. This truly realizes physical-level network redundancy and further improves the fault tolerance and reliability of CTDB cluster communication.

[0014] In one embodiment, selecting the target IP communication link from the second IP communication links corresponding to other physical network interface cards includes:

[0015] For each other physical network interface card, determine the first number of nodes that communicate with other nodes through the IP communication link corresponding to the other physical network interface card;

[0016] Use the other physical network cards corresponding to the smallest number of first nodes as backup physical network cards;

[0017] Select the target IP communication link from the second IP communication links corresponding to the backup physical network card.

[0018] In the above embodiments, when selecting a backup physical network interface card (NIC), the number of service nodes carried by each NIC is used as the basis to prioritize switching services to the physical NIC with the lightest current load. This avoids the problem of a sudden increase in service pressure on a single NIC after a fault switch, realizes dynamic load balancing among multiple physical NICs, improves the overall network resource utilization of the nodes, and reduces the risk of increased latency and packet loss caused by single NIC overload, thus ensuring the stability of service communication.

[0019] In one embodiment, before detecting a break in the first IP communication link with the second node in the cluster, the method further includes:

[0020] For each candidate physical network interface card (NIC) in the first node, determine the number of second nodes among the connected nodes that communicate with the first node via the IP communication link corresponding to the candidate NIC; wherein, the connected nodes are the nodes in the cluster that communicate with the first node.

[0021] Select the IP communication link from the candidate physical network interface card corresponding to the smallest number of second nodes as the first IP communication link;

[0022] A business communication connection is established with the second node through the first IP communication link.

[0023] In the above embodiments, when initially establishing a service communication connection, the physical network card with the lightest load is selected to carry the new service based on the current number of service nodes of each physical network card. This achieves load distribution of multiple physical network cards from the connection establishment stage, avoids service traffic being concentrated on a single network card, and ensures that the load of each network card is always relatively balanced. This improves the utilization rate of the overall network bandwidth of the node, reduces the risk of communication bottlenecks caused by overload of a single network card, and further enhances the stability of CTDB cluster communication.

[0024] In one embodiment, the method further includes, prior to detecting a first IP communication link break with other nodes in the cluster:

[0025] Based on the priority of each candidate communication link in the first node, the first IP communication link is selected from each candidate communication link;

[0026] A business communication connection is established with the second node through the first IP communication link.

[0027] In the above embodiments, when establishing the initial service connection, available communication links are selected in descending order of priority. High-quality links with physical network cards, high bandwidth, and low latency are given priority as the main service links, making full use of high-quality network resources to carry service data and ensuring the performance and stability of service communication. At the same time, the hierarchical priority design also forms a gradient backup link system. In case of failure, the backup links can be switched down step by step according to priority, ensuring that the service can maintain the best possible communication quality in different network environments.

[0028] In one embodiment, the method further includes:

[0029] If a change in IP address is detected in the configuration file corresponding to the IP communication link of the first node, the changed IP address is applied.

[0030] In the above embodiments, changes to the IP configuration file can be detected in real time, and the addition, deletion, and modification of IP addresses can be made effective without restarting the CTDB service thread. This solves the problem that the native CTDB must restart the service to update the IP configuration. In scenarios such as IP migration, network adjustment, and floating IP switching, network configuration updates can be completed without interrupting business, improving the operational flexibility and service continuity of the CTDB cluster and reducing the business impact of operation and maintenance.

[0031] In one embodiment, the process of applying the changed IP address includes:

[0032] In response to an update to the configuration file, an address update signal is triggered;

[0033] Based on the address update signal, the configuration file is reloaded.

[0034] In the above embodiments, configuration reload is initiated by asynchronous triggering of internal signals, and hot loading is performed through a process of locking protection, snapshot comparison, and orderly change. This ensures the decoupling of configuration change detection and business processing, and avoids the risks of data race and business interruption during the reload process. It can safely and efficiently complete IP configuration updates without affecting the operation of existing businesses, further improving the reliability and stability of dynamic IP management.

[0035] Secondly, this application also provides a communication device, comprising:

[0036] The selection module is configured to select a target IP communication link from at least one second IP communication link when a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node;

[0037] The communication module is used to conduct business communication with the second node through the target IP communication link.

[0038] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0039] If a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected, a target IP communication link is selected from at least one second IP communication link; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node;

[0040] Business communication is conducted with the second node through the target IP communication link.

[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0042] If a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected, a target IP communication link is selected from at least one second IP communication link; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node;

[0043] Business communication is conducted with the second node through the target IP communication link.

[0044] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0045] If a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected, a target IP communication link is selected from at least one second IP communication link; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node;

[0046] Business communication is conducted with the second node through the target IP communication link.

[0047] The aforementioned communication methods, devices, computer equipment, storage media, and program products configure multiple independent IP communication links between CTDB nodes and deploy business communication and heartbeat communication separately. When the first IP communication link carrying the business is disconnected due to network card failure, link interruption, or other reasons, an available link can be quickly selected from the continuously active second IP communication link to take over the business traffic, thus avoiding the problem of business interruption and improving the overall availability of the CTDB cluster service. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a flowchart illustrating a communication method in one embodiment;

[0050] Figure 2 This is a schematic diagram of the IP address change process in one embodiment;

[0051] Figure 3 This is a structural block diagram of a communication device in one embodiment;

[0052] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] The communication method provided in this application can be applied to business communication scenarios between nodes in a CTDB cluster. This method can be executed by any node in the cluster, where any node can be a server or a terminal. Terminals can be, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud computing services.

[0055] In one exemplary embodiment, such as Figure 1 As shown, a communication method is provided. Taking the application of this method to the first node in a cluster as an example, the method includes the following steps:

[0056] S101, if the first Internet Protocol (IP) communication link with the second node in the cluster is detected to be disconnected, select the target IP communication link from at least one second IP communication link.

[0057] The first node is any node in the cluster that has the CTDB service process deployed.

[0058] The second node is the peer node in the cluster that communicates with the first node. It also deploys the CTDB service process and together with the first node, they form a pair of communication nodes in the cluster.

[0059] The first IP communication link is used for business communication connection with the second node, that is, the main IP communication link between the first node and the second node that carries business communication connection; the second IP communication link is used for heartbeat connection with the second node; that is, the backup IP communication link that carries heartbeat connection, the number of which is at least one, which is only used for heartbeat detection under normal circumstances and does not carry business data.

[0060] The target IP communication link is a backup link selected from the second IP communication link to take over the services of the disconnected first IP communication link.

[0061] For example, the CTDB service process maintains an independent heartbeat detection mechanism for each IP communication link within the event-driven framework of the first node. For the first IP communication link, the CTDB service process sends a heartbeat packet to the corresponding IP address of the second node according to a preset sending period (e.g., 1 second). The heartbeat packet carries the node identifier (ID), link ID, sequence number, current timestamp, and node health status fields of the first node.

[0062] Simultaneously, the first node starts a timeout timer for this link, with a threshold that can be set to 3 heartbeat cycles (e.g., 3 seconds). Whenever the first node receives a heartbeat reply packet from the second node for this link, it immediately resets the timeout timer. If no heartbeat reply is received from the second node for 3 consecutive cycles, and the link layer detects abnormal events such as Internet Control Message Protocol (ICMP) unreachability or Transmission Control Protocol (TCP) connection reset, the CTDB link state machine switches the state of the first IP communication link from active to disconnected, triggering a link disconnection event.

[0063] After a link disconnection event is triggered, the link management module in the first node iterates through all the second IP communication links associated with the second node in its local storage, verifying the current status of each second IP communication link. Since the second IP communication links always maintain a heartbeat connection, the link management module can directly read the real-time status flags of each link and filter out active backup links.

[0064] Then, the CTDB service process selects one of the available second IP communication links as the target IP communication link based on the built-in selection strategy (such as preset priority, link quality score, etc.).

[0065] The entire detection and screening process is completed within the user-space process of CTDB, without relying on kernel-space patches or third-party tools, thus achieving real-time fault detection.

[0066] S102 communicates with the second node via the target IP communication link.

[0067] For example, after the target IP communication link is selected, the CTDB service process performs a service path switching operation. All service sessions of the CTDB service process are identified by a globally unique session ID. The session itself is not bound to a specific IP communication link; it is only associated with the currently used link channel at the transport layer. During the switching process, it is only necessary to modify the transport channel pointer of the corresponding session from the disconnected first IP communication link to the selected target IP communication link to complete the service path switching. The session's context data, sequence number, and status information remain unchanged, and there is no need to rebuild the session.

[0068] For incomplete data packets in transit during the handover, the CTDB service process performs breakpoint resumption. For example, it records the sequence number of successfully sent and acknowledged data packets, and starts retransmitting subsequent data packets from the next unacknowledged sequence number through the target IP communication link to avoid data duplication or loss. Simultaneously, the first node sends a link handover notification message to the second node through the target IP communication link. This message carries the ID of the original first IP communication link, the ID of the new target IP communication link, and the session ID mapping relationship. Upon receiving the notification, the second node synchronously updates its local service path mapping table to ensure that all subsequent bidirectional communication is conducted through the new link.

[0069] After the switchover is complete, the target IP communication link carries both service communication and heartbeat communication, while the remaining unselected second IP communication links continue to carry only heartbeat connections, maintaining a standby state. The entire switchover process is completely transparent to upper-layer services (such as Samba sharing services), and upper-layer services do not need to be aware of the changes in the underlying links, so there will be no service interruption or request timeout.

[0070] For example, suppose a CTDB cluster contains node A (the first node) and node B (the second node). Node A is configured with two IP addresses: 10.0.1.1 and 10.0.2.1, and node B is configured with two IP addresses: 10.0.1.2 and 10.0.2.2. The link between 10.0.1.1 and 10.0.1.2 is the first IP communication link, which by default carries CTDB's business communication; the link between 10.0.2.1 and 10.0.2.2 is the second IP communication link, which only carries heartbeat connections.

[0071] When the network interface card (NIC) of node A (10.0.1.1) experiences a hardware failure leading to a link interruption, and node A does not receive a heartbeat response from node B within 3 seconds, it determines that the first IP communication link is broken. The CTDB service process of node A finds that the second IP communication link between 10.0.2.1 and 10.0.2.2 is active and selects the second IP communication link between 10.0.2.1 and 10.0.2.2 as the target IP communication link.

[0072] Subsequently, Node A switches all business sessions with Node B to the target IP communication link, continues to transmit cluster status synchronization data and metadata to Node B's 10.0.2.2 via 10.0.2.1, and sends a link switch notification. Upon receiving the notification, Node B updates the path mapping synchronously, and business communication between the two parties resumes normally. The Samba sharing service remains uninterrupted throughout the process, and the clients are unaware of the interruption.

[0073] In the above embodiments, multiple independent IP communication links are configured between CTDB nodes, and business communication and heartbeat communication are deployed separately. When the first IP communication link carrying the business is disconnected due to network card failure, link interruption or other reasons, an available link can be quickly selected from the continuously kept-alive second IP communication link to take over the business traffic, avoiding the problem of business interruption and improving the overall service availability of the CTDB cluster.

[0074] In some alternative implementations, the first IP communication link may be disconnected due to a failure of the physical network card where the first IP communication link is located. Therefore, when determining the second IP communication link, the target physical network card corresponding to the first IP communication link can be determined; and the target IP communication link can be selected from the second IP communication links corresponding to other physical network cards; wherein, other physical network cards are the network cards in the first node excluding the target physical network card.

[0075] The target physical network card is the underlying physical network card bound to the original first IP communication link on the first node.

[0076] A physical network interface card (NIC) is an actual hardware network interface device that exists on a node. It has an independent physical port and a Media Access Control (MAC) address, and has independent network transmission and reception capabilities.

[0077] Other physical network cards are the remaining physical network cards in the first node, excluding the target physical network card. Their hardware links are independent of the target physical network card and will not fail simultaneously due to the failure of the target physical network card.

[0078] For example, during the startup phase, the CTDB service process of the first node enumerates all local network interface devices through the Application Programming Interface (API) provided by the operating system, constructing a three-way mapping table of IP address, network interface, and network card type. In a Linux system environment, the CTDB service thread obtains information such as the name, bound IP address, MAC address, and device type of each network interface by calling the ioctl system command or reading the device attribute file in the / sys / class / net directory. For each network interface, CTDB distinguishes between physical and virtual network cards by determining whether a corresponding physical device node exists (e.g., whether the / sys / class / net / eth0 / device directory exists) and whether it is a logical interface created by a virtual bridge / virtual network card.

[0079] When the first IP communication link is disconnected, the link management module in the first node first extracts the local IP address used by the link from the link attributes, then queries the above three-element mapping table to find the network interface corresponding to the IP address, and then determines the physical network card to which it belongs by the interface type. This physical network card is the target physical network card.

[0080] After locating the target physical network interface card (NIC), the CTDB service thread iterates through all second IP communication links associated with the second node. For each second IP communication link, it also queries the underlying physical NIC it is bound to through a ternary mapping table. If the physical NIC bound to a second IP communication link belongs to another physical NIC, i.e., it is not the same hardware NIC as the target physical NIC, then the second IP communication link is included in the candidate set. If the second IP communication link is bound to the same physical NIC as the faulty first IP communication link, then the second IP communication link is directly excluded, because a physical NIC hardware failure will cause all IP address links on that NIC to fail simultaneously, and selecting a second IP communication link on the same physical NIC cannot achieve true redundancy.

[0081] After the candidate set is filtered, the CTDB service thread selects the final target IP communication link from the candidate set. The selection rules can be priority sorting or random selection.

[0082] This cross-physical network interface card (NIC) filtering mechanism ensures complete hardware-level isolation between backup links and faulty links, achieving true physical-level redundancy and fault tolerance, and preventing the simultaneous failure of all backup links due to a single physical NIC failure. The selection of a second IP communication link can be achieved through a filtering function, which can be configured to enable or disable it; for example, it can be set to automatically enable in scenarios with multiple physical NICs.

[0083] For example, assume that node A has two physical network interfaces, eth0 and eth1, where eth0 is bound to IP address 10.0.1.1 and eth1 is bound to IP address 10.0.2.1; node B also has two physical network interfaces, eth0 and eth1, bound to IP addresses 10.0.1.2 and 10.0.2.2 respectively. The first IP communication link is 10.0.1.1-10.0.1.2, bound to the eth0 network interfaces of both nodes; the two second IP communication links are 10.0.1.1-10.0.2.2 (cross-node same network interface) and 10.0.2.1-10.0.2.2 (cross-node eth1 network interface).

[0084] When a hardware failure occurs on the eth0 physical network interface card (NIC) of node A, the first IP communication link is lost. The CTDB service thread first queries and finds that the target NIC for the first IP communication link is eth0. Then, it filters the second IP communication link: the link 10.0.1.1-10.0.2.2 is also bound to the eth0 NIC of node A, so it is excluded; the link 10.0.2.1-10.0.2.2 is bound to the eth1 NIC of node A, belonging to another physical NIC, and is selected as the target IP communication link. Ultimately, service traffic is switched to the link corresponding to the eth1 NIC, completely avoiding the physical NIC corresponding to the failed eth0, ensuring continuous communication availability.

[0085] In the above embodiments, when selecting a backup link, the physical network card to which the faulty link belongs is located first, and then the target link is selected from the backup links corresponding to other independent physical network cards. This enables the backup link and the faulty link to be completely isolated at the hardware level, avoiding the problem that the failure of the same physical network card will cause all related links to fail at the same time. This truly realizes physical-level network redundancy and further improves the fault tolerance and reliability of CTDB cluster communication.

[0086] In some alternative implementations, during the process of selecting a target IP communication link from the second IP communication links corresponding to other physical network cards, for each other physical network card, the number of first nodes that communicate with other nodes through the IP communication links corresponding to other physical network cards can be determined; and the other physical network card corresponding to the smallest number of first nodes is used as a backup physical network card; and then the target IP communication link is selected from the second IP communication links corresponding to the backup physical network cards.

[0087] The first node count is the total number of nodes that are currently communicating with other nodes through the IP communication link corresponding to each other physical network interface card (NIC), which reflects the service load level of the physical NIC.

[0088] The backup physical network interface card (NIC) is the physical NIC with the fewest service nodes selected from the other physical NICs, i.e. the physical NIC with the lightest current load, and is used to carry the service traffic after the switchover.

[0089] For example, the CTDB service process internally maintains a physical network interface card (NIC) and service node count table. This table uses the NIC name as the key and the number of peer nodes currently carrying service communication through that NIC as the value. Updates to this count table are driven by the event callback mechanism of the link management module. For instance, whenever a service communication connection is established with a new node through a certain physical NIC, the count value corresponding to that NIC is incremented by 1; whenever a service connection is broken or switched to another physical NIC, the count value corresponding to the original NIC is decremented by 1. All counting operations are atomic, and in multi-threaded concurrent scenarios, spinlocks ensure data consistency and prevent counting errors.

[0090] When it is necessary to select backup links, for each other physical network interface card (NIC), the link management module directly reads the number of the first node corresponding to that node from the counter table. This count value directly reflects the current service load level of that physical NIC. For example, a higher count indicates that the NIC is carrying more service connections and the network traffic pressure is greater; a lower count indicates that the NIC is under lighter load and has more remaining bandwidth.

[0091] Because the counter table resides in memory and is updated in real time, read operations do not require additional system calls or traversal calculations, enabling the acquisition of load data for all network cards in a very short time, thus ensuring the efficiency of link selection.

[0092] Furthermore, after obtaining the first node count of all other physical network interface cards (NICs), the CTDB service process sorts the count values ​​of all NICs in ascending order and selects the physical NIC with the smallest count value as the backup physical NIC. If multiple physical NICs have the same count value and all are the minimum, they can be further sorted based on indicators such as bandwidth specifications, historical average latency, and packet loss rate, prioritizing the NIC with higher bandwidth, lower latency, and less packet loss.

[0093] This selection strategy follows the load balancing algorithm based on the minimum number of connections, aiming to direct new service traffic to the physical network interface card (NIC) with the lightest load, thus avoiding bandwidth saturation and increased latency issues caused by a single NIC carrying too many service connections. In scenarios with a large number of cluster nodes and numerous cross-node service connections on individual nodes, this strategy can effectively balance the traffic pressure on each physical NIC, improving the overall network throughput and stability.

[0094] After identifying the backup physical network interface card (NIC), the CTDB service process iterates through all IP addresses bound to that NIC and filters out the second IP communication link corresponding to the second node. If there is only one second IP communication link corresponding to the second node on the NIC, it is directly selected as the target IP communication link; if there are multiple links, the optimal one can be selected based on quality indicators such as round-trip time (RTT) and packet loss rate.

[0095] After selecting a link, the CTDB service process synchronously updates the physical network interface card (NIC) and service node count tables. For example, the count value corresponding to the original target NIC is decremented by 1, indicating that the corresponding service connection has been moved from that NIC; the count value corresponding to the new standby NIC is incremented by 1, indicating that the corresponding service connection has been switched to that NIC; ensuring that the count table always matches the actual load status. If other links subsequently fail over, load balancing selection can continue based on the updated count table, forming a closed-loop dynamic scheduling mechanism.

[0096] For example, node A is configured with three physical network interface cards (NICs): eth0, eth1, and eth2. There are five other nodes in the cluster. Currently, eth0 carries the business communication of three nodes, eth1 carries the business communication of one node, and eth2 carries the business communication of one node. The first IP communication link is bound to eth0 for business communication with node B.

[0097] When a failure of the eth0 network interface card (NIC) causes the first IP communication link to disconnect, the CTDB service process first identifies the target physical NIC as eth0, and the other physical NICs as eth1 and eth2. It then queries the counting table; the first node count for both eth1 and eth2 is 1, indicating they have the same load. Further link quality checks reveal that the RTT (Round-Trip Time) for the link from eth1 to node B is 0.2ms, while the RTT for the link from eth2 to node B is 0.5ms. Therefore, eth1 is selected as the backup physical NIC. Finally, the link corresponding to node B is selected from the second IP communication links corresponding to eth1 as the target IP communication link, and the counting table is updated: the count for eth0 is decremented by 1 (becoming 2), and the count for eth1 is incremented by 1 (becoming 2), completing the load balancing service switchover.

[0098] In the above embodiments, when selecting a backup physical network interface card (NIC), the number of service nodes carried by each NIC is used as the basis to prioritize switching services to the physical NIC with the lightest current load. This avoids the problem of a sudden increase in service pressure on a single NIC after a fault switch, realizes dynamic load balancing among multiple physical NICs, improves the overall network resource utilization of the nodes, and reduces the risk of increased latency and packet loss caused by single NIC overload, thus ensuring the stability of service communication.

[0099] In some alternative implementations, the first IP communication link used for business communication between the first node and the second node can also be selected according to a load balancing strategy.

[0100] For example, for each candidate physical network interface card (NIC) in the first node, the number of second nodes among the connected nodes that communicate with the first node through the IP communication link corresponding to the candidate NIC can be determined; wherein, the connected nodes are the nodes in the cluster that communicate with the first node; the IP communication link in the candidate NIC corresponding to the smallest number of second nodes is selected as the first IP communication link; and a business communication connection is established with the second node through the first IP communication link.

[0101] Among them, the candidate physical network interface card (NIC) is all the available physical NICs on the first node, which is the set of NICs that can be selected to establish a business communication connection.

[0102] The connected nodes are other nodes in the cluster that have successfully established a business communication connection with the first node, and represent the statistical scope for calculating business load.

[0103] The second node count is the number of connected nodes that communicate with the candidate physical network interface card (NIC) for each candidate NIC, reflecting the current service load level of the NIC.

[0104] For example, when the first node needs to establish a business communication connection with a new second node, the CTDB service process first triggers the load statistics process. The physical network interface card (NIC) and business node count table maintained internally by the CTDB service process records in real time the number of business nodes currently carried by each physical NIC.

[0105] For all candidate physical network interfaces, the CTDB service process can directly read the corresponding number of second nodes from the counting table. This value represents the scale of service connections currently carried by the network interface.

[0106] To ensure statistical accuracy, even if the same node establishes multiple logical service connections through the same physical network interface card (NIC), it is only counted as one node. This avoids inflated counts due to multiple connections and ensures that the count accurately reflects the node load distribution of the NIC. Furthermore, the counting table is synchronously updated when any event that could alter the load distribution is triggered, such as a node going offline, a connection being lost, or a link switching, ensuring that the load data read at the time of connection establishment is up-to-date.

[0107] Furthermore, after obtaining the number of second nodes for all candidate physical network interfaces (NICs), the CTDB service process sorts the count values ​​of all NICs in ascending order and selects the physical NIC with the smallest count value as the NIC carrying this service connection. If multiple NICs have the same count value, a secondary selection is performed based on priority parameters such as bandwidth, latency, and reliability level of the NICs, prioritizing the physical NIC with better performance.

[0108] After selecting the bearer network interface card (NIC), the CTDB service process chooses an IP communication link from the IP addresses bound to that physical NIC that corresponds to an IP address reachable by the second node, and uses this link as the first IP communication link. This selection mechanism performs load balancing from the initial stage of service connection establishment, evenly distributing new services across different physical NICs and avoiding the concentration of all services on a single NIC, thus achieving load balancing across multiple NICs from the source. Compared to a passive strategy of adjusting load only when a fault occurs, this proactive connection establishment and balancing method ensures that the load on each NIC remains at a relatively balanced level, resulting in more rational overall network resource utilization.

[0109] After selecting the first IP communication link, the CTDB transport layer module initiates a service connection establishment request to the corresponding IP address of the second node. The request message carries the node ID, link ID, supported protocol version, and service capability information of the first node. Upon receiving the request, the second node verifies the node's identity and the link's legitimacy, returns a connection confirmation message, and the two parties formally establish a service communication connection after completing the handshake.

[0110] After the connection is successfully established, the CTDB service process immediately updates the physical network interface card (NIC) and service node count tables, incrementing the number of the second node corresponding to the NIC by 1 to synchronize the load count. All subsequent service data for this connection is transmitted through this first IP communication link, while the corresponding second IP communication link simultaneously initiates heartbeat detection to maintain a standby state.

[0111] For example, suppose node A is configured with two physical network interfaces, eth0 and eth1, and has already established service connections with three nodes in the cluster, where eth0 carries the services of two nodes and eth1 carries the services of one node. Now, node A needs to establish a service communication connection with node B, which has just joined the cluster.

[0112] The CTDB service process on node A first reads the counting table. The count of the second node on eth0 is 2, and the count of the second node on eth1 is 1. Therefore, eth1 can be selected as the bearer network interface. From the IP addresses bound to eth1, a link reachable from node B is chosen as the first IP communication link. Node A then initiates a connection request to node B through this link. After a successful handshake, service communication is established. Once the connection is established, the count of the second node on eth1 in the counting table is updated to 2, and the service loads of the two network interfaces are 2 and 2 respectively, achieving a balanced state.

[0113] In the above embodiments, when initially establishing a service communication connection, the physical network card with the lightest load is selected to carry the new service based on the current number of service nodes of each physical network card. This achieves load distribution of multiple physical network cards from the connection establishment stage, avoids service traffic being concentrated on a single network card, and ensures that the load of each network card is always relatively balanced. This improves the utilization rate of the overall network bandwidth of the node, reduces the risk of communication bottlenecks caused by overload of a single network card, and further enhances the stability of CTDB cluster communication.

[0114] In some optional implementations, when selecting the IP communication link in the candidate physical network interface card corresponding to the smallest number of second nodes as the first IP communication link, it is also possible to select the IP communication link in the candidate physical network interface card corresponding to the smallest number of second nodes, the number of third nodes that make service communication connections with the connected nodes, and use the IP communication link corresponding to the smallest number of third nodes as the first IP communication link.

[0115] In this way, the IP communication link with the lightest load can be selected to carry new services, which can avoid the concentration of service traffic on a single IP communication link. This ensures that the load of each IP communication link is always relatively balanced, reduces the risk of communication bottlenecks caused by overload of a single IP communication link, and further enhances the stability of CTDB cluster communication.

[0116] In some alternative implementations, when selecting the first IP communication link for business communication between the first node and the second node, the first IP communication link can be selected from the candidate communication links according to their priority in the first node; and a business communication connection can be established with the second node through the first IP communication link.

[0117] Among them, candidate communication links are all available IP communication links on the first node that can be used to establish business communication, including links of different physical network cards and different network segments.

[0118] Priority is the weight level set for each candidate communication link. The higher the priority, the more likely the link will be selected as the main service link. Priority can be set based on dimensions such as network card type, link quality, and network bandwidth.

[0119] For example, the CTDB service process supports configuring priority values ​​for each candidate communication link through configuration files, with higher values ​​indicating higher priority. Simultaneously, the CTDB service process has built-in priority generation rules that can automatically calculate priorities for links that haven't been manually configured. For instance, it can first differentiate between network interface card (NIC) types; links corresponding to physical NICs have a higher priority by default than links corresponding to virtual NICs because physical NICs have independent hardware transceiver units, resulting in higher stability and lower latency. For links with the same physical NIC, they are further sorted based on the NIC's rated bandwidth, with 10 Gigabit NICs having a higher priority than Gigabit NICs. For different IP links with the same NIC, they are sorted based on historically measured average round-trip time and packet loss rate, with links having lower latency and less packet loss having higher priority.

[0120] When a service connection needs to be established with a second node, the CTDB service process first obtains all reachable candidate communication links, reads the priority value of each link, and sorts them from highest to lowest priority. Then, starting with the highest-priority link, it checks link availability sequentially by sending a probe packet and waiting for a response. The first link to receive a normal response is selected as the first IP communication link. If the highest-priority link is unavailable, the next highest-priority link is checked sequentially until an available link is found. This priority-based probing mechanism ensures availability while prioritizing the use of the highest-quality link to carry the service.

[0121] After selecting the first IP communication link, the CTDB service process initiates a service connection establishment request to the second node through this first IP communication link. The connection establishment process can adopt a three-way handshake mechanism. For example, the first node sends a synchronization message carrying information such as node identifier, link identifier, and protocol version; the second node returns a synchronization confirmation message upon receiving it; the first node then sends a final confirmation message after receiving the confirmation, and the connection is established between the two parties.

[0122] Once the connection is established, the first IP communication link serves as the primary link, carrying all business data transmission. The remaining lower-priority candidate links act as secondary IP communication links, carrying only heartbeat connections and maintaining a standby state. The CTDB service process periodically re-evaluates the priority of all links. If the quality of a standby link improves to the point that its priority surpasses that of the current primary link, a seamless primary / standby switchover can be performed at an appropriate time, always keeping the business links in optimal condition. The dynamic priority evaluation cycle is configurable; for example, it can be set to evaluate every 5 minutes to avoid frequent switching affecting business stability.

[0123] In the above embodiments, when establishing the initial service connection, available communication links are selected in descending order of priority. High-quality links with physical network cards, high bandwidth, and low latency are given priority as the main service links, making full use of high-quality network resources to carry service data and ensuring the performance and stability of service communication. At the same time, the hierarchical priority design also forms a gradient backup link system. In case of failure, the backup links can be switched down step by step according to priority, ensuring that the service can maintain the best possible communication quality in different network environments.

[0124] In some alternative implementations, when changing the IP address in the first node, the change can be made effective to avoid interruption of business communication caused by restarting the CTDB service process.

[0125] For example, if a change in the IP address is detected in the configuration file corresponding to the IP communication link of the first node, the change in IP address can be applied.

[0126] The configuration file is a file that stores configuration information such as node IP addresses, cluster node list, and communication parameters on the CTDB node.

[0127] Changing the IP address refers to adding, deleting, or modifying IP address entries in the configuration file, including adding or removing the local communication IP of a node, modifying the IP of a peer node, and other IP-level configuration changes.

[0128] The activation process involves synchronizing the IP changes in the configuration file to the CTDB service process, making the new IP configuration effective, and this process does not require restarting the CTDB service process.

[0129] For example, the CTDB service process internally runs a separate configuration monitoring thread specifically responsible for monitoring changes in the IP configuration file's status. In a Linux system environment, this monitoring thread is implemented based on the inotify file system event mechanism. For instance, when the thread starts, it calls `inotify_init` to create an inotify instance, and then calls `inotify_add_watch` to add the IP configuration file to the monitoring list. The types of events monitored include file content modification (IN_MODIFY), file write completion and closing (IN_CLOSE_WRITE), and file attribute change (IN_ATTRIB). When an administrator modifies and saves the configuration file, the file system triggers the corresponding event, and the inotify mechanism sends the event notification to the monitoring thread.

[0130] Upon receiving an event notification, the monitoring thread first reads the new configuration file content, calculates the Message-Digest Algorithm 5 (MD5) checksum of the file content, and compares it with the checksum of the previously loaded configuration. If the checksums match, it means the file has not undergone substantial changes, and the event is ignored. If the checksums do not match, the new configuration file is further parsed, all IP address entries are extracted, and a differential comparison is performed with the currently effective IP list in memory to identify three types of changes: newly added IP addresses, deleted IP addresses, and modified IP addresses. Once a change is identified, the configuration monitoring thread posts a configuration change event to the event queue of the CTDB service process, triggering the subsequent activation processing. In addition to the inotify event trigger, the monitoring thread can also periodically (e.g., every 30 seconds) perform a timed polling check as a fallback mechanism to ensure that configuration changes are not missed due to event loss.

[0131] Upon receiving a configuration change event, the CTDB service process executes the IP change activation process. For example, for a newly added IP address, it first verifies the IP address's validity and availability, checking if the IP is already bound to the local network interface card and is active. If verification passes, it dynamically creates a listening socket corresponding to the IP address, binds it to the corresponding IP address and port, starts listening and heartbeat detection, adds the IP address to the local node's address list, and sends a node address update notification to all other nodes in the cluster via existing active links, informing them of the newly added communication address. Upon receiving the notification, other nodes update their local node address mapping tables and subsequently establish backup links with this node using the new IP.

[0132] For a deleted IP address, first check if it carries any business communication. If so, smoothly migrate the business connection to another available IP communication link, then close the listening socket corresponding to the IP address, remove the IP address from the local address list, and finally notify other nodes in the cluster to remove the address. If the IP address only carries a heartbeat connection, simply close the socket and notify the peer.

[0133] For modified IP addresses, it is equivalent to first deleting the old IP and then adding the new IP. The two processes described above are executed sequentially, with priority given to adding the new IP address and migrating the business before removing the old IP address, to ensure uninterrupted business operations.

[0134] In the above embodiments, changes to the IP configuration file can be detected in real time, and the addition, deletion, and modification of IP addresses can be made effective without restarting the CTDB service thread. This solves the problem that the native CTDB must restart the service to update the IP configuration. In scenarios such as IP migration, network adjustment, and floating IP switching, network configuration updates can be completed without interrupting business, improving the operational flexibility and service continuity of the CTDB cluster and reducing the business impact of operation and maintenance.

[0135] In some alternative implementations, the change of IP address can be processed in response to an update of the configuration file, triggering an address update signal; and based on the address update signal, the configuration file can be reloaded.

[0136] The address update signal is an internal event signal used by the CTDB service process to perform configuration reload, and can be triggered by the configuration monitoring thread.

[0137] For example, after the configuration monitoring thread detects a substantial update to the configuration file and identifies the changes, it does not directly execute the configuration reload operation. Instead, it sends an address update signal through an in-process signal mechanism, delegating the reload operation to the main process's event loop for unified processing. The CTDB main process runs on an event-driven architecture, and all operations are executed serially in the main event loop, avoiding race conditions caused by multiple threads directly modifying runtime configurations.

[0138] For example, internal signals such as SIG, _ADDR, and _UPDATE can be defined within CTDB, and the monitoring thread can be configured to send these signals to the main process thread by calling the signal sending function. The main process's event loop registers a callback function to handle these signals. When the signal arrives, the event loop, after completing the current task, prioritizes the execution of the configured overload callback.

[0139] This asynchronous signal triggering method completely decouples the configuration monitoring thread from the main business thread. The monitoring thread is only responsible for detection and notification, without participating in business logic, and will not block the main event loop. At the same time, the main process executes reload at appropriate times, avoiding data inconsistency issues caused by configuration modifications during critical business processing. In addition to internal signals, CTDB can also receive externally sent SIGHUP system signals to trigger address updates.

[0140] After receiving the address update signal, the main process calls the configuration reload callback function to execute the complete configuration reload process. First, the callback function locks the write lock on the configuration read-write lock to prevent other threads from reading configuration data during the reload process, ensuring data consistency. Then, the function opens the latest configuration file, parses it line by line according to the CTDB service thread configuration syntax specification, extracts all network-related parameters such as IP addresses, port numbers, heartbeat parameters, and priority configurations, and builds a new configuration snapshot.

[0141] After parsing, the function compares the new configuration snapshot with the currently effective old configuration item by item, generating a set of change differences, including added IP addresses, deleted IP addresses, and modified parameters. Then, it applies the changes sequentially in the order of addition, modification, and deletion. For example, it first adds all newly added IP addresses and their corresponding sockets, then modifies adjustable parameters, and finally removes the IP addresses and sockets that need to be deleted. For changes involving business links, the backup link is adjusted first, and then the business connection is gradually migrated, ensuring that at least one available link carries the business throughout the process.

[0142] After all changes are applied, the function switches the currently effective configuration pointer to the new configuration snapshot, releases the memory of the old configuration, and then releases the configuration read-write lock, completing the entire reload process. During the reload, the sending and receiving of all business data will only be briefly paused, and the upper-layer business will be unaware of it; there will be no connection loss or request timeout. After the reload is completed, a configuration reload log will be generated, recording the changes and execution results for easy operation and maintenance auditing.

[0143] For example, while the CTDB service process on node A is running, the administrator modifies the IP configuration file, changing the original 10.0.1.1 to 10.0.1.3 and saving the file. After detecting the file update, the configuration monitoring thread sends a SIG_ADDR_UPDATE address update signal to the main process.

[0144] After the main process's event loop finishes processing the current cluster state synchronization task, it receives an address update signal and triggers a configuration reload callback. The callback function locks the connection, reads the new configuration file, parses it to obtain the new IP address list, and compares it to find that 10.0.1.1 needs to be deleted and 10.0.1.3 needs to be added.

[0145] First, a listening socket for 10.0.1.3 can be added, notifying the peer node of the new address. Then, the service connections originally carried by 10.0.1.1 can be smoothly migrated to the 10.0.1.3 link. After confirming normal service, the socket for 10.0.1.1 can be closed, and the peer node can be notified to remove the address. Finally, the configuration pointer can be switched and unlocked to complete the configuration reload. The entire process is uninterrupted, and the CTDB service process continues to run without requiring a restart.

[0146] For example, see Figure 2 , Figure 2 A flowchart illustrating the IP address change process is provided, which includes the following steps:

[0147] 1. Steady-state operation phase: The client continuously accesses the CTDB service process of node A; the CTDB service processes of node A and node B are bound to IPs 10.0.2.1 and 10.0.2.2 respectively, and the two nodes maintain continuous heartbeat and cluster communication through IP communication links.

[0148] 2. Trigger IP configuration update: Perform a dynamic configuration update on node A, changing the communication IP address bound to the CTDB service process from 10.0.2.1 to the new IP 10.0.2.3.

[0149] 3. Seamless IP address switching: The CTDB service process of node A can smoothly switch its IP address and bind to the new IP 10.0.2.3 without restarting the process or interrupting the service.

[0150] 4. Results on the business side: The IP address switch does not affect client access at all, client access remains normal, and there is no awareness of the underlying IP address change.

[0151] 5. Results on the cluster side: Heartbeats and cluster communication between nodes remain stable, cluster state synchronization is unaffected, and the overall cluster state is maintained.

[0152] In the above embodiments, configuration reload is initiated by asynchronous triggering of internal signals, and hot loading is performed through a process of locking protection, snapshot comparison, and orderly change. This ensures the decoupling of configuration change detection and business processing, and avoids the risks of data race and business interruption during the reload process. It can safely and efficiently complete IP configuration updates without affecting the operation of existing businesses, further improving the reliability and stability of dynamic IP management.

[0153] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0154] Based on the same inventive concept, this application also provides a service process apparatus for implementing the service process method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more service process apparatus embodiments provided below can be found in the limitations of the service process method described above, and will not be repeated here.

[0155] In one exemplary embodiment, such as Figure 3 As shown, a communication device is provided, configured on the first node in a cluster, comprising:

[0156] Selection module 10 is used to select a target IP communication link from at least one second IP communication link when a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node.

[0157] The communication module 20 is used to conduct business communication with the second node through the target IP communication link.

[0158] In one embodiment, the selection module 10 is specifically used for:

[0159] Determine the target physical network interface card (NIC) corresponding to the first IP communication link; select the target IP communication link from the second IP communication links corresponding to other physical NICs; wherein, other physical NICs are the NICs in the first node excluding the target physical NIC.

[0160] In one embodiment, the selection module 10 is specifically used for:

[0161] For each other physical network interface card (NIC), determine the first number of nodes that communicate with other nodes through the IP communication links corresponding to the other physical NICs; designate the other physical NICs corresponding to the smallest number of first nodes as backup physical NICs; and select the target IP communication link from the second IP communication links corresponding to the backup physical NICs.

[0162] In one embodiment, before detecting that the first IP communication link with the second node in the cluster is broken, the communication module 20 is further configured to:

[0163] For each candidate physical network interface card (NIC) in the first node, determine the number of second nodes among the connected nodes that communicate with the first node via the IP communication link corresponding to the candidate NIC; wherein, the connected nodes are the nodes in the cluster that communicate with the first node; select the IP communication link in the candidate NIC corresponding to the smallest number of second nodes as the first IP communication link; establish a business communication connection with the second node through the first IP communication link.

[0164] In one embodiment, before detecting that the first IP communication link with the second node in the cluster is broken, the communication module 20 is further configured to:

[0165] Based on the priority of each candidate communication link in the first node, the first IP communication link is selected from the candidate communication links; and a business communication connection is established with the second node through the first IP communication link.

[0166] In one embodiment, the device further includes an activation module for:

[0167] If a change in IP address is detected in the configuration file corresponding to the IP communication link of the first node, the change in IP address will be applied.

[0168] In one embodiment, the activation module is specifically used for:

[0169] In response to an update to the configuration file, an address update signal is triggered; based on the address update signal, the configuration file is reloaded.

[0170] Each module in the aforementioned communication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0171] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a communication method.

[0172] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0173] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the communication method described in any of the above embodiments.

[0174] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the communication method described in any of the above embodiments.

[0175] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the communication method described in any of the above embodiments.

[0176] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0177] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0178] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0179] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A communication method, characterized in that, The method is applied to the first node in the cluster, and the method includes: If a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected, a target IP communication link is selected from at least one second IP communication link; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node; Business communication is conducted with the second node through the target IP communication link.

2. The method according to claim 1, characterized in that, The step of selecting a target IP communication link from at least one second IP communication link includes: Identify the target physical network interface card (NIC) corresponding to the first IP communication link; Select the target IP communication link from the second IP communication links corresponding to other physical network cards; wherein, the other physical network cards are the network cards in the first node excluding the target physical network card.

3. The method according to claim 2, characterized in that, The step of selecting the target IP communication link from the second IP communication links corresponding to other physical network cards includes: For each other physical network interface card, determine the first number of nodes that communicate with other nodes through the IP communication link corresponding to the other physical network interface card; Use the other physical network cards corresponding to the smallest number of first nodes as backup physical network cards; Select the target IP communication link from the second IP communication links corresponding to the backup physical network card.

4. The method according to claim 1, characterized in that, Before detecting a break in the first IP communication link with the second node in the cluster, the method further includes: For each candidate physical network interface card (NIC) in the first node, determine the number of second nodes among the connected nodes that communicate with the first node via the IP communication link corresponding to the candidate NIC; wherein, the connected nodes are the nodes in the cluster that communicate with the first node. Select the IP communication link from the candidate physical network interface card with the smallest number of second nodes as the first IP communication link; A business communication connection is established with the second node through the first IP communication link.

5. The method according to claim 1, characterized in that, Before detecting a break in the first IP communication link with other nodes in the cluster, the method further includes: Based on the priority of each candidate communication link in the first node, the first IP communication link is selected from each candidate communication link; A business communication connection is established with the second node through the first IP communication link.

6. The method according to claim 1, characterized in that, The method further includes: If a change in IP address is detected in the configuration file corresponding to the IP communication link of the first node, the changed IP address is applied.

7. The method according to claim 6, characterized in that, The process of applying the changed IP address includes: In response to an update to the configuration file, an address update signal is triggered; Based on the address update signal, the configuration file is reloaded.

8. A communication device, characterized in that, The device is configured on the first node in the cluster, and the device includes: The selection module is configured to select a target IP communication link from at least one second IP communication link when a first Internet Protocol (IP) communication link with a second node in the cluster is detected to be disconnected; wherein the first IP communication link is used for business communication connection with the second node, and the second IP communication link is used for heartbeat connection with the second node; The communication module is used to conduct business communication with the second node through the target IP communication link.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

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

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images