Node processing method of server cluster and electronic device

Abstract

The application discloses a node processing method of a server cluster and electronic equipment, relates to the technical field of automatic operation and maintenance, and a first node is taken as a fault source, a fault type is first judged, and information containing a node identifier and a fault cause is transmitted based on the fault type, so that the delay of passive waiting detection is avoided; a third node relies on the hardware-level communication advantage of a same chassis backboard, quickly transfers a fault signal when the first node cannot directly communicate, and avoids a fault information gap caused by the fact that the first node cannot actively send; a second node receives and processes fault messages from the first node or the third node, accurately locates a fault node and executes a disconnection operation, and slow response depending on heartbeat timeout is avoided. From active fault reporting to quick execution of disconnection, the whole process is compressed in time consumption, the processing efficiency of a fault node in the server cluster is significantly improved, and fault response delay is effectively reduced.

Description

Technical Field

[0001] This application relates to the field of automated operation and maintenance technology, and in particular to a node processing method and electronic device for a server cluster. Background Technology

[0002] With the development of the Internet industry, in order to ensure the stable operation of server clusters, it is necessary to deal with faulty nodes in the server clusters in a timely manner.

[0003] In related technologies, other nodes in a server cluster passively detect the faulty node's faulty state through a heartbeat mechanism. However, the heartbeat mechanism has a large latency, making it difficult to quickly detect faulty nodes. Summary of the Invention

[0004] This application provides a node processing method and electronic device for a server cluster, which at least solves the problem of difficulty in quickly detecting faulty nodes in related technologies.

[0005] This application provides a node processing method for a server cluster, applied to the first node, the method comprising:

[0006] When the first node fails, the failure type is determined. The failure type is used to indicate whether the first node can send messages to the second node of the server cluster.

[0007] When the fault type indicates that the first node can send a message to the second node, a first fault message is sent to at least one second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node has lost connection with the first node in the server cluster.

[0008] When the fault type indicates that the first node is unable to send a message to the second node, a first signal is sent to at least one third node. The third node and the first node are in the same chassis of the server cluster. The first signal is used to indicate that the first node has failed.

[0009] This application provides a node processing method for a server cluster, applied to a third node, the method comprising:

[0010] Receive the first signal, which indicates that the first node has failed. The third node and the first node are in the same chassis of the server cluster.

[0011] Based on the first signal, a second fault message is determined. The second fault message includes the cause of the first node's failure and the identifier of the first node. The second fault message is used to indicate that the second node in the server cluster has lost connection with the first node in the server cluster.

[0012] Send a second fault message to the second node.

[0013] This application provides a node processing method for a server cluster, applied to a second node, the method comprising:

[0014] Receive a first fault message sent by the first node or a second fault message sent by the third node. The first node and the third node are in the same chassis of the server cluster. The first fault message or the second fault message includes the identifier of the first node and the reason for the failure of the first node.

[0015] Based on the first fault message or the second fault message, the connection with the first node in the server cluster is lost.

[0016] This application also provides a node processing device for a server cluster, applied to a first node, the device comprising:

[0017] The confirmation module is used to determine the fault type when the first node fails. The fault type is used to indicate whether the first node can send messages to the second node of the server cluster.

[0018] The sending module is used to send a first fault message to at least one second node when the fault type indicates that the first node can send a message to the second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node has lost connection with the first node in the server cluster.

[0019] The sending module is also used to send a first signal to at least one third node when the fault type indicates that the first node is unable to send a message to the second node. The third node and the first node are in the same chassis of the server cluster. The first signal is used to indicate that the first node has failed.

[0020] This application provides a node processing device for a server cluster, applied to a third node, the device comprising:

[0021] The receiving module is used to receive the first signal, which indicates that the first node has failed. The third node and the first node are in the same chassis of the server cluster.

[0022] The determination module is used to determine a second fault message based on a first signal. The second fault message includes the cause of the first node's failure and the identifier of the first node. The second fault message is used to indicate that the second node in the server cluster has lost connection with the first node in the server cluster.

[0023] The sending module is used to send a second fault message to the second node.

[0024] This application provides a node processing device for a server cluster, applied to a second node, the device comprising:

[0025] The receiving module is used to receive a first fault message sent by the first node or a second fault message sent by the third node. The first node and the third node are in the same chassis of the server cluster. The first fault message or the second fault message includes the identifier of the first node and the reason for the failure of the first node.

[0026] The processing module is used to disconnect from the first node in the server cluster based on the first fault message or the second fault message.

[0027] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described server cluster node processing methods.

[0028] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described server cluster node processing methods.

[0029] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server cluster node processing methods.

[0030] The node processing method and electronic equipment for the server cluster provided in this application involve a first node acting as the fault source. The first node determines the fault type and transmits information including the node identifier and fault cause based on the fault type, avoiding delays caused by passively waiting for detection. A third node, leveraging the hardware-level communication advantage of the same chassis backplane, quickly relays fault signals when the first node cannot communicate directly, preventing information gaps caused by the first node's inability to actively send signals. A second node receives and processes fault messages from either the first or third node, accurately locates the faulty node, and performs a disconnection operation, avoiding slow responses dependent on heartbeat timeouts. This end-to-end process, from proactive fault reporting to rapid disconnection, significantly reduces time consumption, improves the processing efficiency of faulty nodes in the server cluster, and effectively reduces fault response latency. Attached Figure Description

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

[0032] Figure 1 Interaction diagram of the node processing method of the server cluster provided in the embodiments of this application Figure 1 ;

[0033] Figure 2Interaction diagram of the node processing method of the server cluster provided in the embodiments of this application Figure 2 ;

[0034] Figure 3 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 1 ;

[0035] Figure 4 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 2 ;

[0036] Figure 5 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 3 ;

[0037] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, other embodiments obtained by those of ordinary skill in the art without creative effort are all within the protection scope of this application.

[0039] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0040] To minimize the impact of a single node failure on customer services, other nodes in the cluster must detect the failure as quickly as possible, initiate cluster reorganization, and take over the services of the failed node. Normally, other nodes in the cluster would disconnect all links from the failed node to remove it from the cluster. However, link disconnection has a delay, as one side of the link needs to determine from a heartbeat mechanism that the other side is unresponsive before initiating the disconnection, resulting in a delay of up to seconds.

[0041] To address the technical issue of the large latency in the heartbeat mechanism, which makes it difficult to quickly detect faulty nodes, the following technical concept is proposed: By enabling faulty nodes to actively notify the connected nodes in the server cluster of fault information, the connected nodes can prioritize logical disconnection at the cluster level, which has a smaller latency compared to physical link disconnection. Furthermore, when the faulty node cannot actively notify, other nodes within the same chassis can notify the connected nodes on behalf of the faulty node.

[0042] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] Figure 1 Interaction diagram of the node processing method of the server cluster provided in the embodiments of this application Figure 1 ,like Figure 1 As shown in the embodiments of this application, the node processing method for a server cluster is applied to any electronic device, and the method includes:

[0044] S101. When the first node fails, it determines the fault type. The fault type is used to indicate whether the first node can send messages to the second node of the server cluster.

[0045] In a server cluster, a node is the smallest independent computing unit that constitutes the cluster. A node is a hardware device or software instance with independent computing, storage, and networking capabilities. Fault types can include software faults and hardware faults. Software faults refer to node malfunctions caused by abnormalities in the operating system, cluster management software, configuration files, or dependent components. Hardware faults refer to damage or abnormalities in the physical components of a node. For example, a faulty communication module in a node may prevent it from actively sending messages.

[0046] Specifically, the first node detects whether a fault has occurred by monitoring the hardware status through a preset hardware management interface, detecting the software process and service status through a preset agent program, and verifying system resources and configurations. When a fault occurs in the first node, it identifies whether the fault allows the first node to send a message to the second node of the server cluster and determines the fault type.

[0047] S102. When the fault type indicates that the first node can send a message to the second node, the first node sends a first fault message to at least one second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node loses connection with the first node in the server cluster.

[0048] The second node indicates the node in the server cluster that communicates with the first node. The identifier of the first node can be the World Wide Node Name (WWNN). WWNN is a 64-bit identifier used in Fibre Channel storage networks to uniquely identify nodes (such as storage devices, servers, etc.) and to achieve unique identification and communication addressing of nodes in Fibre Channel networks, ensuring that different nodes can accurately establish connections and transmit data.

[0049] Specifically, the first node invokes the model responsible for inter-node communication in the server cluster. When the fault type indicates that the first node can send a message to the second node, it sends a first fault message to at least one second node. The module responsible for inter-node communication registers an exit function during initialization. The exit function sends the first fault information of the first node to the target node, which is the second node. The message structure varies depending on the communication protocol.

[0050] For example, the causes of the first node failure may be "an unrecoverable error occurred in the node's core computing component, making it unable to process tasks assigned by the cluster", "physical damage to the node's storage module, causing complete failure of data read and write functions", "hardware failure of the node's network interface, making it unable to establish communication connections with other nodes in the cluster", and "abnormality of the node's power system, relying only on backup power and unable to maintain normal operation".

[0051] S103. When the fault type indicates that the first node cannot send a message to the second node, the first node sends a first signal to at least one third node. The third node and the first node are in the same chassis of the server cluster. The first signal is used to indicate that the first node has failed.

[0052] The third node and the first node are located in the same chassis of the server cluster, and the first node and the third node are connected through the chassis backplane.

[0053] Specifically, the hardware detection circuit in the first node is connected to the chassis backplane or the programmable controller on the node. When the fault type indicates that the first node cannot send a message to the second node, the hardware detection circuit sends a first signal to the programmable controller, and the programmable controller sends the first signal to at least one third node in the chassis through the chassis backplane.

[0054] S104. The third node determines the second fault message based on the first signal. The second fault message includes the cause of the first node's failure and the identifier of the first node. The second fault message is used to indicate that the second node in the server cluster has lost connection with the first node in the server cluster.

[0055] Specifically, the third node receives a first signal based on the chassis backplane. This first signal indicates a failure in the first node, and both the third and first nodes reside in the same chassis within the server cluster. Based on the first signal, an interrupt handler is triggered, and a second fault message is determined according to the bits in the interrupt handler.

[0056] S105, the third node sends a second fault message to the second node.

[0057] Specifically, the third node calls the corresponding communication module and the corresponding function interface to send a second fault message to the second node.

[0058] S106. The second node disconnects from the first node in the server cluster based on the first fault message or the second fault message.

[0059] Among them, disconnection is used to instruct the second node to terminate communication and cooperation with the faulty node at the server cluster logical level.

[0060] Specifically, the second node receives a first fault message sent by the first node, or a second fault message sent by the third node. The first and third nodes reside in the same chassis within the server cluster. The first or second fault message includes the identifier of the first node and the reason for its failure. The second node invokes a high-priority thread to disconnect from the first node within the server cluster at the network layer, cluster layer, or resource layer, based on the first or second fault message.

[0061] The node processing method for a server cluster provided in this application embodiment involves a first node acting as the fault source. This node first determines the fault type and transmits information including the node identifier and fault cause based on the fault type, avoiding delays caused by passively waiting for detection. A third node, leveraging the hardware-level communication advantage of the same chassis backplane, quickly relays fault signals when the first node cannot communicate directly, preventing information gaps caused by the first node's inability to actively send signals. A second node receives and processes fault messages from either the first or third node, accurately locates the faulty node, and performs a disconnection operation, avoiding slow responses dependent on heartbeat timeouts. This comprehensive process, from proactive fault reporting to rapid disconnection, significantly reduces time consumption, improves the processing efficiency of faulty nodes in the server cluster, and effectively reduces fault response latency.

[0062] Figure 2 Interaction diagram of the node processing method of the server cluster provided in the embodiments of this application Figure 2 ,like Figure 2 As shown in the embodiments of this application, the node processing method for a server cluster is applied to any electronic device, and the method includes:

[0063] S201. When the first node fails, it determines the fault type. The fault type is used to indicate whether the first node can send messages to the second node of the server cluster.

[0064] In one possible implementation, when the first node is initialized, a first policy is obtained, which is used to indicate the steps to be performed when the first node exits the server cluster; based on the first policy, the function of the first interface is updated, which is the interface used by the first node when it exits the server cluster.

[0065] The first interface is a preset interface called by any node in the server cluster when it leaves the server cluster. Its main functions include saving data, recording operation logs, and disconnecting from the other nodes in the server cluster.

[0066] Specifically, the first policy is obtained from the preset configuration information of the server cluster, and the function of the preset first interface is updated based on the first policy, so that the updated first interface can correctly perform the exit operation according to the requirements of the first policy.

[0067] In one possible implementation, the first strategy includes at least one of the following: sending a first fault message to at least one second node; recording the cause of the first node's fault; terminating the current process of the first node; and storing the configuration information of the first node.

[0068] If the first strategy includes multiple operations, they will be executed in the order described above.

[0069] For example, the cause of the first node failure can be recorded. If the failure is due to software code, the function name and line number of the failure can be recorded, along with the call stack of the current thread. If the failure is caused by an interrupt or exception, the interrupt number or exception content can be recorded. The configuration information of the first node can be stored, such as writing important metadata to a preset file and storing that preset file.

[0070] S202. When the fault type indicates that the first node can send a message to the second node, the first node sends a first fault message to at least one second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node loses connection with the first node in the server cluster.

[0071] If possible, the target second node is determined according to a preset node priority order. The node priority order is determined based on the second node's load status in the server cluster, communication latency with the first node, and historical collaboration stability. When sending the first fault message to the target second node, the task progress data currently being processed by the first node is carried synchronously. The task progress data includes log records of completed operations, dependencies of incomplete steps, and storage paths of key data. During the sending process, the message transmission status is monitored. If a transmission interruption is detected, a backup communication link is immediately activated to resend the message, and the transmission anomaly information is recorded in the local fault handling log.

[0072] By comprehensively considering the load of the second node, communication latency, and historical collaboration stability, the target node is determined to ensure efficient transmission of fault messages. Simultaneously carrying the task progress data of the first node helps subsequent tasks transition and recover smoothly. During message transmission, the status is monitored, backup links are activated, and anomalies are recorded, which effectively improves the reliability of server cluster fault handling, task continuity, and transmission anti-interference capability, and further enhances the overall fault tolerance and stability of the cluster.

[0073] S203. When the fault type indicates that the first node is unable to send a message to the second node, the first node sends a first signal to at least one third node. The third node and the first node are in the same chassis of the server cluster. The first signal is used to indicate that the first node has failed.

[0074] S204. The third node determines the second fault message based on the first signal. The second fault message includes the cause of the first node's failure and the identifier of the first node. The second fault message is used to indicate that the second node in the server cluster has lost connection with the first node in the server cluster.

[0075] In one possible implementation, in the first signal, a first node corresponding to a sub-signal indicating a fault is obtained, the first signal including multiple sub-signals, each sub-signal being associated with a node in the chassis, the sub-signals being used to indicate whether a fault has occurred in each node; the cause of the first node fault and the identifier of the first node are obtained; based on the cause of the first node fault and the identifier of the first node, a second fault message is determined.

[0076] Specifically, after receiving the first signal, the third node parses the multiple sub-signals contained therein. Each sub-signal corresponds to a node in the chassis. The faulty first node is identified from the sub-signals. The identification information of the first node (such as node identification number, Internet Protocol address, etc.) and the cause of the fault are collected. Based on this information, a second fault message is generated.

[0077] For example, if node 2 experiences a hard drive failure, it sends a first signal to node 3 in the same chassis. The first signal contains four sub-signals: [normal, fault, normal, normal] (corresponding to nodes 1-4 respectively). Node 3 parses the sub-signals, determines that node 2 has failed, obtains the identifier of node 2 (ID: server-2, IP: 192.168.1.2) and the cause of the failure (hard drive read / write error), and generates a second fault message.

[0078] In one possible implementation, a target register for the first node is determined, which stores the cause of the first node's failure; the target register is accessed, and the cause of the first node's failure is retrieved from the target register.

[0079] The target register is used to indicate the hardware or software register in the first node that is specifically used to store fault information.

[0080] Specifically, the third node first determines the target register in the first node used to store the cause of the fault, accesses the target register through the chassis backplane, and reads and obtains the specific cause of the fault in the first node from the target register.

[0081] S205, the third node sends a second fault message to the second node.

[0082] S206. The second node disconnects from the first node in the server cluster based on the first fault message or the second fault message.

[0083] In one possible implementation, the tasks being processed associated with the first node are paused, and the unprocessed tasks associated with the first node are cleared, and the relevant resources are reclaimed; a cluster view reorganization is initiated, the cluster view being used to indicate information about each node in the server cluster; and a message instructing the first node to exit the server cluster is sent to the functional modules of the second node.

[0084] The cluster view is used to indicate the information table that records the status, role, and connection relationships of nodes in the cluster.

[0085] Specifically, the system suspends ongoing tasks related to the first node, clears the queue of unprocessed tasks, reclaims relevant system resources, initiates cluster view reorganization, updates the status information of each node in the cluster, marks the first node as "exited," and sends notifications to its various functional modules to inform them that the first node has exited the cluster, ensuring that all modules work in coordination.

[0086] If possible, continue processing the task queue until completion before disconnecting.

[0087] S207. When the second node loses physical layer connection with the first node, determine whether the connection with the first node has been lost in the server cluster.

[0088] Physical layer disconnection is used to indicate that the physical communication link (such as network cable, optical fiber, etc.) between nodes is interrupted.

[0089] Specifically, the driver module of the second node obtains the physical disconnection signal. Based on the physical disconnection signal, the second node determines that a physical layer disconnection has occurred with the first node and determines whether the connection with the first node has been lost in the server cluster.

[0090] S208. If the second node has lost connection with the first node in the server cluster, then the loss of connection with the first node is confirmed to be complete.

[0091] S209. If the second node is not disconnected from the first node in the server cluster, then it will disconnect from the first node in the server cluster.

[0092] The node processing method for a server cluster provided in this application embodiment involves a first node acting as the fault source. It first determines the fault type and transmits information including the node identifier and fault cause based on the fault type, avoiding delays caused by passively waiting for detection. A third node, leveraging the hardware-level communication advantage of the same chassis backplane, quickly relays fault signals when the first node cannot communicate directly, preventing information gaps caused by the first node's inability to actively send signals. A second node receives and processes fault messages from either the first or third node, accurately locates the faulty node, and performs a disconnection operation, avoiding slow responses dependent on heartbeat timeouts. This streamlined process from proactive fault reporting to rapid disconnection significantly reduces time consumption, improves the processing efficiency of faulty nodes in the server cluster, and effectively reduces fault response latency. Furthermore, nodes can still enter the fault switching process through link disconnection, ensuring the idempotency of the fault switching process. Regardless of whether the fault is triggered by "actively sending a message" or "physical link interruption," a consistent disconnection result is achieved, guaranteeing the stability of the cluster under complex fault scenarios.

[0093] By obtaining the initial policy during node initialization and updating the exit interface accordingly, this mechanism ensures that nodes adhere to a unified standard when exiting the cluster, preventing cluster management chaos caused by inconsistent exit procedures. Furthermore, this mechanism supports flexible customization of exit policies based on actual needs, adapting to the specific requirements of different business scenarios. Since interface configuration is completed during initialization, it reduces system overhead and error risks associated with temporary adjustments during node operation, thereby improving the overall standardization and flexibility of cluster management.

[0094] By clearly defining at least one key operation included in the first strategy, a complete handling system for node failure exit was constructed. Whether it's sending failure messages to other nodes for information synchronization, recording the cause of the failure, terminating the current process, or storing configuration information, operations ensure the stable operation of the cluster from different dimensions. This not only enables rapid isolation and resource cleanup of failed nodes, preventing the spread of failures and ensuring data consistency, but also provides detailed evidence for subsequent fault investigation and problem tracing, significantly improving the comprehensiveness and reliability of cluster fault handling.

[0095] By analyzing the first signal, which contains multiple sub-signals, the system can accurately identify the first faulty node in complex scenarios with multiple nodes within the same chassis, effectively avoiding misjudgments of node failures. Simultaneously, this mechanism requires obtaining the faulty node's identifier and specific cause to generate a second fault message, ensuring the integrity of the fault information. This provides accurate information for other nodes in the cluster to perform targeted disconnection operations, significantly optimizing the efficiency and accuracy of fault propagation within the same chassis and enhancing the cluster's response capability to localized node failures.

[0096] By identifying and accessing the target register of the faulty node, the limitation of node communication interruption was overcome, ensuring the authenticity and accuracy of the fault cause information. This provided valuable raw data for subsequent fault analysis and system optimization, and improved the depth and effectiveness of cluster fault handling.

[0097] By pausing related tasks, clearing unprocessed tasks, and reclaiming resources, faulty nodes can be quickly isolated, preventing further impact on cluster operations. Simultaneously, initiating cluster view reorganization ensures consistent understanding of node status across the entire cluster, avoiding collaboration errors caused by information asymmetry. Sending notifications to various functional modules enables coordinated responses from all parts of the system, enhancing the cluster's fault tolerance and stability from multiple perspectives.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0099] Figure 3 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 1 .like Figure 3 As shown, embodiments of this application also provide a node processing device 30 for a server cluster, including: a confirmation module 301 and a sending module 302.

[0100] The confirmation module 301 is used to determine the fault type when the first node fails. The fault type is used to indicate whether the first node can send messages to the second node of the server cluster.

[0101] The sending module 302 is used to send a first fault message to at least one second node when the fault type indicates that the first node can send a message to the second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node has lost connection with the first node in the server cluster.

[0102] The sending module 302 is also configured to send a first signal to at least one third node when the fault type indicates that the first node is unable to send a message to the second node. The third node and the first node are in the same chassis of the server cluster. The first signal is used to indicate that the first node has failed.

[0103] In one possible implementation, the confirmation module 301 is further configured to:

[0104] Obtain the first policy, which indicates the steps to be taken when the first node exits the server cluster;

[0105] Based on the first strategy, the functionality of the first interface is updated. The first interface is the interface used by the first node when it exits the server cluster.

[0106] In one possible implementation, the first strategy includes at least one of the following:

[0107] Send a first fault message to at least one second node;

[0108] Record the cause of the first node failure;

[0109] Terminate the current process of the first node;

[0110] Store the configuration information of the first node.

[0111] For a description of the features of the node processing device in the embodiment of the server cluster, please refer to the relevant description of the node processing method in the embodiment of the server cluster, which will not be repeated here.

[0112] Figure 4 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 2 .like Figure 4 As shown, embodiments of this application also provide a node processing device 40 for a server cluster, including: a receiving module 401, a determining module 402, and a sending module 403.

[0113] The receiving module 401 is used to receive a first signal, which indicates that the first node has failed. The third node and the first node are in the same chassis of the server cluster.

[0114] The determination module 402 is used to determine a second fault message based on the first signal. The second fault message includes the cause of the first node failure and the identifier of the first node. The second fault message is used to indicate that the second node in the server cluster has lost connection with the first node in the server cluster.

[0115] The sending module 403 is used to send a second fault message to the second node.

[0116] In one possible implementation, the determining module 402 is specifically used for:

[0117] In the first signal, the first node corresponding to the sub-signal indicating the fault is obtained. The first signal includes multiple sub-signals, which are associated with each node in the chassis. The sub-signals are used to indicate whether each node has failed.

[0118] Obtain the cause of the first node failure and the identifier of the first node;

[0119] Based on the cause of the first node failure and the identifier of the first node, the second failure message is determined.

[0120] In one possible implementation, the determining module 402 is specifically used for:

[0121] Determine the target register of the first node, which already stores the cause of the first node's failure.

[0122] Access the target register and retrieve the cause of the first node failure from the target register.

[0123] For a description of the features of the node processing device in the embodiment of the server cluster, please refer to the relevant description of the node processing method in the embodiment of the server cluster, which will not be repeated here.

[0124] Figure 5 Schematic diagram of the node processing device of the server cluster provided in the embodiments of this application Figure 3 .like Figure 5 As shown, embodiments of this application also provide a node processing device 50 for a server cluster, including a receiving module 501 and a processing module 502.

[0125] The receiving module 501 is used to receive a first fault message sent by the first node or a second fault message sent by the third node. The first node and the third node are in the same chassis of the server cluster. The first fault message or the second fault message includes the identifier of the first node and the reason for the fault of the first node.

[0126] The processing module 502 is used to disconnect from the first node in the server cluster based on the first fault message or the second fault message.

[0127] In one possible implementation, the processing module 502 is specifically used for:

[0128] Pause the tasks being processed associated with the first node, clear the unprocessed tasks associated with the first node, and reclaim the related resources;

[0129] Initiate cluster view reorganization. The cluster view is used to indicate information about each node in the server cluster.

[0130] Send a message to the functional module of the second node to instruct the first node to exit the server cluster.

[0131] In one possible implementation, the processing module 502 is further configured to:

[0132] When a physical layer disconnection occurs with the first node, determine whether the connection with the first node has been lost in the server cluster.

[0133] If the connection with the first node in the server cluster has been lost, then the disconnection with the first node is considered complete.

[0134] If the connection with the first node is not broken in the server cluster, then the connection with the first node is broken in the server cluster.

[0135] For a description of the features of the node processing device in the embodiment of the server cluster, please refer to the relevant description of the node processing method in the embodiment of the server cluster, which will not be repeated here.

[0136] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus.

[0137] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to execute any of the above-mentioned server cluster node processing method embodiments.

[0138] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0139] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0140] The memory may include high-speed memory (Random Access Memory, RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0141] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0142] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the node processing method for a server cluster.

[0143] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0144] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described server cluster node processing method embodiments.

[0145] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the node processing method for a server cluster.

[0146] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The node processing method and electronic device for a server cluster provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for processing nodes in a server cluster, characterized in that, Applied to the first node, the method includes: When the first node fails, the failure type is determined, and the failure type is used to indicate whether the first node can send messages to the second node of the server cluster. When the fault type indicates that the first node can send a message to the second node, a first fault message is sent to at least one second node. The first fault message includes the identifier of the first node and the reason for the fault. The first fault message is used to indicate that the second node is disconnected from the first node in the server cluster. When the fault type indicates that the first node cannot send a message to the second node, a first signal is sent to at least one third node through the chassis backplane, so that the third node determines a second fault message based on the first signal and sends the second fault message to at least one second node; the third node and the first node are in the same chassis of the server cluster, the first signal is used to indicate that the first node has failed; the second fault message is used to indicate that the second node has lost connection with the first node in the server cluster. The second node disconnecting from the first node in the server cluster includes: pausing the tasks being processed associated with the first node, clearing the unprocessed tasks associated with the first node, and reclaiming related resources; initiating a cluster view reorganization, wherein the cluster view is used to indicate information about each node in the server cluster; and sending a message to the functional module of the second node to instruct the first node to exit the server cluster.

2. The method according to claim 1, characterized in that, During the initialization of the first node, the method further includes: Obtain a first strategy, which indicates the steps to be performed when the first node exits the server cluster; Based on the first strategy, the function of the first interface is updated. The first interface is the interface used by the first node when the server cluster exits.

3. The method according to claim 2, characterized in that, The first strategy includes at least one of the following: Send the first fault message to at least one of the second nodes; Record the cause of the first node failure; Terminate the current process of the first node; Store the configuration information of the first node.

4. A method for processing nodes in a server cluster, characterized in that, Applied to a third node, the method includes: The first signal is received via the chassis backplane. The first signal is used to indicate that the first node has failed. The third node and the first node are in the same chassis of the server cluster. The first signal is sent by the first node to the third node when the fault type indicates that the first node cannot send a message to the second node. Based on the first signal, a second fault message is determined. The second fault message includes the cause of the first node failure and the identifier of the first node. The second fault message is used to indicate that the second node of the server cluster is disconnected from the first node in the server cluster. Sending the second fault message to the second node to cause the second node to disconnect from the first node in the server cluster; wherein, the disconnection of the second node from the first node in the server cluster includes: pausing the tasks being processed associated with the first node, clearing the unprocessed tasks associated with the first node, and reclaiming the relevant resources; initiating a cluster view reorganization, wherein the cluster view is used to indicate the information of each node in the server cluster; and sending a message to the functional module of the second node to instruct the first node to exit the server cluster.

5. The method according to claim 4, characterized in that, Based on the first signal, a second fault message is determined, including: In the first signal, the first node corresponding to the sub-signal indicating the fault is obtained. The first signal includes multiple sub-signals, which are associated with each node in the chassis. The sub-signals are used to indicate whether each node has failed. Obtain the cause of the first node failure and the identifier of the first node; The second fault message is determined based on the cause of the first node's failure and the identifier of the first node.

6. The method according to claim 5, characterized in that, The reasons for the failure of the first node include: Determine the target register of the first node, which already stores the cause of the first node's failure; The target register is accessed, and the cause of the first node failure is obtained from the target register.

7. A method for processing nodes in a server cluster, characterized in that, Applied to the second node, the method includes: The system receives a first fault message sent by a first node or a second fault message sent by a third node. The first fault message is sent by the first node to the second node when it determines a fault type indicating that it can send a message to the second node. The second fault message is determined by the third node based on a first signal sent by the first node to the third node via the chassis backplane when it determines a fault type indicating that it cannot send a message to the second node. The first node and the third node are located in the same chassis of the server cluster. The first fault message or the second fault message includes the identifier of the first node and the reason for the first node's fault. Based on the first fault message or the second fault message, the connection with the first node in the server cluster is lost; The disconnection from the first node in the server cluster includes: Pause the tasks being processed associated with the first node, clear the unprocessed tasks associated with the first node, and reclaim the relevant resources; Initiate cluster view reorganization, whereby the cluster view is used to indicate information about each node in the server cluster; Send a message to the functional module of the second node to instruct the first node to exit the server cluster.

8. The method according to claim 7, characterized in that, The method further includes: When a physical layer disconnection occurs with the first node, determine whether the connection with the first node has been lost in the server cluster. If the connection with the first node has been lost in the server cluster, then the disconnection with the first node is determined to be complete. If the connection with the first node is not broken in the server cluster, then the connection with the first node is broken in the server cluster.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the node processing method of the server cluster as claimed in any one of claims 1 to 3, or to implement the node processing method of the server cluster as claimed in any one of claims 4 to 6, or to implement the steps of the node processing method of the server cluster as claimed in claim 7 or 8.

Images