A method and apparatus for a BMC to manage a JBOG

Abstract

The application provides a method and device for BMC to manage JBOG, and belongs to the field of server hardware monitoring and management. The method provided by the application comprises the following steps: the BMC starts a JBOG management service, and listens to at least one preset physical link address; in response to detecting a JBOG in-place signal on the preset physical link address, the BMC acquires a data packet from the JBOG through the physical link; the BMC loads the data packet into the JBOG management service, and calls an information acquisition instruction through a preset unified interface to acquire hardware information of the JBOG; and the BMC monitors and manages the JBOG according to the acquired hardware information. The method and device for BMC to manage JBOG provided by the application can realize plug-and-play hardware monitoring of various JBOGs by the BMC.

Description

Technical Field

[0001] This application relates to the field of server hardware monitoring and management technology, and in particular to a method and apparatus for BMC to manage JBOG. Background Technology

[0002] With the ever-increasing computing demands of data centers, the hardware expansion capabilities within a single server chassis are no longer sufficient to meet the demands of high-performance computing, artificial intelligence training, and large-scale storage scenarios for GPUs, hard drives, network interface cards (NICs), and other devices. Therefore, the industry commonly adopts an architecture where external expansion device groups (tail-end) are connected to the server mainframe (head unit) via dedicated cables to flexibly expand server hardware resources. These external expansion device groups are typically called JBOGs (Just a Bunch of GPUs / Drives), and they can integrate multiple GPUs, hard drives, network interface cards, and other components, providing the server with additional computing, storage, and networking capabilities. The server mainframe needs to monitor and manage the hardware information of each component within the JBOG in real time to ensure stable system operation and fault early warning.

[0003] In existing systems consisting of servers and JBOGs, the hardware information monitoring function of the JBOG is typically implemented by the Baseboard Management Controller (BMC) within the server host. The BMC and JBOG establish a communication connection via a physical link (such as an I2C bus). Currently, the BMC acquires JBOG hardware information primarily through static adaptation and hard-coded access: the BMC firmware pre-programs the hardware information acquisition method for specific JBOG models, including the I2C slave address, register offset address, data parsing format, and conversion formula for each monitored component. During system operation, the BMC obtains the raw data by directly sending read commands to the fixed I2C slave address, and then converts the raw data into monitoring information such as temperature, power consumption, and status according to the pre-defined parsing rules.

[0004] However, existing methods have significant shortcomings. First, the cost of re-adaptation is high. Whenever JBOG hardware changes, such as replacing GPUs or hard drive backplanes from different manufacturers or with different models, BMC firmware developers need to modify the I2C access code, adjust the data parsing logic, recompile the firmware, and flash it to the server motherboard according to the new hardware manual. This process is usually time-consuming and involves collaboration among multiple departments, including hardware, firmware, and testing, increasing maintenance costs and business downtime. Second, flexibility is poor. Because BMC firmware is strongly tied to specific JBOG models, the same BMC cannot dynamically support JBOG devices from different manufacturers and with different configurations. When data centers replace or upgrade JBOGs, they often need to simultaneously upgrade the server BMC firmware, limiting the flexibility of hardware selection and deployment efficiency. In addition, as the number of JBOG models and configurations increases, the BMC firmware needs to maintain a large amount of adaptation code for different hardware, leading to firmware code redundancy, maintenance difficulties, and compatibility issues. Therefore, how to achieve compatible acquisition and unified monitoring of different JBOG hardware information by the BMC without modifying the BMC firmware or re-flashing the program has become an urgent problem to be solved. Summary of the Invention

[0005] In view of this, this application provides a method and apparatus for BMC to manage JBOG, which enables BMC to acquire and uniformly monitor JBOG hardware information from different manufacturers and with different configurations without modifying the BMC firmware or re-flashing the program, thereby reducing adaptation costs and improving system flexibility and maintenance efficiency.

[0006] Specifically, this application is implemented through the following technical solution:

[0007] The first aspect of this application provides a method for BMC to manage JBOG, the method comprising:

[0008] BMC starts the JBOG management service and listens on at least one preset physical link address;

[0009] In response to the detection of a JBOG presence signal on the preset physical link address, the BMC obtains a data packet from the JBOG through the physical link; wherein the data packet is pre-stored by the JBOG and encapsulates an information acquisition instruction for obtaining the JBOG hardware information;

[0010] The BMC loads the data packet into the JBOG management service and calls the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein, the interface name of the unified interface is independent of the hardware model of the JBOG.

[0011] The BMC monitors and manages the JBOG based on the acquired hardware information.

[0012] A second aspect of this application provides a device for BMC to manage JBOG, the device including a monitoring module, a connection module, a receiving module, a processing module, and a management module;

[0013] The monitoring module is used by BMC to start the JBOG management service and monitor at least one preset physical link address;

[0014] The connection module is used to establish a connection with the JBOG in response to detecting a JBOG presence signal on the preset physical link address.

[0015] The receiving module is used to obtain data packets from the JBOG through the physical link after the connection is established. The data packets are encapsulated with information acquisition instructions for obtaining hardware information of the JBOG.

[0016] The processing module is used to load the data packet into the JBOG management service and call the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein the interface name of the unified interface is independent of the hardware model of the JBOG.

[0017] The management module is used to monitor the JBOG based on the acquired hardware information.

[0018] The method and apparatus for BMC management of JBOGs provided in this application involve the BMC initiating a JBOG management service and listening to a preset physical link address. Upon detecting a JBOG presence signal, the BMC dynamically acquires a data packet pre-stored on the JBOG end, encapsulating information retrieval instructions, and loads this data packet into the JBOG management service. It then uses a preset unified interface to call instructions to obtain JBOG hardware information, thereby achieving monitoring and management of the JBOG. Overall, this method eliminates the need for the BMC to pre-code hardware access logic related to specific JBOG models in the firmware, enabling monitoring of different JBOGs. This reduces the compatibility coupling between the BMC and the JBOG, and improves the system's compatibility with various JBOGs. Specifically, by listening to the preset physical link address and responding to the presence signal, the BMC can automatically detect the physical access of the JBOG and start the subsequent management process without manual configuration. By dynamically obtaining data packets containing information retrieval instructions from the JBOG, the underlying access methods required to obtain hardware information are provided by the JBOG side, and the BMC does not need to know the specific access details of the internal hardware of the JBOG in advance. By calling the information retrieval instructions through a preset unified interface, and the interface name of this unified interface is independent of the hardware model of the JBOG, the management call logic on the BMC side remains stable and unified, unaffected by changes in the specific model or configuration of the accessed JBOG. Thus, it can achieve compatible acquisition and monitoring management of different JBOG hardware information without modifying the BMC firmware. Attached Figure Description

[0019] Figure 1 A flowchart of an embodiment of the BMC management JBOG method provided in this application;

[0020] Figure 2 This is a schematic diagram of the second embodiment of the device for managing JBOG using BMC provided in this application. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0024] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0025] Example 1

[0026] Figure 1 This is a flowchart of an embodiment of the BMC management JBOG method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0027] S101, BMC starts the JBOG management service and listens to at least one preset physical link address.

[0028] It's important to note that the BMC (Baseboard Management Controller) is an independent management chip on the server motherboard. It can perform out-of-band monitoring and management of system hardware whether the server is powered on or off, and can operate independently without relying on the server's operating system. JBOG (Just a Bunch Of GPUs / Drives) refers to an expansion unit (also known as the tail section) consisting of a group of GPUs or hard drives and other expansion devices. Its internal hardware information, such as GPU temperature, power consumption, power status, and hard drive health status, needs to be monitored and managed through the server's BMC.

[0029] The preset physical link address in this step specifically refers to the preset I2C bus address. The I2C bus (Inter-Integrated Circuit) is a bidirectional two-wire synchronous serial bus consisting of a data line SDA and a clock line SCL. It is suitable for short-distance, low-speed communication between devices. Each preset physical link address corresponds to an independent I2C communication link, which is used to realize signal transmission and data interaction between the BMC and a specific JBOG physical connection port.

[0030] Specifically, the BMC listens to at least one preset physical link address, including:

[0031] (1) The BMC listens to multiple preset physical link addresses, and each preset physical link address corresponds to a physical connection port of JBOG.

[0032] It should be noted that after starting the JBOG management service, the BMC will simultaneously listen to multiple preset I2C addresses according to a pre-configured strategy. Each preset I2C address corresponds one-to-one with a JBOG physical connection port. This application supports multiple JBOGs simultaneously accessing the same BMC for management. The specific physical connection method is as follows: a retimer card is configured on the head unit (server host), which is inserted into the riser card on the head unit; a retimer card is also configured on the tail unit (JBOG); the head unit retimer card and the tail unit retimer card are connected by a dedicated data cable to form a physical link. Each connection cable is assigned a unique I2C address. The BMC achieves parallel listening to multiple physical connection ports by presetting these I2C addresses (e.g., 0x50, 0x51, 0x52, etc.) in the firmware configuration file.

[0033] With this configuration, different JBOGs connect to the BMC through different physical connection ports, corresponding to different I2C addresses. This enables independent identification and management of multiple JBOGs, avoiding signal conflicts and communication chaos caused by multiple JBOGs sharing the same address. Simultaneously, the multi-address preset monitoring provides a hardware-level isolation foundation for subsequent multi-tail parallel management.

[0034] (2) When the JBOG signal is detected simultaneously on multiple preset physical link addresses, the BMC establishes a connection with each JBOG and independently executes the steps of acquiring data packets, loading, and calling information acquisition instructions for each JBOG.

[0035] BMC periodically scans the multiple preset physical link addresses monitored in step (1). When a presence signal sent by JBOG is detected on one or more addresses, BMC confirms that a JBOG has been connected to the corresponding port and establishes an independent communication connection with each presence JBOG.

[0036] Specifically, the presence signal detection method relies on the I2C bus protocol. The BMC periodically sends I2C probe commands (such as the i2cdetect tool) to scan each preset address. If the device at the corresponding address returns an acknowledgment response, it is determined that a JBOG presence signal exists at that address. This presence signal indicates that the JBOG tail unit has been physically connected and completed power-on initialization, and its internal CPLD (Complex Programmable Logic Device) or microcontroller is ready to interact with the BMC via this I2C address. When multiple preset addresses simultaneously detect presence signals, the BMC's JBOG management service creates an independent management session thread for each presence address. Each thread runs independently according to the exact same processing flow, without interfering with each other.

[0037] It should be noted that this independent processing method enables the parallel management of multiple JBOGs, avoiding data interaction conflicts between multiple JBOGs. Even if a communication failure or unexpected disconnection occurs in one JBOG, it will not affect the normal monitoring of other JBOGs by the BMC. This solves the problem that the current BMC is difficult to simultaneously support multiple JBOGs with different configurations.

[0038] (3) The BMC distinguishes and manages the hardware information of different JBOGs based on the physical link address of each JBOG.

[0039] It's important to note that BMC uses the preset physical link address corresponding to each JBOG as its unique identifier within the system. Throughout the process, this address is consistently used as an index to differentiate and manage the hardware information of different JBOGs. Within BMC's internal data structure, each managed JBOG instance uses its physical link address as a unique index key. All hardware information obtained from this JBOG, such as GPU temperature, power consumption, PSU status, and hard drive health, is stored in association with this address. In the web management interface or command-line management tool, hardware information is displayed in groups according to physical port location. For example, a JBOG connected to I2C address 0x50 is labeled "JBOG Port 1," address 0x51 corresponds to "JBOG Port 2," and so on. When BMC records system event logs, the log entries also carry the corresponding physical link address information, facilitating maintenance personnel to quickly locate the specific tail position of the abnormal event. This differentiated management method, which uses physical link addresses as identifiers, allows BMC to manage multiple JBOGs independently without modifying firmware or maintaining separate adaptation code for each JBOG.

[0040] By enabling the BMC to enter the JBOG management-ready state in this way, continuously monitoring the preset physical link address, and promptly detecting the physical access presence signal of the JBOG, a foundation is laid for subsequent operations. The BMC does not need to know the specific model or configuration of the accessed JBOG in advance; it only needs to monitor the preset physical link address to detect the JBOG access.

[0041] S102. In response to detecting a JBOG presence signal at the preset physical link address, the BMC obtains a data packet from the JBOG through the physical link; wherein the data packet is pre-stored by the JBOG and encapsulates an information acquisition instruction for obtaining the JBOG hardware information.

[0042] It should be noted that the data packet refers to a binary format file (such as xxx.bin format) pre-prepared and stored in the Flash memory of the JBOG tail unit. This data packet differs from traditional static hardware description information (such as device ID, manufacturer name, etc.); it encapsulates information retrieval instructions for obtaining JBOG hardware information. These instructions are a set of commands that can be executed at the BMC (Brain Control Center), covering operations for reading information such as temperature, power consumption, and status of various components within the JBOG. Their underlying implementation is typically I2C bus operation commands, pre-written by each hardware manufacturer according to the I2C specifications of their components. The Flash memory is a non-volatile storage chip configured at the JBOG tail unit, used to pre-store the aforementioned data packet. This ensures that the data is not lost after the JBOG is powered off, guaranteeing that the BMC can read the complete data packet content each time the JBOG is powered on.

[0043] In step S101, after the BMC has detected the JBOG's presence signal and established a physical connection with it, in this step, the BMC reads pre-stored data packets from the JBOG via the established physical link and converts the information retrieval instructions in the data packets into a form that the BMC can call locally, providing instruction support for subsequent unified interface calls and hardware information retrieval. Through this setup, the JBOG pre-encapsulates its own hardware information retrieval method into a data packet and stores it in its local Flash memory. The BMC dynamically reads and loads this data packet when the JBOG connects, eliminating the need to pre-code any access logic related to a specific JBOG model in the BMC firmware, thus achieving decoupling between the BMC and the JBOG.

[0044] Specifically, the BMC obtains data packets from the JBOG via the physical link, including:

[0045] (1) The BMC reads the binary format data packets stored in the Flash of the JBOG segment by segment using the I2C command.

[0046] It should be noted that the specific reading process is as follows: First, the BMC needs to obtain the access address of the Flash memory on the JBOG side. Preferably, the CPLD at the tail end of the JBOG can provide the BMC with the I2C slave device address information of the Flash memory. The BMC obtains the base address and capacity of the Flash by accessing specific registers of the CPLD. Second, the BMC uses I2C read commands to read the Flash content in segments. Since the amount of data transmitted in a single I2C bus is limited, the BMC adopts a segment-by-segment reading method, reading a fixed-length data segment at a time, and continuously sending I2C read commands (such as the i2ctransfer command) until the entire data packet is read. During the reading process, the BMC maintains the offset address pointer of the current read to ensure the continuity and integrity of the data segments. Finally, the BMC concatenates and reassembles the read data segments in memory to restore a complete binary format data packet file.

[0047] The I2C bus has limitations on the length of data transmitted in a single transaction due to protocol constraints, and the BMC has limited memory resources. Segmented reading avoids consuming excessive bus bandwidth and memory space at once. Furthermore, segmented reading combined with offset address pointers allows for resumed transmission or error retries in case of communication anomalies during the reading process, improving the reliability of data acquisition.

[0048] (2) The BMC parses the data packet, generates a plaintext string, and converts the plaintext string into a locally callable shared library file.

[0049] It should be noted that BMC parses the binary data packet obtained in step (1), extracts the encapsulated instruction content, and converts it into a shared library file format that the BMC operating system can recognize and dynamically load, such as a .so file in Linux. The specific parsing and conversion process includes: First, BMC parses the binary data packet according to the preset data packet format specification. The data packet contains protocol header information and payload information. The protocol header may contain fields such as version number, vendor ID, data packet length, and checksum; the payload encapsulates the encoded information retrieval instruction content. BMC extracts the data packet content field by field according to the preset parsing rules and restores it to plaintext string form. Second, BMC converts the parsed plaintext string into a shared library file. In one embodiment of this application, the plaintext string contains the source code or intermediate representation of the information retrieval instruction. BMC calls the local compilation toolchain or script interpreter to compile or convert it into a dynamic shared library file. This shared library file encapsulates the executable code of all information retrieval instructions. BMC can load it into the process space of the JBOG management service through the dynamic loading interface provided by the operating system. Finally, the shared library files are placed in a designated directory in the BMC file system for use by subsequent unified interface calls.

[0050] It's important to note that the binary data packets use a hardware-independent storage format, while the shared library files are in a format recognizable and executable by the BMC operating system. A conversion process achieves adaptation from storage format to execution format, enabling the instructions pre-stored on the JBOG side to be executed on the BMC side. Simultaneously, this design isolates the BMC from the underlying hardware details of the JBOG. The information retrieval instructions encapsulated in the data packets are written by the JBOG manufacturer according to its hardware specifications, containing specific I2C addresses, register offsets, data conversion formulas, and other low-level details. The BMC loads the shared library files and calls their instruction interfaces, without needing to be aware of these low-level details; it only needs to obtain the final hardware information. This approach makes the BMC's management logic completely independent of the JBOG hardware model. When the JBOG hardware changes, only the data packets in the JBOG's Flash memory need to be updated; no modifications are required on the BMC side.

[0051] Through the above steps (1) and (2), BMC does not need to know the hardware model and I2C access details of JBOG in advance. It can obtain the monitoring capabilities provided by JBOG through standard I2C read operations and format conversion processes, laying the instruction foundation for subsequent unified interface call execution.

[0052] S103. The BMC loads the data packet into the JBOG management service and calls the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein, the interface name of the unified interface is independent of the hardware model of the JBOG.

[0053] It should be noted that loading refers to the BMC loading the shared library file (.so file) generated in S102 into the address space of the JBOG management service process through the dynamic loading mechanism provided by the operating system, making the information retrieval instructions in it executable code that the BMC can call. The unified interface refers to a series of standardized function interfaces preset by the BMC for calling the JBOG hardware information retrieval function. The interface names follow preset naming rules and are independent of the specific hardware model of JBOG.

[0054] To ensure that the data packets provided by the JBOG are compatible with the current firmware version of BMC and to avoid operational abnormalities due to version inconsistencies, BMC first performs a version verification process before officially loading the data packets.

[0055] Specifically, the data packet also contains version number information; before the BMC loads the data packet into the JBOG management service, it includes:

[0056] (1) The BMC parses the data packet and extracts the version number information.

[0057] It should be noted that in step S102, the BMC has already parsed the binary data packet into a plaintext string. In this step, the BMC further extracts the version number information from the parsed content. When the data packet is prepared, a version number field is pre-written into its protocol header to identify the BMC firmware version range or protocol version to which the data packet applies. The BMC locates the version number field in the protocol header according to the preset data packet format specification, reads and records the version number information for subsequent comparison.

[0058] (2) The BMC compares the version number information with the locally preset supported version. If the versions do not match, it stops loading and records the system event log.

[0059] It should be noted that the System Event Log (SEL) is a standard logging mechanism used by BMC to record system hardware events in accordance with the IPMI (Intelligent Platform Management Interface) specification. It is used to store and trace hardware event information such as over-temperature, abnormal voltage, and component offline.

[0060] It should be noted that the BMC maintains a list of supported versions in advance, recording the range of data packet versions compatible with the current BMC firmware. The BMC compares the version number information extracted in step (1) with this list of supported versions: if the version number is within the supported range, the version is determined to match, and the subsequent loading steps continue; if the version number is not within the supported range, the version is determined to be incompatible, the BMC stops the current loading process, and records a version incompatibility event in the system event log. This event includes information such as the JBOG physical link address and data packet version number, which facilitates troubleshooting by maintenance personnel. By setting up the version verification mechanism, operational abnormalities or monitoring failures caused by incompatibility between the JBOG data packet and the BMC firmware version can be effectively prevented, thus improving the robustness and maintainability of the system.

[0061] After the version verification is passed, BMC further identifies and verifies the identity and configuration characteristics of the JBOG to determine whether the JBOG is allowed to access the current system.

[0062] Furthermore, the BMC loads the data packet into the JBOG management service, including:

[0063] (1) The BMC reads the JBOG identification information contained in the data packet.

[0064] It should be noted that, in addition to the version number information, the protocol header of the data packet also contains JBOG identification information. The JBOG identification information may include information such as the tail serial number, manufacturer ID, supported component types and quantities, etc., which are used to uniquely identify the identity and configuration characteristics of the JBOG. When parsing the data packet, the BMC extracts the above identification information simultaneously for subsequent verification.

[0065] (2) The BMC verifies whether the JBOG identification information matches the local configuration.

[0066] It should be noted that the BMC can preset a list of allowed JBOG vendors or a configuration policy. The BMC will compare and verify the JBOG identification information extracted in step (1) with the local configuration, such as verifying whether the vendor ID is in the allowed list, or verifying whether the component type is supported by the current BMC firmware.

[0067] (3) If a match is found, the information retrieval instruction in the data packet is registered in the call list of the JBOG management service.

[0068] After successful verification, BMC loads the shared library files generated in S102 into the JBOG management service's process space via a dynamic loading interface (such as the dlopen function), and registers the information retrieval functions exported from the shared library into the management service's internal call list one by one. During the registration process, BMC establishes a mapping relationship between a unified interface name and the specific function addresses in the shared library, ensuring that subsequent calls using the unified interface name can correctly route to the corresponding information retrieval instruction. If the verification fails, BMC also stops loading and records the system event log.

[0069] In addition, the interface name of the preset unified interface includes a component type identifier, a component serial number identifier, and an information type identifier, wherein the component serial number identifier is reserved according to the maximum number of components supported by the JBOG.

[0070] It should be noted that the interface name follows the format GET_[Component Type][Serial Number]_[Information Type]. Here, the component type identifier indicates the type of component, such as PSU (Power Supply), GPU (Graphics Processing Unit), DISK (Hard Disk Drive), NIC (Network Interface Card), etc.; the component serial number identifier indicates the component's number in JBOG, starting from 0; and the information type identifier indicates the type of information to be retrieved, such as TEMP (Temperature), POWER (Power Consumption), STATUS (Status), etc. For example, the interface name GET_PSU0_TEMP indicates retrieving the temperature of power supply number 0, GET_GPU2_POWER indicates retrieving the power consumption of GPU number 2, and GET_DISK1_STATUS indicates retrieving the status of hard disk number 1.

[0071] It should also be noted that component serial numbers are reserved based on the maximum number of components supported by JBOG. For example, if JBOG supports a maximum of 6 PSUs, then 6 sets of interfaces, PSU0 to PSU5, are reserved. When only 4 PSUs are actually connected to the JBOG, interfaces PSU0 to PSU3 can return the corresponding hardware information normally, while interfaces PSU4 and PSU5 will return specific values ​​(such as -1) when called because the corresponding components do not exist. This design of reserving interface names based on the maximum number ensures that the unified interface set on the BMC side can cover various JBOG configurations without adding or deleting interfaces due to differences in the actual JBOG configuration, thus ensuring the stability and universality of the BMC management logic.

[0072] Based on the above unified interface naming rules, BMC executes the information retrieval instruction invocation process in the following manner.

[0073] Specifically, the BMC invokes the information retrieval command through a preset unified interface, including:

[0074] (1) The BMC traverses all unified interfaces according to the preset unified interface naming rules and sequentially calls the information acquisition instructions corresponding to each unified interface.

[0075] It should be noted that after the information retrieval command registration is completed, the BMC generates a complete list of interface names according to the preset unified interface naming rules, and iterates through the list, calling the corresponding information retrieval command for each interface name in sequence. Since the interface names are reserved according to the maximum number of components, the iterative calls can cover all possible components, ensuring no omissions.

[0076] (2) Each time it is called, the BMC will associate the call result with the identifier of the unified interface and store it; if the call result indicates that the corresponding component does not exist, the call result will be ignored.

[0077] It should be noted that after each interface call returns, BMC associates the call result with the corresponding interface identifier (i.e., interface name) and stores it in an internal data structure for subsequent web interface display and logging. If the call result returns a specific value (such as -1), indicating that the component corresponding to the interface does not actually exist in the current JBOG, BMC ignores the result and does not record it as valid hardware information. This fault-tolerant mechanism allows BMC to adapt to different JBOG configurations without needing to adjust the call logic separately for each configuration.

[0078] Based on the single-call process, BMC uses a periodic polling mechanism to continuously monitor JBOG hardware information and triggers alarms when an anomaly is detected.

[0079] Specifically, the BMC calls the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG, including:

[0080] (1) The BMC periodically calls the information acquisition instructions of each component through the unified interface at a preset polling period to obtain the hardware information of all components.

[0081] It should be noted that BMC uses a periodic polling mechanism to obtain JBOG hardware information. For example, the polling period can be preset to once per second, meaning that BMC iterates through all unified interfaces once every second to obtain the latest hardware information of each component. Within a polling period, the information acquisition instructions for all components are executed sequentially, ensuring the synchronization and timeliness of the information of each component.

[0082] (2) When the hardware information is detected to not meet the preset threshold conditions, the BMC generates and records the system event log.

[0083] It should be noted that the BMC (Browser Control Center) has preset threshold conditions for normal ranges for various types of hardware information, such as the upper limit threshold for GPU temperature and the lower limit threshold for PSU voltage. After acquiring hardware information each time, the BMC compares the actual value with the preset threshold. When it detects that the hardware information does not meet the preset threshold conditions, such as the temperature exceeding the upper limit or the voltage falling below the lower limit, the BMC generates a corresponding system event log entry according to the IPMI specification, recording the occurrence time of the abnormal event, the location of the component, the abnormal value, and other information, so that maintenance personnel can promptly detect and handle hardware anomalies.

[0084] This step verifies the version and identifier of the data packets to ensure that the instruction library provided by the JBOG is compatible with the BMC. After successful verification, the instruction library is loaded into the JBOG management service. Then, the information retrieval instructions within the library are called through a pre-defined unified interface to obtain hardware information about various components within the JBOG. With this setup, the management logic on the BMC side is entirely built on the pre-defined unified interface. The interface name does not change with the JBOG hardware model. When connecting JBOGs from different manufacturers or with different configurations, the BMC only needs to load the corresponding shared library files, without modifying the upper-level management code, to complete the acquisition and monitoring of hardware information.

[0085] S104. The BMC monitors and manages the JBOG based on the acquired hardware information.

[0086] It should be noted that monitoring and management refer to the process by which the BMC, having successfully acquired hardware information of various components within the JBOG in the S103, summarizes, analyzes, displays, and responds to this information. Specifically, monitoring functions include visualizing the acquired hardware information through a web management interface or command-line tools; storing hardware information in a time-series format to generate historical trend charts; and determining and notifying users of abnormal states based on preset alarm policies. Management functions include executing corresponding system policies based on hardware status (e.g., adjusting fan speed when temperature exceeds limits, implementing power limits when power consumption exceeds limits); and responding to remote commands from maintenance personnel to control JBOG components (e.g., powering on / off, resetting, etc.).

[0087] In real-world data center operations and maintenance scenarios, JBOG devices may be physically disconnected and reconnected due to maintenance, replacement, or expansion. To ensure that the BMC can respond correctly to such hot-swappable scenarios, an independent in-situ monitoring and re-matching mechanism has been set up.

[0088] Specifically, the method further includes:

[0089] (1) The BMC monitors the presence of JBOG through an independent monitoring thread.

[0090] It should be noted that when the BMC starts the JBOG management service, in addition to creating a main thread for data interaction and hardware monitoring, it also creates a dedicated monitoring thread. The sole responsibility of this monitoring thread is to continuously monitor the presence status changes of JBOGs on each preset physical link address. This monitoring thread runs independently of the main business thread. Even if the main business thread is blocked or waiting due to JBOG communication anomalies, the presence monitoring thread can still function normally, ensuring that the BMC can promptly detect changes in the physical connection status of JBOGs. Specifically, the monitoring thread determines JBOG presence by periodically scanning preset I2C addresses. The scanning period can be set according to response timeliness and system resource usage, for example, it can be set to scan once every 2 seconds.

[0091] (2) When the JBOG is detected to be out of place, the BMC stops monitoring the physical link address corresponding to the current JBOG.

[0092] It should be noted that when the monitoring thread detects that a JBOG previously present on a preset physical link address no longer returns an acknowledgment response, it determines that the JBOG is no longer present (i.e., physically disconnected or powered off). At this point, the BMC first stops polling monitoring activities for that JBOG in the main business thread, releasing relevant system resources; secondly, it marks the JBOG's status as offline and displays the offline status to operations personnel through the web management interface or command-line tools; simultaneously, the BMC can record a JBOG offline event in the system event log, including offline time, physical link address, and other information, facilitating operations auditing. In this way, by promptly stopping monitoring of offline JBOGs, the BMC avoids continuously polling invalid addresses, saving system resources and reducing the generation of meaningless error logs.

[0093] (3) When the JBOG presence signal is detected again on the same physical link address, the BMC rescans the JBOG serial number. If the serial number changes, the system event log is recorded and the steps of acquiring data packets, loading, and calling information acquisition instructions are re-executed.

[0094] It's important to note that when the monitoring thread detects a JBOG presence signal reappearing on the same physical link address (i.e., the original port is reconnected to the JBOG device), the BMC does not simply restore the previous monitoring state. Instead, it executes a complete re-identification and matching process. Specifically, first, the BMC reads the current JBOG's serial number (SN) through the established physical link. The serial number is a unique identifier burned into the JBOG's tail at the factory and stored in the JBOG's CPLD or Flash, used to uniquely identify the physical device. Second, the BMC compares the read serial number with the serial number previously recorded for that physical link address. If the serial numbers match, it indicates that the same JBOG device has been connected. For example, if a temporary power outage is followed by power restoration, the BMC can directly resume monitoring of the JBOG without re-executing the complete data packet acquisition and loading process, thus speeding up the recovery process. If the serial number is different, it indicates that a brand new JBOG device has been connected to the physical port. For example, the maintenance personnel have replaced the tailgate with a different model or a different manufacturer. At this time, the BMC records a JBOG replacement event in the system event log, including information such as replacement time, physical link address, old serial number, and new serial number. Subsequently, the BMC re-executes the complete process from S102 to S104 for the newly connected JBOG, that is, re-acquire data packets, re-perform version verification and identification verification, reload shared library files, re-register information acquisition instructions, and restart polling monitoring.

[0095] Through the aforementioned serial number change detection and re-matching mechanism, BMC can automatically identify device changes when a JBOG is physically replaced and execute corresponding processing strategies based on the changes. This allows maintenance personnel to perform JBOG replacement operations without manually logging into BMC to make any configuration modifications or firmware upgrades. They only need to complete the physical cable plugging and unplugging operations, and BMC can automatically complete the identification, adaptation, and monitoring access of the new device, realizing plug-and-play and hot-swapping support for JBOG. Specifically, when a JBOG is physically disconnected and reconnected due to maintenance, replacement, or other reasons, BMC can automatically sense the change in connection status, identify whether the device has been replaced, and execute the corresponding recovery or re-matching process. The entire process requires no manual intervention and no modification or re-flashing of the BMC firmware.

[0096] The method provided in this embodiment pre-stores data packets encapsulated with information retrieval instructions on the JBOG end. After detecting the JBOG presence signal, the BMC dynamically retrieves the data packet through the physical link and loads it into the JBOG management service. Then, it calls the information retrieval instructions through a preset unified interface with an interface name independent of the JBOG hardware model to obtain the hardware information of each component inside the JBOG and implement monitoring and management. Compared with the existing technology where the BMC firmware needs to be hard-coded for specific JBOG models, this method decouples the BMC-side management logic from the JBOG hardware model. When connecting JBOGs from different manufacturers and with different configurations, there is no need to modify or re-flash the BMC firmware. Adaptation can be completed simply by the JBOG end providing the corresponding data packet, which greatly reduces the adaptation cost and maintenance complexity, and realizes plug-and-play management of JBOG. Meanwhile, through the coordination of mechanisms such as pre-defined unified interface for reserving names according to the maximum number of components, traversal calls and fault tolerance processing, version and identifier verification, independent thread in-place monitoring and serial number change rematching, the system's adaptability to multi-JBOG parallel management, hot-swappable scenarios and abnormal situations has been further improved, enhancing the server's flexibility, compatibility and maintainability of JBOG hardware monitoring.

[0097] Example 2

[0098] Corresponding to the aforementioned embodiment of a method for managing JBOG using a BMC, this application also provides an embodiment of an apparatus for managing JBOG using a BMC.

[0099] Figure 2 This is a schematic diagram of the second embodiment of the BMC management JBOG device provided in this application. Please refer to... Figure 2 The device provided in this embodiment includes a monitoring module 210, a connection module 220, a receiving module 230, a processing module 240, and a management module 250.

[0100] The monitoring module 210 is used by the BMC to start the JBOG management service and monitor at least one preset physical link address;

[0101] The connection module 220 is used to establish a connection with the JBOG in response to detecting a JBOG presence signal on the preset physical link address.

[0102] The receiving module 230 is used to obtain data packets from the JBOG through the physical link after the connection is established. The data packets are encapsulated with information acquisition instructions for obtaining hardware information of the JBOG.

[0103] The processing module 240 is used to load the data packet into the JBOG management service and call the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein the interface name of the unified interface is independent of the hardware model of the JBOG.

[0104] The management module 250 is used to monitor the JBOG based on the acquired hardware information.

[0105] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0106] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0107] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0108] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing JBOG using BMC, characterized in that, The method includes: BMC starts the JBOG management service and listens on at least one preset physical link address; In response to the detection of a JBOG presence signal on the preset physical link address, the BMC obtains a data packet from the JBOG through the physical link; wherein the data packet is pre-stored by the JBOG and encapsulates an information acquisition instruction for obtaining the JBOG hardware information; The BMC loads the data packet into the JBOG management service and calls the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein, the interface name of the unified interface is independent of the hardware model of the JBOG. The BMC monitors and manages the JBOG based on the acquired hardware information.

2. The method according to claim 1, characterized in that, The BMC obtains data packets from the JBOG via the physical link, including: The BMC reads the binary format data packets stored in the Flash of the JBOG segment by segment using I2C commands; The BMC parses the data packet, generates a plaintext string, and converts the plaintext string into a locally callable shared library file.

3. The method according to claim 1, characterized in that, The BMC loads the data packet into the JBOG management service, including: The BMC reads the JBOG identification information contained in the data packet; The BMC verifies whether the JBOG identification information matches the local configuration. If a match is found, the information retrieval instruction in the data packet is registered in the call list of the JBOG management service.

4. The method according to claim 1, characterized in that, The interface name of the preset unified interface includes a component type identifier, a component serial number identifier, and an information type identifier, wherein the component serial number identifier is reserved according to the maximum number of components supported by the JBOG.

5. The method according to claim 1, characterized in that, The BMC invokes the information retrieval command through a preset unified interface, including: The BMC traverses all unified interfaces according to the preset unified interface naming rules and sequentially calls the information retrieval instructions corresponding to each unified interface. Each time a call is made, the BMC associates and stores the call result with the identifier of the unified interface; if the call result indicates that the corresponding component does not exist, the call result is ignored.

6. The method according to claim 1, characterized in that, The data packet also contains version number information; before the BMC loads the data packet into the JBOG management service, it also includes: The BMC parses the data packet and extracts the version number information; The BMC compares the version number information with the locally preset supported versions. If the versions do not match, it stops loading and records the system event log.

7. The method according to claim 1, characterized in that, The BMC invokes the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG, including: The BMC periodically calls the information acquisition instructions of each component through the unified interface at a preset polling cycle to obtain the hardware information of all components. When the hardware information is detected to not meet the preset threshold conditions, the BMC generates and records a system event log.

8. The method according to claim 1, characterized in that, The BMC listens to at least one preset physical link address, including: The BMC listens to multiple preset physical link addresses, and each preset physical link address corresponds to a physical connection port of a JBOG. When JBOG signals are detected simultaneously on multiple preset physical link addresses, the BMC establishes connections with the multiple JBOGs respectively, and independently executes the steps of acquiring data packets, loading, and calling information acquisition instructions for each JBOG. The BMC distinguishes and manages the hardware information of different JBOGs based on the physical link address of each JBOG.

9. The method according to claim 1, characterized in that, The method further includes: The BMC monitors the presence of JBOG through a separate monitoring thread; When a JBOG is detected to be out of place, the BMC stops monitoring the physical link address corresponding to the current JBOG. When the presence of a JBOG signal is detected again on the same physical link address, the BMC rescans the JBOG's serial number. If the serial number changes, the system event log is recorded, and the steps of acquiring data packets, loading, and calling information acquisition instructions are re-executed.

10. A device for managing JBOG using a BMC, characterized in that, The device includes a monitoring module, a connection module, a receiving module, a processing module, and a management module; The monitoring module is used by BMC to start the JBOG management service and monitor at least one preset physical link address; The connection module is used to establish a connection with the JBOG in response to detecting a JBOG presence signal on the preset physical link address. The receiving module is used to obtain data packets from the JBOG through the physical link after the connection is established. The data packets are encapsulated with information acquisition instructions for obtaining hardware information of the JBOG. The processing module is used to load the data packet into the JBOG management service and call the information acquisition instruction through a preset unified interface to obtain the hardware information of the JBOG; wherein the interface name of the unified interface is independent of the hardware model of the JBOG. The management module is used to monitor the JBOG based on the acquired hardware information.

Images