Method, system, and computing device for managing server components

CN122507409APending Publication Date: 2026-08-04XFUSION DIGITAL TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
XFUSION DIGITAL TECH CO LTD
Filing Date
2026-03-27
Publication Date
2026-08-04

AI Technical Summary

Technical Problem

[0004]但是在多服务器部件的场景下,每新增一个部件型号,都需要重新开发硬件接口和软件配置,且同一类型的服务器部件在使用状态不同时,需要设置不同的配置文件,无法实现统一的部件识别与配置,导致部件识别及配置过程繁琐、周期长、兼容性差

Benefits of technology

[0025] Based on the embodiments of this application, the baseboard management controller can automatically compare the physical connection status of the server components and the server with the expected configuration, locate connection deviations, and avoid failures such as communication interruption, bandwidth limitation or functional loss caused by cable issues.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122507409A_ABST
    Figure CN122507409A_ABST
Patent Text Reader

Abstract

The embodiment of the application relates to the technical field of servers, and provides a server component management method and system and a computing device, which are applied to a BMC in a server, the method comprises the following steps: in response to a server component requesting to establish a connection with the server, acquiring FRU configuration fields stored in the server component, the FRU configuration fields comprising first information and second information; determining the component type of the server component based on the first information, and inquiring about an expected configuration of the server component; if the second information is a null value, writing the expected configuration into the second information; and identifying the server component and allocating transmission channel resources according to the first information and the second information. Based on the embodiment of the application, the BMC can automatically identify the type of the server component by reading the FRU configuration fields when the server component is accessed, and the identification of the server component and the allocation of resources can be realized through the comparison between the expected configuration and the second information, so that the configuration errors and compatibility risks caused by manual intervention are avoided, and the identification efficiency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a method, system and computing device for managing server components. Background Technology

[0002] Rack servers, as a type of standard-sized server, offer advantages such as flexible configuration and strong scalability. Rack servers support the installation of different types of server components, such as backplanes and expansion cards that provide different functions, to meet users' business processing, storage, and expansion needs.

[0003] To adapt to various types of server components, rack servers can utilize component information, such as component numbers, to generate corresponding configuration files and integrate them into the rack server's system version, thereby enabling the identification of server components.

[0004] However, in scenarios with multiple server components, each new component model requires the redevelopment of hardware interfaces and software configurations. Furthermore, different configuration files need to be set for the same type of server component when they are used in different states, making it impossible to achieve unified component identification and configuration. This results in a cumbersome, time-consuming, and incompatible component identification and configuration process. Summary of the Invention

[0005] This application provides a method, system, and computing device for managing server components. It can identify and allocate resources to server components by utilizing preset configuration fields in the server components and the expected configuration in the server, thereby reducing the complexity of component identification and improving identification efficiency and compatibility.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for managing server components, applied to a baseboard management controller within a server. The method includes: responding to a server component requesting to establish a connection with the server, obtaining a Field Replaceable Unit (FRU) configuration field stored in the server component; the FRU configuration field includes first information and second information, wherein the first information is used to indicate the type of the server component, and the second information is used to indicate the enabling configuration of the server component in actual application; based on the first information, determining the component type of the server component, and querying the expected configuration of the server component in the server; if the second information is empty, writing the expected configuration into the second information; the baseboard management controller identifies the server component and allocates transmission channel resources to the server component according to the first information and the second information.

[0007] Based on the embodiments of this application, the baseboard management controller in the server can automatically identify the type of the component by reading the FRU configuration field stored in the server component when the server component requests to establish a connection with the server. By comparing the expected configuration in the server with the second information in the FRU field, the server component can be identified and resources allocated, avoiding configuration errors and compatibility risks caused by manual intervention and improving identification efficiency.

[0008] In one possible implementation, determining the component type of a server component based on the first information, and querying the expected configuration of the server component in the server, includes: obtaining a preset component type mapping table; the component type mapping table stores the correspondence between field values ​​of the first information and component types; determining the first component type of the server component based on the field values ​​of the first information; and querying the expected configuration corresponding to the server component of the first component type in the server.

[0009] Based on the embodiments of this application, the baseboard management controller can quickly match the component type with the expected configuration by looking up a table, thereby shortening the time required for the server to identify server components and achieving rapid identification of server components.

[0010] In another possible implementation, before establishing a connection with the server in response to a server component request and obtaining the FRU configuration field stored in the server component, the method further includes: in response to receiving a component configuration instruction, determining the server's component configuration requirement information; the component configuration requirement information includes the component type of the server component to be connected and the expected configuration parameters of each server component; establishing a mapping relationship between the component type of the server component and the expected configuration parameters; storing the mapping relationship to obtain the expected configuration file; querying the expected configuration corresponding to the server component of the first component type in the server, including: obtaining the expected configuration file; querying the expected configuration parameters matching the first component type in the expected configuration file based on the first component type; and determining the expected configuration parameters matching the first component type as the expected configuration.

[0011] Based on the embodiments of this application, the baseboard management controller can dynamically generate expected configuration files according to the real-time configuration requirements of the server, so as to adapt the identification and configuration process to the business scenario and flexibly respond to the diverse needs under different business scenarios.

[0012] In another possible implementation, if the second information is empty, the expected configuration is written into the second information, including: converting the expected configuration into a configuration field value based on a preset configuration mapping relationship; and writing the configuration field value into the second information.

[0013] Based on the embodiments of this application, the baseboard management controller can automatically write the expected configuration into the component FRU storage area to synchronize the component configuration information, while ensuring the consistency of subsequent identification and configuration, and avoiding misjudgment or inaccurate alarms due to missing FRU information.

[0014] In another possible implementation, after determining the component type of the server component based on the first information and querying the expected configuration of the server component in the server, the method further includes: if the second information is not empty, obtaining the field value of the second information and the configuration field value corresponding to the expected configuration; when the field value of the second information is the same as the configuration field value, activating the port corresponding to the field value of the second information in the server component based on the field value of the second information and the component type; determining the channel to be enabled of the server component based on the port; and allocating transmission channel resources corresponding to the channel to be enabled to the server component.

[0015] Based on the embodiments of this application, the baseboard management controller can reuse the configuration of the component when the second information already exists in the component, avoid repeated writing and ensure that the channel resources are consistent with the expected configuration, thereby improving resource scheduling efficiency and server operation stability.

[0016] In another possible implementation, the FRU configuration field also includes third information, which is used to indicate the maximum support capability of the server component. After obtaining the field value of the second information and the configuration field value corresponding to the expected configuration, the method further includes: verifying the field value of the second information based on the third information; if the field value of the second information is within the range of the third information, comparing the field value of the second information with the configuration field value; if the field value of the second information is outside the range of the third information, generating a first alarm message; the first alarm message is used to indicate that the configuration information of the server component has exceeded the limit.

[0017] Based on the embodiments of this application, the baseboard management controller can perform capability boundary verification on the existing configuration in the components to ensure that the actual configuration does not exceed the upper limit of the hardware physical capabilities, thereby reducing the risk of system anomalies, performance degradation or hardware damage caused by out-of-specification configurations.

[0018] In another possible implementation, before writing the expected configuration into the second information, the method further includes: verifying the configuration field value based on the third information; if the configuration field value is within the range of the third information, then writing the configuration field value into the second information; if the configuration field value is outside the range of the third information, then generating a second alarm message; the second alarm message is used to indicate that the expected configuration does not conform to the specifications of the server components.

[0019] Based on the embodiments of this application, the baseboard management controller can perform capability boundary pre-verification on the configuration field values ​​corresponding to the expected configuration, avoid writing out-of-specification configurations into the FRU, and avoid the risk of configuration going out of bounds.

[0020] In another possible implementation, the method further includes: the baseboard management controller acquiring order configuration information, which includes the requirements for enabling configuration of the server component in the application; and writing the order configuration information into third information stored in the server component.

[0021] Based on the embodiments of this application, the production system can dynamically map order configuration information with third-party information to achieve calibration of configuration strategies and hardware capabilities, so that the server delivery configuration meets the order requirements and supports flexible adjustment of the enabling status as needed after delivery, without the need for return to the factory or manual intervention.

[0022] In another possible implementation, the order configuration information is written into the third information stored in the server component, including: during the production or assembly process of the server component, the production system writes the order configuration information into the third information of the server component.

[0023] Based on the embodiments of this application, the production system can write order configuration information into the corresponding component firmware during the production process of server components, so that the server components can be bound to hardware capabilities and business requirements from the source of the production line, thereby shortening the delivery cycle of server components.

[0024] In another possible implementation, before the baseboard management controller identifies the server component and allocates transmission channel resources to the server component based on the first and second information, the method further includes: determining the expected connection relationship between the server component and the server based on the second information and a preset cable connection scheme; detecting the physical connection status between the server component and the server; if the physical connection status is found to meet the expected connection relationship, identifying the server component and allocating transmission channel resources to the server component; if the physical connection status is found to not meet the expected connection relationship, generating a third alarm message; the third alarm message is used to indicate abnormal cable connection or incorrect component installation position.

[0025] Based on the embodiments of this application, the baseboard management controller can automatically compare the physical connection status of the server components and the server with the expected configuration, locate connection deviations, and avoid failures such as communication interruption, bandwidth limitation or functional loss caused by cable issues.

[0026] In another possible implementation, obtaining the field replaceable unit (FRU) configuration field stored in the server component includes: responding to a server component request to establish a connection with the server, establishing a communication connection between the server and the server component; reading the field data stored in the FRU storage area by the server component; and obtaining the FRU configuration field based on the field data.

[0027] Based on the embodiments of this application, the baseboard management controller can obtain the corresponding FRU configuration field from the newly connected server components, enabling the server to identify the server components using the configuration field and perform subsequent resource allocation tasks.

[0028] In another possible implementation, the FRU configuration field is obtained based on the field data. The method further includes: obtaining the first checksum of the field data based on a preset verification algorithm; reading the second checksum in the FRU storage area; if the first checksum and the second checksum are consistent, the FRU configuration field is obtained based on the field data and the second checksum; if the first checksum and the second checksum are inconsistent, a fourth alarm message is generated; the fourth alarm message is used to indicate that the FRU storage area data is corrupted or read abnormally.

[0029] Based on the embodiments of this application, the baseboard management controller can use the checksum in the FRU configuration field and the checksum generated during the reading of the FRU configuration field to complete the data integrity verification, so that the configuration field it reads is complete and accurate, thereby ensuring that the subsequent identification, configuration and alarm logic are all based on trusted data.

[0030] Secondly, embodiments of this application also provide a management system for server components, including: a configuration reading unit configured to establish a connection with a server in response to a server component request, and to obtain a Field Replaceable Unit (FRU) configuration field stored in the server component; the FRU configuration field includes first information and second information, wherein the first information is used to indicate the type of the server component, and the second information is used to indicate the enabling configuration of the server component in actual application; a field processing unit configured to determine the component type of the server component based on the first information, and to query the expected configuration of the server component in the server; and, if the second information is empty, to write the expected configuration into the second information; and a component identification unit configured to identify the server component based on the first information and the second information and to allocate transmission channel resources to the server component.

[0031] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0032] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0033] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0034] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0035] Figure 1 A connection diagram of a server component; Figure 2 A flowchart illustrating a method for managing server components provided in an embodiment of this application; Figure 3 A schematic diagram illustrating the modification of the FRU configuration field of a server component, provided as an embodiment of this application; Figure 4 A flowchart illustrating a process for determining an expected configuration file within a server, provided as an embodiment of this application; Figure 5 A schematic diagram illustrating a process for determining component type and expected configuration, provided for an embodiment of this application; Figure 6 A schematic diagram illustrating a process for obtaining configuration fields provided in an embodiment of this application; Figure 7 A schematic diagram illustrating a process for verifying the configuration of a server component, provided as an embodiment of this application; Figure 8 A schematic diagram of a server component provided in an embodiment of this application; Figure 9 A schematic diagram illustrating a resource allocation process provided in an embodiment of this application; Figure 10 A flowchart illustrating a verification configuration field provided in an embodiment of this application; Figure 11 A schematic diagram of a management system for a server component provided in an embodiment of this application; Figure 12 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0037] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0038] The Baseboard Management Controller (BMC) is used to monitor the hardware status of the device, perform remote management operations, and provide monitoring and control functions for the device, ensuring that the server has stable out-of-band management capabilities in complex operating environments.

[0039] A rack server is a standard-sized server hardware component designed for 19-inch rack mounting, facilitating server installation and expansion. Rack servers have multiple hardware slots, each designed to accommodate hot-swappable server components.

[0040] Server components are hot-swappable hardware modules located within rack servers. Their physical form and functional interfaces strictly adhere to rack server slot specifications, supporting plug-and-play and hot-swappable operation. Server components may include computing units, storage modules, network modules, and expansion cards, used to perform core tasks such as computing, storage, network communication, and functional expansion.

[0041] A Field Replaceable Unit (FRU) is a non-volatile storage structure used to store component information, typically integrated onto server components. In this embodiment, the FRU can be embedded in the printed circuit board (PCB) corresponding to the server component in the form of an electrically erasable programmable read-only memory (EEPROM) chip for persistently storing relevant information of the server component.

[0042] The application scenarios of this application will be explained below.

[0043] Rack servers, as a type of high-density, modular server hardware, offer standardized architecture and hot-swappable design that enhances deployment efficiency and configuration capabilities. However, with the continuous increase in component types and configuration complexity, in scenarios with multiple server components, each new component model requires the development of a separate configuration file based on its Part Number (PN). Furthermore, due to differences in business scenarios, the same type of component may generate multiple PN variants, leading to an exponential increase in the number of configuration files. This not only makes the configuration process of server components more cumbersome but also increases the maintenance costs and error risks of configuration management.

[0044] Figure 1 This is a connection diagram of a server component.

[0045] like Figure 1As shown, server 10 can connect to two server components simultaneously, both communicating with the BMC in the server via a high-speed serial bus. For example, the two server components can be hard drive backplanes of the same specifications, but server component 11a connects to two hard drives, while server component 11b connects to four hard drives. In this case, the server needs to develop configuration files for each of the two server components based on user input instructions, and then identify and manage backplanes with different numbers of hard drives based on the configuration files.

[0046] During the process of server 10 identifying server components, each new component or configuration requirement requires manual intervention to generate and maintain a dedicated configuration file. Furthermore, the response to configuration changes of server components is delayed, making it difficult to meet the real-time requirements of data centers for rapid deployment and dynamic adaptation of server components.

[0047] Based on this, this application provides a method for managing server components. By setting corresponding configuration fields within the server components, the BMC in the server can automatically read and parse these fields, thereby determining the server's identification and configuration method for the server components. This reduces reliance on configuration files, lowers the complexity of server component identification, and improves identification efficiency and accuracy.

[0048] Figure 2 This is a flowchart illustrating a server component management method provided in an embodiment of this application. The following is based on... Figure 2 The content shown is an exemplary illustration of the server identification process for server components provided in the embodiments of this application.

[0049] It should be noted that the solution provided in this embodiment is applied to a baseboard management controller within a server. This server can install server components and can be a rack server or any server capable of hot-swapping server components. The server in this embodiment includes at least a baseboard management controller (BMC) and a high-speed serial bus interface for communicating with the server components. The BMC, as the server's baseboard management controller, is responsible for performing the server's low-level management tasks, including hardware monitoring, remote control, and component identification. The high-speed serial bus interface is used to establish a low-latency, high-bandwidth data path with the server components.

[0050] like Figure 2 As shown, in this embodiment of the application, the process by which the server identifies the server component it is connected to may include the following steps S100 to S400.

[0051] S100: In response to a server component requesting to establish a connection with the server, the BMC obtains the field replaceable unit (FRU) configuration field stored in the server component.

[0052] In step S100, the BMC in the server can read the FRU configuration fields stored in the FRUs of each server component via a high-speed serial bus after the server component requests to establish a connection with the server. This allows the server to identify and configure the server components using the FRU configuration fields. In one embodiment, the server component requesting to establish a connection with the server received by the BMC can be a signal generated when the server component first connects to the server, or a signal generated in the server when the server or a server component restarts or resets. This application does not impose any limitations on this.

[0053] In this embodiment, after the server component requests to establish a connection with the server, the FRU configuration field obtained by the BMC can be a predefined field content stored in the FRU. In one example, the FRU configuration field can be written to the server component before it leaves the factory, so that the BMC can read it to obtain the corresponding field content after the server component requests to establish a connection with the server.

[0054] In this embodiment of the application, the FRU configuration field may include at least first information and second information. The first information is used to indicate the type of server component, and the field value corresponding to the first information can identify the category to which the server component belongs, such as hard disk backplane, riser card, or expansion card. The second information is used to indicate the enabling configuration of the server component in the actual application of the server, such as the number of slots in the actual application, the supported protocol type, and the Peripheral Component Interconnect Express (PCIe) version.

[0055] For example, the first and second information can be stored in the FRU in binary encoded form and read by the BMC at fixed address offsets. The number of bytes occupied by the first and second information is fixed, which allows the BMC to accurately parse the field semantics and ensure consistent recognition.

[0056] It should be noted that before the server component requests to establish a connection with the server, the second information can be empty, so that it can be dynamically written by the BMC later, ensuring that the field value of the second information is strictly consistent with the actual deployment requirements. Here, "empty" in the second information means that the corresponding field value is 0x00, or that the corresponding field value is a preset invalid value identifier. This value has no actual configuration meaning and is only used as a placeholder to prevent the server from misinterpreting it as a valid configuration when reading it later.

[0057] After a server component is connected, the BMC can read the FRU configuration field stored in the FRU through an interface to automatically identify and configure the component on demand, reducing manual intervention and coding requirements.

[0058] In some embodiments, the FRU configuration field may further include third information and a verification field. The third information describes the maximum supported capabilities of the server component, such as the total number of protocol interfaces supported by the hard drive backplane or the number of PCIe slots supported by the Riser card. The verification field is used to verify the data integrity and consistency of the first, second, and third information to prevent identification anomalies caused by write errors or transmission interference.

[0059] Similar to the first and second information, the third information and the verification field are also stored using fixed-length binary encoding. The field value corresponding to the third information can be pre-written when the server component leaves the factory, while the verification field is calculated and written based on the contents of the other fields when the server component leaves the factory. This ensures that the server can quickly verify the validity of the FRU configuration field using the verification field during subsequent identification and configuration processes, avoiding misidentification caused by field tampering or damage.

[0060] In some embodiments of this application, the field value length of the first information in the FRU configuration field can be 1 byte, the field value lengths of the second and third information are each 2 bytes, and the length of the verification field is 1 byte. All fields in the FRU configuration field can be stored continuously in a preset order, such as the order of first information-third information-second information-verification field, which facilitates efficient reading by the BMC with a fixed offset.

[0061] In this context, one byte of the first information field value corresponds to 8 bits of binary data, which can encode 256 component types. The server can determine the component category corresponding to this field value through a predefined component type mapping table. For example, when the field value is 0x01, it is mapped to "hard disk backplane", 0x02 corresponds to "Riser card", and 0x03 corresponds to "expansion card". The BMC can identify the corresponding component type based on the field value of the first information in the FRU configuration field it obtains.

[0062] The second and third information fields are both encoded using 2 bytes (16 bits) of binary code, representing the theoretical capability limit and the actual deployment configuration, respectively. Because components of the same type have certain functional limitations, such as differences in the number of interfaces, supported protocol versions, and physical disk bit width between different hard drive backplanes, the second and third information can be split into high 8 bits and low 8 bits to carry different dimensions of capability identifiers and configuration parameters. This allows for multi-dimensional capability descriptions and refined configuration expressions within a limited word length.

[0063] Taking a server component as an example, the hard drive backplane can support at least one of several storage protocols, including Serial Attached Serial Advanced Technology Attachment (SAS), Serial Advanced Technology Attachment (SATA), and Non-Volatile Memory Express (NVMe). Because the SAS and SATA protocols share physical layer electrical characteristics, the high 8 bits can be used to identify the combined number of SAS / SATA channels, while the low 8 bits are dedicated to identifying the number of NVMe channels, thus simultaneously characterizing two key capability indicators within a 16-bit space.

[0064] For example, when the high 8 bits of the third information are 0x04 and the low 8 bits are 0x08, it indicates that the backplane supports 4 SAS / SATA channels and 8 NVMe channels. However, if the high 8 bits of the second information are set to 0x02 and the low 8 bits are set to 0x04, it indicates that only 2 SAS / SATA channels and 4 NVMe channels are currently actually enabled.

[0065] By separating the server component capabilities and configuration parameters in the FRU configuration field, the hardware capabilities and software configuration of the server components are decoupled, which ensures the versatility and reusability of the components, and supports precise and dynamic configuration adjustments of the components according to server requirements.

[0066] When the server component is a Riser card, the high 8 bits of the third and second information can be used to identify the number of PCIe 5.0 slots, while the low 8 bits are used to identify the number of PCIe 4.0 slots, thus ensuring compatibility with mixed deployment scenarios of multiple generations of PCIe protocols.

[0067] It should be noted that the encoding rules for the third and second information disclosed in the foregoing embodiments are all feasible implementation methods and are not the only limitations. In practical applications, the field partitioning logic can be dynamically adjusted according to the component type, platform requirements, and protocol evolution. For example, the high 4 bits can be defined as the protocol type identifier, and the remaining 12 bits can be allocated with capabilities and configuration weights as needed. The embodiments of this application do not limit the bit width and semantic mapping of the field encoding.

[0068] S200: Based on the first information, determine the component type of the server component and query the expected configuration of the server component in the server.

[0069] In step S200, after obtaining the FRU configuration field from the server component, the BMC can parse the field value corresponding to the first information and map it to the corresponding component type, such as backplane, Riser, or expansion card. This enables the BMC to match the hardware configuration requirements of the server equipped with the BMC based on the corresponding component type and obtain the expected configuration corresponding to the server component.

[0070] In one example, the expected configuration of server components of various component types can be determined by the hardware requirement information built into the server. This hardware requirement information can be pre-set and stored in the BMC's registers during the server's construction process, and can be updated by the server administrator according to actual business scenarios to adapt to different business needs. Therefore, the BMC can obtain the server's hardware requirement information by reading the contents of its own registers, and then determine the expected configuration of that type of server component by obtaining the server component type.

[0071] BMC, through its built-in hardware requirements information, can determine the configuration requirements for various component types and, based on the mapping relationship between component types and configuration requirements, determine the expected configuration for each type of server component. For example, when the component type is identified as "Riser Card," BMC can obtain the configuration requirements, such as the number of PCIe slots that the corresponding Riser Card should support, based on its built-in requirements information, and thus obtain the corresponding expected configuration.

[0072] S300: If the second information is empty, write the expected configuration into the second information.

[0073] In step S300, the BMC will parse the second information in the FRU configuration field to determine the configuration status marked in the server component, so as to determine whether it meets the expected configuration.

[0074] Because the byte corresponding to the second information in the FRU storage area can be null at the factory, when a server component requests to establish a connection with the server, the BMC in the server can first check whether this field has been effectively written. If the second information is null, the initialization process is triggered, the BMC writes its expected configuration to the FRU storage area, and obtains the corresponding second information based on the written content.

[0075] Figure 3 This is a schematic diagram illustrating how to modify the FRU configuration field of a server component, as provided in an embodiment of this application.

[0076] like Figure 3As shown, when the BMC has the setting permissions, if the BMC detects that the second information in the FRU configuration field is empty, the BMC can generate the corresponding binary data based on the expected configuration and write it to the FRU storage area to realize the initial filling of the FRU configuration field.

[0077] In this embodiment, the registers in the BMC can store a mapping table between the expected configuration and the corresponding binary data, enabling the BMC to quickly convert the expected configuration in the BMC into configuration field values ​​in binary data format based on a preset configuration mapping relationship.

[0078] After obtaining the configuration field value corresponding to the expected configuration, the BMC can write it to the corresponding offset address in the FRU storage area to complete the initialization configuration. At the same time, the BMC can also write it to the FRU configuration field stored in the server component, so that the server component can execute its corresponding identification and resource allocation logic based on the latest and most accurate configuration status when it needs to re-establish a connection with the server in the future.

[0079] Taking the hard drive backplane as an example of the component type identified by BMC, if the BMC detects that the second information of the component is empty when the expected configuration is 4 NVMe channels, the BMC will generate the corresponding binary data 0x04 according to the expected configuration of 4 NVMe channels and write it into the corresponding byte of the backplane FRU storage area to realize the filling of the second information.

[0080] S400: The BMC identifies the server component and allocates transmission channel resources to the server component based on the first and second information.

[0081] In step S400, after writing the expected configuration into the second information, the BMC can use the configuration to identify the accessed server component and allocate transmission channel resources adapted to the configuration to the server component, so that the server component can run in the server, realizing the automatic identification and configuration process of the server component by the server during the process of the server component requesting to establish a connection with the server.

[0082] Taking the hard drive backplane as an example of the component type identified by BMC, if the expected configuration is 4 NVMe channels and the content written in the second information is 0x04, then BMC will allocate 4 NVMe link resources accordingly and verify whether the actual number of disk bays connected to the backplane matches the cable topology, so as to form a closed-loop verification between the cable connection and the actual configuration, thereby improving the accuracy and efficiency of BMC in identifying server components.

[0083] Through the steps S100 to S400 above, the BMC in the server can use the predefined and stored FRU configuration fields in the server components to complete the identification and configuration of the server components, reduce manual intervention, and enable the server components to autonomously execute the identification and resource allocation process when requesting to establish a connection with the server, thereby improving the deployment efficiency and configuration accuracy of the server components.

[0084] The steps in the above embodiments will be further described below with reference to the accompanying drawings.

[0085] Figure 4 This is a schematic diagram illustrating a process for determining a desired configuration file within a server, provided as an embodiment of this application. The following is in conjunction with... Figure 4 The content shown herein serves as an exemplary illustration of the process by which the BMC determines the actual needs of the server in this embodiment of the application.

[0086] like Figure 4 As shown, in this embodiment of the application, the process by which the BMC determines the expected configuration file inside the server may include the following steps S201 to S203.

[0087] S201: In response to receiving a component configuration instruction, determine the component configuration requirements of the server.

[0088] In step S201, the BMC may, in response to receiving a component configuration instruction, determine the configuration requirements of each server component of the server, wherein the component configuration requirements include the component type of the server component to be connected and the expected configuration parameters of each server component.

[0089] It should be understood that during the construction process, BMC will store the configuration requirements for different component types determined according to the server's design goals and actual application scenarios. For example, in a server for AI training scenarios, a hard disk backplane needs to be set up and support 8 SAS channels so that the hard disk backplane can connect 8 hard disks. Based on the above steps, corresponding resources will be allocated to meet the high-throughput data storage requirements. On the other hand, a server for edge inference scenarios may only need 2 NVMe channels so that the hard disk backplane can connect 2 hard disks, reducing resource consumption and balancing power consumption and performance.

[0090] Therefore, the component configuration instructions can include the design goals and application scenario information corresponding to the server. Based on this, BMC can parse the component configuration requirements and determine the component type of the server component to be connected, as well as the expected configuration parameters corresponding to each server component.

[0091] In some embodiments of this application, the component configuration instructions may be a server delivery file, which has a fixed overall server configuration state, including the types and quantities of server components set in the server, as well as the expected configuration parameters for each server component. For example, the server delivery file may specify that the server needs to be equipped with two hard disk backplanes and one Riser card, where the two hard disk backplanes support 8 SAS channels and 4 NVMe channels respectively, and the Riser card needs to support 3 PCIe slots. The BMC can read this file from its corresponding registers when the server starts up, and parse the component types and expected configuration parameters based on the file to obtain the server's component configuration requirements information.

[0092] In another embodiment, component configuration instructions can also be remotely issued by the administrator of the server cluster where the server resides. The component configuration instructions can carry the various server components that the server needs to connect to, as well as the corresponding slots and number of interfaces for each server component. After receiving the component configuration instructions, the BMC can update its own configuration status by overwriting the information in the component configuration instructions to its local configuration, which facilitates adaptation to changes in business load or adjustments to operation and maintenance strategies, and optimizes resource utilization and deployment flexibility.

[0093] In another embodiment, the component configuration instruction may also be the order configuration information obtained by the BMC. The order configuration information includes the server's enable configuration requirements for the server component in the application. The order configuration information may be configuration information generated by the server based on the functions it needs to implement. After obtaining the order configuration information, the BMC may write the order configuration information into the third information in the FRU configuration field of the server component.

[0094] In some embodiments, the order configuration information may also be information generated by the production system corresponding to the server component during the production or assembly process. Accordingly, the FRU configuration field stored in the server component may be written into the third information stored in the server component by the corresponding production system during the production or assembly process.

[0095] S202: Establish the mapping relationship between the component types of server components and the expected configuration parameters.

[0096] In step S202, after obtaining the component configuration requirement information, BMC can generate a corresponding mapping relationship based on the component type of each server component and the expected configuration parameters corresponding to each server component.

[0097] In one example, taking a component configuration requirement that includes two hard disk backplanes and one Riser card, BMC can establish a corresponding mapping relationship between "component type - expected configuration parameters" for each server component. For example, hard disk backplane A corresponds to 8 SAS channels, hard disk backplane B corresponds to 4 NVMe channels, and the Riser card corresponds to 3 PCIe slots.

[0098] S203: Store the mapping relationship to obtain the expected configuration file.

[0099] In step S203, the BMC can write the mapping relationship generated based on the component configuration requirement information into the local configuration register in the BMC or the non-volatile storage unit in the server, thereby obtaining the corresponding expected configuration file, which serves as the basis for the subsequent BMC to execute the management process of the server component.

[0100] It should be understood that the process from steps S201 to S203 can be completed during the server power-on self-test phase or dynamically loaded during runtime, so that the BMC in the server can identify and configure server components during initial deployment, and can also respond to the hot-plugging of server components or receive corresponding instructions to modify the configuration policy during server operation, and update the configuration in combination with the real-time status of server components, thereby realizing on-demand configuration and hot-plugging of the server.

[0101] Through the above steps S201 to S203, BMC can generate and write the expected configuration file, so as to provide a data foundation for BMC to identify and allocate resources to the server component after the server component is connected to the server, avoid resource conflicts or functional abnormalities caused by configuration errors, and improve the deployment efficiency and operational stability of the server.

[0102] Figure 5 This is a schematic flowchart illustrating the process of determining component type and expected configuration, provided in an embodiment of this application. The following is in conjunction with... Figure 5 The content shown illustrates, by way of example, the process by which the BMC determines the component type and expected configuration in the embodiments of this application.

[0103] like Figure 5 As shown, in this embodiment of the application, the process by which the BMC determines the component type and the expected configuration may include the following steps S210 to S233.

[0104] S210: Obtain the preset component type mapping table.

[0105] In step S210, the registers in the BMC may store a preset component type mapping table, which stores the correspondence between the field values ​​of the first information and the component types. The BMC can obtain the corresponding component type mapping table by reading its own storage unit.

[0106] In this embodiment, the component type mapping table in the BMC can be a static table pre-set in the BMC's built-in registers, or a dynamic table dynamically issued by the management platform and cached in the BMC after the server powers on. The information in the component type mapping table is stored in key-value pairs, where binary data serves as the key and the corresponding component type as the value, enabling the BMC to match the corresponding component type based on the binary data in the FRU configuration field.

[0107] In one example, in the component type mapping table, a key of "0" corresponds to a value of "hard disk backplane", a key of "1" corresponds to a value of "Riser card", and a key of "2" corresponds to a value of "expansion card". In this way, the BMC can quickly look up the table to determine the component type of the server component based on the binary data in the bytes corresponding to the first information read.

[0108] It should be understood that the correspondence between the field values ​​of the first information in the above component type mapping table and the component type is only an example. In practical applications, server components of the same component type can be further subdivided into finer-grained subtypes based on the range of protocol types supported by the server component. For example, hard drive backplanes can be further divided into general hard drive backplanes, NVMe backplanes, SAS / SATA backplanes, etc., and each subtype corresponds to a unique key-value pair in the mapping table, ensuring that the recognition accuracy and configuration granularity are improved simultaneously.

[0109] S220: Determine the first component type of the server component based on the field value of the first information.

[0110] In step S220, the BMC can use its query in the register to obtain the field value of the binary data format corresponding to the first information, and query the first component type corresponding to the field value in the component type mapping table to realize the identification of the component type of the server component.

[0111] S230: Query the expected configuration corresponding to the server component of the first component type in the server.

[0112] In step S230, after querying and obtaining the first component type corresponding to the server component, the BMC can obtain the expected configuration information corresponding to the component type in the server based on the first component type, so that when the server component requests to establish a connection with the server, it can manage the server component according to the server's needs.

[0113] In this embodiment of the application, the server may store a desired configuration file so that the BMC can obtain the desired configuration corresponding to the first component type.

[0114] For example, such as Figure 5 As shown, the process of querying the expected configuration by BMC may include the following steps S231 to S233.

[0115] S231: Obtain the expected configuration file.

[0116] In step S231, the BMC can access its own registers or the server's storage unit based on the storage address of the expected configuration file, and read the expected configuration file generated based on the aforementioned steps S201 to S203, thereby obtaining the server's own configuration requirements.

[0117] S232: Based on the first component type, query the expected configuration parameters that match the first component type in the expected configuration file.

[0118] In step S232, the BMC can query the expected configuration file for the same configuration entry as the first component type, and extract its associated expected configuration parameters. In one example, taking the hard disk backplane as the first component type, the BMC can locate the "hard disk backplane" entry in the expected configuration file and extract the parameter items that have not been configured, thus obtaining the expected configuration parameters that match the first component type.

[0119] For example, if the expected configuration file includes two hard disk backplane entries, where the expected configuration parameters for hard disk backplane A are 8 SAS channels and the expected configuration parameters for hard disk backplane B are 4 NVMe channels, then the BMC can determine the corresponding expected configuration parameters according to the specific type of the server component.

[0120] If the first information in the server component cannot be used to obtain more granular component types, or if the BMC cannot obtain a unique matching entry in the expected configuration file, the BMC can also extract all the expected configuration parameters corresponding to multiple entries and perform matching processing in the subsequent identification process.

[0121] S233: The expected configuration parameters that match the first component type are determined as the expected configuration.

[0122] In step S233, the BMC can determine the expected configuration parameters that it has extracted and that match the first component type as the corresponding expected configuration, so that the BMC can compare the expected configuration with the accessed server component in subsequent steps.

[0123] In one example, if multiple expected configuration parameters are extracted, the BMC can determine each expected configuration parameter as the expected configuration corresponding to each server component that needs to be connected to the server. When comparing the expected configuration with the second information, the BMC will use each expected configuration for matching and verification in turn. If the BMC detects that any expected configuration is consistent with the second information, it can determine that the second information of that server component is consistent with the expected configuration.

[0124] After BMC detects that an expected configuration matches the second information, it can mark the configuration entry corresponding to the expected configuration as a match after the server component corresponding to the second information has been identified and resources have been allocated. This avoids duplicate matching and ensures the accuracy and efficiency of subsequent configuration processes.

[0125] Through the above steps S210 to S233, BMC can match the corresponding expected configuration within the server based on the collected second information, and then determine whether the component meets the current deployment requirements. When the server component meets the requirements, the identification and resource allocation process is automatically triggered to complete the management operation of the server component.

[0126] Figure 6 This is a schematic diagram illustrating a process for obtaining configuration fields, provided in an embodiment of this application. The following is in conjunction with... Figure 6 The content shown illustrates, through example, the process by which the BMC obtains the configuration fields stored in the FRU of the server component in this embodiment of the application.

[0127] like Figure 6 As shown in (a), the process of BMC obtaining FRU configuration fields in this embodiment of the application may include the following steps S110 to S130.

[0128] S110: In response to a server component's request to establish a connection with the server, a communication connection is established between the server and the server component.

[0129] In step S110, the BMC can respond to signals such as component access request or component reset time to first establish a communication connection between the server and the server component, thereby providing a communication foundation for subsequent data reading and parsing.

[0130] In one example, the way BMC constructs communication connections between servers and server components is affected by the physical interface types used by the servers and server components. When establishing a communication connection, BMC can automatically negotiate communication parameters based on the interface protocol of the server components to which the server is connected, thereby completing the physical layer handshake and link initialization with the server components.

[0131] S120: Read field data stored in the FRU storage area by the server component.

[0132] In step S120, after establishing a communication connection with the server component, the BMC can read the corresponding field data in the FRU storage area of ​​the server component through the communication connection, so as to obtain the corresponding FRU configuration field.

[0133] In this embodiment, the BMC can access the FRU storage area located in the server component to obtain the binary data stream stored therein. For example, after establishing a communication connection, the BMC can send a probe signal to the component to confirm the existence of the device and trigger an FRU data read request. Upon receiving a response, the BMC performs segmented reading at the storage address corresponding to the FRU storage area, sequentially requesting the corresponding number of bytes from the FRU storage area to ensure complete acquisition of the first information, third information, second information, and verification field.

[0134] The BMC can locate the storage position of each field in the FRU using offset addresses. The offset address refers to the byte offset of the starting position of a field in the FRU storage area relative to the FRU header. In one example, the field data defined in the server component can be the first 16 bytes in the FRU storage area, with an offset address range of 0x00 to 0x0F. The BMC can obtain the corresponding field data by reading the binary data within this storage address range.

[0135] In some embodiments, the BMC can also use offset addresses to read fields in the FRU storage area sequentially according to address order and partitioning rules. When a read fails, a retry mechanism is automatically triggered to ensure the reliability of field reading and to make the reading process fault-tolerant.

[0136] S130: Obtain the FRU configuration fields based on the field data.

[0137] In step S130, after reading the obtained field data, the BMC can combine the field data according to the number of bytes and the order of arrangement of the fields to obtain the corresponding FRU configuration fields. In one example, the FRU configuration field read by the BMC is 16 bytes of binary data, where the byte at offset address 0x00 can be used as the first information in the FRU configuration field, the bytes at offset addresses 0x01 and 0x02 are the third information, the bytes at offset addresses 0x03–0x04 are the second information, and the field at offset address 0x0F is the check field. The fields strictly follow the byte alignment and boundary marking rules to reduce ambiguity in the parsing process.

[0138] In some embodiments of this application, the second information in the FRU configuration field may be multiple. For example, second information a is used to identify the relevant parameters actually used by the interface, second information b is used to identify the type of the adapted Central Processing Unit (CPU), and second information c is used to identify the adapted server model.

[0139] Different secondary information can be represented by fields with different offset addresses. For example, bytes at offset addresses 0x03–0x04 can represent secondary information 'a', bytes at offset addresses 0x05–0x06 can represent secondary information 'b', and bytes at offset addresses 0x07–0x08 can represent secondary information 'c'. Each information field is parsed independently and does not interfere with each other. This allows the BMC to parse the field data in the FRU storage area into its corresponding fields and combine the parsed fields into FRU configuration fields, providing structured data for subsequent automatic identification and on-demand configuration of server components.

[0140] After receiving the field data from the FRU, the BMC can validate the field data to avoid incomplete data reading or other errors. For example... Figure 6 As shown in (b) of this application embodiment, the process by which the BMC obtains the FRU configuration field may include the following steps S131 to S134.

[0141] S131: Obtain the first verification code of the field data based on the preset verification algorithm.

[0142] In step S131, after obtaining the field data, the BMC can perform verification operations on the field data according to the preset verification algorithm to obtain the first verification code of the field data.

[0143] BMC can determine the verification range corresponding to the verification algorithm based on the offset address of each byte in the field data. In one example, the verification range covers all bytes from offset address 0x00 to 0x0E, excluding the bytes corresponding to the verification field, so that the verification result is not affected by the checksum carried by the server component.

[0144] It should be noted that the verification algorithm used by BMC after obtaining the field data is the same as the verification algorithm used by the server component when writing the checksum in the FRU. This ensures that the checksum generated by the same field data is consistent, thereby ensuring the uniqueness and reproducibility of the verification result.

[0145] S132: Read the second checksum in the FRU storage area.

[0146] In step S132, the BMC determines the byte position corresponding to the second checksum by using the offset address corresponding to each byte in the field data, and reads the second checksum stored at that position. In one example, the second checksum is stored at offset address 0x0F, and the BMC can determine the byte corresponding to that offset address in the field data as the second checksum.

[0147] In some embodiments, when the BMC reads bytes stored in the FRU storage area, it can read each byte sequentially according to the order of its offset addresses to ensure data integrity and order consistency. After obtaining all bytes from offset addresses 0x00 to 0x0E, the BMC can execute the aforementioned step S131 to obtain the first checksum. Then, it reads the byte at offset address 0x0F in the FRU storage area and determines it as the second checksum.

[0148] S133: If the first check code matches the second check code, then the FRU configuration field is obtained based on the field data and the second check code.

[0149] In step S133, after obtaining the first check code and the second check code, the BMC can compare the two. If they match, the field data is determined to be complete and reliable. The BMC can combine the original field data and the second check code, and use the offset address to accurately parse each byte in it to obtain the specific values ​​of the first information, the third information and the second information. The second check code is used as the check field to combine and obtain the corresponding FRU configuration field.

[0150] S134: If the first check code and the second check code are inconsistent, a fourth alarm message is generated.

[0151] In step S134, if there is a difference between the first and second check codes obtained by the BMC, it is determined that the field data read by the BMC is corrupted or tampered with. At this time, the BMC can trigger an alarm mechanism to generate a fourth alarm message to notify the server maintenance personnel that the FRU storage area data is corrupted or read abnormally.

[0152] In some embodiments, when the first checksum and the second checksum are inconsistent, the BMC can first delete the collected field data, trigger the retransmission mechanism, and control the BMC to re-execute the above steps S120 and S131 to S132 to reread and verify the FRU data. If the newly obtained first checksum matches the second checksum, the BMC continues to execute step S133 and generates an alarm log to record the checksum inconsistency event and the retry success time, facilitating subsequent auditing and tracing.

[0153] If the newly obtained first verification code is still inconsistent with the second verification code, it is determined that the data anomaly continues. The BMC can generate a fourth alarm message, which may include the time of the anomaly occurrence, the first verification code generated by the two verifications, and the part number of the abnormal component, so that maintenance personnel can quickly locate the source of the fault and initiate the spare parts replacement process.

[0154] Through the above steps S110 to S134, the embodiments of this application can realize the acquisition and automatic verification of information in the configuration fields of server components, which makes it convenient for BMC to use the FRU configuration fields to configure server components in subsequent processes. At the same time, it takes into account the integrity of data collection, configuration flexibility and fault traceability, avoids server component identification errors and configuration failures caused by abnormal data reading, and optimizes the server's management effect on server components.

[0155] Figure 7 This is a flowchart illustrating a verification server component configuration provided in an embodiment of this application. Figure 8 This is a schematic diagram of a server component provided in an embodiment of this application. The following is in conjunction with... Figure 7 and Figure 8 The content shown illustrates the process of configuring the BMC verification server component.

[0156] like Figure 7 As shown, the configuration process of the BMC verification server component in this embodiment may include the following steps S401 to S404.

[0157] S401: Based on the second information and the preset cable connection scheme, determine the expected connection relationship between the server component and the server.

[0158] In step S401, after the BMC writes the expected configuration into the second information, or after the BMC determines that the field value of the second information it collects in the FRU storage area of ​​the server component is not empty and is consistent with the expected configuration, the BMC can first determine the expected connection relationship of the server component so that the BMC can allocate resources such as transmission channels to the server component and verify whether the actual physical connection is consistent with the expectation.

[0159] In one example, the pre-defined cable connection scheme in BMC is the standard cabling logic followed by the server when connecting to server components. This allows the server to determine the expected connection relationship between the server components and the server when the number of connection interfaces between the server and the server components is different, so that BMC can allocate server system resources to the server components in subsequent processes.

[0160] like Figure 8As shown in (a), the hard disk backplane 810 may be provided with four connectors 811 and two hard disk interfaces 812 corresponding to each connector 811. The two hard disk interfaces 812 on each connector 811 enable each connector 811 to connect two hard disks 813.

[0161] Taking the second information as 0x08 as an example, the BMC can determine that all four connectors 811 in the hard disk backplane 810 are connected to the server, and each connector 811 is in dual hard disk mode. During the execution of step S400, the BMC allocates resources such as transmission channels to the server components, that is, it allocates an independent transmission channel to each connector 811, so that the server can establish a complete communication link with the corresponding two hard disks 813 through the connector 811.

[0162] However, when the second information is 0x02, only one connector 811 in the hard disk backplane 810 is connected to the server, and this connector 811 is in dual hard disk mode. At this time, when the BMC executes step S400, it needs to allocate transmission channels and other resources only to the connector 811 with the connection relationship, while the other three connectors remain in a resource dormant state to avoid channel conflicts and bandwidth waste.

[0163] In one example, the BMC can obtain the preset cable connection scheme of the server component based on the content of the second information, thereby determining the expected connection relationship and corresponding cable topology between the server and the server component. Taking the hard drive backplane 810 as an example, when the second information is 0x02, the cable connection scheme provided by the BMC is that connector 811a is connected to hard drives 813a and 813b. Accordingly, the BMC can determine this connection relationship as the expected connection relationship.

[0164] like Figure 8 As shown in (b), the Riser Card 820 can have three Slots 821, each corresponding to a cable module mounting position. When the second information is 0x03, the BMC determines that all three Slots 821 are enabled. At this time, during the allocation of system resources, the BMC needs to allocate independent PCIe link resources for Slots 821a, 821b, and 821c respectively to ensure that all three can carry high-speed data transmission tasks. When the second information is 0x01, the BMC only needs to allocate PCIe link resources for one Slot 821. At this time, the BMC can determine the expected connection relationship between the server components and the server based on the preset cable connection scheme, so as to detect and verify the cable connection status in subsequent steps.

[0165] S402: Detect the physical connection status between server components and the server.

[0166] In step S402, the BMC can determine the physical connection status between the server component and the server by sending signals and receiving feedback signals.

[0167] In one example, the server component can be equipped with a corresponding connection detection pin for the interface. By connecting to this pin, the BMC can detect the interface level in the server component and then determine whether the cable is connected based on the level status.

[0168] S403: If the physical connection status is detected to meet the expected connection relationship, then identify the server component and allocate transmission channel resources to the server component.

[0169] In step S403, the BMC can compare the expected connection relationship of the component with the physical connection status to determine whether they are completely matched. When the expected connection relationship and the physical connection status are consistent, the BMC determines that the cable connection is correct, and the BMC can execute the subsequent step S400 to identify the server component and allocate the corresponding transmission channel resources to the server component.

[0170] S404: If the physical connection status is detected as not meeting the expected connection relationship, a third alarm message is generated.

[0171] In step S404, when the BMC detects that the expected connection relationship and physical connection status of the component are inconsistent, it can generate a third alarm message. The third alarm message is used to indicate that the cable connection is abnormal or the component is installed in the wrong position, so as to prompt the maintenance personnel to check the cable connection abnormality or the component installation position error.

[0172] In this embodiment, when the number of interfaces corresponding to the physical connection state is less than the number of interfaces required for the expected connection relationship, the BMC will trigger a resource allocation degradation mechanism, activating only the functional modules corresponding to the connected interfaces and dynamically adjusting the bandwidth allocation strategy. Conversely, when the number of interfaces corresponding to the physical connection state exceeds the number of interfaces required for the expected connection relationship, the BMC will generate a third alarm message and stop the resource allocation process for that component to prevent signal conflicts or abnormal power consumption caused by redundant connections.

[0173] Through the above steps S401 to S404, BMC can verify the connection relationship between the server and each server component, ensuring that the physical connection relationship of the server component is consistent with the configuration information identified by BMC, thereby ensuring the resource allocation of the component interface and avoiding the risk of performance degradation or system downtime due to connection deviation.

[0174] Figure 9 This is a schematic diagram illustrating a resource allocation process provided in an embodiment of this application. The following is in conjunction with... Figure 9The content shown illustrates, by way of example, the process of BMC allocating resources when the second information is not empty, according to an embodiment of this application.

[0175] like Figure 9 As shown, in this embodiment of the application, the process of BMC allocating resources to server components may include the following steps S301 to S307.

[0176] S301: If the second information is not empty, obtain the field value of the second information and the configuration field value corresponding to the expected configuration.

[0177] In step S301, after executing step S200, BMC can detect the field value of the second information. When the field value corresponding to the second information is empty, BMC can execute step S300 to generate the corresponding second information for the server component.

[0178] When the second information is not empty, the BMC will obtain the field value corresponding to the second information and the configuration field value corresponding to the expected configuration, so that the server can compare the configuration in the server component with the expected configuration in the server.

[0179] S302: Validate the field values ​​of the second information based on the third information.

[0180] In step S302, when the BMC detects that the second information is a non-empty value, it can verify the field value in the second information according to the third information to determine whether the field value corresponding to the second information is within the maximum supported range defined by the third information.

[0181] Taking the hard drive backplane as an example of a server component, if the third information indicates that it supports a maximum of 8 NVMe interfaces, while the second information is set to configure 12 NVMe interfaces, then it is determined that the configuration is out of bounds; or, if the second information is set to configure 2 SAS interfaces, then the BMC can determine that the second information is outside the maximum support range defined by the third information, thus avoiding hardware damage or protocol incompatibility issues caused by configuration out of bounds.

[0182] S303: If the field value of the second information is within the range of the third information, then compare the field value of the second information with the configuration field value.

[0183] In step S303, if the BMC determines that the field value of the second information is within the range of the third information, it can trigger a field comparison process to compare the field value of the second information with the expected configuration field value bit by bit. If they match, the subsequent step S305 is executed to enter the resource allocation stage; if they do not match, the BMC will stop the resource allocation process and trigger an alarm mechanism to prompt the operation and maintenance personnel to check the field value of the second information stored in the server components.

[0184] S304: If the field value of the second information is outside the range of the third information, then generate the first alarm information.

[0185] In step S304, if the BMC determines that the field value of the second information is outside the range of the third information, the BMC's alarm mechanism is triggered, a first alarm message is generated and pushed to the operation and maintenance personnel, and the first alarm message is used to indicate that the configuration information of the server component has exceeded the limit.

[0186] In one example, after generating the first alarm message, BMC can stop the identification and resource allocation process of the server component, record the alarm timestamp, component type, out-of-bounds configuration items and capability limits, and synchronously update the status field in the component management database to "configuration anomaly" to ensure that subsequent operation and maintenance are traceable.

[0187] S305: When the field value of the second information is the same as the configuration field value, activate the port corresponding to the field value of the second information in the server component based on the field value of the second information and the component type.

[0188] In step S305, after determining that the field value of the second information is within the range of the third information, the BMC can determine whether the field value of the second information is the same as the configuration field value. If they are the same, the BMC can activate the port corresponding to the field value of the second information in the server component according to the field value of the second information and the component type, so as to start the process of the BMC allocating system resources.

[0189] S306: Based on the port, determine the channel to be enabled for server components.

[0190] In step S306, the BMC can determine the protocols and bandwidth specifications supported by the server component based on the activated ports, and then determine the number and topology of the channels to be activated by the server component, so that the BMC can allocate corresponding transmission channel resources for each channel to be activated in subsequent steps.

[0191] S307: Allocate transmission channel resources corresponding to the channel to be enabled to the server component.

[0192] In step S307, after obtaining the corresponding channel to be enabled, the BMC can allocate transmission channel resources such as PCIe links, memory bandwidth and power management policies to each channel, and synchronously update the resource configuration status of the server, so that the resource configuration status is synchronized with the component management database in real time, ensuring that the entire life cycle of the server components is traceable.

[0193] Based on steps S301 to S307, BMC can identify and configure server components whose second information is not empty, and at the same time use the third information to strongly verify the legality of the configuration, so as to avoid system-level compatibility risks caused by human misconfiguration or firmware abnormalities.

[0194] Figure 10 This is a flowchart illustrating a verification configuration field provided in an embodiment of this application. The following is in conjunction with... Figure 10 The content shown illustrates the process of BMC verification configuration fields in this application embodiment.

[0195] like Figure 10 As shown, in this embodiment of the application, the process by which the BMC verifies the configuration field it obtains may include the following steps S310 to S330.

[0196] S310: Verify configuration field values ​​based on third-party information.

[0197] In step S310, after obtaining the expected configuration and the corresponding configuration field value, the BMC can use the third information to verify whether the configuration field value is within the maximum supported range defined by the third information, so as to determine whether the BMC can write the configuration field value into the second information based on the state of the configuration field value.

[0198] S320: If the configuration field value is within the range of the third information, then write the configuration field value into the second information.

[0199] In step S320, if the configuration field value is within the range of the third information, the BMC can write the configuration field value into the second information and trigger the check code update mechanism to update the check field stored in the component FRU storage area to ensure the integrity of the configuration data.

[0200] S330: If the configuration field value is outside the range of the third information, then generate the second alarm information.

[0201] In step S330, if the configuration field value exceeds the limit of the third information, the BMC immediately generates a second alarm message, prompting the maintenance personnel that the expected configuration in the server does not match the specifications of the server components. This avoids hardware anomalies or system crashes caused by configuration exceeding limits, ensuring the stable operation of the server in complex and ever-changing deployment scenarios.

[0202] Based on steps S310 to S330, BMC can verify the configuration field values ​​corresponding to the expected configuration to ensure that they are strictly within the legal range defined by the third information, avoid the risk of configuration going out of bounds, ensure the stable operation of the server, and improve the server's identification efficiency and configuration accuracy for different types of server components.

[0203] Figure 11 This is a schematic diagram of a management system for a server component provided in an embodiment of this application.

[0204] Corresponding to the aforementioned embodiments of server component management methods, this application also provides embodiments of a server component management system. For example... Figure 11 As shown, the server component management system 1100 may include a configuration reading unit 1110, a field processing unit 1120, and a component identification unit 1130.

[0205] The configuration reading unit 1110 is configured to establish a connection with the server in response to a request from the server component and obtain the field replaceable unit (FRU) configuration field stored in the server component. The FRU configuration field includes first information and second information, wherein the first information is used to indicate the type of the server component and the second information is used to indicate the enable configuration of the server component in actual application.

[0206] The field processing unit 1120 is configured to determine the component type of the server component based on the first information, and to query the expected configuration of the server component in the server; and, if the second information is null, to write the expected configuration into the second information.

[0207] The component identification unit 1130 is configured to identify server components and allocate transmission channel resources to the server components based on first information and second information.

[0208] Figure 12 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0209] like Figure 12 As shown, the computing device 1200 includes a processor 1201 and a memory 1202. Exemplarily, the computing device 1200 may also include a communications interface 1203 and a communications bus 1204.

[0210] The processor 1201, memory 1202, and communication interface 1203 communicate with each other via communication bus 1204. The communication interface 1203 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0211] In some embodiments, the processor 1201 is used to execute program 1205, specifically performing the relevant steps in the above-described server component management method embodiments. Specifically, program 1205 may include program code, which includes computer-executable instructions.

[0212] For example, processor 1201 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1200 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0213] In some embodiments, memory 1202 is used to store program 1205. Memory 1202 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0214] Specifically, program 1205 can be called by processor 1201 to cause computing device 1200 to perform management methods for server components.

[0215] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1200, causes the computing device 1200 to perform the server component management method described in the above embodiments.

[0216] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0217] This application provides a chip system for use in a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the server performs various steps in the server component management method shown in the above-described method embodiments.

[0218] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the management method of the corresponding server component provided above, and will not be repeated here.

[0219] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method for managing server components, characterized in that, The method, applied to a baseboard management controller within a server, includes: In response to a server component requesting to establish a connection with the server, the configuration field of the Field Replaceable Unit (FRU) stored in the server component is obtained; the FRU configuration field includes first information and second information, wherein the first information is used to indicate the type of the server component, and the second information is used to indicate the enable configuration of the server component in actual application; Based on the first information, determine the component type of the server component, and query the expected configuration of the server component in the server; If the second information is empty, the expected configuration is written into the second information; The baseboard management controller identifies the server component and allocates transmission channel resources to the server component based on the first information and the second information.

2. The method according to claim 1, characterized in that, The step of determining the component type of the server component based on the first information, and querying the expected configuration of the server component in the server, includes: Obtain a preset component type mapping table; the component type mapping table stores the correspondence between the field values ​​of the first information and the component types; Based on the field values ​​of the first information, determine the first component type of the server component; Query the expected configuration corresponding to the server component of the first component type in the server.

3. The method according to claim 2, characterized in that, Before responding to a server component's request to establish a connection with the server and obtaining the FRU configuration field stored in the server component, the method further includes: In response to receiving a component configuration instruction, the component configuration requirement information of the server is determined; the component configuration requirement information includes the component type of the server component to be connected and the expected configuration parameters of each server component; Establish a mapping relationship between the component type of the server component and the expected configuration parameters; Store the mapping relationship to obtain the expected configuration file; The step of querying the server component of the first component type for the expected configuration in the server includes: Obtain the expected configuration file; Based on the first component type, query the expected configuration parameters that match the first component type in the expected configuration file; The expected configuration parameters that match the first component type are determined as the expected configuration.

4. The method according to any one of claims 1 to 3, characterized in that, If the second information is empty, the expected configuration is written into the second information, including: Based on the preset configuration mapping relationship, the expected configuration is converted into configuration field values; Write the configuration field value into the second information.

5. The method according to any one of claims 1 to 4, characterized in that, After determining the component type of the server component based on the first information and querying the expected configuration of the server component in the server, the method further includes: If the second information is not empty, obtain the field values ​​of the second information and the configuration field values ​​corresponding to the expected configuration; When the field value of the second information is the same as the configuration field value, the port corresponding to the field value of the second information in the server component is activated based on the field value of the second information and the component type. Based on the port, determine the channel to be enabled for the server component; Allocate transmission channel resources corresponding to the channel to be enabled to the server component.

6. The method according to claim 5, characterized in that, The FRU configuration field also includes third information, which indicates the maximum support capability of the server component. After obtaining the field value of the second information and the configuration field value corresponding to the expected configuration, the method further includes: Based on the third information, verify the field values ​​of the second information; If the field value of the second information is within the range of the third information, then compare the field value of the second information with the configuration field value; If the field value of the second information is outside the range of the third information, a first alarm message is generated; the first alarm message is used to indicate that the configuration information of the server component has exceeded the limit.

7. The method according to claim 6, characterized in that, Before writing the expected configuration into the second information, the method further includes: Based on the third information, verify the value of the configuration field; If the value of the configuration field is within the range of the third information, then the value of the configuration field is written into the second information; If the value of the configuration field is outside the range of the third information, a second alarm message is generated; the second alarm message is used to indicate that the expected configuration does not conform to the specifications of the server components.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The baseboard management controller acquires order configuration information, which includes the enable configuration requirements for the server component in the application. The order configuration information is written into the third information stored in the server component.

9. The method according to claim 8, characterized in that, The step of writing the order configuration information into the third information stored in the server component includes: During the production or assembly of the server component, the production system writes the order configuration information into the third information of the server component.

10. The method according to any one of claims 1 to 9, characterized in that, Before the baseboard management controller identifies the server component and allocates transmission channel resources to the server component based on the first information and the second information, the method further includes: Based on the second information and the preset cable connection scheme, the expected connection relationship between the server component and the server is determined; Detect the physical connection status between the server component and the server; If the physical connection state is detected to satisfy the expected connection relationship, then the server component is identified and transmission channel resources are allocated to the server component; If the physical connection status is detected to be inconsistent with the expected connection relationship, a third alarm message is generated; the third alarm message is used to indicate abnormal cable connection or incorrect component installation position.

11. The method according to any one of claims 1 to 10, characterized in that, The step of obtaining the Field Replaceable Unit (FRU) configuration fields stored in the server component includes: In response to the server component's request to establish a connection with the server, a communication connection is established between the server and the server component; Read the field data stored in the FRU storage area of ​​the server component; Based on the field data, the FRU configuration field is obtained.

12. The method according to claim 11, characterized in that, The method for obtaining the FRU configuration field based on the field data further includes: Based on a preset verification algorithm, the first verification code of the field data is obtained; Read the second checksum from the FRU storage area; If the first check code matches the second check code, then the FRU configuration field is obtained based on the field data and the second check code; If the first check code does not match the second check code, a fourth alarm message is generated; the fourth alarm message is used to indicate that the data in the FRU storage area is corrupted or read abnormally.

13. A management system for server components, characterized in that, include: The configuration reading unit is configured to establish a connection with the server in response to a request from the server component, and to obtain the Field Replaceable Unit (FRU) configuration field stored in the server component; the FRU configuration field includes first information and second information, wherein the first information is used to indicate the type of the server component, and the second information is used to indicate the enable configuration of the server component in actual application; The field processing unit is configured to determine the component type of the server component based on the first information, and query the expected configuration of the server component in the server; and, if the second information is null, write the expected configuration into the second information. The component identification unit is configured to identify the server component and allocate transmission channel resources to the server component based on the first information and the second information.

14. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled; the memory is used to store program instructions. The processor is used to execute the program instructions to perform the management method of the server component as described in any one of claims 1 to 12.