Server state management method and apparatus, electronic device, and readable storage medium

Abstract

The application provides a server state management method and device, electronic equipment and readable storage medium. When a central server in a server cluster is powered on, a warehouse storing topology relationship data corresponding to the central server is created. The topology relationship data includes a component relationship tree corresponding to the central server and a corresponding relationship between components in the central server and corresponding sensors and effectors. Topology relationship data corresponding to each subsystem and topology relationship data corresponding to each subserver in the server cluster are also added to the warehouse. The central server realizes real-time monitoring of each subserver. Each subserver is recognized by the central server as a node in the system topology. Each subserver uses its own BMC to manage all components, forming a small topology. The central server can manage all data under the current system through the topology relationship data, improving the efficiency of server management.

Description

Technical Field

[0001] This invention relates to the field of servers, and more particularly to a server status management method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Currently, most server startup status detection is based on hardware information detection. Sensors or monitoring chips are used to detect the temperature, rotation speed, and other statuses of physical hardware, and the information is transmitted to the BMC (baseboard management controller) and displayed on the BMC interface. The BMC allows users to view the status of each component in the server.

[0003] In related technologies, a Base Management Controller (BMC) can store topology information between various components within a server, allowing control of the state of each component. However, with the increasing demands for server computing and storage performance, a single server is often insufficient. Multiple storage servers are typically configured into a server cluster. For servers within a cluster, the aforementioned control methods for individual servers only apply to that single server and are difficult to extend to the entire cluster. This makes it challenging to achieve state control for each individual server in a server cluster environment. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a server state management method, apparatus, electronic device and readable storage medium that overcomes or at least partially solves the above problems.

[0005] In a first aspect, embodiments of this application disclose a server status management method, applied to a central server in a server cluster, the method comprising:

[0006] In response to the power-on operation of the central server, a repository is created to store the topology relationship data corresponding to the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors.

[0007] In response to the startup operation of the central server, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository;

[0008] Obtain the topology relationship data corresponding to each sub-server in the server cluster, and add the topology relationship data corresponding to each sub-server to the repository;

[0009] By using the component relationship tree in the warehouse, the state of each subsystem or sensor in each subserver included in the central server is obtained, and the state of the component corresponding to the sensor is controlled by the control effector.

[0010] Secondly, embodiments of this application disclose a server status management device, applied to a central server in a server cluster, the device comprising:

[0011] The first addition module is used to create a repository for storing the topology relationship data corresponding to the central server in response to the power-on operation of the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the entities in the central server and their corresponding sensors and effectors.

[0012] The second adding module is used to add the topology relationship data corresponding to each subsystem contained in the central server to the repository in response to the startup operation of the central server;

[0013] The third addition module is used to obtain the topology relationship data corresponding to each sub-server in the server cluster and add the topology relationship data corresponding to each sub-server to the repository;

[0014] The management module is used to obtain the status of each subsystem or sensor in each subserver included in the central server through the component relationship tree in the warehouse, and to control the status of the component corresponding to the sensor through the control effector.

[0015] Thirdly, embodiments of this application also disclose an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0016] Fourthly, embodiments of this application also disclose a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0017] In this embodiment, when the central server in the server cluster powers on, it creates a repository to store the topology relationship data corresponding to the central server. This topology relationship data includes a component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors. In response to the central server's startup operation, the topology relationship data corresponding to each subsystem included in the central server is added to the repository. Simultaneously, the topology relationship data corresponding to each subserver in the server cluster is acquired and added to the repository. At this point, the central server's repository includes the topology relationship data corresponding to each subsystem of the central server and each subserver in the server cluster. The central server can then obtain the status of each subsystem or sensor included in the central server through the component relationship tree and control the status of the components corresponding to the sensors through the control effectors. This application uses one server as the central server. During the startup process, each subserver interacts with the central server, enabling the central server to monitor each subserver in real time. Each subserver acts as a node in the system topology, which is recognized by the central server. Each subserver manages all its components through its own BMC, forming a small topology. In this way, the central server can manage all the data in the current system, improving the efficiency of server management in the server cluster. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the steps of a server status management method provided in an embodiment of the present invention;

[0019] Figure 2 This is an architecture diagram of a server cluster provided in an embodiment of the present invention;

[0020] Figure 3 This is a flowchart of another server status management method provided in an embodiment of the present invention;

[0021] Figure 4 This is a system topology diagram of a server cluster provided in an embodiment of the present invention.

[0022] Figure 5 This is a block diagram of a server status management device provided in an embodiment of the present invention;

[0023] Figure 6 This is a block diagram of a terminal according to another embodiment of the present invention;

[0024] Figure 7 This is a schematic diagram of the terminal structure according to another embodiment of the present invention. Detailed Implementation

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

[0026] refer to Figure 1 This illustrates a server status management method provided in an embodiment of this application, applied to a central server in a server cluster. The method includes:

[0027] Step 101: In response to the power-on operation of the central server, a warehouse is created to store the topology relationship data corresponding to the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors.

[0028] In this embodiment of the invention, in a server cluster application scenario, control of each sub-server in the server cluster can be achieved through a central server in the server cluster. The BMC is located on the central server. When the central server is powered on, it automatically creates its own PDR (Platform Descriptor, used to describe the relationships between various assets) repository. The PDR repository may include the central server's own component relationship PDR, sensor PDR (used to detect components in the central server), effector PDR (used to set the function of corresponding components), and component relationship tree. The component relationship PDR describes the relationships between various physical components in the central server, the sensor PDR describes the relationship between each sensor and a physical component, the effector PDR describes the correspondence between physical components and effectors, and the component relationship tree is a tree structure generated based on the component relationship PDR to describe the relationships between various physical components of the central server.

[0029] Furthermore, organizing the information of each entity component in the central server into a tree structure can represent the hierarchical structure of the central server. The top level of this tree structure represents the entire server, while the branches and leaves represent the individual components within the server. The relationships within the entire central server can form a tree structure, which is recorded using a linked list created by PDR (Programmable Detail Recognition). When a component fails, the user can not only identify which component has failed but also use this tree structure to identify potential functional abnormalities in other components caused by this failure.

[0030] Each server requires numerous physical or virtual sensors to monitor its startup status. The component information acquired by these sensors can be directly transmitted to the BMC (Browser Control Center) for display on the interface. Physical sensors can have their status and readings read directly by software, while virtual sensors are simulated by the PDR (Power Controller Registry), which stores the virtual sensors and their data in memory. After receiving the information, the BMC parses the data, analyzes the server status, and displays the status in real-time on the web (World Wide Web) interface. If a startup anomaly occurs at any stage, it can be displayed to the user through the web interface, allowing the user to debug the server system based on the status information without directly checking the logs.

[0031] When the central server is powered on, in order to improve efficiency, the BMC will create a part of the general PDR. This part of the PDR is shared by the BMC and the firmware. For example, at this time, the status information of the firmware such as fans, power supply or motherboard can be obtained and saved to the PDR.

[0032] Step 102: In response to the startup operation of the central server, add the topology relationship data corresponding to each subsystem contained in the central server to the repository.

[0033] In this embodiment of the invention, in step 101, the central server is powered on and creates some Partial Data Relationships (PDRs). At this time, since the central server has not yet started, some components of the central server cannot be detected. When the central server starts, different components will be detected at different startup stages. As the central server starts at different stages, PDRs can be created to describe the relationships between the various components. That is, when the central server powers on, the firmware and the subsystems on each board generate their own component relationship PDRs, sensor PDRs, effector PDRs, and component relationship trees. Each subsystem only maintains its own component relationship tree. After each subsystem generates its own PDR, it can write the PDR into the LPC bus based on the PLDM (Platform Level Data Model, the communication protocol between BMC and PNOR) protocol.

[0034] The central server can obtain the PDR information corresponding to each subsystem from the LPC bus and add the topology data corresponding to each subsystem to the PDR repository. At this time, the PDR repository of the central server includes the topology data of the central server itself, as well as the topology data of each subsystem of the central server. The subsystems of the central server can include: static devices or hot-swappable devices, etc.

[0035] Step 103: Obtain the topology relationship data corresponding to each sub-server in the server cluster, and add the topology relationship data corresponding to each sub-server to the repository.

[0036] In this embodiment of the invention, each sub-server has its own BMC (Browser Management Center) for collecting PDRs (Product Data Relationships) from the sub-server. During the boot process, each sub-server in the server cluster first acquires all PDRs from the central server, storing them locally one by one. Then, it creates its own PDR data, a process identical to the PDR collection process during the central server's boot. Each sub-server stores its complete PDR and its own component relationship tree. After each sub-server in the server cluster has created its own PDR repository and component relationship tree, it communicates with the central server via the network. The central server acquires the sub-servers' PDRs locally, parses out the component relationship PDRs, and merges the sub-servers' component relationships into its own component relationship tree, thereby enriching its own component relationship tree.

[0037] Step 104: Obtain the status of each subsystem or sensor in each subserver included in the central server through the component relationship tree in the warehouse, and control the status of the component corresponding to the sensor through the control effector.

[0038] In an embodiment of the present invention, reference is made to Figure 2 , Figure 2 The diagram illustrates the architecture of the server cluster in this application, including: a central server, subsystems of the central server, server 1, server 2, etc., which can be sub-servers in the server cluster. Sub-servers and the central server are connected and communicate with each other through switches and network cards. Each sub-server has its own PDR repository and its own identifier (the EID (endpoint ID) in the attached diagram is the identifier, used to identify each terminal). Each subsystem also has its own corresponding identifier and PDR. Subsystems and the central server interact with each other through the PLDM protocol.

[0039] Once all sub-servers have booted up, the central server will contain the topology information of all server machines in the current server cluster. At this point, the central server monitors the sub-servers using sensors and effectors. For example, to control the boot-up or shutdown of a sub-server, it can modify the effector state of that sub-server. A command to modify the effector state of a sub-server is sent to the sub-server via the PLDM protocol. Upon receiving the command, the sub-server parses it and determines that it is controlling its shutdown, thus initiating the shutdown process. Because the central server contains the topology data of each subsystem or sub-server, it can obtain the status information of the components within each subsystem or sub-server and modify the status of those components.

[0040] In summary, in this embodiment, when the central server in the server cluster powers on, it creates a repository to store the topology relationship data corresponding to the central server. This topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors. In response to the central server's startup operation, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository. Simultaneously, the topology relationship data corresponding to each subserver in the server cluster is obtained and added to the repository. At this point, the central server's repository includes the topology relationship data corresponding to each subsystem of the central server and each subserver in the server cluster. The central server can then obtain the status of each subsystem or sensor in each subserver through the component relationship tree and control the status of the components corresponding to the sensors through the control effectors. This application uses one server as the central server. During the startup process, each subserver interacts with the central server, enabling the central server to monitor each subserver in real time. Each subserver acts as a node in the system topology, which is recognized by the central server. Each subserver manages all its components through its own BMC, forming a small topology. In this way, the central server can manage all the data in the current system, improving the efficiency of server management in the server cluster.

[0041] refer to Figure 3 This document illustrates a flowchart of another server status management method provided in this application embodiment, applied to a central server in a server cluster. The method includes:

[0042] Step 201: In response to the power-on operation of the central server, a warehouse is created to store the topology relationship data corresponding to the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors.

[0043] This step can be referred to in step 101, and will not be repeated here.

[0044] Step 202: Read the topology data corresponding to each subsystem from the LPC bus using the PLDM protocol. The topology data corresponding to each subsystem is written to the LPC bus by each subsystem based on the PLDM protocol.

[0045] In this embodiment of the invention, after each subsystem of the central server generates its own topology relationship data, the generation of its own topology relationship data includes: each subsystem's own PDR repository, which may include each subsystem's own component relationship PDR, sensor PDR, effector PD, and component relationship tree. Each subsystem can write the topology relationship data to the LPC (Low Pin Count Bus) bus via the PLDM protocol. The central server can obtain the corresponding topology relationship data of each subsystem by reading the LPC bus.

[0046] Step 203: Parse the topology relationship data to obtain the component relationship tree corresponding to each subsystem, and merge the component relationship trees corresponding to each subsystem into the component relationship tree corresponding to the central server in the warehouse.

[0047] In this embodiment of the invention, the central server obtains the topology data corresponding to each subsystem by reading the LPC bus, obtains the component relationship data (PDR) corresponding to the subsystem by parsing the topology data, and merges the component relationship tree corresponding to the subsystem into the component relationship tree corresponding to the central server. This makes the component relationship tree corresponding to the central server include not only the component relationship of the central server itself, but also the component relationship trees corresponding to each subsystem. This allows the central server to obtain the component status corresponding to each subsystem based on the component relationship tree.

[0048] Additionally, the PDR repository is a collection of PDR linked lists. Sensor-type PDRs can act as virtual sensors to record relevant machine component information. When a PDR is updated, the update information is sent to the BMC via the PLDM protocol, thus achieving synchronization with the BMC. The update information is encapsulated according to the PLDM protocol. First, the request information is added with the PLDM protocol header, and then the information is transmitted to the MCTP (Message Control Transfer Protocol, a low-level transport protocol used for data transmission between the BMC and firmware) transport layer. After receiving the information, the MCTP transport layer processes it again, adding the MCTP layer header. If the data is long, it is split and sent to the LPC bus transmit area in multiple parts. The BMC polls the transmit area in the LPC. When there is unread data in the LPC, the BMC reads it segment by segment, assembles it into a complete message, and parses the message.

[0049] Step 204: Obtain the topology relationship data corresponding to each sub-server in the server cluster, and add the topology relationship data corresponding to each sub-server to the repository.

[0050] Optionally, step 204 specifically includes:

[0051] Sub-step 2041: Obtain the identifier information of the topology relationship data corresponding to each sub-server;

[0052] Sub-step 2042: Based on the tag information of the topological relationship data, obtain the topological relationship data corresponding to the tag information;

[0053] Sub-step 2043 involves parsing the topological relationship data corresponding to the flag information and adding it to the repository.

[0054] In this embodiment of the invention, the topology relationship data of each sub-server in the server cluster includes: each sub-server's own PDR repository, which may include each sub-server's own component relationship PDR, sensor PDR, effector PD, and component relationship tree. After creating its own PDR repository and component relationship tree, the sub-server in the server cluster sends a PDR repo change event (an event message used to notify the other party that the PDR repo has changed and remind it to take corresponding actions) to the central server via the network, and sends the identification information of its own topology relationship data to the central server. After receiving the PDR identification information, the central server obtains the newly added PDR of the sub-server locally through the get pdr command, determines which sub-server this part of the PDR comes from by parsing the PDR, obtains the component relationship PDR, and merges the components of the sub-server into its own component relationship tree, thereby enriching its own component relationship tree.

[0055] In other words, during the startup process, the sub-server actively sends its own topology data to the central server. The central server then merges this data into its own topology data, enriching the topology data stored by the central server. The central server uses this topology data from the sub-servers to monitor and manage each sub-server and its components.

[0056] Optionally, sub-step 2043 specifically includes:

[0057] Sub-step 20431: Parse the topology relationship data and obtain the sub-server identifier corresponding to the topology data.

[0058] Sub-step 20432: Merge the component relationship trees of the sub-servers corresponding to each of the sub-server identifiers into the component relationship tree of the central server in the warehouse.

[0059] In this embodiment of the invention, after parsing the topology relationship data, the central server can determine which sub-server the topology data comes from by using the sub-server identifier corresponding to the topology data. Then, the component relationship corresponding to the sub-server is added to the component relationship tree of the central server.

[0060] refer to Figure 4 , Figure 4 The system topology diagram of the server cluster in this application is shown. After the central server and each sub-server in the server cluster are powered on, the component relationship tree stored in the repository is in the form of: Figure 4 As shown, the component relationship tree includes the topological relationships of the components of the central server and each sub-server. The diagram illustrates that the system topology includes the component relationship tree of the central server and the component relationship trees of each sub-server. For example, the system topology diagram shows that the central server includes component 1, which has a parent-child relationship with components 11 and 12 (e.g., components 11 and 12 are on component 1). Component 11 is also connected to component 111, and component 12 is connected to component 121. The relationships between the various components of the central server can be determined through the component relationship tree of the central server. Similarly, the relationship between components 111 and 111 can be determined based on the component relationship tree of sub-server 1, and the relationship between components 111 and 111 in sub-server 2 can be determined based on the component relationship tree of sub-server 2. Thus, when the central server obtains the status of component 11 through sensors connected to component 11 of the sub-server and determines that component 11 is faulty, it can further investigate whether component 111 is also faulty based on the stored component relationship tree of sub-server 1. The central server can monitor and manage the status of a specific component within a sub-server by using the component relationship tree and the stored PDRs (Program Data Records) of the sub-server's sensors or effectors. In other words, when the central server boots up, it proactively retrieves the topology information from each sub-server and synchronizes it to its own component relationship diagram. This allows the central server to monitor and manage all sub-servers immediately after booting up, using the entire system's topology diagram.

[0061] Step 205: Obtain the status of each subsystem or sensor in each subserver included in the central server through the component relationship tree in the warehouse, and control the status of the component corresponding to the sensor through the control effector.

[0062] This step can be referred to in step 104, and will not be repeated here.

[0063] Optionally, step 205 specifically includes:

[0064] Sub-step 2051: Send control commands to the sub-server via the PLDM protocol; so that the sub-server controls the effector corresponding to the component to perform control operations by parsing the control commands, and controls the state of the component corresponding to the sensor.

[0065] In this embodiment of the invention, the central server can send control commands to the sub-servers via the PLDM protocol. Upon receiving the control commands, the sub-servers parse the commands and control the corresponding effectors of the components to execute control operations, thus enabling the central server to control the state of the components. For example, if controlling the fan speed of a sub-server, the central server first determines whether the fan is currently on or off, and its current speed, using the corresponding sensor. Then, it sends a command to the sub-server to modify the state of the fan effector. This command is then sent to the sub-server via the PLDM protocol. Upon receiving the event, the sub-server parses it to determine that the event controls the fan speed change, and thus modifies the fan speed to the speed specified by the event.

[0066] Optionally, the method further includes:

[0067] Step 206: When the central server is shut down and restarted, and the sub-servers are powered on, obtain the status information of each sub-server.

[0068] In this embodiment of the invention, when the central server is shut down and then restarted, but the sub-server is powered on, the central server cannot know the current status of the sub-server. Therefore, it will synchronize through the PLDM protocol to obtain the current status of the sub-server again.

[0069] Step 207: Based on the status information of each sub-server, synchronize the topology relationship data of each sub-server to the warehouse.

[0070] In this embodiment of the invention, the status of a sub-server includes whether it is powered on or powered off. If the sub-server is powered on, the central server needs to synchronize the sub-server's topology data to its local machine to ensure the real-time status of each sub-server managed by the central server.

[0071] Optionally, step 207 specifically includes:

[0072] Sub-step 2071: When each sub-server is powered on, a data synchronization command is sent to each sub-server.

[0073] Sub-step 2072: Receive the topology relationship data sent by each sub-server and save the topology relationship data to the repository.

[0074] In this embodiment of the invention, the central server first sends a data synchronization command to each sub-server via the PLDM protocol: `get pldm version`. Upon receiving the data synchronization command, the sub-server returns a message to the central server indicating that it is currently powered on. After receiving the message that the sub-server is powered on, the central server sends a `get pdr` command to each sub-server to obtain all PDRs (Process Data Records) of the sub-server and saves them locally, enriching its component relationship tree. When the central server receives a PDR of type sensor or effector from a sub-server, it sends a `get sensor reading` command to the sub-server to obtain its current status. At this point, the central server can synchronize the information from the sub-server.

[0075] In this application, communication between the central server and each sub-server is conducted via the PLDM protocol. Compared to the IPMI (Intelligent Platform Management Interface) protocol, which can intelligently monitor, control, and automatically report the operational status of a large number of servers across different operating systems, firmware, and hardware platforms to reduce server system costs, this method allows for better sensor expansion. The central server manages not only the sub-servers but also its own static and hot-swappable devices, enabling the management of all server devices and components in the server cluster using only a single central server. Furthermore, whether the central server or a sub-server is powered on or restarted, PDR synchronization is performed to ensure that the central server can monitor all sub-servers in real time, guaranteeing system stability. By synchronizing topology relationship data, the problem of the central server managing the system topology of all sub-servers in the server cluster is solved. During the boot process of each sub-server, the central server cannot know the real-time status of each sub-server and cannot control the working status of each sub-server through sensors and effects. In other words, this solves the problem of the central server's weak monitoring capabilities over sub-servers and its inability to play a central management role.

[0076] In summary, in this embodiment, when the central server in the server cluster powers on, it creates a repository to store the topology relationship data corresponding to the central server. This topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors. In response to the central server's startup operation, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository. Simultaneously, the topology relationship data corresponding to each subserver in the server cluster is obtained and added to the repository. At this point, the central server's repository includes the topology relationship data corresponding to each subsystem of the central server and each subserver in the server cluster. The central server can then obtain the status of each subsystem or sensor in each subserver through the component relationship tree and control the status of the components corresponding to the sensors through the control effectors. This application uses one server as the central server. During the startup process, each subserver interacts with the central server, enabling the central server to monitor each subserver in real time. Each subserver acts as a node in the system topology, which is recognized by the central server. Each subserver manages all its components through its own BMC, forming a small topology. In this way, the central server can manage all the data in the current system, improving the efficiency of server management in the server cluster.

[0077] refer to Figure 5 This illustration shows a server status management device 30 provided in an embodiment of this application, applied to a central server in a server cluster. The device includes:

[0078] The first adding module 301 is used to create a warehouse for storing the topology relationship data corresponding to the central server in response to the power-on operation of the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the entities in the central server and the corresponding sensors and effectors.

[0079] The second adding module 302 is used to add the topology relationship data corresponding to each subsystem contained in the central server to the warehouse in response to the startup operation of the central server;

[0080] The third adding module 303 is used to obtain the topology relationship data corresponding to each sub-server in the server cluster and add the topology relationship data corresponding to each sub-server to the repository;

[0081] The management module 304 is used to obtain the status of each subsystem or sensor in each subserver included in the central server through the component relationship tree in the warehouse, and to control the status of the component corresponding to the sensor through the control effector.

[0082] Optionally, the first adding module includes:

[0083] The reading submodule is used to read the topology data corresponding to each subsystem from the LPC bus via the PLDM protocol. The topology data corresponding to each subsystem is written to the LPC bus by each subsystem based on the PLDM protocol.

[0084] The first parsing submodule is used to parse the topological relationship data, obtain the component relationship tree corresponding to each subsystem, and merge the component relationship trees corresponding to each subsystem into the component relationship tree corresponding to the central server in the warehouse.

[0085] Optionally, the second adding module includes:

[0086] The flag acquisition submodule is used to retrieve the flag information of the topology relationship data corresponding to each sub-server;

[0087] The topology acquisition submodule is used to acquire topology data corresponding to the flag information based on the flag information of the topology data;

[0088] The first addition submodule is used to parse the topological relationship data corresponding to the flag information and add it to the repository.

[0089] Optionally, the first added submodule includes:

[0090] The second parsing submodule is used to parse the topology relationship data and obtain the sub-server identifier corresponding to the topology data.

[0091] The first merging submodule is used to merge the component relationship trees of the subservers corresponding to each of the subserver identifiers into the component relationship tree of the central server in the warehouse.

[0092] Optionally, the management module includes:

[0093] The instruction sending submodule is used to send control instructions to the sub-server via the PLDM protocol; thereby enabling the sub-server to control the effector corresponding to the component to perform control operations by parsing the control instructions, and to control the state of the component corresponding to the sensor.

[0094] Optionally, the method further includes:

[0095] The sub-server status acquisition module is used to acquire the status information of each sub-server when the central server is shut down and restarted, and the sub-server is in the power-on state.

[0096] The synchronization module is used to synchronize the topology data of each sub-server to the warehouse based on the status information of each sub-server.

[0097] Optionally, the synchronization module includes:

[0098] The synchronization instruction sending submodule is used to send data synchronization instructions to each sub-server when each sub-server is powered on.

[0099] The data addition submodule is used to receive topology relationship data sent by each sub-server and save the topology relationship data to the repository.

[0100] In summary, in this embodiment, when the central server in the server cluster powers on, it creates a repository to store the topology relationship data corresponding to the central server. This topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors. In response to the central server's startup operation, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository. Simultaneously, the topology relationship data corresponding to each subserver in the server cluster is obtained and added to the repository. At this point, the central server's repository includes the topology relationship data corresponding to each subsystem of the central server and each subserver in the server cluster. The central server can then obtain the status of each subsystem or sensor in each subserver through the component relationship tree and control the status of the components corresponding to the sensors through the control effectors. This application uses one server as the central server. During the startup process, each subserver interacts with the central server, enabling the central server to monitor each subserver in real time. Each subserver acts as a node in the system topology, which is recognized by the central server. Each subserver manages all its components through its own BMC, forming a small topology. In this way, the central server can manage all the data in the current system, improving the efficiency of server management in the server cluster.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0115] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the server state management method.

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

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

Claims

1. A server status management method, characterized in that, The method, applied to a central server in a server cluster, includes: In response to the power-on operation of the central server, a repository is created to store the topology relationship data corresponding to the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the components in the central server and their corresponding sensors and effectors. In response to the startup operation of the central server, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository; Obtain the topology relationship data corresponding to each sub-server in the server cluster, and add the topology relationship data corresponding to each sub-server to the repository; By using the component relationship tree in the warehouse, the state of each subsystem and sensor in each subserver included in the central server is obtained, and the state of the component corresponding to the sensor is controlled by the control effector. In response to the startup operation of the central server, the topology relationship data corresponding to each subsystem contained in the central server is added to the repository, including: The topology data corresponding to each subsystem is read from the LPC bus using the PLDM protocol, and the topology data corresponding to each subsystem is written to the LPC bus by each subsystem based on the PLDM protocol. The topology data is parsed to obtain the component relationship tree corresponding to each subsystem, and the component relationship trees corresponding to each subsystem are merged into the component relationship tree corresponding to the central server in the warehouse; The step of obtaining the topology relationship data corresponding to each sub-server in the server cluster and adding the topology relationship data corresponding to each sub-server to the repository includes: Obtain the identification information of the topology relationship data corresponding to each sub-server; Based on the tag information of the topology relationship data, obtain the topology relationship data corresponding to the tag information; After parsing the topological relationship data corresponding to the flag information, it is added to the repository; The step of parsing the topological relationship data corresponding to the flag information and adding it to the repository includes: Parse the topology data to obtain the sub-server identifier corresponding to the topology data; Merge the component relationship trees of each of the sub-server identifiers into the component relationship tree of the central server in the warehouse; The control of the state of the component corresponding to the sensor via the control effector includes: Control commands are sent to the sub-server via the PLDM protocol; the sub-server then parses the control commands to control the effector corresponding to the component to perform control operations, thereby controlling the state of the component corresponding to the sensor.

2. The method according to claim 1, characterized in that, The method further includes: When the central server is shut down and restarted, and the sub-servers are powered on, obtain the status information of each sub-server. Based on the status information of each sub-server, the topological relationship data of each sub-server is synchronized to the warehouse.

3. The method according to claim 2, characterized in that, The step of synchronizing the topology data of each sub-server to the warehouse based on the status information of each sub-server includes: While each sub-server is powered on, a data synchronization command is sent to each sub-server. Receive the topology relationship data sent by each of the sub-servers and save the topology relationship data to the repository.

4. A server status management device, characterized in that, The device is used as a central server in a server cluster, and includes: The first addition module is used to create a repository for storing the topology relationship data corresponding to the central server in response to the power-on operation of the central server. The topology relationship data includes the component relationship tree corresponding to the central server and the correspondence between the entities in the central server and their corresponding sensors and effectors. The second adding module is used to add the topology relationship data corresponding to each subsystem contained in the central server to the repository in response to the startup operation of the central server; The third addition module is used to obtain the topology relationship data corresponding to each sub-server in the server cluster and add the topology relationship data corresponding to each sub-server to the repository; The management module is used to obtain the status of each subsystem and sensor in each subserver of the central server through the component relationship tree in the warehouse, and to control the status of the component corresponding to the sensor through the control effector; The first adding module includes: The reading submodule is used to read the topology data corresponding to each subsystem from the LPC bus via the PLDM protocol. The topology data corresponding to each subsystem is written to the LPC bus by each subsystem based on the PLDM protocol. The first parsing submodule is used to parse the topological relationship data, obtain the component relationship tree corresponding to each subsystem, and merge the component relationship trees corresponding to each subsystem into the component relationship tree corresponding to the central server in the warehouse; The second added module includes: The flag acquisition submodule is used to acquire flag information of the topology relationship data corresponding to each sub-server; The topology acquisition submodule is used to acquire topology data corresponding to the flag information based on the flag information of the topology data; The first addition submodule is used to parse the topological relationship data corresponding to the flag information and add it to the repository; The first added submodule includes: The second parsing submodule is used to parse the topology relationship data and obtain the sub-server identifier corresponding to the topology relationship data. The first merging submodule is used to merge the component relationship trees of the subservers corresponding to each of the subserver identifiers into the component relationship tree of the central server in the warehouse; The management module includes: The instruction sending submodule is used to send control instructions to the sub-server via the PLDM protocol; thereby enabling the sub-server to control the effector corresponding to the component to perform control operations by parsing the control instructions, and to control the state of the component corresponding to the sensor.

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

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

Images