MCU-based server cluster management system

Abstract

The present application belongs to the field of computer technology, and specifically discloses a server cluster management system based on MCU, including: a management node and a server cluster, wherein the server cluster includes multiple member nodes; each member node is a server configured with an MCU, the MCU is connected to one or more modules inside the server, and the MCU is used to monitor the status of the server on this node and execute received instructions; the monitoring node is connected to each member node, and the MCU on the monitoring node is also used to obtain the server status information of each member node for packaging, and the MCU on the monitoring node is also used to receive instructions issued by the management node; the MCU on the main monitoring node is also used to send server status data packets to the management node, and the MCU on the main monitoring node is also used to distribute instructions to the MCUs of the corresponding member nodes. The present application can significantly improve the management efficiency of the server cluster.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and more specifically, relates to an MCU-based server cluster management system. Background Art

[0002] Currently, common server management systems are primarily based on the openBMC system, which manages the status of individual servers through the BMC management network. Large-scale applications typically deploy multiple servers, and the independence of each server leads to complex and inconvenient operations and management. Furthermore, human error during the deployment of software environments across multiple servers can also impact cluster stability. Improving the efficiency of server cluster management is a pressing technical challenge in this field. Summary of the Invention

[0003] In response to the shortcomings of the existing technology, the purpose of this application is to improve the efficiency of server cluster management.

[0004] To achieve the above objectives, the present application provides an MCU-based server cluster management system, comprising: a management node and a server cluster, wherein the server cluster comprises a plurality of member nodes;

[0005] Each member node is a server equipped with an MCU. The MCU communicates with one or more modules inside the server. The MCU is used to monitor the status of the server on the node and execute received instructions.

[0006] At least one of the multiple member nodes serves as a monitoring node. The monitoring node is in communication with each member node. The MCU on the monitoring node is also used to obtain server status information of each member node, package the obtained server status information into a server status data packet, and receive instructions from the management node.

[0007] One monitoring node serves as the master monitoring node. The MCU on the master monitoring node is also used to send server status data packets to the management node. The MCU on the master monitoring node is also used to distribute instructions to the MCUs of the corresponding member nodes.

[0008] The management node is used to receive server status data packets sent by the active monitoring node, and is also used to send instructions to the monitoring node.

[0009] In a possible implementation, there are two monitoring nodes, one monitoring node serves as a primary monitoring node, and the other monitoring node serves as a backup monitoring node;

[0010] The standby monitoring node is used to determine whether the active monitoring node has failed by monitoring the heartbeat signal of the active monitoring node; if it is determined that the active monitoring node has failed, the node is converted to the active monitoring node.

[0011] In a possible implementation, the management node is further configured to determine whether a monitoring node fails by monitoring the heartbeat signals of the two monitoring nodes; if it is determined that a monitoring node fails, a member node is configured as a new monitoring node.

[0012] In one possible implementation, the monitoring node is used to:

[0013] The acquired server status information is packaged based on a linked list, where a node in the linked list is used to store the server status information of a member node.

[0014] In one possible implementation, the monitoring node is used to:

[0015] When a member node is added to the server cluster, the corresponding node is added to the linked list;

[0016] Or, when a member node is deleted from the server cluster, the corresponding node is deleted from the linked list.

[0017] In one possible implementation, the management node is used to:

[0018] A first instruction is issued to the monitoring node, where the first instruction is used to instruct reporting of server status information of a specified category.

[0019] In one possible implementation, the management node is used to:

[0020] A second instruction is issued to the monitoring node, where the second instruction is used to instruct to perform a firmware upgrade operation on the target member node according to the target firmware, where the target firmware is compatible with the server status of the target member node.

[0021] In one possible implementation, the management node is used to:

[0022] A third instruction is issued to the monitoring node, where the third instruction is used to instruct to perform a script update operation on the target member node according to the target script file, where the target script file is adapted to the server status of the target member node.

[0023] In one possible implementation, the MCU is configured with state-part threads and task-part threads;

[0024] The status part thread is used to transmit data in a short message communication mode and provide the received instructions to the task part thread;

[0025] The task part thread is used to execute corresponding operations according to the instructions provided by the status part thread.

[0026] In a possible implementation, the MCU is also used to send abnormal status information to the monitoring node when the server status is abnormal;

[0027] The management node is further configured to display the abnormal status information through an alarm interface when receiving abnormal status information sent by the active monitoring node.

[0028] In general, the above technical solutions conceived by this application have the following beneficial effects compared with the existing technologies:

[0029] Real-time monitoring and unified management of the cluster are achieved through a management node and member nodes equipped with an MCU (including at least one monitoring node). The active monitoring node is responsible for collecting and reporting status information and distributing commands, while the management node processes and analyzes data and issues commands, jointly ensuring efficient and stable cluster operation. Through this architecture, the server cluster management system achieves refined management and real-time monitoring of the server cluster, significantly improving server cluster management efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is a schematic diagram of the structure of an MCU-based server cluster management system provided in an embodiment of the present application;

[0031] Figure 2 This is a schematic diagram of the communication connection between the MCU provided in the embodiment of the present application and other modules inside the server. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0033] In the specification and claims of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first instruction" and "second instruction" are used to distinguish different instructions, rather than to describe a specific order of instructions.

[0034] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0035] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0036] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application.

[0037] Figure 1 This is a schematic diagram of the structure of the MCU-based server cluster management system provided in the embodiment of the present application. Figure 1 As shown, the system includes: a management node (such as a PC) and a server cluster, the server cluster includes multiple member nodes;

[0038] Each member node is a server equipped with an MCU (Microcontroller Unit). The MCU communicates with one or more modules within the server. The MCU is used to monitor the status of the server on the node and execute received instructions.

[0039] At least one of the multiple member nodes serves as a monitoring node. The monitoring node communicates with each member node. The MCU on the monitoring node is also used to obtain server status information (device configuration information and device operation status information, etc.) of each member node, and packages (organizes) the obtained server status information to obtain a server status data packet. The MCU on the monitoring node is also used to receive instructions issued by the management node.

[0040] One monitoring node serves as the master monitoring node. The MCU on the master monitoring node is also used to send server status data packets to the management node. The MCU on the master monitoring node is also used to distribute instructions to the MCUs of the corresponding member nodes.

[0041] The management node is used to receive server status data packets sent by the active monitoring node, and is also used to send instructions to the monitoring node.

[0042] Specifically, the system mainly consists of two parts: one is the management node, which can be a high-performance personal computer (PC) or other suitable equipment; the other is the server cluster, which is composed of multiple member nodes.

[0043] Each member node is a server equipped with an MCU. These MCUs communicate with one or more key modules within the server, enabling real-time monitoring of server status. The MCU's primary functions include: 1. real-time monitoring of the server's operating status on the node to ensure stable and reliable operation; 2. executing external commands to achieve unified management and control of the server cluster.

[0044] For example, Figure 2 Schematic diagram of the communication connection between the MCU and other modules inside the server provided in the embodiment of the present application, such as Figure 2 As shown in the figure, the MCU communicates with key modules in the server, such as the CPU (Central Processing Unit), CPLD (Complex Programmable Logic Device), and storage module, using a bus (for example, I2C bus communication).

[0045] For example, the MCU can save key information to the FLASH in the form of a configuration table, such as server attributes, IP addresses, and serial codes assigned by the management node. After the network or power supply is restored, member nodes can start and join the cluster network based on the key information in the FLASH, achieving rapid cluster recovery.

[0046] For example, MCU supports system status reporting, such as processor model, memory frequency, memory capacity, graphics card model, system log, etc.; MCU supports reporting of entire machine status, such as module presence, module working status, storage hard disk presence, temperature, current, voltage, fan control, etc. of important chips.

[0047] For example, the MCU can access a network by automatically obtaining an IP address. The network is used for communication between member nodes and between member nodes and a management node.

[0048] For example, an optional method for a member node to join a cluster after being powered on is: after being powered on, the member node establishes communication with the management node through broadcasting, and the management node configures the member node to join the cluster and then be managed by the monitoring node.

[0049] Among multiple member nodes, at least one is designated as a monitoring node. The monitoring node's MCU not only monitors its own server status but also communicates with other member nodes in the cluster. The monitoring node's MCU regularly obtains server status information from each member node, organizes and packages this information into server status data packets. Furthermore, the monitoring node's MCU receives commands from the management node.

[0050] Among the monitoring nodes, one is designated as the master monitoring node. The MCU on the master monitoring node also performs the following functions: 1. It sends compiled server status data packets to the management node, enabling it to monitor the operational status of the entire cluster in real time; 2. It receives commands from the management node and distributes them to the MCUs of the corresponding member nodes, enabling unified scheduling and management of the entire cluster.

[0051] The main functions of the management node include: first, receiving server status data packets sent by the main monitoring node, processing and analyzing these data to promptly discover and solve problems; second, issuing instructions to the monitoring node, and realizing unified management and control of the entire server cluster through the monitoring node to ensure efficient and stable operation of the cluster.

[0052] Alternatively, as Figure 1 As shown, a local area network can be provided for the cluster to facilitate communication between member nodes and between member nodes and the management node.

[0053] Therefore, the cluster is monitored and managed in real time and in a unified manner through the management node and member nodes equipped with an MCU (including at least one monitoring node). The active monitoring node is responsible for collecting and reporting status information and distributing instructions, while the management node processes and analyzes data and issues instructions, jointly ensuring the efficient and stable operation of the cluster. Through this architecture, the server cluster management system achieves refined management and real-time monitoring of the server cluster, significantly improving server cluster management efficiency.

[0054] In a possible implementation, there are two monitoring nodes, one monitoring node serves as a primary monitoring node, and the other monitoring node serves as a backup monitoring node;

[0055] The standby monitoring node is used to determine whether the active monitoring node has failed by monitoring the heartbeat signal of the active monitoring node; if it is determined that the active monitoring node has failed, the node is converted to the active monitoring node.

[0056] Specifically, in this server cluster management system, the monitoring node configuration employs a dual-failure mechanism, consisting of a primary monitoring node and a backup monitoring node. The backup monitoring node continuously monitors the primary monitoring node's heartbeat signal to determine its operational status. If the backup monitoring node detects that the primary monitoring node's heartbeat signal disappears or becomes abnormal, it indicates a possible failure of the primary monitoring node. In this case, the backup monitoring node automatically becomes the primary monitoring node, ensuring the continuity and reliability of the server cluster management system and preventing a single point of failure from paralyzing the entire cluster management system.

[0057] In a possible implementation, the management node is further configured to determine whether a monitoring node fails by monitoring the heartbeat signals of the two monitoring nodes; if it is determined that a monitoring node fails, a member node is configured as a new monitoring node.

[0058] Specifically, in this server cluster management system, the management node not only receives and processes server status data packets but also has the crucial task of monitoring the operational status of two monitoring nodes (the active and standby nodes). The following details how the management node monitors the heartbeat signals of monitoring nodes to determine if a monitoring node has failed and reconfigures the monitoring node if necessary.

[0059] (1) Heartbeat signal monitoring;

[0060] The management node receives regular heartbeat signals from the active and standby monitoring nodes. These heartbeat signals are periodic messages sent by the monitoring nodes to prove that they are still functioning properly.

[0061] (2) Fault detection;

[0062] If the management node does not receive the heartbeat signal of a monitoring node within a predetermined time, or the received signal indicates that a problem may have occurred with the monitoring node, the management node will consider that the monitoring node may have failed.

[0063] (3) Fault confirmation;

[0064] To avoid misjudgment, the management node may attempt to reconnect to the suspected faulty monitoring node or send a test command to confirm the status of the monitoring node. If it is confirmed that the monitoring node is indeed not working properly, the management node will take action.

[0065] (4) Reconfigure monitoring nodes;

[0066] If the management node confirms that the active monitoring node has failed and the backup monitoring node has become the active monitoring node, the system will be missing a backup monitoring node. Alternatively, if the management node confirms that the backup monitoring node has failed, the system will also be missing a backup monitoring node. In this case, the management node will select a suitable node from the existing member nodes (non-monitoring nodes) and configure it as the new backup monitoring node.

[0067] When selecting a new monitoring node, the management node will consider various factors, such as the node's current load, network location, hardware resources, etc., to ensure that the new monitoring node can effectively undertake monitoring tasks.

[0068] (5) Configuration process;

[0069] The management node will send configuration instructions to the selected member node to configure the node as a backup monitoring node.

[0070] (6) System recovery;

[0071] After the new backup monitoring node is configured, the system will return to the dual monitoring node state and continue to ensure the stable operation and management of the server cluster.

[0072] Therefore, through this mechanism, the server cluster management system can not only respond quickly and restore the monitoring function when a monitoring node fails, but also enable the system to continue to have the ability to self-repair by configuring new monitoring nodes, thereby ensuring continuous monitoring and management of the entire cluster.

[0073] In one possible implementation, the monitoring node is used to:

[0074] The acquired server status information is packaged based on a linked list, where a node in the linked list is used to store the server status information of a member node.

[0075] Specifically, a linked list is a commonly used data structure that consists of a series of nodes, each of which contains a data portion and a pointer to the next node. In the monitoring node, the linked list is used to organize and manage server status information.

[0076] The server status information of each member node is encapsulated in a linked list node. This linked list node typically contains the following information: the member node identifier (such as IP address or unique number); the server's real-time status (such as CPU usage, memory usage, disk space, network traffic, etc.); the server's health status (such as whether there are any failures, error logs, etc.); and a timestamp (recording the time when the information was collected).

[0077] Packaging: After the monitoring node's MCU collects server status information from each member node, it populates the data portion of the corresponding linked list node with this information. Once the status information of all member nodes has been added to the linked list, the monitoring node's MCU packages the entire linked list into a server status data packet. This packet is typically in a structured data format such as JSON, XML, or a custom binary format.

[0078] Using a linked list structure to package server status information has the following advantages: (1) Flexibility: Linked lists allow for the dynamic addition and removal of nodes, adapting to changes in cluster size. (2) High efficiency: Linked lists can effectively utilize memory, occupying only the memory space required for actual data. (3) Ease of management: The linked list structure makes it easier to update and maintain server status information.

[0079] Therefore, in this way, the monitoring node can efficiently collect and organize server status information, and the main monitoring node can provide the management node with real-time cluster operation status, thereby realizing refined management and real-time monitoring of the server cluster.

[0080] In one possible implementation, the monitoring node is used to:

[0081] When a member node is added to the server cluster, the corresponding node is added to the linked list;

[0082] Or, when a member node is deleted from the server cluster, the corresponding node is deleted from the linked list.

[0083] Specifically, the monitoring node in the server cluster management system is responsible for maintaining a linked list of member node status information, ensuring that the linked list always reflects the current cluster configuration. The following details how the monitoring node updates the linked list when a member node is added or removed from the server cluster.

[0084] When adding a member node. (1) Detecting a new node: When a new member node is added to the server cluster, the monitoring node will detect this change through some mechanism (such as network discovery protocol, configuration update notification, etc.). (2) Creating a new linked list node: The monitoring node will create a new linked list node for the newly added member node. This node will contain the identifier and initial state information of the new member node. (3) Inserting into the linked list: The monitoring node inserts the newly created linked list node into the linked list. The insertion position can be determined according to a specific sorting rule, such as the order of node identifiers or the time when the node was added. (4) Updating the linked list: After inserting the new node, the monitoring node will update the structure of the linked list to ensure the integrity and correctness of the linked list. This may include updating the pointer to the new node and / or the end pointer of the linked list.

[0085] When a member node is deleted. (1) Detecting node removal: When a member node in the server cluster is removed, the monitoring node will also receive notification of this change through some mechanism. (2) Locating the linked list node: The monitoring node will search the linked list for the linked list node corresponding to the deleted member node. This is usually done through the node identifier. (3) Deleting the linked list node: Once the corresponding linked list node is found, the monitoring node will delete the node from the linked list. This involves updating the pointer of the previous node to point to the next node after the deleted node, or updating the end pointer of the linked list if the last node is deleted. (4) Releasing resources: After deleting the linked list node, the monitoring node will release the resources associated with the node to avoid memory leaks. (5) Updating the linked list status: The monitoring node will update the status of the linked list to ensure that the linked list reflects the actual configuration of the current cluster.

[0086] In one possible implementation, the management node is used to:

[0087] A first instruction is issued to the monitoring node, where the first instruction is used to instruct the reporting of server status information of a specified category (processor information, driver information, system log, etc.).

[0088] Specifically, the process of issuing instructions from the management node. (1) Instruction formulation: The management node formulates specific instructions based on the current monitoring needs or system maintenance plan. These instructions can be periodic routine inspections or investigations into specific events or problems. (2) Instruction content: The first instruction, namely "report server status information of specified categories", will clearly indicate the categories of server status information that the monitoring node needs to collect and report. These categories may include processor information, driver information, system logs, etc. (3) Instruction issuance: The management node issues the first instruction to the active monitoring node.

[0089] Accordingly, after receiving the first instruction from the management node, the main monitoring node will parse the instruction content and prepare to execute it; then, according to the instruction requirements, it will collect server status information of the specified category from the MCU of each member node; then, it will organize and package the collected information into a structured data packet and send it to the management node for analysis and processing.

[0090] It is understandable that the management node issues the above-mentioned first instruction, which can proactively obtain the latest server status information of the specified category, and assist the administrator in timely understanding the real-time status of the cluster, thereby quickly identifying and resolving potential problems. The benefit of doing so is that it improves the initiative and foresight of system monitoring.

[0091] In one possible implementation, the management node is used to:

[0092] A second instruction is issued to the monitoring node, where the second instruction is used to instruct to perform a firmware upgrade operation on the target member node according to the target firmware, where the target firmware is compatible with the server status of the target member node.

[0093] Specifically, the second instruction is intended to instruct the monitoring node to perform a firmware upgrade operation on the specified member node. This operation is usually to fix known vulnerabilities, improve hardware performance, or add new functions.

[0094] The second instruction may include target firmware information and the target member node identifier for which the firmware upgrade is to be performed. The target firmware is adapted to the server status of the target member node to ensure compatibility and security of the upgrade operation.

[0095] After the management node sends the second instruction to the monitoring node, the active monitoring node receives and parses the second instruction to determine the task details of the firmware upgrade; then, the active monitoring node transmits the target firmware to the target member node according to the instruction, and instructs the MCU on the target member node to execute the firmware upgrade process; after the upgrade is completed, the active monitoring node reports the upgrade execution results to the management node.

[0096] Illustratively, the firmware of a BIOS (Basic Input / Output System) module, a CPLD module, and an ARM (Advanced RISC Machines) module may be upgraded.

[0097] Therefore, by issuing the second instruction, the management node can control the member nodes in the cluster and perform firmware upgrades, thereby realizing automated management and maintenance of the cluster firmware, improving operation and maintenance efficiency, and reducing the risk of human operational errors.

[0098] In one possible implementation, the management node is used to:

[0099] A third instruction is issued to the monitoring node, where the third instruction is used to instruct to perform a script update operation on the target member node according to the target script file, where the target script file is adapted to the server status of the target member node.

[0100] Specifically, the third instruction instructs the monitoring node to execute a script update operation on the target member node. This is typically done to automate specific configuration changes or maintenance tasks, such as deploying a software environment in a cluster with one click.

[0101] The third instruction includes the target script file and the target member node identifier where the script needs to be executed. The target script file is customized according to the server status of the target member node to ensure the accuracy and effectiveness of the script execution.

[0102] The management node sends the third instruction to the monitoring node; the active monitoring node then receives and parses the third instruction to understand the specific requirements of the script update; the active monitoring node then sends the target script file to the target member node and instructs the MCU of the target member node to execute the script update operation; after the script update is completed, the active monitoring node collects the script update operation execution results and reports them to the management node.

[0103] Therefore, by issuing the third instruction, the management node can control the member nodes in the cluster and execute script updates, thereby realizing automated management and maintenance of cluster scripts, improving operation and maintenance efficiency, and reducing the risk of human operational errors.

[0104] Optionally, if the firmware upgrade of a member node requires a new script file to adapt to it, the second and third instructions can be issued at the same time. This means that when a member node receives a new firmware update, the relevant script files will be synchronously adjusted to adapt to the changes at the firmware level. For example, if the firmware update introduces new commands or changes the setting method of certain parameters, the script files will be updated accordingly to ensure that these new commands can be correctly called or the new parameter format is used during execution. Vice versa, when script files are updated to introduce new configuration strategies or optimize existing operating processes, they can run smoothly with the new functions and support provided by the firmware. This two-way adaptation mechanism forms a close collaborative relationship between the firmware and the script files, so that the system can maintain its optimal operating state after each update, avoiding potential problems caused by version mismatches, and enhancing the stability and reliability of the system.

[0105] In one possible implementation, the MCU is configured with state-part threads and task-part threads;

[0106] The status part thread is used to transmit data in a short message communication mode and provide the received instructions to the task part thread;

[0107] The task part thread is used to execute corresponding operations according to the instructions provided by the status part thread.

[0108] The main function of the status thread is to transmit data using short message communication. Short message communication is an efficient and concise data exchange method that allows the MCU to send and receive information at the fastest speed while minimizing bandwidth. The status thread monitors key server parameters in real time, such as CPU load, memory usage, and disk I / O status. It sends this status information to the monitoring node via short messages, and receives instructions from the monitoring node. This communication method ensures real-time and reliable data, maintaining stable communication even under poor network conditions.

[0109] After receiving instructions, the state thread passes them to the task thread. The task thread then performs the corresponding operations based on the instructions provided by the state thread. These operations may include, but are not limited to, server restarts, configuration updates, software deployments, and security policy enforcement. The execution process of the task thread is highly optimized to ensure that instructions are executed quickly and accurately to meet the needs of cluster management.

[0110] The workflow of the task thread is as follows. (1) Receiving instructions: The task thread obtains instructions from the status thread. These instructions come from the management node and are transferred through the main monitoring node. (2) Parsing instructions: The task thread parses the instructions and determines the specific operations to be performed. (3) Executing operations: Based on the content of the instructions, the task thread will perform the corresponding operations, such as adjusting server configuration, starting or stopping services, loading or unloading modules, etc. (4) Feedback results: After execution, the task thread will feedback the operation results to the status thread, and the status thread will send the result information back to the monitoring node via a short message so that the management node can understand the status of the instruction execution and the overall status of the cluster.

[0111] Therefore, through the cooperation between the status part thread and the task part thread, it is possible to execute instructions in a timely manner while monitoring real-time data. The close combination of real-time data monitoring and immediate instruction execution can effectively ensure the real-time and reliability of data transmission and instruction execution.

[0112] Optionally, a state machine mechanism and a communication mechanism with response are used for data processing.

[0113] A state machine is an abstract machine that can change to the next state based on the current state and input signals. A state machine consists of the following basic components: (1) State: The state of the system at a given moment. (2) Input: The external or internal event that triggers the state transition. (3) Transition: The change from one state to another. (4) Action: The possible operation performed during the state transition.

[0114] Acknowledged communication refers to a communication mechanism in which the sender, after sending data, requires the receiver to return an acknowledgment signal (ACK) to confirm that the data has been correctly received. If the sender does not receive an acknowledgment within a predetermined time, it will resend the data or take other error handling measures.

[0115] In a possible implementation, the MCU is also used to send abnormal status information to the monitoring node when the server status is abnormal;

[0116] The management node is further configured to display the abnormal status information through an alarm interface when receiving abnormal status information sent by the active monitoring node.

[0117] Specifically, when the MCU detects an anomaly in a critical server module, such as overheating, hardware failure, system crash, or performance degradation, it immediately initiates an emergency response mechanism. The MCU quickly collects specific information about the anomaly, including the error code, the timestamp of the anomaly, the affected module, and the possible cause of the failure, and transmits this anomaly status information to the monitoring node. This process ensures that the monitoring node has real-time information on the health of member nodes, preventing issues from escalating due to information delays.

[0118] Optionally, the MCU can implement device status alarms by using a timer plus a soft interrupt.

[0119] Upon receiving abnormal status information, a monitoring node immediately processes it. If it's the active monitoring node, it further transmits this information to the management node. When the management node receives abnormal status information from the active monitoring node, it displays it graphically or in a table format on the alarm interface. This information may include the server node ID, the abnormality type, a description of the abnormality, recommended resolution steps, and the potential impact.

[0120] Optionally, when an abnormal state occurs, the management node can trigger an alarm interface by interrupting.

[0121] Through the alarm interface, operations and maintenance personnel can quickly take action, such as remotely restarting servers, adjusting load balancing, activating backup servers, or dispatching technicians for on-site repairs. This timely alarm and response mechanism significantly shortens troubleshooting time, reduces potential losses, and ensures the continued stable operation of the server cluster. Furthermore, the management node records all abnormal events and corresponding handling measures, providing data support for subsequent problem analysis and system optimization.

[0122] It can be understood that the server cluster management system provided by this application can realize functions such as synchronization of member node status information to the management node, remote upgrade of the cluster's CPLD / BIOS firmware, health status monitoring of the entire machine / module, and system log acquisition, breaking the traditional point-to-point management, reducing the impact of human error, and significantly improving the management efficiency of the server cluster.

[0123] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

[0124] It is easy for those skilled in the art to understand that the above is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A server cluster management system based on MCU, characterized in that: include: Management nodes and server clusters, where a server cluster includes multiple member nodes; Each member node is a server equipped with an MCU. The MCU communicates with one or more modules inside the server. The MCU is used to monitor the status of the server on the node and execute received instructions. At least one of the multiple member nodes serves as a monitoring node. The monitoring node is in communication with each member node. The MCU on the monitoring node is also used to obtain server status information of each member node, package the obtained server status information into a server status data packet, and receive instructions from the management node. One monitoring node serves as the master monitoring node. The MCU on the master monitoring node is also used to send server status data packets to the management node. The MCU on the master monitoring node is also used to distribute instructions to the MCUs of the corresponding member nodes. The management node is used to receive server status data packets sent by the active monitoring node. The management node is also used to issue instructions to the monitoring node, including: Sending a first instruction to the monitoring node, the first instruction is used to instruct reporting server status information of a specified category; Sending a second instruction to the monitoring node, the second instruction is used to instruct to perform a firmware upgrade operation on the target member node according to the target firmware, and the target firmware is adapted to the server status of the target member node; Sending a third instruction to the monitoring node, the third instruction is used to instruct to perform a script update operation on the target member node according to the target script file, where the target script file is adapted to the server status of the target member node; If the firmware upgrade of the member node requires a new script file to adapt thereto, the second instruction and the third instruction are issued at the same time.

2. The MCU-based server cluster management system according to claim 1, characterized in that: There are two monitoring nodes, one as the primary monitoring node and the other as the backup monitoring node; The backup monitoring node is used to determine whether the active monitoring node has failed by monitoring the heartbeat signal of the active monitoring node; If it is determined that the active monitoring node fails, the current node will be converted to the active monitoring node.

3. The MCU-based server cluster management system according to claim 2, characterized in that: The management node is also used to determine whether a monitoring node has failed by monitoring the heartbeat signals of the two monitoring nodes; if it is determined that a monitoring node has failed, a member node is configured as a new monitoring node.

4. The MCU-based server cluster management system according to claim 1, characterized in that: Monitoring nodes are used to: The acquired server status information is packaged based on a linked list, where a node in the linked list is used to store the server status information of a member node.

5. The MCU-based server cluster management system according to claim 4, characterized in that: Monitoring nodes are used to: When a member node is added to the server cluster, the corresponding node is added to the linked list; Or, when a member node is deleted from the server cluster, the corresponding node is deleted from the linked list.

6. The MCU-based server cluster management system according to claim 1, characterized in that: The MCU is configured with stateful threads and task-specific threads; The status part thread is used to transmit data in a short message communication mode and provide the received instructions to the task part thread; The task part thread is used to execute corresponding operations according to the instructions provided by the status part thread.

7. The MCU-based server cluster management system according to any one of claims 1 to 6, characterized in that: The MCU is also used to send abnormal status information to the monitoring node when the server status is abnormal; The management node is further configured to display the abnormal status information through an alarm interface when receiving abnormal status information sent by the active monitoring node.

Images