A sensor data processing method of a multi-node server and a multi-node server

Abstract

The application discloses a kind of sensor data processing method and multi-node server of multi-node server, it is related to server technical field.The multi-node server, multiple host nodes are managed by a management controller, reduce system cost, complexity and improve management efficiency and reliability;Second, management controller upper portion is deployed with the node private sensor database for storing the sensor data of corresponding host node, and the common sensor database for storing the sensor data of shared module, and node private sensor database and host node one-to-one correspondence, the unified management of management controller to sensor data and sensor data according to host node isolation are realized;Management controller obtains target data from the node private sensor database of target host node and / or common sensor database according to request, guarantee that accurate, fast response node request and improve data security.

Description

Technical Field

[0001] This invention relates to the field of server technology, and in particular to a sensor data processing method for a multi-node server and a multi-node server. Background Technology

[0002] Dual-node servers are a high-density server architecture that integrates two independent host nodes into a single physical chassis. By sharing the chassis structure, power supply system, and heat dissipation modules, they significantly improve space utilization and reduce overall system costs. In related technologies, the system management functions of dual-node servers are typically implemented by a management controller (such as a Baseboard Management Controller (BMC)). Each host node is configured with an independent management controller (i.e., a "one-to-one" architecture), and each management controller typically has a Sensor Data Record (SDR) library to store sensor data from the managed host node. However, the need for each host node to configure an independent management controller and related peripheral circuitry increases material costs and board space requirements. Furthermore, the need for multiple host nodes to establish a communication mechanism to achieve shared functionality leads to high design complexity. Additionally, this distributed management architecture with multiple management controllers results in a significantly increased workload for firmware maintenance and low management efficiency.

[0003] Therefore, while ensuring the independent operation of each node, how to effectively reduce system cost and complexity, and improve management efficiency and reliability, is a technical problem that urgently needs to be solved by people in this field. Summary of the Invention

[0004] This invention provides a sensor data processing method and a multi-node server for multi-node servers, which at least solves the problems of high system cost and complexity, low management efficiency and reliability when each host node is configured with an independent management controller in related technologies.

[0005] This invention provides a multi-node server, including a management controller and host nodes. The management controller manages a shared module and at least two host nodes. The management controller is equipped with a node-private sensor database and a public sensor database, and the node-private sensor database corresponds one-to-one with the host nodes. The node-private sensor database is used to store sensor data of the corresponding host node, and the public sensor database is used to store sensor data of the shared module.

[0006] The management controller is used to receive requests that represent the acquisition of sensor data from a target host node, and to acquire the target data from the node's private sensor database and / or public sensor database corresponding to the target host node according to the request; and to respond to the request using the target data.

[0007] The beneficial effects of this invention are that the multi-node server includes a management controller and host nodes. First, the management controller manages a shared module and at least two host nodes. That is, multiple host nodes are managed through a single management controller (i.e., a one-to-many architecture), eliminating the need to configure independent management controllers and related peripheral circuits for each host node, thus reducing material costs and circuit board space. When sharing a common module, the management controller makes the decision directly, eliminating the need for communication mechanisms between multiple host nodes, reducing design complexity. Furthermore, since multiple host nodes share a single management controller, the workload of firmware maintenance for the management controller is reduced, improving management efficiency. Second, in the previous method where only one SDR library was set up on a single management controller to store sensor data from all managed host nodes, when any node requested its own sensor data through the management controller, because all sensor data for the entire system was stored in the same SDR, the node could easily obtain data from other nodes, thus failing to accurately... The present invention addresses the issues of inaccurate and rapid response to node requests and low data security in the multi-node server. The management controller of this invention deploys a node-private sensor database for storing sensor data from corresponding host nodes, and a public sensor database for storing sensor data from shared modules. Each node-private sensor database corresponds one-to-one with a host node, enabling unified management of sensor data by the management controller and isolation of sensor data by host node. This is a prerequisite for accurately obtaining sensor data from a single host node in an architecture where multiple host nodes correspond to one management controller. Furthermore, upon receiving a request indicating the need to obtain sensor data from a target host node, the management controller retrieves the target data from the node-private sensor database and / or the public sensor database corresponding to the target host node. Finally, it responds to the request using the target data. This ensures that the host node can obtain sensor data from the target node, data from the public sensor database, and a complete record of the target node's sensor data (including data from both the node-private and public sensor databases), guaranteeing accurate and rapid response to node requests and improving data security.

[0008] In addition, the present invention also provides a sensor data processing method for a multi-node server applied to a management controller, a sensor data processing method for a multi-node server applied to a host node, an electronic device, a non-volatile storage medium, and a computer program product, which have the same or corresponding technical features as the multi-node server mentioned above, and have the same effects. Attached Figure Description

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

[0010] Figure 1 A schematic diagram of a conventional dual-node management system hardware architecture provided for an embodiment of the present invention;

[0011] Figure 2 This is a schematic diagram of a conventional dual-node sensor data acquisition and recording method provided in an embodiment of the present invention;

[0012] Figure 3 A schematic diagram of a multi-node server provided in an embodiment of the present invention;

[0013] Figure 4 An interface allocation diagram provided for an embodiment of the present invention;

[0014] Figure 5 This is a schematic diagram of a baseboard management controller managing sensor data from two nodes, provided in an embodiment of the present invention.

[0015] Figure 6 A flowchart illustrating a sensor data processing method for a multi-node server applied to a management controller in a multi-node server, provided as an embodiment of the present invention;

[0016] Figure 7 A schematic diagram illustrating a node identification method provided in an embodiment of the present invention;

[0017] Figure 8 A schematic diagram illustrating the conversion of an intelligent platform management interface protocol into a message bus communication protocol, provided for an embodiment of the present invention;

[0018] Figure 9 This is a schematic diagram illustrating how data is acquired from a dual-node sensor data record via a first management bus interface, as provided in an embodiment of the present invention.

[0019] Figure 10 This is a schematic diagram illustrating how data is acquired from a dual-node sensor data record via a second management bus interface, as provided in an embodiment of the present invention.

[0020] Figure 11 A schematic diagram illustrating a method for managing a dual-node host system using a single-baseboard management controller, provided in an embodiment of the present invention;

[0021] Figure 12 This is a schematic diagram of a dual-node sensor data recording method provided in an embodiment of the present invention. Detailed Implementation

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

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

[0024] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The number of host nodes included in the multi-node server provided by the present invention is not limited and is determined according to the actual situation. The following description uses a two-node server as an example to illustrate the hardware architecture of a traditional two-node management system. Figure 1 This is a schematic diagram of a traditional dual-node management system hardware architecture provided in an embodiment of the present invention, such as... Figure 1 As shown, in traditional dual-node management hardware architectures, the relationship between the baseboard management controller (BMC) and the host node is typically managed in a one-to-one manner. Each BMC is responsible for managing its corresponding server node, and when managing shared resources (such as the Inter-Integrated Circuit (I2C) bus), coordination is achieved through an I2C arbitration module. The role of the I2C arbitration module is to ensure that resource conflicts are avoided to a certain extent and data integrity is guaranteed when multiple BMC boards access common resources in the chassis simultaneously. However, this architecture design also has certain drawbacks and limitations, especially in terms of system cost and reliability.

[0025] In addition, the first baseboard management controller manages host node A, and the second baseboard management controller manages host node B. In the first and second baseboard management controllers, the controllers managing the central processing unit (CPU) module include a first controller (e.g., an eSPI controller, connected to the CPU module's first interface (e.g., an eSPI interface), a second controller (e.g., a JTAG controller, connected to the CPU module's second interface (e.g., a JTAG interface), and a third controller (e.g., an I3C controller, connected to the CPU module's third interface (e.g., an I3C interface)). The controllers managing the network interface card (NIC) module include a fourth controller (e.g., a Network Controller Sideband Interface Controller, NCSI, connected to the NIC module's fourth interface (NCSI interface)). The controllers managing the sensor module include multiple fifth controllers (e.g., I2C controllers, connected to the sensor module's fifth and sixth interfaces (e.g., I2C interfaces)) and a sixth controller (e.g., an ADC controller, connected to a seventh interface (e.g., an ADC interface)). A network controller manages the network ports (connected to the BMC network port). A seventh controller manages the shared modules (e.g., an I2C controller). The seventh controller in the first and second baseboard management controllers is connected to the shared module via an arbitration module. If interfaces eight through ten are all I2C interfaces, then the arbitration module is an I2C arbitration module. Additionally, this architecture also includes an eighth controller (e.g., an ADC controller).

[0026] Traditional dual-node servers require each host node to be configured with an independent management controller and related peripheral circuits, increasing material costs and circuit board space. Furthermore, multiple host nodes need to establish a communication mechanism to achieve shared functionality, resulting in high design complexity. Additionally, this distributed management architecture with multiple management controllers leads to a significant increase in firmware maintenance workload and low management efficiency. Therefore, this invention provides a hardware architecture for multi-node management using a single management controller, thereby reducing system costs and improving system reliability.

[0027] In addition, each management controller typically has a sensor database to store sensor data from the host nodes it manages. Figure 2 This is a schematic diagram of a traditional dual-node sensor data acquisition and recording method provided in an embodiment of the present invention, as shown below. Figure 2As shown, the traditional dual-node sensor data acquisition and recording method involves a user management layer 100, a network protocol layer 200, and a server layer 300. The two modules of the user management layer 100 (a first management bus interface (e.g., Intelligent Platform Management Interface, IPMI) and a second management bus interface (e.g., Redfish API)) establish connections with two network addresses (network address one and network address two) of the network protocol layer 200, and then connect to two baseboard management controllers (first baseboard management controller and second baseboard management controller) in the server layer through these network addresses. The two baseboard management controllers in the server layer also perform data synchronization operations, respectively associating with the sensor database (i.e., SDR) of motherboard one and the sensor database of motherboard two. In this architecture, each baseboard management controller independently collects and manages the sensor data of its assigned node through its local sensor database.

[0028] In hardware architectures where a single management controller manages multiple nodes, each management controller typically has a sensor database to store sensor data from the managed host nodes. Therefore, with a single sensor database managing sensor data from all nodes and common areas, when any host node requests its own sensor data through the management controller, the fact that all sensor data is stored in the same database makes it easy for that host node to access data from other host nodes. This results in inaccurate and slow responses to node requests, as well as low data security. Therefore, this invention also proposes a method for managing sensor data within the management controller. Figure 3 This is a schematic diagram of a multi-node server provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the system includes a management controller (such as a baseboard management controller) and host nodes. The management controller manages a shared module and at least two host nodes. Specifically, the management controller in the multi-node server is equipped with multiple sets of first interface controllers for interacting with the host nodes, and a set of second interface controllers for connecting to the shared module; each host node is connected to a corresponding set of first interface controllers. A preset interface on the first interface controller is connected to a target sensor on its corresponding host node, and a preset interface on the second interface controller is connected to a target sensor on the shared module. In this one-to-many configuration, the binding of the controller interface to the sensor is fundamental for the baseboard management controller to acquire sensor data and allows the management controller to clearly identify the source of the acquired sensor data.

[0029] Combination Figure 3 The provided dual-node server further illustrates this architecture. It includes the following components:

[0030] (1) Dual-node motherboard subsystem: includes physically isolated host node A and host node B motherboard components, each motherboard integrating the following functional modules:

[0031] 1) Central Processing Unit (CPU) module: Configured with eSPI / JTAG / I3C interfaces to realize in-band communication channels with BMC.

[0032] 2) Network Interface Card (NIC) module: integrates a network controller interface that conforms to the NCSI standard.

[0033] 3) Sensor monitoring module: Includes I2C interface and ADC interface, which monitors the sensor parameters of the motherboard in real time.

[0034] (2) Baseboard Management Controller Subsystem. It adopts a dual-channel design and integrates two complete interface controller groups. Each group includes an eSPI controller, a JTAG controller, an I2C controller, an NCSI controller, an I2C controller, and an ADC controller, which establish independent connection channels with the corresponding modules of host node A and host node B, respectively.

[0035] 1) The eSPI / JTAG / I2C interface connects to the host node CPU module to realize BMC in-band management functions, reliability, availability, serviceability (RAS), diagnostic and CPU debugging functions;

[0036] 2) The NCSI interface connects to the node network interface controller module to provide the BMC with an out-of-band management network channel for the NCSI interface card and to monitor and manage the NCSI interface card.

[0037] 3) The I2C / ADC interface group is connected to the node sensor monitoring module, enabling the BMC to monitor the motherboard power health status, temperature parameters, power consumption data and voltage indicators in real time.

[0038] In in-band access scenarios, the system uses the IPMI protocol via the eSPI channel to enable interaction between nodes and the BMC. When an in-band IPMI request is executed on host node A or host node B, the instruction is transmitted to the BMC via the eSPI channel, where the BMC parses the instruction and executes the corresponding management operations.

[0039] (3) Chassis resource sharing module. The following shared devices are directly connected to the BMC using the I2C bus direct connection scheme.

[0040] 1) Power Supply Unit (PSU) provides unified power management for dual nodes.

[0041] 2) Fan control module, providing unified heat dissipation regulation for dual nodes.

[0042] 3) Some chassis sensor modules provide sensor information shared by both nodes for recording sensor data.

[0043] This design achieves unified resource scheduling through the BMC native I2C master controller, eliminating the arbitration module in the traditional architecture, reducing system complexity while improving reliability.

[0044] (4) Management network interface. A dedicated BMC management network interface is configured on the front panel of the chassis, providing an independent out-of-band management channel to support remote node monitoring and management, realize real-time acquisition and control of the operating status of each node, and allow users to directly access the BMC management system through this interface to complete centralized monitoring and configuration management of the dual-node system.

[0045] The following describes the connection methods between the target sensors on the host node, the target sensors on the shared module, and the interface controller on the management controller. The target sensors on the host node include various types of sensors installed on the board; these sensors include at least one or more of the following: temperature sensors, voltage sensors, and combinations of sensors with signal acquisition and control functions. The first interface controller includes a peripheral interface controller, an analog-to-digital converter controller, and a general-purpose input / output controller. The first interface controller is a peripheral interface controller, and its peripheral interface is connected to the temperature sensor on its corresponding host node. The first interface controller is also an analog-to-digital converter controller, and its analog-to-digital conversion interface is connected to the voltage sensor on its corresponding host node. Finally, the first interface controller is a general-purpose input / output controller, and its general-purpose input / output interface is connected to the sensor on its corresponding host node that has signal acquisition and control functions.

[0046] The second interface controller includes a peripheral interface controller and a general-purpose input / output controller. The target sensors on the common module include at least one or more of the following: a chassis temperature sensor, a fan speed sensor, a power parameter sensor, and a combination of sensors with signal acquisition and control functions. The second interface controller is a peripheral interface controller, whose peripheral interfaces are connected to the chassis temperature sensor, fan speed sensor, and power parameter sensor on the common module, respectively. The second interface controller is also a general-purpose input / output controller, whose general-purpose input / output interfaces are connected to the sensors with signal acquisition and control functions on the common module.

[0047] The connection between the preset interface on the aforementioned interface controller and the target sensor is referred to as the sensor data logging management hardware interface allocation. Sensor data logging functionality involves various interface types at the hardware level, including peripheral interface controllers (such as internal integrated circuits (I2C), analog-to-digital converters (ADCs), and general-purpose input / output (GPIO) controllers). To adapt to a dual-node architecture, the aforementioned interfaces are now uniformly planned and allocated, specifically divided into three categories: host node A dedicated interface, host node B dedicated interface, and common interface. Figure 4 This is a schematic diagram of interface allocation provided in an embodiment of the present invention, such as... Figure 4 As shown, both host node A and host node B are connected to the baseboard management controller. Host node A and host node B contain sensors including a temperature sensor, a voltage regulator, components (with sensors mounted on them), a voltage sensor, a button detection sensor, a fault detection sensor, a status indicator sensor, a power status detection sensor, and an presence detection sensor. Internal integrated circuit controller interfaces 0 to 2 are connected to the chassis temperature sensor, fan speed sensor, and power parameter sensor on the common module via their respective internal integrated circuit controller interfaces 0' (hereinafter referred to as interface 0') to 2'. The general-purpose input / output interfaces Y0 (GPIOY0) to Z7 (GPIOZ7) and AA0 (GPIOAA0) to AA7 (GPIOAA7) on the baseboard management controller are all connected to sensors for power supply presence detection and sensors for fan presence detection; internal integrated circuit controller 3 is connected to the temperature sensor in host node A, and internal integrated circuit controller 9 is connected to the temperature sensor in host node B; internal integrated circuit controller 8 is connected to components in host node A, and internal integrated circuit controller 14 is connected to components in host node B. Connect the following: Analog-to-digital converter interface 0 (ADC0) to analog-to-digital converter interface 7 (ADC7) to the voltage sensor in host node A; Analog-to-digital converter interface 8 (ADC8) to analog-to-digital converter interface 15 (ADC15) to the voltage sensor in host node B; General Purpose Input / Output Interface A0 (GPIOA0) to General Purpose Input / Output Interface L7 (GPIOOL7) to the presence status sensor in host node A; General Purpose Input / Output Interface M0 (GPIOM0) to General Purpose Input / Output Interface X7 (GPIOX7) to the presence status sensor in host node B.

[0048] Combination Figure 4 The allocation of the internal integrated circuit controller interface (i.e., I2C interface) is as follows:

[0049] I2C0 to I2C2: Configured as common I2C interfaces for collecting system-level sensor information, including but not limited to power status parameters, fan operating status (obtained via the fan control board), and common temperature monitoring points (such as the temperature of the chassis inlet and outlet).

[0050] I2C3 to I2C8: These are dedicated I2C interfaces for host node A, responsible for connecting various sensors on host node A, including temperature sensors, voltage regulators, and other functional components and expansion cards.

[0051] I2C9 to I2C14: These are dedicated I2C interfaces for host node B, used to connect temperature sensors, voltage regulators, and other related components and boards on host node B.

[0052] In addition, in practice, extra I2C interfaces can be set up as reserved I2C interfaces for future function expansion or system debugging.

[0053] The interface assignment for the analog-to-digital converter (ADC) is as follows:

[0054] Since the voltage monitoring links are implemented independently on the motherboards of the two host nodes, the ADC interface does not need to have a common part set up; all resources are allocated to node-specific resources, as follows:

[0055] ADC0 to ADC7: These are dedicated ADC interfaces for host node A, used to monitor various voltage signals on host node A.

[0056] ADC8 to ADC15: These are dedicated ADC interfaces for host node B, used to monitor various voltage signals on host node B.

[0057] The general purpose input / output (GPIO) interface allocation is as follows:

[0058] GPIOY0 to GPIOZ7 and GPIOAA0 to GPIOAA7: Defined as a common GPIO interface group, used to detect system-level status signals, such as power supply status, fan status, etc.

[0059] GPIOA0 to GPIOL7: These are dedicated GPIO interfaces for host node A, responsible for various signal acquisition and control functions on host node A, including Power Good signal, hardware presence signal, Error status signal, panel button input, and LED indicator control.

[0060] GPIOM0 to GPIOX7: These are dedicated GPIO interfaces for host node B, used to handle functions such as PowerGood signal, presence detection, Error signal, button signal, and LED control on host node B.

[0061] By providing the structured allocation of I2C, ADC, and GPIO interfaces, this solution offers a clear and scalable hardware interface foundation for the implementation of Sensor Data Recording (SDR) in a dual-node system, ensuring the independence of sensor information acquisition at each node and the unified management of common information.

[0062] Previously, a single SDR (Sensor Data Repository) on the management controller stored sensor data from all managed host nodes. However, when any host node requested its own sensor data through the management controller, the data from other nodes was easily accessed because all sensor data was stored in the same SDR. This resulted in inaccurate and slow responses to node requests, as well as low data security. Therefore, to ensure accurate and fast responses to node requests and improve data security, the management controller is equipped with both a node-specific private sensor database and a public sensor database. The node-specific private sensor database stores sensor data for its corresponding host node, while the public sensor database stores sensor data from shared modules. This unified management of sensor data by the management controller and the isolation of sensor data by host node are prerequisites for accurately obtaining sensor data from individual host nodes in an architecture where multiple host nodes correspond to a single management controller.

[0063] In practice, to directly obtain complete sensor data from the host nodes (i.e., including sensor data located on the host nodes and sensor data from shared modules), the management controller also includes a master sensor database. Both the node-private sensor database and the public sensor database have data links to the master sensor database. The master sensor database has multiple storage areas, each corresponding one-to-one with a host node. These storage areas store the sensor data of their respective host nodes. The host node's sensor data includes data from both its node-private sensor database and its public sensor database.

[0064] To enable those skilled in the art to intuitively understand the design of the sensor database (i.e., SDR) in the management controller of the present invention, the underlying implementation logic of dual-node sensor data recording will be further described below in conjunction with the accompanying drawings and specific embodiments. Figure 5 This is a schematic diagram of a substrate management controller managing sensor data of two nodes, provided in an embodiment of the present invention. Figure 5As shown, the system includes a total sensor database, a private sensor database for host node A (i.e., host node A's private SDR), a private sensor database for host node B (i.e., host node B's private SDR), and a public sensor database (i.e., a public SDR). The private sensor databases for host node A and host node B respectively contain motherboard temperature information, power consumption information, board temperature and presence information, partial temperature information, voltage information, fault detection information, status indication information, power status detection information, presence detection information, and button information. The total sensor database includes storage areas for host node A and host node B.

[0065] As independent entities, host node A and host node B have various sensors on their motherboards and related boards, including temperature sensors, power consumption sensors, component temperature and voltage sensors, as well as various GPIO signals (such as presence signals, error status, Power Good signals, LED control signals, and panel button inputs), all of which are classified as the private SDR part of each node.

[0066] On the other hand, sensors located in the common area of ​​the chassis, such as inlet and outlet temperature sensors, fan speed and presence detection sensors, power supply voltage and current and power supply presence signals, are uniformly divided into common SDRs and shared by the two nodes.

[0067] When the user layer initiates a request to retrieve the complete SDR data of a node (such as host node A) via IPMI or the RedFish protocol interface, the underlying Desktop Bus Interface (DBus) layer performs a dynamic data combination operation: it extracts host node A's private SDR data from storage and merges it with the public SDR data to form the complete SDR record set of host node A. Similarly, host node B's SDR is composed of host node B's private SDR and the aforementioned public SDR. This combined SDR data is then returned to the upper-layer application via the DBus interface for use by the IPMI or RedFish interface layer.

[0068] This design enables unified management of sensor data and node-isolated access logic in a dual-node system, ensuring the independence and integrity of sensor data at each node while avoiding redundant storage and collection of common data, thus improving system maintainability and data consistency.

[0069] Based on the above interface allocation and sensor database design, the management controller receives a request to obtain sensor data from the target host node, retrieves the target data from the node's private sensor database and / or public sensor database corresponding to the target host node, and responds to the request using the target data.

[0070] In the multi-node server provided in this embodiment of the invention, firstly, the management controller manages a shared module and at least two host nodes. That is, multiple host nodes are managed through a single management controller (i.e., a one-to-many architecture), eliminating the need to configure independent management controllers and related peripheral circuits for each host node, thus reducing material costs and circuit board space. When sharing a common module, the management controller makes the decision directly, eliminating the need for communication mechanisms between multiple host nodes, reducing design complexity. Furthermore, since multiple host nodes share a single management controller, the workload of firmware maintenance for the management controller is reduced, improving management efficiency. Secondly, in the previous method where only one SDR library was set up on a single management controller to store sensor data from all managed host nodes, when any node requested its own sensor data through the management controller, because all sensor data for the entire system was stored in the same SDR, the node could easily obtain data from other nodes, thus failing to accurately... The present invention addresses the issues of inaccurate and rapid response to node requests and low data security in the multi-node server. The management controller of this invention deploys a node-private sensor database for storing sensor data from corresponding host nodes, and a public sensor database for storing sensor data from shared modules. Each node-private sensor database corresponds one-to-one with a host node, enabling unified management of sensor data by the management controller and isolation of sensor data by host node. This is a prerequisite for accurately obtaining sensor data from a single host node in an architecture where multiple host nodes correspond to one management controller. Furthermore, upon receiving a request indicating the need to obtain sensor data from a target host node, the management controller retrieves the target data from the node-private sensor database and / or the public sensor database corresponding to the target host node. Finally, it responds to the request using the target data. This ensures that the host node can obtain sensor data from the target node, data from the public sensor database, and a complete record of the target node's sensor data (including data from both the node-private and public sensor databases), guaranteeing accurate and rapid response to node requests and improving data security.

[0071] The foregoing description of a multi-node server, along with this invention, provides a sensor data processing method for a multi-node server with a management controller applied in the multi-node server. The management controller manages a shared module and at least two host nodes; the management controller deploys a node-private sensor database and a public sensor database, with each node-private sensor database corresponding one-to-one with a host node. Figure 6 A flowchart illustrating a sensor data processing method for a multi-node server applied to a management controller in a multi-node server, as provided in an embodiment of the present invention, is shown below. Figure 6 As shown, the method includes:

[0072] S10: Receive a request to acquire sensor data representing the target host node;

[0073] S11: Obtain target data from the private sensor database and / or public sensor database corresponding to the target host node according to the request;

[0074] Among them, the node private sensor database is used to store the sensor data of the corresponding host node, and the public sensor database is used to store the sensor data of the shared module.

[0075] S12: Respond to the request using the target data.

[0076] The structure of a multi-node server is described above and will not be repeated here. The following section will only describe in detail the sensor data processing methods for multi-node servers.

[0077] Since a management controller manages multiple host nodes, upon receiving a request from a host node, it needs to distinguish the host node from which the request originated. That is, before retrieving the target data from the target host node's private sensor database and / or public sensor database according to the request, the following steps are also included:

[0078] Determine the target interface name based on the request;

[0079] The target host node from which the request originates is determined based on the target interface name and the pre-established mapping relationship between interface names and host nodes.

[0080] This method enables the determination of the host node from which the request originates, ensuring that the sensor data subsequently acquired is from that host node.

[0081] Typically, server maintenance involves monitoring the server via IPMI requests. For example, CPU temperature and fan control modes can be obtained via IPMI requests both in-band and out-of-band. However, the IPMI protocol stack lacks specifications for multi-node management. This makes it impossible to distinguish the correspondence between requests and nodes when using a single BMC to manage two nodes; that is, it cannot identify the host node from which an in-band request originates or the host node to which an out-of-band request is accessing. Therefore, to facilitate request management and transmission in multi-node servers, if a request does not conform to the rules of the target protocol, it is converted to a protocol that conforms to the target protocol. The target protocol is a protocol used for inter-process communication. The target protocol is not limited; it can be a message bus (Desktop Bus, DBus) communication protocol. The target interface name is determined based on the request, including:

[0082] If the detection request does not conform to the rules of the target protocol, then the pre-established protocol conversion rules are obtained; where the target protocol is a protocol used for inter-process communication.

[0083] The request is converted according to the protocol conversion rules to obtain a request that conforms to the target protocol;

[0084] The target interface name is determined based on the request that conforms to the target protocol.

[0085] The target host node from which the request originates is determined based on the target interface name and the pre-established mapping relationship between interface names and host nodes, including:

[0086] The target interface name is compared with the mapping relationship between the interface name and the host node name obtained from the memory to determine the host node name corresponding to the target interface name;

[0087] The target host node from which the request originated is determined based on the host node name corresponding to the target interface name; the interface name and the host node name exist in memory as key-value pairs.

[0088] The protocol conversion rules are not limited and are determined based on the protocol used in the request and the selected target protocol. In some embodiments, the request is a request conforming to the first management bus interface protocol (i.e., the IPMI protocol), and the target protocol is the message bus communication protocol (i.e., the DBus protocol). Obtaining the pre-established protocol conversion rules includes:

[0089] Get the interface name and object name set according to the source of the request, and get the function used to represent the functionality to be implemented in the request;

[0090] The message header of the message bus communication protocol is determined based on the interface name, object name, and function used to characterize the functionality to be implemented in the request.

[0091] Add a data type identifier before the fields representing logical units, the fields representing network function codes, and the fields representing the operations to be performed in the request.

[0092] Add the array type and the array length fields in sequence before the data fields in the request to serve as the function signature for the message bus communication protocol.

[0093] The process of obtaining the interface name and object name set according to the source of the request includes:

[0094] If the source of the request is detected to be in-band, obtain the name of the in-band interface and the name of the host node from which the request came, and set the interface name and object name according to the name of the in-band interface and the name of the host node.

[0095] If the request originates from out-of-band, obtain the port number assigned by the network protocol from which the request originated, and set the interface name and object name based on the port number.

[0096] The protocol conversion process described above can be implemented through the protocol conversion module, and host node identification can be implemented through the node identification module. The protocol conversion module and the node identification module are connected. To help those skilled in the art better understand the above-described process of protocol conversion and host node identification, the following will still use... Figure 3 The process of protocol conversion and host node identification is explained using a dual-node server and the conversion of IPMI commands to the DBus protocol as an example.

[0097] Figure 7 This is a schematic diagram of a node identification method provided in an embodiment of the present invention, as shown below. Figure 7As shown, when a command is input to the first interface controller A (e.g., eSPI controller A), the interface conversion-A module (e.g., KCS-transfer-A) on the protocol conversion module transmits the message to the message bus (DBUS bus), where it reaches the node identification module for identification. When a command is input to the first interface controller B (e.g., eSPI controller B), the interface conversion-B module (e.g., KCS-transfer-B) on the protocol conversion module transmits the message to the message bus (DBus bus), where it reaches the node identification module for identification. When an out-of-band access command is input to node A from a network protocol (UDP protocol) assigned to port a (e.g., port number 623), the LAN conversion-A module (e.g., LAN-transfer-A) on the protocol conversion module transmits the message to the message bus (DBus bus), where it reaches the node identification module for identification. The out-of-band access node B receives commands from a network protocol (User Datagram Protocol, UDP) assigned to port b (e.g., port number 624). The LAN conversion-B module (e.g., Lan-transfer-B) on the protocol conversion module transmits the message to the message bus (DBus bus), where it reaches the node identification module for identification. The node identification module can control and configure node settings based on node identification policies. Figure 7 In this context, Node A is the logical number of the first node in a dual-node machine; it can also be named Node 1 or Node One, etc. On the physical link, this node is always connected to eSPI controller A. When a dual-node server is shipped, some machines may only be equipped with one node, which might be the second physical node. In this case, the node needs to be named Node A (or Node B if both nodes are present). Dynamic configuration of the node name is achieved through the control unit, ensuring consistency in operation and maintenance management.

[0098] Figure 8 This is a schematic diagram illustrating the conversion of an intelligent platform management interface protocol into a message bus communication protocol, as provided in an embodiment of the present invention. Figure 8As shown, in the transport layer, the DBus (message bus protocol) name is set according to the recorded transport path (interfaceName), and the DBus object name is set according to the recorded transport path (interfaceName). Correspondingly, the message header of the message bus protocol (i.e., DBus) includes the message bus interface name and its corresponding content (e.g., DBus interface name, com.otrd.ipmi.interface.{interfaceName}), the message bus object name and its corresponding content (e.g., DBus object name, / com / otrd / ipmi / interface / {interfaceName}), and the message bus method name and its corresponding content (e.g., DBus method name, executeIPMICommand). The message conforming to the intelligent platform management interface protocol includes four sets of bytes. The first set of bytes is Byte1 [BIT0-BIT1], which corresponds to the logical unit (LUN); the second set of bytes is Byte1 [BIT2-BIT7], which corresponds to the network function code (NetFn); the third set of bytes is Byte2, which corresponds to the operation to be performed (Cmd); and the fourth set of bytes is Byte3:N, which corresponds to the data (Data).

[0099] The entire protocol conversion process includes the following steps:

[0100] (1) Transport layer path record:

[0101] 1) For messages transmitted via the eSPI channel:

[0102] Messages originating from eSPI controller A are marked with interfaceName as eSPI-A;

[0103] The message originates from eSPI controller B, with the interfaceName marked as eSPI-B.

[0104] 2) For messages transmitted via UDP over the network:

[0105] Messages received through port number 623 are marked with interfaceName as Lan-623;

[0106] Messages received through port number 624 are tagged with interfaceName as Lan-624.

[0107] (2) IPMI SDR instruction data parsing:

[0108] The system parses the IPMI SDR command data transmitted by the transport layer according to the following format:

[0109] BIT0 to BIT1 of Byte 1: Recorded as LUN (Logical Unit Number);

[0110] BIT2 to BIT7 of Byte 1: Recorded as NetFn (Network Function Code);

[0111] Byte 2: Recorded as Cmd (command code).

[0112] Byte 3 to Byte N: Records are data byte arrays Data.

[0113] (3) Protocol conversion implementation:

[0114] The IPMI protocol is designed specifically for BMC monitoring and management and cannot be directly used for inter-process communication. In this system, the transmission module and the node identification module are independent processes, making DBus communication a suitable alternative. The specific implementation is as follows:

[0115] 1) Add a DBus message header to the IPMI message.

[0116] 2) Set the interface name and object name according to the message source interfaceName.

[0117] 3) Function signature setting rules:

[0118] LUN field: Add a 0x79 prefix to mark it as BYTE type;

[0119] NetFn field: Add a 0x79 prefix and mark it as BYTE type;

[0120] Cmd field: Add a 0x79 prefix and mark it as BYTE type;

[0121] Data field: Add 0x79 and 0x61 prefixes to mark it as a BYTE array type, and add a length field N to indicate the array length.

[0122] (4) Node identification processing:

[0123] The message is transmitted to the node identification module via the DBus bus, and the node identification module performs the following processing steps:

[0124] 1) Signal monitoring:

[0125] Continuously monitor DBUS bus signals.

[0126] 2) Message filtering:

[0127] Processing is triggered when a DBUS message that meets the following conditions is detected:

[0128] Interface name matching default format: com.otrd.ipmi.interface.{interfaceName};

[0129] The default format for object path matching is: / com / otrd / ipmi / interface / {interfaceName};

[0130] The method name is: executeIPMICommand.

[0131] 3) Path resolution:

[0132] Extract the string after the last " / " from the object path to get the interfaceName;

[0133] 4) Node determination:

[0134] The corresponding node name is obtained by parsing the interfaceName mapping relationship.

[0135] This scheme decouples physical connections from logical naming, improving the flexibility of system configuration, while ensuring reliable communication between different modules through a standardized protocol conversion mechanism.

[0136] After determining the host node from which the request originated in the above embodiments, the target data is retrieved from the node's private sensor database and / or public sensor database corresponding to the target host node according to the request.

[0137] Obtain the target storage area of ​​the target host node in the overall sensor database;

[0138] Transmit sensor data from the private sensor database of the target host node and sensor data from the public sensor database to the target storage area.

[0139] Retrieve target data from the target storage area according to the request.

[0140] In this method, after receiving a request, the private sensor data and public sensor data of the target host node are integrated according to the request, and then the target data is obtained from the storage area. Compared with integrating the sensor data of all host nodes, the amount of data processing is reduced.

[0141] In addition to the methods for acquiring target data described above, to improve the efficiency of target data acquisition, in some embodiments, before receiving a request representing the acquisition of sensor data of the target host node, the following steps are also included:

[0142] Collect sensor data from the host node and store the sensor data collected from the host node in the node's private sensor database corresponding to the host node;

[0143] Collect sensor data from the shared module and store the sensor data from the shared module in a common sensor database;

[0144] The data in the host node's private sensor database and the data in the public sensor database are stored in the corresponding storage area of ​​the host node in the total sensor database;

[0145] After receiving a request to acquire sensor data representing the target host node, the method further includes:

[0146] Obtain the target storage area of ​​the target host node in the overall sensor database;

[0147] Retrieve target data from the target storage area according to the request.

[0148] In this method, the management controller continuously collects sensor data even before a request is received, and integrates the sensor data from the host node and the common parts. This allows the target data to be retrieved directly from the storage area when a request is received, improving the efficiency of sensor data acquisition.

[0149] To ensure that the management controller responds to requests with the latest sensor data, the data in the storage area can be updated at regular intervals to ensure that the data stored in the storage area is the latest, thereby ensuring that the sensor data obtained by the target node is the latest data.

[0150] The above process describes the location for acquiring target data, namely, acquiring it from the sensor database. In this embodiment, the specific method for acquiring target data from the sensor database is further explained. The hierarchy in the management controller, from bottom to top, is the information acquisition layer, the DBus layer, and the command layer. DBus is referred to as the DBus middleware. In this invention, the DBus middleware is used to acquire target data from the sensor database. Specifically, acquiring target data from the target storage area according to a request includes:

[0151] Obtain the root path of the pre-defined target host node through the distributed bus middleware (i.e., DBus middleware);

[0152] Obtain the bus names of multiple sensors under the root path based on the root path of the target host node;

[0153] Obtain the complete object path of the sensor based on its bus name;

[0154] Retrieve target data from the target storage area based on the complete object path of the sensor.

[0155] To address the sensor data management requirements in dual-node systems, this invention proposes a method for acquiring target data from sensor databases using a distributed sensor data middleware based on DBus.

[0156] The data query mechanism of the DBus middleware is as follows:

[0157] The system uses the GetSubTree method of the objectMapper process to retrieve sensor data. The specific workflow is as follows:

[0158] 1) Specify the root path of the target node (e.g., / xyz / openbmc_project / sensors / board1);

[0159] 2) Obtain all bus names under this path (e.g., xyz.openbmc_project.CPUSensor);

[0160] 3) Obtain the complete object path (e.g., / xyz / openbmc_project / sensors / board1 / cpu0_temp);

[0161] 4) Get sensor value interface (xyz.openbmc_project.Sensor.Value);

[0162] 5) Finally, read the specific sensor values.

[0163] After obtaining the target data, the management controller needs to return the target data to the host node that sent the request in response to the request. To ensure that the target host node obtains the target data, the implementation includes responding to the request using the target data, including:

[0164] Obtain the object path of the distributed bus middleware;

[0165] The target host node is determined based on the object path of the distributed bus middleware;

[0166] Send the target data to the target host node in response to the request.

[0167] This means that a host node isolation mechanism is set up for the DBus middleware. Since sensors on each node in a dual-node system may have the same name but different values, this invention achieves node differentiation through DBus object path isolation. The specific implementation scheme is as follows:

[0168] Sensor data path for host node A: / xyz / openbmc_project / sensors / <boardid1> / <sensor_name> ;

[0169] Host node B sensor data path: / xyz / openbmc_project / sensors / <boardid2> / <sensor_name> .

[0170] For example, the implementation of a CPU temperature sensor:

[0171] The node path of host node A is: / xyz / openbmc_project / sensors / board1 / cpu0_temp;

[0172] The node path of host node B is: / xyz / openbmc_project / sensors / board2 / cpu0_temp.

[0173] This method directly determines the target host node based on the object path name of the distributed bus middleware, without needing to differentiate at the command layer (where the target host node can generally be obtained from the attribute information in the data), thus improving the efficiency of determining the target host node.

[0174] Based on the above-mentioned distributed bus middleware for retrieving target data, the following section will use two types of requests (requests conforming to the first management bus interface protocol, such as IPMI requests; and requests conforming to the second management bus interface protocol, such as Redfish requests) as examples to illustrate the solution for obtaining multi-node sensor SDRs.

[0175] In some embodiments, the request is a request conforming to the first management bus interface protocol, and before obtaining the root path of the pre-defined target host node through the distributed bus middleware, it further includes:

[0176] Obtain the target port number from the request, and determine the target port based on the target port number;

[0177] The network daemon corresponding to the target port receives and parses the request, and then proceeds to the step of obtaining the root path of the pre-defined target host node through the distributed bus middleware.

[0178] After retrieving target data from the target storage area based on the sensor's complete object path, the process also includes:

[0179] The target data is encapsulated according to the format of the first management bus interface protocol;

[0180] Obtain the object path of the distributed bus middleware;

[0181] The target host node is determined based on the object path of the distributed bus middleware;

[0182] The encapsulated target data is returned to the target host node via the target port.

[0183] Figure 9 This is a schematic diagram illustrating the acquisition of data from dual-node sensor data records via a first management bus interface, as provided in an embodiment of the present invention. Similarly, it involves a user management layer 100, a network protocol layer 200, and a server layer 300. A multi-instance network daemon (netipmid process) architecture is used to implement dual-node sensor management. The user management layer corresponds to ports numbered 623 and 624; the server contains network daemon a and network daemon b; through the distributed bus middleware, all sensor data records under the boardID1 path can be obtained from the sensor database with board ID1; and through the distributed bus middleware, all sensor data records under the boardID2 path can be obtained from the sensor database with board ID2.

[0184] The specific implementation plan is as follows:

[0185] (1) Process design:

[0186] Host node A: Starts a netipmid process instance and binds it to port number 623;

[0187] Host node B: Starts a netipmid process instance and binds it to port number 624;

[0188] (2) Example of data acquisition process:

[0189] When it is necessary to obtain sensor data records from the host node, perform the following steps:

[0190] 1) User sends out-of-band IPMI commands:

[0191] ipmitool -I lanplus -H <bmcip>-U <username> -P <password> -p 623 sdrelist;

[0192] 2) The netipmid process on port 623 receives the request;

[0193] 3) Query all sensor data under boardID1 through the DBus middleware;

[0194] 4) Encapsulate the data into the IPMI response format;

[0195] 5) The sensor data is recorded and returned to the client through port number 623.

[0196] This method ensures that access methods conforming to the first management bus interface protocol can accurately obtain the sensor data recording information of the corresponding host node, while maintaining data isolation and access security.

[0197] In some embodiments, the request is a request conforming to the second management bus interface protocol, and before obtaining the root path of the pre-defined target host node through the distributed bus middleware, it further includes:

[0198] Obtain the Uniform Resource Locator (URL) corresponding to the request conforming to the second management bus interface protocol;

[0199] The web service daemon parses the path parameters in the Uniform Resource Locator (URL) to obtain the identifier of the target host node; then it proceeds to the step of obtaining the pre-defined root path of the target host node through the distributed bus middleware.

[0200] After retrieving target data from the target storage area based on the sensor's complete object path, the process also includes:

[0201] Convert the target data into data that conforms to the format specified by the second management bus interface protocol;

[0202] Obtain the object path of the distributed bus middleware;

[0203] The target host node is determined based on the object path of the distributed bus middleware;

[0204] The target data obtained after format conversion is returned to the target host node.

[0205] Figure 10 This is a schematic diagram illustrating the acquisition of data from dual-node sensor data records via a second management bus interface, as provided in an embodiment of the present invention. Similarly, it involves a user management layer 100, a network protocol layer 200, and a server layer 300. A web service daemon (BMC Web process) architecture is used to implement dual-node sensor management. The user management layer can output either motherboard number 1 or motherboard number 2. Hypertext Transfer Protocol Secure (HTTPS) is used in the network protocol layer; through the distributed bus middleware, all sensor data records under the path of motherboard number 1 (board ID1 path) can be obtained from the sensor database of motherboard number 1; and through the distributed bus middleware, all sensor data records under the path of motherboard number 2 (board ID2 path) can be obtained from the sensor database of motherboard number 2.

[0206] The specific implementation plan is as follows:

[0207] The system provides sensor data access services through the Redfish RESTful interface:

[0208] (1) Basic access configuration:

[0209] Protocol (e.g., HTTPS), base URL; authentication method: basic authentication or session authentication;

[0210] (2) Sensor data recording and acquisition process:

[0211] 1) User requests sensor data from host node A: GET / redfish / v1 / Systems / board1 / Thermal;

[0212] 2) The BMCweb process performs the following operations:

[0213] Parse URL parameters to obtain the target host node ID;

[0214] Query the sensor data record information corresponding to the boardID through the DBus middleware;

[0215] Convert the data to JSON format.

[0216] 3) Example of returned data:

[0217] {"Temperatures": [{"Name": "CPU0 Temp","ReadingCelsius": 45,"SensorNumber": 1}, {"Name": "CPU1 Temp","ReadingCelsius": 47,"SensorNumber":2}]}.

[0218] (3) Response processing mechanism:

[0219] 1) Status code handling: 200 OK: Request successful; 401 Unauthorized: Authentication failed; 403 Forbidden: Insufficient permissions; 500 Internal Server Error: Internal server error.

[0220] 2) Client-side processing flow:

[0221] Check HTTP status codes; parse JSON data; extract sensor information (name, value, number, etc.); display the parsed and extracted sensor data in the user interface.

[0222] In this invention, unified management of sensor data records on a dual-node server is achieved through multi-protocol support, ensuring accurate acquisition of sensor data record information of the corresponding node under different access methods, while maintaining data isolation and access security.

[0223] To enable those skilled in the art to better understand the entire process of the sensor data acquisition method described above, a dual-node management system will be used as an example to illustrate the entire process of the sensor data acquisition method. Figure 11 This is a schematic diagram illustrating a method for managing a dual-node host system using a single-baseboard management controller, as provided in an embodiment of the present invention. Figure 11 As shown, it includes a monitoring request interaction module, a protocol conversion module, a node identification module, a command identification module, a sensor data recording and management module, and a protocol encapsulation module. In the monitoring request interaction module, input requests from node A, node B, and out-of-band input requests are sent to the protocol conversion module. After passing through the node identification module, command identification module, sensor data recording and management module, protocol encapsulation module, and protocol conversion module, data and response requests are returned.

[0224] Figure 12 This is a schematic diagram of a dual-node sensor data recording method provided in an embodiment of the present invention, as shown below. Figure 12 As shown, it includes a client, a network protocol layer, and a management controller server. The client sends data to the network protocol layer, which then sends it to the server's receiving and processing process. The server retrieves the target data from the sensor data records of host node A and host node B. The server's receiving and processing process then returns the target data to the client's sending process through the network protocol layer.

[0225] The entire process includes the following steps:

[0226] 1. Access channel identification and command reception.

[0227] (1) In-band access mode: When the IPMI SDR (Sensor Data Recording) command is executed locally on host node A or host node B, the command is transmitted to BMC through the eSPI interface.

[0228] (2) Out-of-band access mode: A node-differentiated access mechanism is implemented using differentiated UDP port numbers.

[0229] When accessing the BMC via port number 623 under the UDP protocol, the system automatically identifies it as a management request from host node A;

[0230] When accessing the BMC via port number 624 under the UDP protocol, the system automatically identifies it as a management request to host node B.

[0231] 2. Command parsing and protocol conversion.

[0232] (1) After receiving the command, the BMC first records the characteristic parameters of the transmission channel;

[0233] (2) Call the protocol conversion module to convert the received IPMI protocol instructions into the DBus bus communication protocol format.

[0234] 3. Node identification and routing.

[0235] The system processes DBus commands through a dedicated node identification module, which performs the following operations:

[0236] (1) Parse the node identifier field in the instruction;

[0237] (2) Determine the identity of the source node based on port mapping relationships or channel characteristics;

[0238] (3) Attach a node-specific route label to the instruction to ensure the accuracy of the subsequent processing path.

[0239] 4. Command recognition and execution.

[0240] (1) Analyze the instruction opcode and identify the target functional module corresponding to the instruction;

[0241] (2) For sensor data recording and reading instructions, the DBus instruction is distributed to the sensor data management module of the corresponding node according to the node label;

[0242] (3) Activate the execution unit of the sensor data management module to process the sensor data reading access request.

[0243] 5. Response encapsulation conversion and return.

[0244] After the command is executed, the system performs the response processing procedure:

[0245] (1) Response result encapsulation: Encapsulate the response result according to the DBus response format;

[0246] (2) Protocol Conversion: The protocol conversion module converts the DBus response into IPMI SDR data format;

[0247] (3) Channel selection return: Based on the characteristics of the original access channel, the in-band selection returns response data through the eSPI interface or the corresponding out-of-band UDP port (port number 623 / port number 624).

[0248] Through the above steps, this process realizes a complete closed-loop processing flow for in-band and out-of-band IPMI commands, ensuring efficient processing of in-band and out-of-band IPMI SDR commands in a dual-node system.

[0249] The multi-node server provided by this invention innovatively adopts a single management controller to achieve centralized control of both nodes, compared to the traditional dual-node system where each host node requires an independent baseboard management controller. This technical solution effectively reduces BMC-related hardware costs by approximately 50% through hardware architecture restructuring, while optimizing the internal space layout of the chassis. Specifically, the freed-up front panel space of the standard chassis can accommodate an additional hard drive bay, significantly improving chassis space utilization. By eliminating redundant BMC configurations, this design not only reduces server hardware procurement costs but also decreases system assembly time, achieving a more streamlined and efficient hardware system design.

[0250] The management system of this invention adopts a layered modular design concept. Each functional module includes, but is not limited to, a transport layer protocol stack, a node identification module, and a sensor data recording and management module, all of which communicate and interact using standardized interfaces. The modules maintain high functional cohesion and low interface coupling, supporting module replacement and functional expansion. This architectural design allows the system to flexibly adapt to changes in management needs of varying scales. When functional upgrades are required, only specific modules need to be iteratively updated, greatly improving the overall compatibility and maintainability of the system.

[0251] By structurally allocating interfaces such as I2C, ADC, and GPIO, a clear and scalable hardware interface foundation is provided for the implementation of Sensor Data Recording (SDR) functionality in multi-node systems, ensuring the independence of sensor information acquisition at each node and the unified management of common information. Through a combined architecture of "node-private SDR" and "common SDR," unified management of sensor data and node-isolated access logic are achieved in multi-node systems. This ensures the independence and integrity of sensor data at each node while avoiding duplicate storage and acquisition of common data, thus improving system maintainability and data consistency.

[0252] This invention achieves centralized acquisition and unified processing of multi-node sensor data records through an innovative unified sensor data recording management mechanism. The system supports batch configuration and real-time monitoring of threshold parameters for dual-node sensors via IPMI v2.0 and the standard Redfish protocol interface, simplifying the operation and maintenance steps of the traditional dual-BMC architecture while reducing configuration error rates. This technology significantly improves the work efficiency of data center operation and maintenance personnel and reduces operational complexity. Furthermore, through Dbus middleware design and IPMI and Redfish interface design, it ensures accurate acquisition of sensor data recording information of the corresponding nodes under different access methods, while maintaining data isolation and access security.

[0253] By managing multi-node SDR information through a single management controller, sensor information from multiple motherboards is unified under one management controller. Out-of-band SDR information for any single node can be obtained via the IPMI / Redfish interface, and batch configuration of dual-node sensor thresholds is supported via the IPMI / Redfish protocol, reducing the complexity of operation and maintenance.

[0254] The preceding text described a sensor data processing method for a multi-node server used as a management controller in a multi-node server. This embodiment also provides a sensor data processing method for a multi-node server used as a host node in a multi-node server. The method includes:

[0255] Obtain the request to acquire sensor data that is to be sent to the management controller;

[0256] Send a request to the management controller to acquire sensor data; so that the management controller can acquire target data from the private sensor database and / or public sensor database of the target host node according to the request, and respond to the request using the target data;

[0257] Receive target data sent by the management controller to characterize the response request.

[0258] The sensor data processing method for host nodes in a multi-node server provided in this embodiment has the same or corresponding technical features as the sensor data processing method for management controllers in a multi-node server described above. The embodiments of the sensor data processing method for management controllers in a multi-node server have been described in detail above, and the embodiments of the sensor data processing method for host nodes in a multi-node server will not be repeated here, and the effects are the same as above.

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

[0260] This invention also provides a sensor data processing device for a multi-node server, comprising:

[0261] The first receiving module is used to receive a request representing the acquisition of sensor data from the target host node;

[0262] The first acquisition module is used to acquire target data from the node private sensor database and / or public sensor database corresponding to the target host node according to the request; wherein, the node private sensor database is used to store the sensor data of the corresponding host node, and the public sensor database is used to store the sensor data of the shared module;

[0263] The response module is used to respond to requests using the target data.

[0264] Embodiments of the present invention also provide a sensor data processing device for a multi-node server, comprising:

[0265] The second acquisition module is used to acquire a request to be sent to the management controller to represent the acquisition of sensor data;

[0266] The sending module is used to send a request to the management controller to acquire sensor data; so that the management controller can acquire target data from the private sensor database and / or public sensor database of the target host node according to the request, and respond to the request using the target data.

[0267] The second receiving module is used to receive target data sent by the management controller to characterize the response request.

[0268] For a description of the features in the embodiment corresponding to the sensor data processing device of the multi-node server, please refer to the relevant description in the embodiment corresponding to the sensor data processing method of the multi-node server, which will not be repeated here.

[0269] Embodiments of the present invention also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the sensor data processing method for a multi-node server.

[0270] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above embodiments of the sensor data processing method for a multi-node server.

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

[0272] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the sensor data processing method for a multi-node server.

[0273] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the sensor data processing method for a multi-node server.

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

[0275] The foregoing has provided a detailed description of a sensor data processing method for a multi-node server and a multi-node server provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.< / bmcip>

Claims

1. A multi-node server, comprising a management controller and host nodes, characterized in that, The management controller manages a shared module and at least two host nodes; the management controller is equipped with a node private sensor database and a public sensor database, and the node private sensor database corresponds one-to-one with the host node; wherein, the node private sensor database is used to store sensor data of the corresponding host node, and the public sensor database is used to store sensor data of the shared module; the shared module includes sensors; The management controller is configured to receive a request representing the acquisition of sensor data from a target host node, acquire target data from the node's private sensor database and / or the public sensor database corresponding to the target host node according to the request, and respond to the request using the target data; The management controller also includes a total sensor database; both the node private sensor database and the public sensor database have data links with the total sensor database. The overall sensor database is configured with multiple storage areas, and each storage area corresponds one-to-one with a host node. The storage area is used to store the sensor data of its corresponding host node. The sensor data of the host node includes data from the node's private sensor database and data from the public sensor database, so as to realize unified management of sensor data and node-isolated access logic in the dual-node system. Before retrieving target data from the node-private sensor database corresponding to the target host node and / or the public sensor database according to the request, the method further includes: Determine the target interface name based on the request; The target host node from which the request originates is determined based on the target interface name and the pre-established mapping relationship between interface names and host nodes; The step of determining the target interface name according to the request includes: If the request is found to be inconsistent with the rules of the target protocol, then a pre-established protocol conversion rule is obtained; wherein, the target protocol is a protocol used for inter-process communication. The request is converted according to the protocol conversion rules to obtain a request that conforms to the target protocol; The target interface name is determined based on the request conforming to the target protocol; The request is a request conforming to the first management bus interface protocol, and the target protocol is the message bus communication protocol; wherein, the first management bus interface is the intelligent platform management interface; Obtaining pre-established protocol conversion rules includes: Obtain the interface name and object name set according to the source of the request, and obtain the function used to characterize the functionality to be implemented in the request; The message header of the message bus communication protocol is determined based on the interface name, object name, and the function used to characterize the requested functionality. Add a data type identifier before the field representing the logical unit, the field representing the network function code, and the field representing the operation to be performed in the request. In the request, an array type and an array length field are added sequentially before the data field to serve as the function signature of the message bus communication protocol. Obtaining the interface name and object name set according to the source of the request includes: If the source of the request is detected to be in-band, obtain the in-band interface name and host node name from which the request came, and set the interface name and object name according to the in-band interface name and host node name; If the source of the request is detected to be out-of-band, obtain the port number assigned to the network protocol from which the request originated, and set the interface name and object name according to the port number; Responding to the request using the target data includes: Obtain the object path of the distributed bus middleware; the hierarchy in the management controller, from bottom to top, is the information acquisition layer, message bus layer, and command layer. The target host node is determined based on the object path of the distributed bus middleware, so that the target host node can be determined directly based on the object path name of the distributed bus middleware without further differentiation of the target host node at the command layer. The target data is sent to the target host node in response to the request.

2. The multi-node server according to claim 1, characterized in that, The management controller in the multi-node server is equipped with multiple sets of first interface controllers for interacting with host nodes, and a set of second interface controllers for connecting to the shared module; one host node is connected to a set of first interface controllers; a preset interface on the first interface controller is connected to the target sensor on its corresponding host node, and a preset interface on the second interface controller is connected to the target sensor on the shared module.

3. The multi-node server according to claim 2, characterized in that, The target sensors on the host node include various types of sensors mounted on the board; wherein, the various types of sensors include at least one or more of the following: temperature sensors, voltage sensors, and combinations of sensors with signal acquisition and control functions; The first interface controller includes a peripheral interface controller, an analog-to-digital converter controller, and a general-purpose input / output controller; The first interface controller is a peripheral interface controller, and the peripheral interface on the peripheral interface controller is connected to the temperature sensor on its corresponding host node; The first interface controller is an analog-to-digital converter controller, and the analog-to-digital conversion interface on the analog-to-digital converter controller is connected to the voltage sensor on its corresponding host node; The first interface controller is a general-purpose input / output controller, and the general-purpose input / output interface on the general-purpose input / output controller is connected to the sensor with signal acquisition and control functions on its corresponding host node.

4. The multi-node server according to claim 2, characterized in that, The second interface controller includes a peripheral interface controller and a general-purpose input / output controller; The target sensors on the shared module include at least one or more of the following: chassis temperature sensor, fan speed sensor, power parameter sensor, and a combination of sensors with signal acquisition and control functions; The second interface controller is a peripheral interface controller, and the peripheral interfaces on the peripheral interface controller are respectively connected to the chassis temperature sensor, fan speed sensor and power parameter sensor on the common module; The second interface controller is a general-purpose input / output controller, and the general-purpose input / output interface on the general-purpose input / output controller is connected to the sensor with signal acquisition and control functions on the shared module.

5. A sensor data processing method for a multi-node server, characterized in that, A management controller is applied in a multi-node server. The management controller manages a shared module and at least two host nodes. The management controller deploys a node-private sensor database and a public sensor database, with each node-private sensor database corresponding to a host node. The shared module includes sensors. The management controller also includes a total sensor database. Data links exist between the node-private sensor database and the public sensor database and the total sensor database. The total sensor database has multiple storage areas, each corresponding to a host node. These storage areas store sensor data for their respective host nodes. The sensor data for each host node includes data from its corresponding node-private sensor database and data from the public sensor database, enabling unified management and node-isolated access logic for sensor data in a dual-node system. The method includes: Receive a request to acquire sensor data representing the target host node; According to the request, target data is obtained from the node private sensor database corresponding to the target host node and / or the public sensor database; wherein, the node private sensor database is used to store the sensor data of the corresponding host node, and the public sensor database is used to store the sensor data of the shared module; The request is responded to using the target data; Before retrieving target data from the node-private sensor database corresponding to the target host node and / or the public sensor database according to the request, the method further includes: Determine the target interface name based on the request; The target host node from which the request originates is determined based on the target interface name and the pre-established mapping relationship between interface names and host nodes; The step of determining the target interface name according to the request includes: If the request is found to be inconsistent with the rules of the target protocol, then a pre-established protocol conversion rule is obtained; wherein, the target protocol is a protocol used for inter-process communication. The request is converted according to the protocol conversion rules to obtain a request that conforms to the target protocol; The target interface name is determined based on the request conforming to the target protocol; The request is a request conforming to the first management bus interface protocol, and the target protocol is the message bus communication protocol; wherein, the first management bus interface is the intelligent platform management interface; Obtaining pre-established protocol conversion rules includes: Obtain the interface name and object name set according to the source of the request, and obtain the function used to characterize the functionality to be implemented in the request; The message header of the message bus communication protocol is determined based on the interface name, object name, and the function used to characterize the requested functionality. Add a data type identifier before the field representing the logical unit, the field representing the network function code, and the field representing the operation to be performed in the request. In the request, an array type and an array length field are added sequentially before the data field to serve as the function signature of the message bus communication protocol. Obtaining the interface name and object name set according to the source of the request includes: If the source of the request is detected to be in-band, obtain the in-band interface name and host node name from which the request came, and set the interface name and object name according to the in-band interface name and host node name; If the source of the request is detected to be out-of-band, obtain the port number assigned to the network protocol from which the request originated, and set the interface name and object name according to the port number; Responding to the request using the target data includes: Obtain the object path of the distributed bus middleware; the hierarchy in the management controller, from bottom to top, is the information acquisition layer, message bus layer, and command layer. The target host node is determined based on the object path of the distributed bus middleware, so that the target host node can be determined directly based on the object path name of the distributed bus middleware without further differentiation of the target host node at the command layer. The target data is sent to the target host node in response to the request.

6. The sensor data processing method for a multi-node server according to claim 5, characterized in that, Obtaining target data from the node's private sensor database corresponding to the target host node and / or the public sensor database according to the request includes: Obtain the target storage area of ​​the target host node in the overall sensor database; The sensor data in the node private sensor database corresponding to the target host node, as well as the sensor data in the public sensor database, are transferred to the target storage area. The target data is retrieved from the target storage area according to the request.

7. The sensor data processing method for a multi-node server according to claim 5, characterized in that, Before receiving a request to acquire sensor data representing the target host node, the process also includes: Collect sensor data from the host node and store the sensor data collected from the host node in the node's private sensor database corresponding to the host node; Collect sensor data from the shared module and store the sensor data from the shared module in a common sensor database; The data in the host node's private sensor database and the data in the public sensor database are stored in the storage area of ​​the host node corresponding to the total sensor database. After receiving a request to acquire sensor data representing the target host node, the method further includes: Obtain the target storage area of ​​the target host node in the overall sensor database; The target data is retrieved from the target storage area according to the request.

8. The sensor data processing method for a multi-node server according to claim 7, characterized in that, The step of retrieving the target data from the target storage area according to the request includes: The root path of the target host node is obtained through a distributed bus middleware. Obtain the bus names of multiple sensors under the root path based on the root path of the target host node; Obtain the complete object path of the sensor based on its bus name; The target data is obtained from the target storage area based on the complete object path of the sensor.

9. The sensor data processing method for a multi-node server according to claim 8, characterized in that, The request is a request conforming to the first management bus interface protocol, and before obtaining the pre-set root path of the target host node through the distributed bus middleware, it also includes: Obtain the target port number from the request, and determine the target port based on the target port number; The network daemon process corresponding to the target port receives and parses the request, and then proceeds to the step of obtaining the root path of the target host node through the distributed bus middleware.

10. The sensor data processing method for a multi-node server according to claim 9, characterized in that, After retrieving the target data from the target storage area based on the sensor's complete object path, the process further includes: The target data is encapsulated according to the format of the first management bus interface protocol; Obtain the object path of the distributed bus middleware; The target host node is determined based on the object path of the distributed bus middleware; The encapsulated target data is returned to the target host node through the target port.

11. The sensor data processing method for a multi-node server according to claim 8, characterized in that, The request is a request conforming to the second management bus interface protocol, and before obtaining the pre-set root path of the target host node through the distributed bus middleware, it also includes: Obtain the Uniform Resource Locator (URL) corresponding to the request conforming to the second management bus interface protocol; The path parameters in the Uniform Resource Locator are parsed by the web service daemon to obtain the identifier of the target host node; then the step of obtaining the pre-set root path of the target host node through the distributed bus middleware is performed.

12. The sensor data processing method for a multi-node server according to claim 11, characterized in that, After retrieving the target data from the target storage area based on the sensor's complete object path, the process further includes: The target data is converted into data conforming to the format specified by the second management bus interface protocol; Obtain the object path of the distributed bus middleware; The target host node is determined based on the object path of the distributed bus middleware; The target data obtained after format conversion is returned to the target host node.

13. The sensor data processing method for a multi-node server according to any one of claims 5 to 12, characterized in that, The step of determining the target host node from which the request originates based on the target interface name and the pre-established mapping relationship between interface names and host nodes includes: The target interface name is compared with the mapping relationship between the interface name and the host node name obtained from the memory to determine the host node name corresponding to the target interface name; The target host node from which the request originates is determined based on the host node name corresponding to the target interface name; wherein, the interface name and the host node name exist in the memory in the form of key-value pairs.

14. A sensor data processing method for a multi-node server, characterized in that, This system is applied to host nodes in a multi-node server. A management controller in the multi-node server manages a shared module and at least two host nodes. The management controller deploys a node-private sensor database and a public sensor database, with each node-private sensor database corresponding to a host node. The shared module includes sensors. The management controller also includes a total sensor database. Both the node-private sensor database and the public sensor database have data links to the total sensor database. The total sensor database has multiple storage areas, each corresponding to a host node. These storage areas store sensor data from their respective host nodes. The sensor data from each host node includes data from its corresponding node-private sensor database and data from the public sensor database, enabling unified management and node-isolated access logic for sensor data in a dual-node system. The method includes: Obtain the request to acquire sensor data that is to be sent to the management controller; A request to acquire sensor data is sent to the management controller; so that the management controller can acquire target data from the node private sensor database corresponding to the target host node and / or the public sensor database according to the request, and respond to the request using the target data; Receive target data sent by the management controller to characterize the response request; Before retrieving target data from the node-private sensor database corresponding to the target host node and / or the public sensor database according to the request, the method further includes: Determine the target interface name based on the request; The target host node from which the request originates is determined based on the target interface name and the pre-established mapping relationship between interface names and host nodes; The step of determining the target interface name according to the request includes: If the request is found to be inconsistent with the rules of the target protocol, then a pre-established protocol conversion rule is obtained; wherein, the target protocol is a protocol used for inter-process communication. The request is converted according to the protocol conversion rules to obtain a request that conforms to the target protocol; The target interface name is determined based on the request conforming to the target protocol; The request is a request conforming to the first management bus interface protocol, and the target protocol is the message bus communication protocol; wherein, the first management bus interface is the intelligent platform management interface; Obtaining pre-established protocol conversion rules includes: Obtain the interface name and object name set according to the source of the request, and obtain the function used to characterize the functionality to be implemented in the request; The message header of the message bus communication protocol is determined based on the interface name, object name, and the function used to characterize the requested functionality. Add a data type identifier before the field representing the logical unit, the field representing the network function code, and the field representing the operation to be performed in the request. In the request, an array type and an array length field are added sequentially before the data field to serve as the function signature of the message bus communication protocol. Obtaining the interface name and object name set according to the source of the request includes: If the source of the request is detected to be in-band, obtain the in-band interface name and host node name from which the request came, and set the interface name and object name according to the in-band interface name and host node name; If the source of the request is detected to be out-of-band, obtain the port number assigned to the network protocol from which the request originated, and set the interface name and object name according to the port number; Responding to the request using the target data includes: Obtain the object path of the distributed bus middleware; the hierarchy in the management controller, from bottom to top, is the information acquisition layer, message bus layer, and command layer. The target host node is determined based on the object path of the distributed bus middleware, so that the target host node can be determined directly based on the object path name of the distributed bus middleware without further differentiation of the target host node at the command layer. The target data is sent to the target host node in response to the request.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the sensor data processing method of the multi-node server as described in any one of claims 5 to 14 when executing the computer program.

16. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the sensor data processing method of the multi-node server as described in any one of claims 5 to 14.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the sensor data processing method of the multi-node server as described in any one of claims 5 to 14.

Images