CN116820596A - FRU (field replaceable unit) management method, device and system - Google Patents

Abstract

The application provides a field replaceable unit FRU management method, equipment and a system, and relates to the technical field of computers. The method is used for a first device, the first device automatically responds to a creation request after receiving the creation request on the basis that the first device comprises a target FRU, automatically creates a configuration file of the target FRU based on configuration content in the configuration file of the target FRU carried by the creation request, and then manages the target FRU based on the created configuration file of the target FRU. Because the first device can automatically create the configuration file of the target FRU based on the creation request, compared with the prior art in which the configuration file of the target FRU can be configured for the first device only by developing, testing, releasing the version and other processes of the firmware program, the method is beneficial to reducing the cost of replacing the target FRU and improving the efficiency of replacing the target FRU.

Description

Field replaceable unit FRU management method, equipment and system

Technical field

The present application relates to the field of computer technology, and in particular to a field replaceable unit FRU management method, equipment and system.

Background technique

A field replaceable unit (FRU) is a replaceable component on a hardware device. After the hardware device is replaced with a new FRU, if the management component of the hardware device wants to manage the new FRU, it needs to configure the configuration file of the new FRU for the management component.

In the related art, the configuration file of a new FRU is configured for the management component, usually by upgrading the firmware program of the management component. Upgrading the firmware program of the management component usually requires processes such as development, testing, and version release. As a result, when replacing FRUs on multiple hardware devices at the same time, it is necessary to develop, test, version release and other processes for the firmware programs of the management components of multiple hardware devices, which is not only extremely costly, but also very inefficient.

Contents of the invention

Embodiments of the present application provide a FRU management method, device, and system that can automatically create a FRU configuration file, which not only helps reduce the cost of replacing an FRU, but also helps improve the efficiency of replacing an FRU.

In order to achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

In a first aspect, a field replaceable unit FRU management method is provided for a first device, and the first device includes a target FRU; the method includes: receiving a creation request, and the creation request is used to request the creation of a configuration file of the target FRU; creating The request includes configuration content in the configuration file of the target FRU; in response to the creation request, a configuration file of the target FRU is created based on the configuration content in the configuration file of the target FRU; and based on the configuration file of the target FRU, the target FRU is managed.

In this embodiment, on the basis that the first device includes the target FRU, after the first device receives the creation request, since the creation request carries the configuration content in the configuration file of the target FRU, the first device responds to the creation request. request, automatically create the configuration file of the target FRU based on the configuration content in the configuration file of the target FRU carried in the creation request, and then manage the target FRU based on the created configuration file of the target FRU. Since the first device can automatically create the configuration file of the target FRU based on the creation request and the configuration content in the configuration file of the target FRU carried in the creation request, therefore, compared to the related technology, the firmware program needs to be developed, tested, and released. Waiting for the process to configure the configuration file of the target FRU for the first device not only helps to reduce the cost of replacing the target FRU, but also helps to improve the efficiency of replacing the target FRU.

In a possible implementation, the creation request is sent by the client device in response to a creation instruction. The creation instruction is used to instruct the first device to send a creation request for the configuration file of the target FRU. The client device stores the configuration of the target FRU. Configuration content in the file.

In this implementation, when the user determines that the first device needs to use the configuration file of the target FRU, the client device is instructed to send a creation request to the first device through a create instruction, so that the first device can automatically create the configuration file of the target FRU, so that , not only saves the time for the first device to obtain from other devices, but also helps to increase the necessity of the configuration file of the target FRU created by the first device, and avoids creating the configuration file when the configuration file of the target FRU is not needed.

In another possible implementation, the method further includes: receiving a query request sent by the client device, the query request being used to request to query the FRU type supported by the first device; in response to the query request, sending the target FRU type to the client device ; Wherein, the target FRU type is a FRU type supported by the first device.

In this implementation, by receiving the query request sent by the client and responding to the query request, the FRU type supported by the first device is returned to the client, so that the client device can understand the FRU type supported by the first device. In this way, it is helpful to The configuration file requested in the creation request matches the FRU type supported by the first device, thereby helping to ensure that the first device can successfully use the created configuration file.

In another possible implementation, the method further includes: receiving a first start request sent by the client device. The first start request is used to request to start the FRU configuration service of the first device, so that the first device supports creating the target FRU. configuration file; in response to the first enable request, set the FRU configuration management service of the first device to an enabled state.

In this implementation, in response to the received first enable request, the first device sets the FRU configuration management service of the first device to an enabled state, so that the first device supports creating a configuration file of the target FRU. Since the first device only supports creating the configuration file of the target FRU when the FRU configuration management service is set to on, this helps avoid creating configuration files without permission, thereby helping to ensure the security of FRU management. sex.

In another possible implementation, the method also includes: when the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device; the second device stores the configuration file of the target FRU, and obtains the request. Used to request to obtain the configuration content in the configuration file; wherein the creation request is sent by the second device in response to the acquisition request.

In this implementation, when the first device does not configure the configuration file of the target FRU, the first device actively sends an acquisition request to the second device to request to obtain the configuration content in the configuration file of the target FRU. In this way, it is helpful to Improve the convenience and automation of creating target FRU configuration files for the second device.

In another possible implementation, when the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device includes: in response to the received target instruction, sending an acquisition request to the second device ; The target instruction is used to instruct to obtain the configuration content in the configuration file of the target FRU from the second device. The target instruction is sent when the first device does not configure the configuration file of the target FRU.

In this implementation, the first device sends an acquisition request to the second device in response to the target instruction sent by the client. In this way, when the user determines that the first device needs to use the configuration file of the target FRU, the first device can be instructed to Sending a retrieval request to the second device helps to increase the necessity of configuring content retrieval.

In another possible implementation, when the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device includes: responding to the target scan result, sending an acquisition request to the second device; target scan The results include that the configuration file of the target FRU was not scanned on the first device.

In this implementation, the first device automatically sends an acquisition request to the second device in response to the target scan result without user participation, which helps to improve the convenience and automation of configuration content acquisition.

In another possible implementation, in response to the creation request, create a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU, including: if the configuration content in the configuration file meets preset conditions, respond to the creation request , based on the configuration content in the configuration file, create the configuration file of the target FRU.

In this implementation, if the configuration content in the configuration file meets the preset conditions, the creation request will be responded to. This helps to avoid using non-compliant configuration content to create the configuration file, resulting in management goals based on the created configuration file. FRU, causing the target FRU to function abnormally.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the pre-attribute name; wherein the attribute name of the configuration content includes the manufacturer identification and PN component of the target FRU. At least one of the identification, SN serial number, model, name, FRU type and model identification.

In this implementation, whether the configuration content meets the preset conditions is determined by whether the attribute name of the configuration content is the same as the preset attribute name. This helps ensure the integrity of the configuration content parsed from the configuration file.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; where, the configuration The attribute name of the content includes at least one of the manufacturer identification, PN component identification, SN serial number, model, and name of the target FRU.

In this implementation, it is determined whether the configuration content meets the preset conditions by whether the attribute name of the configuration content is the same as the preset attribute name, and whether the field type of the configuration content is the same as the preset field type. This helps to ensure that the configuration content is The accuracy and completeness of the configuration content parsed in the file.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; where, the configuration The attribute name of the content includes the model ID and/or FRU type of the target FRU.

In this implementation, it is determined whether the configuration content meets the preset conditions by whether the attribute name of the configuration content is the same as the preset attribute name, and whether the attribute value of the configuration content is the same as the preset attribute value. This helps to ensure that the configuration content is the same as the preset attribute name. The accuracy and completeness of the configuration content parsed in the file.

In another possible implementation manner, the acquisition request includes the name of the target FRU, and the acquisition request is used to request to obtain the configuration content in the configuration file indicated by the name of the target FRU.

In this implementation, since the name of the FRU configuration file is the same as the name of the FRU, the acquisition request includes the name of the target FRU and requests to obtain the configuration content in the configuration file indicated by the name of the target FRU. In this way, When you need to obtain the configuration content in the configuration file of a specific FRU, it helps to ensure the accuracy of the obtained configuration content.

In another possible implementation, the acquisition request includes the model identification of the first device, the acquisition request is used to request to obtain the configuration content in the configuration file supported by the model identification, and the configuration file of the target FRU is the configuration supported by the model identification. document.

In this implementation, the acquisition request is set to include the model identification of the first device, and the configuration content in the configuration file indicated by the model identification is requested. In this way, when multiple FRUs are replaced on the first device, multiple FRUs need to be obtained. It helps to improve the efficiency of obtaining the configuration content in the configuration files of multiple FRUs.

In another possible implementation, when the acquisition request includes the model identification of the first device, the acquisition request may also include the target FRU type, and the target FRU type is the FRU type supported by the first device. The acquisition request is used to request Obtain the configuration content in the configuration file belonging to the target FRU type. The configuration file of the target FRU is a configuration file belonging to the target FRU type.

In this implementation, by setting the acquisition request to include the target FRU type, it is used to indicate that the configuration file requested by the acquisition request should belong to the target FRU type. In this way, it helps to ensure that the configuration of the target FRU obtained by the first device from the second device The file can be matched with the first device, thereby helping to ensure that the first device can normally use the obtained configuration file.

In another possible implementation, the configuration content in the configuration file is in JSON format; receiving the creation request includes: receiving the creation request based on the first interface; the first interface supports transmitting data in JSON format.

In this implementation, since the configuration file of the FRU is a JSON file and the configuration content in the configuration file of the FRU is in JSON format, the first device receives the configuration content in the configuration file of the target FRU through the first interface, and the first interface Supports the transmission of JSON format files, so that when transmitting configuration content, there is no need to convert the data format, which helps ensure the convenience and accuracy of data transmission.

In another possible implementation, the method further includes: sending a second start request to the second device. The second start request is used to request to start the FRU configuration management service of the second device, so that the second device supports exporting the configuration file. configuration content in.

In this implementation, the FRU configuration management service is configured by setting the second device. When the FRU configuration management service is on, the second device can export the configuration file of the target FRU. When it is off, the second device cannot export the configuration of the target FRU. The file, in this way, helps ensure the security of the FRU's configuration file in the second device.

In another possible implementation, the method further includes: setting the FRU configuration management server of the first device to an open state, so that the first device supports creating a configuration file of the target FRU.

In this implementation, when the FRU configuration management server of the first device is set to the open state, the first device supports the creation of the configuration file of the target FRU. This helps to avoid the creation of the configuration file without permission, and thus Helps ensure the security of FRU management.

In a second aspect, a field replaceable unit FRU management method is provided for a second device, where a configuration file of a target FRU is stored; the method includes: receiving an acquisition request; and the acquisition request is used to request acquisition of the target FRU. The configuration content in the configuration file; in response to the acquisition request, send a creation request to the device that sent the acquisition request; the creation request includes the configuration content in the configuration file of the target FRU, and the creation request is used to request the creation of the configuration file of the target FRU, and the target FRU The configuration file is used to manage the target FRU on the device that sends the acquisition request; or in response to the acquisition request, the configuration content in the configuration file of the target FRU is sent to the device that sends the acquisition request.

In this solution, when the configuration file of the target FRU is stored in the second device, the second device responds to the received acquisition request by returning the creation request or the configuration content in the configuration file of the target FRU, thereby achieving the target FRU. The configuration content in the configuration file is exported, so that other devices can use the configuration content in the target FRU's configuration file to create the target FRU's configuration file. Compared with related technologies, processes such as firmware program development, testing, and version release are required. Only then can the configuration file of the target FRU be configured for the first device, which not only helps to reduce the cost of replacing the target FRU, but also helps to improve the efficiency of replacing the target FRU.

In one possible implementation, the acquisition request is sent by the client device in response to the acquisition instruction.

In another possible implementation manner, the acquisition request is sent by the first device when the first device does not configure the configuration file of the target FRU.

In another possible implementation, responding to the acquisition request includes: responding to the acquisition request if the configuration content in the configuration file meets preset conditions.

In this implementation, when the configuration content in the configuration file meets the preset conditions, the configuration content in the configuration file is sent to the server in response to the acquisition request. This helps to avoid that the configuration content belongs to non-FRU configuration files, thereby improving export The accuracy and security of the configuration content.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the pre-attribute name; wherein the attribute name of the configuration content includes the manufacturer identification and PN component of the target FRU. At least one of the identification, SN serial number, model, name, FRU type and model identification.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; where, the configuration The attribute name of the content includes at least one of the manufacturer identification, PN component identification, SN serial number, model, and name of the target FRU.

In another possible implementation, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; where, the configuration The attribute name of the content includes the model ID and/or FRU type of the target FRU.

In another possible implementation manner, the acquisition request includes the name of the target FRU, and the acquisition request is used to request to acquire the configuration file indicated by the name of the target FRU.

In another possible implementation manner, the acquisition request includes a model identifier of the first device, the acquisition request is used to request acquisition of a configuration file supported by the model identifier, and the configuration file supported by the model identifier includes a configuration file of the target FRU.

In another possible implementation, when the acquisition request includes the model identification of the first device, the acquisition request may also include the target FRU type, and the target FRU type is the FRU type supported by the first device. The acquisition request is used to request Get the configuration file belonging to the target FRU type.

In another possible implementation, the configuration content in the configuration file is in JSON format; in response to the acquisition request, sending a creation request to the device that sent the acquisition request, including: in response to the acquisition request, based on the second interface, sending the acquisition request to The device sends a creation request; the second interface supports transmitting data in JSON format.

In this implementation, since the configuration file of the FRU is a JSON file and the configuration content in the configuration file of the FRU is in JSON format, the second device transmits the configuration content in the configuration file of the target FRU through the second interface, and the second interface Supports the transmission of JSON format files, so that when transmitting configuration content, there is no need to convert the data format, which helps ensure the convenience and accuracy of data transmission.

In another possible implementation, the configuration content in the configuration file is in JSON format; in response to the acquisition request, the configuration content in the configuration file of the target FRU is sent to the device that sent the acquisition request, including: in response to the acquisition request, based on the The second interface sends the configuration content in the configuration file of the target FRU to the device that sends the acquisition request.

In this implementation, since the configuration file of the FRU is a JSON file and the configuration content in the configuration file of the FRU is in JSON format, the second device transmits the configuration content in the configuration file of the target FRU through the second interface, and the second interface Supports the transmission of JSON format files, so that when transmitting configuration content, there is no need to convert the data format, which helps ensure the convenience and accuracy of data transmission.

In another possible implementation, the method further includes: receiving a second start request sent by the first device. The second start request is used to request to start the FRU configuration management service of the second device so that the second device supports exporting the configuration. Configuration content in the file; in response to the second enable request, set the FRU configuration management service of the second device to an enabled state.

In this implementation, in response to the received second enable request, the second device sets the FRU configuration management service of the second device to the enabled state, so that the second device supports exporting the configuration content in the configuration file. This helps This prevents the configuration content in the configuration file on the second device from being exported without permission, thereby helping to ensure the security of the FRU configuration file on the second device.

In another possible implementation, the method further includes: receiving a third start request sent by the client device. The second start request is used to request to start the FRU configuration management service of the second device so that the second device supports exporting the configuration. Configuration content in the file; in response to the second enable request, set the FRU configuration management service of the second device to an enabled state.

In this implementation, in response to the received third creation request, the second device sets the FRU configuration management service of the second device to an open state, so that the second device supports exporting the configuration content in the configuration file. This helps This prevents the configuration content in the configuration file on the second device from being exported without permission, thereby helping to ensure the security of the FRU configuration file on the second device.

In a third aspect, a field replaceable unit FRU management method is provided for a client device. The client device stores the configuration content in the configuration file of the target FRU; the method includes: in response to the creation instruction, sending a request to the first device. Send a creation request; the creation request is used to request the creation of the configuration file of the target FRU; the creation request includes the configuration content in the configuration file.

In this solution, when the configuration content in the configuration file of the target FRU is stored in the client device, the client device actively sends a creation request to the first device, so that the first device can based on the configuration content in the configuration file of the target FRU. Configure content and automatically create the configuration file of the target FRU. Compared with related technologies, which require the development, testing, version release and other processes of the firmware program to configure the configuration file of the target FRU for the first device, it not only helps to reduce the cost of replacing the target FRU. The cost also helps to improve the efficiency of replacing the target FRU.

In a possible implementation, the method further includes: in response to the acquisition instruction, sending an acquisition request to the second device; the acquisition request is used to request to acquire the configuration content in the configuration file of the target FRU; receiving the configuration content sent by the second device Configuration content in the target FRU's configuration file.

In this implementation, the client device obtains the configuration content in the configuration file of the target FRU from the second device by sending an acquisition request to the second device, and then can use the configuration content in the configuration file of the target FRU to create the configuration of the target FRU. File, compared with related technologies, it is necessary to develop, test, version release and other processes of the firmware program to obtain the configuration content in the FRU configuration file, which not only helps to reduce the cost of obtaining the configuration content, but also helps to improve the configuration content. Content efficiency.

In another possible implementation manner, the acquisition request includes the name of the target FRU, and the acquisition request is used to request to obtain the configuration content in the configuration file indicated by the name of the target FRU.

In another possible implementation, the acquisition request includes the model identification of the first device, the acquisition request is used to request to obtain the configuration content in the configuration file supported by the model identification, and the configuration file of the target FRU is the configuration supported by the model identification. document.

In another possible implementation, when the acquisition request includes the model identification of the first device, the acquisition request may also include the target FRU type, and the target FRU type is the FRU type supported by the first device. The acquisition request is used to request Obtain the configuration content in the configuration file belonging to the target FRU type. The configuration file of the target FRU is a configuration file belonging to the target FRU type.

In another possible implementation, in response to the creation instruction, sending a creation request to the first device includes: in response to the creation instruction, sending a creation request to the first device based on a third interface; the third interface supports transmission of JSON format data.

In this implementation, since the configuration file of the FRU is a JSON file and the configuration content in the FRU configuration file is in JSON format, the client device sends the configuration content in the configuration file of the target FRU to the first device through the third interface. The third interface supports the transmission of JSON format files. In this way, when transmitting configuration content, there is no need to convert the data format, which helps ensure the convenience and accuracy of data transmission.

In another possible implementation, in response to the creation instruction, sending a creation request to the first device includes: sending a query request to the first device, where the query request is used to request to query the FRU type supported by the first device; receiving The target FRU type sent is a FRU type supported by the first device; in response to the creation instruction, a creation request is sent to the first device based on the target FRU type; wherein the target FRU belongs to the target FRU type.

In this implementation, a query request is sent to the first device, and based on the queried FRU type supported by the first device, a creation request is sent to the first device. In this way, it is helpful to create the configuration file requested by the request, and Matches the FRU type supported by the first device, which in turn helps ensure that the first device can successfully use the created configuration file.

In another possible implementation, the method further includes: sending a first start request to the first device, where the first start request is used to request to start the FRU configuration service of the first device, so that the first device supports creating the configuration of the target FRU. document.

In this implementation, the client device is set to send a first opening request to the first device, so that the first device supports creating the configuration file of the target FRU, because the first device only supports creating the configuration file of the target FRU when the FRU configuration management service is set to the open state. Create a configuration file for the target FRU. This helps avoid unauthorized creation of configuration files, thereby ensuring the security of FRU management.

In another possible implementation, the method further includes: sending a third start request to the second device to request to start the FRU configuration management service of the second device, so that the second device supports exporting the configuration content in the configuration file.

In this implementation, by sending the third opening request to the second device, the second device supports exporting the configuration content in the configuration file, because the second device only supports exporting the configuration file when the FRU configuration management service is set to the open state. This helps to avoid exporting the configuration content of the configuration file without permission, thereby helping to ensure the security of the configuration file.

In the fourth aspect, a field replaceable unit FRU management device is provided. The device includes: functional units for executing any one of the methods provided in the first aspect, and the actions performed by each functional unit are implemented or executed by hardware. Corresponding software implementation. For example, the FRU management device may include: a receiving unit, a creating unit, and a management unit; a receiving unit configured to receive a creation request, the creation request being used to request creation of a configuration file of the target FRU; the creation request includes configuration content in the configuration file of the target FRU ; The creation unit is used to create a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU in response to the creation request; the management unit is used to manage the target FRU based on the configuration file of the target FRU.

In the fifth aspect, a field-replaceable FRU management device is provided. The device includes: a functional unit for executing any one of the methods provided in the second aspect. The actions performed by each functional unit are implemented by hardware or the corresponding execution is performed by hardware. software implementation. For example, the FRU management device may include: a receiving unit and a sending unit; a receiving unit for receiving an acquisition request; an acquisition request for requesting to acquire the configuration content in the configuration file of the target FRU; and a sending unit for responding to the acquisition request. The device that sends the acquisition request sends a create request; the creation request includes the configuration content in the configuration file of the target FRU. The create request is used to request the creation of the configuration file of the target FRU. The configuration file of the target FRU is used to manage the target on the device that sends the acquisition request. FRU; or in response to the acquisition request, send the configuration content in the configuration file of the target FRU to the device that sent the acquisition request.

In the sixth aspect, a field replaceable unit FRU management device is provided. The device includes: functional units for executing any one of the methods provided in the third aspect, and the actions performed by each functional unit are implemented or executed by hardware. Corresponding software implementation. For example, the FRU management device may include: a sending unit; a sending unit configured to send a creation request to the first device in response to the creation instruction; the creation request is used to request the creation of a configuration file of the target FRU; the creation request includes configuration content in the configuration file .

In a seventh aspect, a field-replaceable FRU management system is provided, including: a first device and a second device, the first device is communicatively connected to the second device, and the second device stores a configuration file of the target FRU; the first device, Used to send an acquisition request to the second device when the first device does not configure the configuration file of the target FRU; the acquisition request is used to request to obtain the configuration content in the configuration file; the second device is used to receive the configuration content sent by the first device. Get request; get request is used to request to get the configuration content in the configuration file; the second device is also used to respond to the get request, send a create request to the first device; create request is used to request to create the configuration file of the target FRU, create request Including the configuration content in the configuration file; the first device is also used to receive a creation request sent by the second device, and the creation request is used to request the creation of the configuration file of the target FRU; the first device is also used to respond to the creation request, based on the configuration The configuration content in the file creates the configuration file of the target FRU.

In an eighth aspect, a field-replaceable FRU management system is provided, including: a first device, a second device and a client device; the client device is communicated and connected with the first device and the second device respectively; the second device is used to Receive an acquisition request from the client device; the acquisition request is used to request to obtain the configuration content in the configuration file of the target FRU; the second device is also used to respond to the acquisition request and send the configuration content in the configuration file of the target FRU to the client device ; The client device is used to send a creation request to the first device in response to the creation instruction; the creation request is used to request the creation of a configuration file of the target FRU; the creation request includes the configuration content in the configuration file; the first device is used to receive the creation request, and respond to the creation request, create a configuration file of the target FRU based on the configuration content in the configuration file; the first device is also used to manage the target FRU based on the configuration file of the target FRU.

In a ninth aspect, a first computer device is provided, including: a processor and a memory, and the processor is connected to the memory. The memory is used to store computer execution instructions, and the processor executes the computer execution instructions stored in the memory, thereby implementing any method provided in the first aspect.

In a tenth aspect, a second computer device is provided, including: a processor and a memory, and the processor is connected to the memory. The memory is used to store computer execution instructions, and the processor executes the computer execution instructions stored in the memory, thereby implementing any method provided in the second aspect.

In an eleventh aspect, a client device is provided, including: a processor; a processor and a memory, and the processor is connected to the memory. The memory is used to store computer execution instructions, and the processor executes the computer execution instructions stored in the memory, thereby implementing any method provided in the third aspect.

A twelfth aspect provides a chip, including: a processor and an interface circuit; the interface circuit is used to receive code instructions and transmit them to the processor; the processor is used to run the code instructions to execute any of the above provided in the first aspect a way.

In a thirteenth aspect, a chip is provided, including: a processor and an interface circuit; the interface circuit is used to receive code instructions and transmit them to the processor; the processor is used to run the code instructions to execute any of the above provided in the second aspect. a way.

A fourteenth aspect provides a chip, including: a processor and an interface circuit; the interface circuit is used to receive code instructions and transmit them to the processor; the processor is used to run the code instructions to execute any of the above provided in the third aspect. a way.

A fifteenth aspect provides a computer-readable storage medium that stores computer execution instructions. When the computer execution instructions are run on a computer device, the computer device executes any of the methods provided in the first aspect.

A sixteenth aspect provides a computer-readable storage medium that stores computer execution instructions. When the computer execution instructions are run on a computer device, the computer device executes any of the methods provided in the second aspect.

A seventeenth aspect provides a computer-readable storage medium that stores computer execution instructions. When the computer execution instructions are run on a computer device, the computer device executes any of the methods provided in the third aspect.

An eighteenth aspect provides a computer program product, including: computer execution instructions, which when the computer execution instructions are run on a computer, cause the computer to execute any of the methods provided in the first aspect.

A nineteenth aspect provides a computer program product, including: computer execution instructions, which when the computer execution instructions are run on a computer, cause the computer to execute any of the methods provided in the second aspect.

In a twentieth aspect, a computer program product is provided, including: computer execution instructions, which when the computer execution instructions are run on a computer, cause the computer to execute any of the methods provided in the third aspect.

Among them, the technical effects brought by any one of the implementation methods from the second aspect to the twentieth aspect can be found in the technical effects brought by the different implementation methods in the first aspect, which will not be described again here.

Description of the drawings

Figure 1A is a schematic diagram of a system structure provided by an embodiment of the present application;

Figure 1B is a schematic structural diagram of a device provided by an embodiment of the present application;

Figure 2A is a schematic diagram of another system architecture provided by an embodiment of the present application;

Figure 2B is a schematic structural diagram of another device provided by an embodiment of the present application;

Figure 3 is a flow chart of a FRU management method provided by an embodiment of the present application;

Figure 4 is a schematic structural diagram of another device provided by an embodiment of the present application;

Figure 5 is a schematic structural diagram of another device provided by an embodiment of the present application;

Figure 6 is a flow chart of another FRU management method provided by an embodiment of the present application;

Figure 7 is a schematic diagram of a FRU management device provided by an embodiment of the present application;

Figure 8 is a schematic diagram of another FRU management device provided by an embodiment of the present application;

Figure 9 is a schematic diagram of another FRU management device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

Among them, in the description of this application, unless otherwise stated, "/" means that the related objects are an "or" relationship. For example, A/B can mean A or B; "and/or" in this application "It is just an association relationship that describes related objects. It means that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. Among them, A ,B can be singular or plural.

Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions thereof refers to any combination of these items, including any combination of a single item (items) or a plurality of items (items). For example, at least one of a, b, or c can mean: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, c can be single or multiple .

In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as “first” and “second” are used to distinguish identical or similar items with basically the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the number and execution order, and words such as "first" and "second" do not limit the number and execution order. At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "such as" in the embodiments of the present application is not to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete manner that is easier to understand.

First, an exemplary introduction to the application scenarios of the embodiments of this application is given.

FRU is a replaceable unit on a hardware device. After the hardware device is replaced with a new FRU, if the management component of the hardware device wants to manage the new FRU, it needs to configure the configuration file of the new FRU for the management component.

In the related art, the configuration file of a new FRU is configured for the management component, usually by upgrading the firmware program of the management component. Upgrading the firmware program of the management component usually requires processes such as development, testing, and version release. As a result, when replacing FRUs on multiple hardware devices at the same time, it is necessary to develop, test, version release and other processes for the firmware programs of the management components of multiple hardware devices, which is not only extremely costly, but also very inefficient.

In view of this, embodiments of the present application provide a FRU management method for the first device. On the basis that the first device includes the target FRU, after receiving the creation request, the first device based on the target FRU carried in the creation request Based on the configuration content in the configuration file, create the configuration file of the target FRU, and then manage the target FRU based on the created configuration file of the target FRU. Since the first device can automatically create the configuration file of the target FRU based on the creation request carrying the configuration content in the configuration file of the target FRU, compared with the related technology, it is necessary to develop, test, version release and other processes for the firmware program. Being able to configure the configuration file of the target FRU for the first device not only reduces the cost of replacing the target FRU, but also improves the efficiency of replacing the target FRU.

Secondly, the system architecture of the embodiment of the present application is introduced as an example.

As shown in Figure 1A, a system architecture diagram is provided by an embodiment of the present application.

Referring to Figure 1A, the system architecture includes at least a first device and a second device. Each of the at least one first device is communicatively connected with the second device.

Exemplarily, at least one first device includes first device 1,..., first device N, where N is a positive integer greater than 1.

Optionally, the product form of the first device and the second device may be a terminal device or a network device.

Terminal devices include mobile phones, augmented reality (AR) devices, virtual reality (VR) devices, personal digital assistants (PDAs), ultra-mobile personal computers (UMPC), tablets Computers, laptops, netbooks, desktop computers, all-in-one computers, etc.

Network equipment includes servers, etc. Among them, the server can be a physical or logical server, or there can be two or more physical or logical servers that share different responsibilities and cooperate with each other to realize various functions of the server.

Optionally, the system architecture may also include client devices. The client device is respectively communicatively connected with each of the at least one first device.

In some embodiments, the client device may be an end device. The user can send target instructions and the like to the first device through the client device.

Based on the above, in an application scenario, the first device is the first server, the second device is the second server, and the client device is the terminal device. The user sends a target instruction to the first server through the terminal device to instruct the first server to send an acquisition request to the second server to request to acquire the configuration content in the FRU configuration file on the second server.

Afterwards, the second server responds to the acquisition request and sends a creation request to the first device. The creation request includes the configuration content in the FRU configuration file, so that the first device can respond to the creation request based on the configuration content in the FRU configuration file. , create a FRU configuration file.

As shown in Figure 1B, it is a schematic structural diagram of the first device, the second device, and the client device in Figure 1A.

It should be noted that the first device in FIG. 1B may be any one of the first devices 1, ..., and first device N in FIG. 1A.

Referring to 1B, a first device includes a first out-of-band controller and a second device includes a second out-of-band controller. The first out-of-band controller is communicatively connected with the second out-of-band controller. The client device includes a central processing unit (CPU).

The client device is used to run the client of the first out-of-band controller. After the client device logs into the client of the first out-of-band controller, the CPU of the client device and the first out-of-band controller can perform data transmission.

Among them, the out-of-band controller (such as the first out-of-band controller and the second out-of-band controller) is completely independent of the CPU of the computer device (such as the first device and the second device) and can be controlled through the out-of-band controller of the computer device. The management interface communicates with the CPU. In addition, out-of-band controllers enable remote maintenance and management of computer equipment through dedicated data channels.

For example, the out-of-band controller may include a monitoring and management unit outside the computer device, a management system in a management chip outside the processor, a baseboard management controller (BMC), a system management module (system management mode, SMM) etc. It should be noted that the embodiment of the present application does not limit the form of the out-of-band controller, and the above is only an exemplary description. In the following embodiments, the out-of-band controller is a BMC as an example for description.

For example, the BMC firmware program is implemented based on the OpenBMC software framework, where OpenBMC is an open source baseboard management software framework.

It should be noted that different computer devices have different names for BMC. For example, some computer devices are called BMC, some computer devices are called iLO, and another computer device is called iDRAC. Whether it is called BMC, iLO or iDRAC, it can be understood as the BMC in the embodiment of the present invention.

Optionally, the first device and the second device include at least one FRU. Exemplarily, at least one FRU includes FRU1,...,FRUk, where k is a positive integer.

For example, at least one FRU includes a motherboard, a network card, a disk array (redundant arrays of independent disks, RAID) card, a power supply, a hard disk, and other pluggable cards on the hardware device.

In some embodiments, the first out-of-band controller and the second out-of-band controller are configured with configuration files of the FRUs they contain. The first out-of-band controller and the second out-of-band controller manage the FRUs contained therein by loading the configuration files of the FRUs contained therein.

In some embodiments, the first out-of-band controller includes first flash memory. The configuration file of the FRU configured in the first out-of-band controller may be stored in the data area of the first flash memory. The second out-of-band controller includes second flash memory. The configuration file of the FRU configured in the second out-of-band controller may be stored in the data area of the second flash memory.

Optionally, the first out-of-band controller includes a first format parsing unit and a file import unit.

The file importing unit is used to import the configuration file of the FRU into the first device, and the first format parsing unit is used to determine whether the configuration file of the FRU imported into the first device meets the preset conditions.

Among them, the first format parsing unit complies with the OpenBMC architecture and Redfish specifications. In this way, when the first format parsing unit parses the creation request, it not only helps to ensure that the data format of the parsed configuration content meets the requirements, but also helps to ensure that the parsed configuration content meets the requirements. The content of the configuration document is accurate and complete.

Optionally, the first out-of-band controller includes a first FRU profile set interface (referred to as the first interface for short).

Among them, the first interface supports the use of data in JSON format. For example, the first interface belongs to the Redfish interface.

For example, the URL address of the first FRU configuration file collection interface is redfish/v1/Manager/{Id}/FRUManagerService/FRUManagers.

In some embodiments, the first interface is used to receive a creation request (such as a POST request), and based on this, the first interface supports transmitting data in JSON format. After the first interface receives the POST request, the file import processing flow is entered. For example, the first interface calls the file import unit to receive the configuration content carried in the creation request, and calls the first format parsing unit to determine whether the configuration content meets the preset conditions.

In some embodiments, the first interface may also be used to receive query requests. This query request is used to request the number and URL addresses of FRU configuration files supported by the current model.

For example, the first interface includes attribute names and attribute values. Among them, the form of the first interface is shown in Table 1.

Table 1

In Table 1, "Members@odata.count" is used to represent the number of configuration files. "1" is used to characterize the number of profiles with a value of 1. "Members" is used to characterize the name of the configuration file. @odata.id is a public attribute of the configuration file defined by the open data protocol (OData protocol) in the redfish specification. It is used to indicate the uniform resource locator (URL) of the configuration file. In other words, "@odata .id":"/redfish/v1/Managers/{Id}/FRUManagerService/FRUManagers/{FRUID}" is used to represent the URL address of the configuration file.

It can be understood that the URL address of the configuration file is used to indicate the storage address of the configuration file. Among them, there is a one-to-one correspondence between the URL address and the configuration file. In other words, one URL address indicates a unique configuration file.

Optionally, the first out-of-band controller may also include a first FRU configuration service interface.

Among them, the first FRU configuration service interface supports the use of data in JSON format. For example, the first FRU configuration service interface belongs to the Redfish interface.

For example, the URL address of the first FRU configuration service interface is redfish/v1/Manager/{Id}/FRUManagerService.

In some embodiments, the first FRU configuration service interface is used to enable or disable the configuration file management service.

In one example, the first FRU configuration service interface is configured with a ServiceEnable attribute, and the ServiceEnable attribute includes enable (True) or disable (False). When the ServiceEnable attribute is enabled, it is used to indicate that the configuration file management service is on. When the ServiceEnable attribute is disabled, it is used to indicate that the configuration file management service is off.

When the configuration file management service is enabled, the first device supports importing/exporting FRU configuration files. On the contrary, when the configuration file management service is in a closed state, the first device does not support importing/exporting the configuration file of the FRU.

In some embodiments, the first FRU configuration service interface may also be used to trigger scanning of FRUs.

In one example, the first FRU configuration service interface is configured with the FRUManager.RescanBuses attribute. The FRUManager.RescanBuses attribute can trigger a specific operation on the corresponding resource based on Redfish's Action format, that is, it can trigger a scanning operation on the FRU.

In some embodiments, the first FRU configuration service interface can also be used to query the FRU types that can be imported into the current model.

In one example, the first FRU configuration service interface is configured with the FRUTypeList attribute. The FRUTypeList attribute is used to query the FRU types that can be imported by the current model to avoid importing invalid configuration files.

Optionally, the first out-of-band controller further includes a first FRU profile interface.

Among them, the first FRU configuration file interface supports the use of data in JSON format. For example, the first FRU configuration file interface belongs to the Redfish interface.

It can be understood that the first FRU configuration file interface can be considered as the interface of a single FRU configuration file, and the first FRU configuration file collection interface can be considered as the interface of a collection of single configuration files. In other words, the first FRU configuration file collection interface can be considered as the first FRU configuration file collection interface. A collection of FRU profile interfaces.

For example, the URL address of the first FRU configuration file interface is redfish/v1/Manager/{Id}/FRUManagerService/FRUManagers/{FRUProductName}.

In some embodiments, the first FRU configuration file interface is used to use the name of the FRU (ProductName) as an index and present the contents of the FRU's configuration file in a form that complies with the Redfish specification.

In some embodiments, when the configuration file of the FRU needs to be exported, the first FRU configuration file interface can also be used to query the configuration file of the specified FRU and remove the Redfish public attributes (ie, URL address) of the configuration file.

Optionally, the second out-of-band controller includes a second format parsing unit and a file export unit.

The file export unit is used to export the configuration file of the FRU in the second flash memory, and the second format parsing unit is used to determine whether the configuration file exported by the file export unit meets the preset conditions.

Optionally, the second out-of-band controller also includes a second FRU profile interface (referred to as the second interface for short).

Among them, the second interface supports the use of data in JSON format. For example, the second interface belongs to the Redfish interface.

In some embodiments, the second interface is used to receive a retrieval request (such as a GET request), and based on this, the second interface supports transmitting data in JSON format. After the second interface receives the GET request, the file export processing flow is entered. For example, the second interface calls the file export unit to export the configuration file of the FRU in the second flash memory, and calls the second format parsing unit to determine what the file export unit exported. Whether the configuration file meets the preset conditions, etc.

For example, the URL address of the second interface is redfish/v1/Manager/{Id}/FRUManagerService/FRUManagers/{FRUProductName}.

In some embodiments, the second interface is used to use the name of the FRU (ProductName) as an index and present the contents of the configuration file of the FRU in a form that complies with the Redfish specification.

In some embodiments, when the configuration file of the FRU needs to be exported, the second interface can be used to query the configuration file of the specified FRU and remove the Redfish public attributes (ie, URL address) of the configuration file. Optionally, the second out-of-band controller includes a second FRU configuration service interface.

It should be noted that for the relevant description of the second FRU configuration service interface, please refer to the relevant description of the first FRU configuration service interface. The principles of the two are the same and will not be described again here.

Optionally, the second out-of-band controller includes a second FRU profile set interface.

It can be understood that the second FRU configuration file interface can be considered as the interface of a single FRU configuration file, and the second FRU configuration file collection interface can be considered as the interface of a collection of single configuration files. In other words, the second FRU configuration file collection interface can be considered as the third FRU configuration file collection interface. A collection of two FRU profile interfaces.

It should be noted that for other relevant descriptions of the second FRU configuration file interface, please refer to the above-mentioned relevant descriptions of the first FRU configuration file interface. The principles of the two are the same and will not be described again here.

As shown in Figure 2A, it is another system architecture diagram provided by an embodiment of the present application.

Referring to Figure 2A, the system architecture includes a client device, at least one first device and a second device. Wherein, the client device is communicatively connected with at least one first device and a second device respectively.

Wherein, the client device is used to import the configuration content in the FRU configuration file from the second device, and import the configuration content in the FRU configuration file into the first device.

As shown in Figure 2B, it is a schematic structural diagram of a first device, a second device and a client device provided by an embodiment of the present application.

Referring to Figure 2B, the client device includes a CPU. Wherein, the CPU is communicatively connected with the first out-of-band controller of the first device and the second out-of-band controller of the second device.

Optionally, the client device also includes a storage device. The storage device is used to store the configuration content in the configuration file of the FRU obtained by the client device from the second device.

It should be noted that for relevant descriptions of the first device and the second device, reference may be made to the relevant descriptions of the system architecture shown in FIG. 1A to FIG. 1B and will not be described again here.

It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art will know that , with the evolution of system architecture and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

For ease of understanding, the FRU management method provided by this application is exemplarily introduced below with reference to the accompanying drawings.

The following embodiments of this application will be divided into two parts to exemplarily introduce the solution of the FRU management method.

The first part, with reference to Figures 3 to 5, introduces the process of the first device obtaining the configuration content of the FRU configuration file from the second device.

The second part, combined with Figure 6, introduces the process of the first device obtaining the configuration content of the FRU configuration file from the client device.

The first part of the embodiment of the present application will be introduced below with reference to FIGS. 3 to 5 .

Figure 3 is a flow chart of a FRU management method according to an exemplary embodiment. Exemplarily, the method includes the following S301-S308.

It should be noted that this method is applicable to the system architecture shown in Figure 1A to Figure 1B.

In some embodiments, the FRU on the second device is replaced with the target FRU, and the second device is configured with the configuration file of the target FRU. In addition, multiple FRUs on the first device are also replaced with target FRUs.

In order to reduce the research and development cost and time of configuring the configuration file of the target FRU for the first device, any first device among the plurality of first devices can automatically create the configuration file of the target FRU based on the following S301-S308. In other words, the first device in the following embodiments may be any first device among multiple first devices.

S301: If the first device does not configure the configuration file of the target FRU, the first device sends an acquisition request to the second device.

The acquisition request is used to request to acquire the configuration content in the configuration file of the target FRU.

For example, the acquisition request may be a GET request in a RESTful architecture. In a RESTful architecture, the GET request may be used to request the return of the requested resource description. In this embodiment of the present application, the GET request is used to request the return of the configuration content in the configuration file of the target FRU.

The target FRU may refer to at least one FRU on the first device for which no FRU configuration file is configured.

It should be noted that the embodiment of the present application does not limit the number of target FRUs. In other words, the target FRUs can be any one or any number of FRUs on the first device that do not have a FRU configuration file configured.

Optionally, obtaining the requested content includes multiple implementation methods. Two implementation methods are used as examples below.

In the first implementation, the acquisition request includes the name of the target FRU.

The acquisition request is used to request to acquire the configuration content in the configuration file indicated by the name of the target FRU.

Among them, the configuration file indicated by the name of the target FRU is the configuration file of the target FRU. For example, the name of the configuration file of the target FRU is the same as the name of the target FRU.

As shown in Figure 4, it is a schematic structural diagram of the first device and the second device.

The first device and the second device shown in Figure 1B are equipped with FRU1. However, after FRU1 left the factory, the manufacturer discovered that FRU1 had hardware defects, and modified FRU1 to obtain FRU1', or updated the software functions of FRU1 to obtain FRU1'. For example, the software function update may refer to the monitorability of FRU1'. The information is updated, or the hardware function of FRU1 is updated to obtain FRU1'. On this basis, the FRU1 on the first device and the second device shown in Figure 1B are replaced with the first device and the second device shown in Figure 4. FRU1' on the device.

It is understandable that after the FRU undergoes hardware upgrade, software upgrade or hardware revision, the configuration file of the FRU also needs to be updated accordingly. In other words, the first out-of-band controller and the second out-of-band controller need to be based on the updated configuration file. , manage the FRU after hardware upgrade, software upgrade or hardware revision.

Based on this, after FRU1 on the second device is replaced with FRU1', the user configures the FRU1' configuration file for the second out-of-band controller of the second device, so that the second out-of-band controller can manage the second out-of-band controller based on the FRU1' configuration file. FRU1' on the second device.

It should be noted that the embodiment of the present application does not limit the method of configuring the configuration file of FRU1' for the second out-of-band controller. It can be any implementation method in the related technology. For example, it can be by upgrading the second out-of-band controller. The controller's firmware program configures the target FRU configuration file for the second out-of-band controller.

Based on the above, FRU1 on the first device is replaced with FRU1' (ie, the target FRRU). When the first device does not configure the configuration file of the target FRU, in order to be able to manage the target FRU, the first device sends an acquisition request (such as a GET request) to the second device to request to obtain the configuration file of the target FRRU (i.e., FRU1 'configuration file).

It can be understood that when the first device needs to obtain the configuration content in the configuration file of any specified FRU (such as the target FRU) from the second device, the acquisition request sent by the first device to the second device may include the name of the specified FRU. In this way, the second device can determine the configuration file to which the configuration content to be obtained by the first device belongs based on the name of the specified FRU.

In this implementation, since the name of the configuration file of the FRU is the same as the name of the FRU, the acquisition request is set to include the name of the target FRU, and the request is made to obtain the configuration content in the configuration file indicated by the name of the target FRU. In this way, When you need to obtain the configuration content in the configuration file of a specific FRU, it helps to ensure the accuracy of the obtained configuration content.

It should be noted that the target FRRU is the replaced FRU1' only for illustrative purposes. The target FRRU can be any replaced FRU on the first device. For example, the target FRU can also be the replaced FRU2',..., FRUk- 1' or FRUk'.

In a second implementation manner, the acquisition request includes the model identification of the first device.

The acquisition request is specifically used to request to obtain the configuration content in the configuration file supported by the model corresponding to the model identification. The configuration file of the target FRU is the model identification support configuration file.

For example, the first equipment model includes rack type, blade type, tower type, etc. Based on this, the model identification of the first device includes a rack type identification, a blade type identification, a tower type identification, etc.

As shown in Figure 5, it is another structural schematic diagram of the first device and the second device.

The first device and the second device shown in Figure 1B include FRU1,..., FRUk. Later, FRU1,...,FRUk were revised due to hardware defects, or the software functions of FRU1,...,FRUk were updated, or the hardware functions of FRU1,...,FRUk were updated, resulting in FRU1',... …, FRUk'. On this basis, referring to Figure 5, the first device, the first device on the second device shown in Figure 1B, and the FRU1,..., FRUk on the second device are replaced with the first device,..., FRUk on the second device shown in Figure 5. FRU1',...,FRUk' on the second device.

Based on this, the user configures the FRU1' configuration file,..., FRUk' configuration file for FRU1',...,FRUk' on the second device, so that the second out-of-band controller can be based on the FRU1' configuration file,..., The FRUk' configuration file manages FRU1',...,FRUk' on the second device.

In some embodiments, FRU1,...,FRUk on the first device are replaced with FRU1',...,FRUk'. When the first device does not configure the configuration files of FRU1',...,FRUk', in order to be able to manage FRU1',...,FRUk', the first device sends an acquisition request to the second device to request Get FRU1' configuration file,..., FRUk' configuration file.

In the second implementation manner, FRU1',...,FRUk' are target FRUs. In other words, the target FRUs include FRU1',...,FRUk'.

It can be understood that when the first device needs to obtain multiple FRU configuration files (such as FRU1' configuration files,..., FRUk' configuration files) from the second device, the acquisition request sent by the first device to the second device can be Including the model identification of the first device, in this way, the second device can determine the configuration files of multiple FRUs that can be used by the model of the first device based on the model identification of the first device, thereby combining the multiple FRUs that can be used by the first device. The configuration content in the configuration file of each FRU is returned to the first device, so that the first device can create multiple FRU configuration files based on the creation request and the configuration content in the multiple FRU configuration files.

In this embodiment, the acquisition request is set to include the model identification of the first device, and the configuration content in the configuration file indicated by the model identification is requested. In this way, when multiple FRUs are replaced on the first device, multiple FRUs need to be obtained. It helps to improve the efficiency of obtaining the configuration content in the configuration files of multiple FRUs.

Optionally, in the case where the acquisition request includes the model identification of the first device, the acquisition request may also include the target FRU type.

The target FRU type is a FRU type supported by the first device, and the acquisition request is used to request to obtain configuration content in a configuration file belonging to the target FRU type, and the configuration file of the target FRU is a configuration file belonging to the target FRU type.

Among them, the FRU type refers to the type of component using the FRU.

For example, if the first FRU component is used as the main board (Board), then the FRU type of the first FRU is the main board. The component using the second FRU is the chassis (Chassis), then the FRU type of the second FRU is the chassis, and the component using the third FRU is the backplane (non volatile memor express, NVMe), then the FRU type of the third FRU is back panel. The component using the fourth FRU is a power supply (PowerSupply), and the FRU type of the fourth FRU is power supply.

It can be understood that the embodiment of the present application does not limit the target FRU type. For example, the target FRU type may be at least one of a mainboard type FRU, a chassis type FRU, a backplane type FRU, and a power supply type FRU. Among them, the mainboard-type FRU refers to the FRU applied to the motherboard (Board), the frame-type FRU refers to the FRU applied to the chassis, the backplane-type FRU refers to the FRU applied to the backplane, and the power-type FRU refers to the FRU applied to the power supply. FRU.

In some embodiments, when the first device needs to obtain the configuration files of multiple FRUs from the second device, the acquisition sent by the first device to the second device may also include the target FRU type, so that the second device can obtain the target FRU type according to the second device. The model identification and target FRU type of a device determine the FRU configuration file. In this way, the determined configuration file is not only a configuration file that can be used by the model of the first device, but also the FRU type supported by the first device. .

In this embodiment, by setting the acquisition request to include the target FRU type, it is used to indicate that the configuration file requested by the acquisition request should belong to the target FRU type. In this way, it helps to ensure that the configuration of the target FRU obtained by the first device from the second device The file can be matched with the first device, thereby helping to ensure that the first device can normally use the obtained configuration file.

Optionally, S301 includes a variety of implementation methods, and below, method 1 to method 2 are used for exemplary description.

Method 1: In response to the received target instruction sent by the client device, send an acquisition request to the second device.

The target instruction is used to instruct to obtain the configuration file of the target FRU from the second device, and the target instruction is sent when the first device does not configure the configuration file of the target FRU.

In some embodiments, after the first device configures the target FRU, the user sends a target instruction to the first device through the client device to instruct the first device to obtain the configuration file of the target FRU from the second device.

For example, the target instruction may include the Internet Protocol (IP) address of the second device, and the first device sends an acquisition request to the second device through the IP address of the second device.

In method 1, the first device sends an acquisition request to the second device in response to receiving the target instruction sent by the client device. In this way, when the user determines that the first device needs to use the configuration file of the target FRU, the first device can be instructed to Sending a retrieval request to the second device helps to increase the necessity of configuring content retrieval.

Method 2: In response to the target scan result of the first device, send an acquisition request to the second device.

The target scan result includes that the configuration file of the target FRU was not scanned on the first device.

In some embodiments, after configuring the target FRU, the first device restarts the FRU configuration service so that the first out-of-band controller scans the target FRU to obtain attribute information of the target FRU from the target FRU, where the attribute information includes the name of the target FRU.

Afterwards, the first out-of-band controller scans the configuration file in the first flash memory according to the name of the target FRU to load the configuration file of the target FRU. If the first out-of-band controller does not scan the configuration file of the target FRU, the first out-of-band controller sends an acquisition request to the second out-of-band controller of the second device.

For example, the Internet Protocol (IP) address of the second device is preset and stored in the first device. In response to the target scanning result, the first device sends an acquisition request to the second device based on the IP address of the second device.

In method 2, the first device automatically sends an acquisition request to the second device in response to the target scan result without user participation, which helps to improve the convenience and automation of configuration content acquisition.

Optionally, S301 includes: if the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device based on the first interface. Among them, the first interface supports the use of JSON format data.

In this embodiment, since the configuration content in the configuration file of the FRU is in JSON format, the first device is configured to send an acquisition request to the second device based on the first interface, thereby enabling the first device and the second device to pass through The first port transmits the configuration content in the configuration file of the target FRU, and the first interface supports the transmission of data in JSON format. In this way, when transmitting the configuration content, there is no need to convert the data format, which helps ensure the convenience of data transmission. sex and accuracy.

Optionally, S301 includes the following S301a to S301c.

S301a: If the first device does not configure the configuration file of the target FRU, send a second start request to the second device.

The second start request is used to request to start the FRU configuration management service of the second device, so that the second device supports exporting the configuration file of the target FRU.

In some embodiments, the FRU configuration management service of the second device refers to the FRU configuration management service supported by the second out-of-band controller. Wherein, the FRU configuration management service of the second device includes an open state and a closed state.

When the FRU configuration management service is enabled, the configuration file of the FRU in the second out-of-band controller supports exporting, so that the second device can send the configuration content in the exported configuration file to other devices. When the FRU configuration management service is turned off, the configuration file of the FRU in the second out-of-band controller does not support export. In this way, the second device will not be able to send the configuration content in the configuration file in the second out-of-band controller to other devices.

After the second out-of-band controller is powered on, its FRU configuration management service is initially in a closed state. Based on this, before the first device sends an acquisition request to the second device, it first sends an enable request to the second device to request to enable the FRU configuration management service of the second device, so that the second device supports exporting the configuration file of the target FRU. .

S301b: The second device responds to the received second start request and starts the FRU configuration management service.

In some embodiments, after receiving the second enable request, the second device changes the status of the FRU configuration management service from the closed state to the enabled state to enable the FRU configuration management service.

Exemplarily, after receiving the second start request sent by the first out-of-band controller, the second FRU configuration service interface of the second out-of-band controller starts the FRU configuration management service in response to the start request.

In some embodiments, after the FRU configuration management service of the second device is enabled, the second device returns an enablement notification to the first device. The enablement notification is used to notify the first device that the FRU configuration management service of the second device has been enabled.

For example, the second out-of-band controller may return a start notification to the first out-of-band controller.

S301c: After determining that the FRU configuration management server of the second device has been started, the first device sends an acquisition request to the second device.

In some embodiments, after receiving the activation notification returned by the second device, the first device determines that the FRU configuration management server of the second device has been activated. Based on this, the first device sends an acquisition request to the second device to request Obtain the configuration content in the configuration file of the target FRU.

In this embodiment, the FRU configuration management service is configured by setting the second device. When the FRU configuration management service is on, the second device can export the configuration file of the target FRU. When it is off, the second device cannot export the configuration of the target FRU. The file, in this way, helps ensure the security of the FRU's configuration file in the second device.

Based on this, by sending an enable request to the second device, the second device can be requested to enable the FRU configuration management service, so that the second device supports exporting the configuration file of the target FRU, which helps ensure the convenience of exporting the configuration file.

S302: The second device receives the acquisition request sent by the first device.

After the second out-of-band controller of the second device receives the acquisition request, in response to the acquisition request, it calls the file export unit to export the configuration file of the target FRU from the second flash memory of the second out-of-band controller.

For example, after the second out-of-band controller receives the acquisition request, the configuration file of the target FRU can be exported from the second flash memory when the FRU configuration file management service is on. Otherwise, the configuration file of the target FRU cannot be exported from the second flash memory.

In some embodiments, where the acquisition request includes the name of the target FRU, the second out-of-band controller parses the name of the target FRU from the URL index of the acquisition request and derives the name of the target FRU from the second flash memory The indicated FRU profile.

In other embodiments, when the acquisition request includes the model identifier of the first device, the second out-of-band controller parses the model identifier of the first device from the URL index of the acquisition request, and based on the model identifier, Export the configuration file indicated by the model identification (ie, the configuration file of the target FRU) from the second flash memory.

In one example, a plurality of first FRU configuration file sets are stored in the second flash memory.

Among them, different first FRU configuration file sets are suitable for different models. For example, the plurality of first FRU configuration file sets include a set suitable for rack-type devices, a set suitable for blade-type devices, a set suitable for tower-type devices, and so on.

It should be noted that the FRU configuration files in different first FRU configuration file sets may be the same, or may be different, and the embodiment of the present application does not limit this.

On this basis, the second out-of-band controller derives the first set of FRU configuration files indicated by the model identification from the second flash memory. In other words, derives the first set of FRU configuration files suitable for the model corresponding to the model identification.

In some embodiments, when the acquisition request includes the target FRU type, the second out-of-band controller parses the target FRU type from the URL index of the acquisition request, and derives the target FRU type from the second flash memory according to the target FRU type. Configuration file for the target FRU type.

In one example, a plurality of second FRU configuration file sets are stored in the second flash memory.

It can be understood that the FRU configuration files in a second FRU configuration file set belong to the same FRU type.

Wherein, different second FRU configuration file sets belong to different FRU types. For example, the plurality of second FRU configuration file sets include a set belonging to the mainboard type FRU, a set belonging to the chassis type FRU, a set belonging to the backplane type FRU, and a set belonging to the power supply type FRU.

On this basis, the second out-of-band controller derives a second set of FRU configuration files indicated by the target FRU type from the second flash memory, in other words, derives a second set of FRU configuration files belonging to the target FRU type.

Wherein, the second set of FRU configuration files belonging to the target FRU type means that the configuration files in the second set of FRU configuration files belong to the target FRU type.

Based on the above, when the acquisition request includes the model identification and target FRU type of the first device, the configuration file exported by the second out-of-band controller from the second flash memory should belong to the first FRU configuration file set indicated by the model identification, and belongs to the second FRU profile set indicated by the target FRU type.

Optionally, S302 includes: the second device receives the acquisition request sent by the first device based on the second interface.

In some embodiments, after receiving the acquisition request, the second interface parses the name of the target FRU from the URL index of the acquisition request. After that, the file export unit is called to export the configuration file of the target FRU. The name of the configuration file of the target FRU is the same as the name of the target FRU.

Optionally, S303: The second device determines whether the configuration content in the configuration file of the target FRU meets the preset conditions.

If the judgment result is yes, execute S304. If the judgment result is no, it ends.

The preset condition includes at least one of a preset attribute name, a preset field type and a preset attribute value.

In some embodiments, the configuration content includes multiple attribute information. The configuration content that satisfies the preset condition may be that the attribute names, field types or attribute values of the plurality of attribute information included in the configuration content match the corresponding preset attribute names, preset field types or preset attribute values in the preset condition.

In some embodiments, when the acquisition request is used to request to acquire the configuration content in the configuration file of an FRU, the second device determines whether the configuration content in the configuration file of the FRU meets the preset conditions.

In other embodiments, when the acquisition request is used to request the acquisition of configuration content in the configuration files of multiple FRUs, the second device respectively determines whether the configuration content in the configuration files of the multiple FRUs meets preset conditions.

In this embodiment, when the configuration content in the configuration file meets the preset conditions, the configuration content in the configuration file is sent to the first device. This helps to avoid that the configuration content belongs to non-FRU configuration files, thereby improving the exported configuration. The accuracy and security of the content prevent the second device from generating a FRU configuration file based on the configuration content of non-FRU configuration files.

Optionally, S303 includes multiple implementation methods, and below, methods a to c are used for exemplary description.

Method a, S303 includes: the second device determines whether the attribute name of the configuration content is the same as the default attribute name, and whether the field type of the configuration content is the same as the default field type.

If the judgment result is the same, in other words, the attribute name of the configuration content is the same as the default attribute name, and the field type of the configuration content is the same as the default field type, it means that the configuration content in the configuration file meets the preset conditions, then S304 is executed. If the judgment result is not the same, in other words, the attribute name of the configuration content is different from the default attribute name, and/or the field type of the configuration content is different from the default field type, it means that the configuration content in the configuration file does not meet the preset conditions. , then ends.

The attribute name of the configuration content includes at least one of the target FRU's manufacturer identification, PN component identification, SN serial number, model, and name; the field type of the configuration content includes a string. In some embodiments, the second interface calls the second format parsing unit to parse the configuration file of the target FRU and encapsulates the parsed content to obtain the configuration content in the configuration file. After that, the second format parsing unit obtains the default attribute name and the default field type, and compares the attribute name of the configuration content with the default attribute name, and the field type of the configuration content with the default field type.

For example, the acquisition request includes public attributes of the target FRU configuration file. For example, the public attributes may include @odata.context//FRU configuration resource template file, @odata.id//unique identifier URL of the FRU configuration resource, @ odata.type//The template name and version number of the FRU configuration resource. The second format parsing unit parses the acquisition request to obtain the public attributes of the target FRU configuration file. After that, it obtains the preset attribute name and preset field type through the public attributes. .

In some embodiments, the first template file is stored in the second flash memory, and the template file records preset attribute names and preset field types.

Based on the above, the second format parsing unit obtains the first template file through the public attributes, thereby obtaining the preset attribute names and preset field types.

In one example, the first template file may be global.json//official template document. The default attribute name includes the default manufacturer identification, the default PN component identification, the default SN serial number, the default model, the default name, etc.

In one example, the first template file includes preset attribute names and preset field types.

For example, the content of the first template is as follows:

Among them, "Properties" is used to represent attribute information, "Manufacturer" is used to represent that the default attribute name is the manufacturer, and the ""type":"string"" in the third line is used to represent that the manufacturer's default field type is character. string. "Model" is used to represent the default attribute name model. "PartNumber" is used to represent the preset attribute named PN part identification. ""SerialNumber" is used to represent the default attribute named SN serial number.

In the above method a, it is determined whether the configuration content meets the preset conditions by whether the attribute name of the configuration content is the same as the preset attribute name, and whether the field type of the configuration content is the same as the preset field type. This helps to ensure that the configuration content is The accuracy and completeness of the configuration content parsed in the file.

Method b: The second device determines whether the attribute name of the configuration content is the same as the default attribute name, and whether the attribute value of the configuration content is the same as the default attribute value.

In method b, the attribute name of the configuration content includes the model ID and/or FRU type of the target FRU.

Among them, the model identification of the target FRU indicates the identification of the model to which the target FRU is applicable.

In some embodiments, the second flash memory stores a second template, and the second template records preset attribute names and preset attribute values.

Based on the above, the second format parsing unit obtains the second template through the public attributes, thereby obtaining the preset attribute name and the preset attribute value.

In one example, the second template document may be oem.json//custom template document. The default attribute name includes the default model identification and the default FRU type.

In one example, the second template file includes a preset attribute name and a preset attribute value.

For example, the content of the second template is as follows:

Among them, "Type" is used to represent the attribute name type (ie, FRU type), and ""title":"ConfigurationType"" is used to represent the type as the configuration type. "enum" is used to characterize the following enumerated attribute values, and ""Board", "Chassis", "NVME", "PowerSupply"" is used to characterize the attribute values. In other words, the default FRU types include Board, Chassis, NVME, and PowerSupply.

It should be noted that for other relevant instructions on method b, please refer to the above method a, which will not be described again here.

In the above method b, it is determined whether the configuration content meets the preset conditions by whether the attribute name of the configuration content is the same as the preset attribute name, and whether the attribute value of the configuration content is the same as the preset attribute value. This helps to ensure that the configuration content is the same as the preset attribute name. The accuracy and completeness of the configuration content parsed in the file.

Method c, S303 includes: the second device determines whether the attribute name of the configuration content is the same as the default configuration attribute name.

If the judgment results are the same, it means that the configuration content in the configuration file meets the preset conditions, and then S304 is executed. If the judgment result is different, it means that the configuration content in the configuration file does not meet the preset conditions, and the process ends.

In mode c, the attribute name of the configuration content may include at least one of the FRU's manufacturer identification, PN component identification, SN serial number, model, name, FRU type, and model identification.

It should be noted that for relevant instructions on method c, please refer to the above method a, which will not be described again here.

In the above method c, whether the configuration content meets the preset conditions is determined by whether the name of the configuration content is the same as the preset configuration name. This helps to ensure the accuracy and completeness of the configuration content parsed from the configuration file.

It should be noted that the above-mentioned methods a to c can be used alone or in combination. For example, method a and method b can be used in combination, and method b can also be used in combination with method c. This is not the case in the embodiments of the present application. Make restrictions.

It should be noted that the above-mentioned methods a to c are only exemplary descriptions, and the specific method of determining whether the configuration content meets the preset conditions in the embodiment of the present application is not limited.

S304: The second device responds to the acquisition request and sends a creation request to the first device.

The creation request is used to request to create the configuration file of the target FRU. The creation request includes the configuration content in the target FRU's configuration file.

For example, the creation request can be a POST request in a RESTful architecture. In a RESTful architecture, the POST request can be used to request the creation of a new resource or the execution of a method of a specified resource. In this embodiment of the present application, the POST request is used to request the creation of a new resource (ie, the configuration file of the target FRU).

In some embodiments, when the second format parsing unit determines that the configuration content satisfies the preset condition, it generates a response body message, which is the response body message (that is, a creation request).

In some embodiments, when the acquisition request is used to request to obtain the configuration content in the configuration file of one FRU, the second device sends a creation request for the configuration file of one FRU to the first device.

In some other embodiments, when the acquisition request is used to request to acquire the configuration content in the configuration files of multiple FRUs, the second device sends creation requests for the configuration files of the multiple FRUs to the first device respectively.

Optionally, S304 includes the second device sending a creation request to the first device based on the second interface in response to the acquisition request.

Among them, the second interface transmits data in JSON format.

In some embodiments, when the second format parsing unit determines that the configuration content meets the preset conditions, it calls the second interface and sends a creation request to the first device.

In this embodiment, since the configuration file of the FRU is a JSON file and the configuration content in the configuration file of the FRU is in JSON format, therefore, the configuration file of the target FRU is transmitted between the first device and the second device through the second interface. configuration content, and the second interface supports the transmission of JSON format files. In this way, there is no need to convert the data format when transmitting the configuration content, which helps ensure the convenience and accuracy of data transmission.

S305: The first device receives the creation request sent by the second device.

Optionally, S305 includes: the first device receives the creation request sent by the second device according to the first interface.

In some embodiments, the first interface of the first out-of-band controller receives the creation request, and then the first interface calls the file import unit to import the configuration content in the configuration file of the target FRU into the first device.

Optionally, S306: The first device determines whether the configuration content in the configuration file of the target FRU meets the preset conditions.

If the judgment result is yes, execute S307. If the judgment result is no, it ends.

In some embodiments, after receiving the creation request, the first interface of the first out-of-band controller calls the format parsing unit, and the format parsing unit parses out the configuration content in the configuration file to determine whether the configuration content meets the preset conditions. . If the preset conditions are met, the configuration content received by the first device is compliant; otherwise, the configuration content is non-compliant.

In this embodiment, the configuration file of the target FRU is created based on the configuration content only when the configuration content in the configuration file of the target FRU meets the preset conditions. This helps to ensure the integrity of the configuration content. In other words, the configuration file is created The required configuration content of the file is complete, which helps to avoid using non-compliant configuration content to create the target FRU configuration file, which may cause the target FRU to function abnormally when managing the target FRU based on the created configuration file.

It should be noted that the implementation process and related instructions of S306 can be referred to the above-mentioned S303, and will not be described again here.

S307: In response to the creation request, the first device creates a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU.

In some embodiments, when the first format parsing unit determines that the configuration content meets the preset conditions, the file import unit is called to create the configuration file of the target FRU in the first flash memory. In this way, the target FRU is stored in the first flash memory. configuration file.

Exemplarily, the file importing unit responds to the creation request, creates a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU, and stores the newly created configuration file of the target FRU in the data area of the first flash memory. The configuration file of the newly created target FRU may be a file in JSON format.

It should be noted that the process of creating a target FRU's configuration file in response to a creation request can refer to the process of creating a new resource based on a POST request in related technologies. The principles of the two are the same and will not be described again here.

In some embodiments, when the obtain request is used to request to obtain the configuration content in the configuration file of one FRU, the first device responds to the create request and creates the configuration file of the one FRU.

In other embodiments, when the obtain request is used to request to obtain the configuration content in the configuration files of multiple FRUs, the second device responds to the create request and creates configuration files of the multiple FRUs respectively.

Optionally, the FRU management method further includes: setting the FRU configuration management server of the first device to an open state.

In some embodiments, in response to the target scan result, the first device sets the FRU configuration management server of the first device to an open state, so that the first device supports creating a configuration file of the target FRU.

Since the first device supports creating the configuration file of the target FRU when the FRU configuration management service is set to on, this helps to avoid creating configuration files without permission, thereby helping to ensure the security of FRU management. .

S308: The first device manages the target FRU based on the configuration file of the target FRU.

In some embodiments, when the acquisition request is used to request to obtain the configuration content in the configuration file of an FRU, the first device manages the FRU based on the configuration file of the FRU.

In other embodiments, when the acquisition request is used to request to acquire the configuration content in the configuration files of multiple FRUs, the second device manages the multiple FRUs based on the configuration files of the multiple FRUs.

In some embodiments, after the configuration file of the target FRU is stored in the first flash memory, the first FRU configuration service interface is called to trigger the scanning FRU operation. Afterwards, the first out-of-band controller scans the FRU of the first device, and after scanning the target FRU, obtains the name of the target FRU stored in the target FRU. Afterwards, the first out-of-band controller loads the configuration file of the target FRU in the first flash memory according to the name of the target FRU, thereby managing the FRU.

In some other embodiments, after the configuration file of the target FRU is stored in the first flash memory, the first device performs a restart operation so that the CPU of the first device is powered on again. After the first device is restarted, the first out-of-band controller scans the FRU of the first device, and after scanning the target FRU, obtains the name of the target FRU stored in the target FRU. Afterwards, the first out-of-band controller loads the configuration file of the target FRU in the first flash memory according to the name of the target FRU, and reports the management service of the target FRU to the CPU, thereby managing the FRU.

Since some functions of the target FRU need to be managed after the CPU of the first device is restarted, after setting the configuration file of the target FRU stored in the first flash memory, the first device performs a restart operation and loads the configuration of the target FRU. file, so that the management business of the target FRU can be reported to the CPU, which helps to ensure the integrity of the first out-of-band controller's management of the target FRU.

In the above embodiment, when the first device does not configure the configuration file of the target FRU, the first device actively sends an acquisition request to the second device to request to obtain the configuration content in the configuration file of the target FRU, and after receiving the first After a device creates a request, it automatically responds to the creation request, automatically creates a configuration file for the target FRU based on the configuration content in the configuration file of the target FRU carried in the creation request, and then manages the target FRU based on the created configuration file of the target FRU. . Since the first device can automatically create the configuration file of the target FRU based on the creation request, compared with the related technology, it is necessary to develop, test, version release and other processes of the firmware program to configure the configuration file of the target FRU for the first device. Not only does it help reduce the cost of replacing the target FRU, it also helps improve the efficiency of replacing the target FRU.

Optionally, the FRU management method also includes the following steps 1 to 2.

Step 1: The client device sends a scan request to the first device.

The scan request is used to request to scan the target FRU after the first device is restarted.

In some embodiments, after storing the configuration file of the target FRU in the first flash memory, in order to enable the first out-of-band controller to manage all functions of the target FRU, the user sends a scan request to the first device through the client device, to instruct the first out-of-band controller of the first device to restart, and after the restart, scan the target FRU.

For example, the CPU of the client device sends a scan request to the target link of the first device. The scan request may be a PSOT request. In this embodiment, the POST request is used to request execution of a method of a specified resource (ie, scan FRU). The scan request includes the customized operation name and operation parameters in the @Redfish.ActionInfo link.

Among them, the target link is redfish/v1/Manager/{Id}/FRUManagerService/Actions/FRUManager.RescanBuses. The @Redfish.ActionInfo link is /redfish/v1/Managers/{Id}/RescanBusesActionInfo. The operation name (Name) is RescanBuses (rescan the bus). The operation parameter (AllowableValues) is Rescan.

Step 2: The first device responds to the received scan request sent by the client device, performs a restart operation, and scans the target FRU after the restart.

In some embodiments, after receiving the scan request, the first device performs a restart operation so that the CPU of the first device is powered on again. Afterwards, the first out-of-band controller scans the FRU on the first device, thereby achieving scanning to the target FRU.

In this embodiment, the first device can be configured to restart in response to the scan request, and after restarting, scan the FRU on the first device. In this way, when the user determines that the FRU needs to be scanned, the user can send a message to the first device. The scan request instructs the first device to scan the FRU, which helps to increase the flexibility of FRU scanning.

The second part of the embodiment of the present application will be introduced below with reference to FIG. 6 .

Figure 6 is a flow chart of another field replaceable unit FRU management method according to an exemplary embodiment. Exemplarily, the method includes the following S601-S612.

It should be noted that this method is applicable to the system architecture shown in Figure 2A to Figure 2B.

In some embodiments, the configuration content in the configuration file of the target FRU is stored on the client device. In addition, FRUs on multiple first devices are also replaced with target FRUs.

In order to reduce the research and development cost and time of configuring the configuration file of the target FRU for the first device, any first device among the plurality of first devices can automatically create the configuration file of the target FRU based on the following S601-S507. In other words, the first device in the following embodiments may be any first device among multiple first devices.

Optionally, S601: The client device responds to the query instruction and sends a query request to the first device.

The query request is used to request to query the FRU type supported by the first device.

In some embodiments, after the client device logs into the client of the first out-of-band controller, the CPU of the client device sends a query request to the first out-of-band controller.

The client device stores configuration files of multiple FRUs. For example, the configuration files of the multiple FRUs may be stored in a storage device of the client device. In order to ensure that the FRU type corresponding to the configuration content subsequently sent to the first device is the FRU type supported by the first device, therefore, the client device sends a query request to the first device to request to query the FRU type supported by the first device. .

Optionally, S602: In response to the query request, the first device sends the target FRU type to the client device.

In some embodiments, the first FRU configuration service interface of the first out-of-band controller receives the query request sent by the client device and obtains the FRU type supported by the first device. Afterwards, the first FRU configuration service interface sends the FRU type supported by the first device (ie, the target FRU type) to the client device.

In this embodiment, the client device queries the FRU type supported by the first device, which helps ensure that the FRU corresponding to the configuration content sent to the first device is the FRU type supported by the first device.

Optionally, the FRU management method also includes:

Step 1: The client device sends a first start request to the first device; the first start request is used to request to start the FRU configuration service of the first device, so that the first device supports the configuration content in the imported configuration file;

Step 2: In response to the received first enable request, the first device sets the FRU configuration management service of the first device to an enabled state.

It should be noted that for the relevant descriptions of steps one to two, please refer to the relevant descriptions of S301a to S301c mentioned above, which will not be described in detail here.

S603: The client device responds to the creation instruction and sends a creation request to the first device.

The creation request is used to request to create the configuration file of the target FRU. The creation request includes the configuration content in the target FRU's configuration file.

Wherein, the creation instruction is used to instruct to send a creation request of the configuration file of the target FRU to the first device.

In some embodiments, the user performs a target operation on the client, and the client generates a creation instruction in response to the target operation performed by the user. The target operation may be an operation performed by the user on the command line, or it may also be an operation performed by the user on the client location of the first out-of-band controller.

In some embodiments, the client device stores the configuration content in the configuration file of the target FRU. In the case that the first device does not configure the configuration file of the target FRU, the client device sends a creation request to the first device, so that the first device can automatically create the configuration file of the target FRU.

In some embodiments, after the client device logs in to the client of the first out-of-band controller, the CPU of the client device sends a creation request to the first out-of-band controller.

In one example, the client device responds to the creation instruction and sends a creation request to the first device based on the target FRU type, where the configuration file of the target FRU belongs to the target FRU type. In this way, it helps to ensure that the first device receives The configuration content in the target FRU's configuration file can be used normally.

Optionally, S603 includes: in response to the creation instruction, sending the creation request to the first device based on a third interface; the third interface supports transmission of data in JSON format.

In this implementation, since the configuration file of the FRU is a JSON file and the configuration content in the FRU configuration file is in JSON format, the client device sends the configuration content in the configuration file of the target FRU to the first device through the third interface. The third interface supports the transmission of JSON format files. In this way, when transmitting configuration content, there is no need to convert the data format, which helps ensure the convenience and accuracy of data transmission.

It should be noted that for other relevant instructions of S603, please refer to the above-mentioned S304. The principles of the two are the same and will not be described again here.

S604: The first device receives the creation request sent by the client device.

It should be noted that for other relevant instructions of S604, please refer to the above-mentioned S305. The principles of the two are the same and will not be described again here.

Optionally, S605: The first device determines whether the configuration content in the configuration file of the target FRU meets the preset conditions.

It should be noted that for other relevant instructions of S605, please refer to the above-mentioned S306. The principles of the two are the same and will not be described again here.

S606: In response to the creation request, the first device creates a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU.

It should be noted that for other related instructions of S606, please refer to the above-mentioned S307. The principles of the two are the same and will not be described again here.

S607: The first device manages the target FRU based on the configuration file of the target FRU.

It should be noted that for other related instructions of S607, you can refer to the above-mentioned S308. The principles of the two are the same and will not be repeated here.

In the above embodiment, when the user determines that the first device needs to use the configuration file of the target FRU, the client device is instructed to send a creation request to the first device through a create instruction, so that the first device can automatically create the configuration file of the target FRU. After receiving the creation request, the first device automatically responds to the creation request and automatically creates the configuration file of the target FRU based on the configuration content in the configuration file of the target FRU carried in the creation request. After that, based on the created configuration file of the target FRU, Management target FRU. Since the first device can automatically create the configuration file of the target FRU based on the creation request, compared with the related technology, it is necessary to develop, test, version release and other processes of the firmware program to configure the configuration file of the target FRU for the first device. Not only does it help reduce the cost of replacing the target FRU, it also helps improve the efficiency of replacing the target FRU.

Below, through S608 to S612, the process of the client device obtaining the configuration file of the target FRU is exemplarily introduced.

S608: The client device responds to the acquisition instruction and sends an acquisition request to the second device.

The acquisition request is used to request to acquire the configuration content in the configuration file of the target FRU.

In some embodiments, after the client device logs in to the client of the second out-of-band controller, the CPU of the client device sends an acquisition request to the second out-of-band controller.

Optionally, the FRU management method also includes:

Step 1: The client device sends a third start request to the second device. The second start request is used to request to start the FRU configuration management service of the second device so that the second device supports exporting the configuration content in the configuration file.

Step 2: In response to the received third enable request, the second device sets the FRU configuration management service of the second device to an enabled state.

It should be noted that for the relevant descriptions of steps one to two, please refer to the relevant descriptions of S301a to S301c mentioned above, which will not be described in detail here.

It should be noted that for other related instructions of S608, you can refer to the above-mentioned S301. The principles of the two are the same and will not be described again here.

S609: The second device receives the acquisition request sent by the client device.

It should be noted that for other relevant instructions of S609, please refer to the above-mentioned S302. The principles of the two are the same and will not be described again here.

Optionally, S610: The second device determines whether the configuration content in the configuration file of the target FRU meets the preset conditions.

It should be noted that for other related instructions of S610, you can refer to the above-mentioned S303. The principles of the two are the same and will not be repeated here.

S611: The second device sends the configuration content in the configuration file of the target FRU to the client device.

It should be noted that for the relevant description of S611, please refer to the above-mentioned S304. The principles of the two are the same and will not be described again here.

S612: The client device receives the configuration content in the configuration file of the target FRU sent by the second device.

It should be noted that for the relevant instructions of S612, please refer to the above-mentioned S305. The principles of the two are the same and will not be described again here.

In the above embodiment, in response to the acquisition instruction, the first device sends an acquisition request to the second device to request to acquire the configuration content in the configuration file of the target FRU from the second device, thereby realizing the configuration content in the configuration file of the target FRU, In this way, other devices can generate the configuration file of the target FRU based on the configuration content in the configuration file. Compared with related technologies, processes such as firmware program development, testing, and version release are required to determine the configuration in the configuration file of the target FRU. content, not only helps to reduce the cost of determining the configuration content in the configuration file, but also helps to improve the efficiency of the configuration content in the configuration file.

The above mainly introduces the solutions provided by the embodiments of the present application from the perspective of methods. In order to realize the above functions, the field replaceable unit FRU management device includes hardware structures and/or software modules corresponding to each function. Persons skilled in the art should easily realize that, with the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is performed by hardware or computer software driving the hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

Embodiments of the present application can exemplarily divide the field replaceable unit FRU management device into functional modules according to the above method. For example, the field replaceable unit FRU management device may include functional modules corresponding to each functional division, or the two functional modules may be divided into two. One or more functions are integrated into one processing module. The above integrated modules can be implemented in the form of hardware or software function modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods.

Exemplarily, FIG. 7 shows a possible structural diagram of the field replaceable unit FRU management device (denoted as field replaceable unit FRU management device 700) involved in the above embodiment. The FRU management device 700 includes a receiving unit 701, creation unit 702 and management unit 703. The receiving unit 701 is configured to receive a creation request, which is used to request the creation of a configuration file of the target FRU; the creation request includes the configuration content in the configuration file of the target FRU. For example, S305 shown in Figure 3, S604 shown in Figure 6. The creation unit 702 is configured to respond to the creation request and create a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU. For example, S307 shown in Figure 3, S606 shown in Figure 6. The management unit 703 is used to manage the target FRU based on the configuration file of the target FRU. For example, S308 shown in Figure 3, S607 shown in Figure 6.

Optionally, the creation request is sent by the client device in response to a creation instruction. The creation instruction is used to instruct the first device to send a creation request for the configuration file of the target FRU. The client device stores the configuration content in the configuration file of the target FRU. .

Optionally, the FRU management device 700 further includes a sending unit 704. The sending unit 704 is configured to send an acquisition request to the second device when the first device does not configure the configuration file of the target FRU; the second device stores the configuration file of the target FRU, and the acquisition request is used to request to obtain the configuration file of the target FRU. Configuration content; wherein the create request is sent by the second device in response to the get request.

Optionally, the sending unit 704 is specifically configured to send an acquisition request to the second device in response to the received target instruction; the target instruction is used to instruct to obtain the configuration content in the configuration file of the target FRU from the second device, and the target instruction It is sent when the first device does not configure the configuration file of the target FRU; or in response to the target scan result, an acquisition request is sent to the second device; the target scan result includes that the configuration file of the target FRU was not scanned on the first device. .

Optionally, the creation unit 702 is specifically configured to create a configuration file of the target FRU based on the configuration content in the configuration file in response to the creation request if the configuration content in the configuration file meets the preset conditions.

Optionally, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; wherein, the attribute name of the configuration content includes At least one of the target FRU's manufacturer identification, PN component identification, SN serial number, model, and name.

Optionally, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; wherein, the attribute name of the configuration content includes The model ID and/or FRU type of the target FRU.

Optionally, the acquisition request includes the name of the target FRU, and the acquisition request is used to request the acquisition of the configuration content in the configuration file indicated by the name of the target FRU; or the acquisition request includes the model identification of the first device, and the acquisition request is used to request the acquisition. The configuration content in the configuration file supported by the model identification. The configuration file of the target FRU is the configuration file supported by the model identification.

Optionally, when the acquisition request includes the model identification of the first device, the acquisition request may also include a target FRU type. The target FRU type is a FRU type supported by the first device, and the acquisition request is used to request to obtain the target FRU type. The configuration content in the configuration file, the configuration file of the target FRU is a configuration file belonging to the target FRU type.

Optionally, the configuration content in the configuration file is in JSON format; the receiving unit 701 is specifically configured to receive the creation request based on the first interface; the first interface supports the transmission of data in JSON format.

For specific descriptions of the above optional methods, please refer to the foregoing method embodiments, and will not be described again here. In addition, the explanation and description of the beneficial effects of any of the field replaceable unit FRU management devices 700 provided above may refer to the above corresponding method embodiments, and will not be described again.

Exemplarily, FIG. 8 shows a possible structural diagram of the field replaceable unit FRU management device (denoted as field replaceable unit FRU management device 800) involved in the above embodiment. The FRU management device 800 includes a receiving device. Unit 801 and sending unit 802. The receiving unit 801 is configured to receive an acquisition request; the acquisition request is used to request to acquire the configuration content in the configuration file of the target FRU. For example, S302 shown in Figure 3 and S602 shown in Figure 6 . The sending unit 802 is configured to respond to the acquisition request and send a creation request to the device that sends the acquisition request; the creation request includes the configuration content in the configuration file of the target FRU, and the creation request is used to request the creation of the configuration file of the target FRU, and the configuration of the target FRU. The file is used to manage the target FRU on the device that sends the acquisition request, or the sending unit 802 is used to respond to the acquisition request and send the configuration content in the configuration file of the target FRU to the device that sends the acquisition request. For example, S304 shown in Figure 3, or S611 shown in Figure 6.

Optionally, the acquisition request is sent by the client device in response to the acquisition instruction; or the acquisition request is sent by the first device when the first device does not configure the configuration file of the target FRU.

Optionally, the sending unit is specifically configured to respond to the acquisition request if the configuration content in the configuration file meets a preset condition.

Optionally, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; wherein, the attribute name of the configuration content includes At least one of the target FRU's manufacturer identification, PN component identification, SN serial number, model, and name.

Optionally, the configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; wherein, the attribute name of the configuration content includes The model ID and/or FRU type of the target FRU.

Optionally, the acquisition request includes the name of the target FRU, and the acquisition request is used to request to obtain the configuration file indicated by the name of the target FRU; or the acquisition request includes the model identification of the first device, and the acquisition request is used to request to obtain the model identification. Supported configuration files, model identification supported configuration files include the configuration file of the target FRU.

Optionally, when the acquisition request includes the model identification of the first device, the acquisition request may also include a target FRU type. The target FRU type is a FRU type supported by the first device, and the acquisition request is used to request to obtain the target FRU type. configuration file.

Optionally, the configuration content in the configuration file is in JSON format; the sending unit 802 is specifically configured to: in response to the acquisition request, send a creation request to the device that sent the acquisition request based on the second interface; the second interface supports the transmission of data in JSON format. .

Optionally, the configuration content in the configuration file is in JSON format; the sending unit 802 is specifically configured to: in response to the acquisition request, send the configuration content in the configuration file of the target FRU to the device that sends the acquisition request, including: in response to the acquisition request, Based on the second interface, the configuration content in the configuration file of the target FRU is sent to the device that sends the acquisition request.

For specific descriptions of the above optional methods, please refer to the foregoing method embodiments, and will not be described again here. In addition, the explanation and description of the beneficial effects of any of the field replaceable unit FRU management devices 800 provided above may refer to the corresponding method embodiments above, and will not be described again.

Exemplarily, FIG. 9 shows a possible structural diagram of the field replaceable unit FRU management device (denoted as field replaceable unit FRU management device 900) involved in the above embodiment. The FRU management device 900 includes: Unit 901. The sending unit 901 is configured to send a creation request to the first device in response to the creation instruction; the creation request is used to request the creation of a configuration file of the target FRU; the creation request includes the configuration content in the configuration file. For example, S603 shown in Figure 6.

Optionally, the FRU management device 900 further includes a receiving unit 902. The sending unit 901 is also configured to send an acquisition request to the second device in response to the acquisition instruction; the acquisition request is used to request acquisition of the configuration content in the configuration file of the target FRU; the receiving unit is used to receive the target FRU sent by the second device Configuration content in the configuration file.

Optionally, the acquisition request includes the name of the target FRU, and the acquisition request is used to request the acquisition of the configuration content in the configuration file indicated by the name of the target FRU; or the acquisition request includes the model identification of the first device, and the acquisition request is used to request the acquisition. The configuration content in the configuration file supported by the model identification. The configuration file of the target FRU is the configuration file supported by the model identification.

Optionally, when the acquisition request includes the model identification of the first device, the acquisition request may also include a target FRU type. The target FRU type is a FRU type supported by the first device, and the acquisition request is used to request to obtain the target FRU type. The configuration content in the configuration file, the configuration file of the target FRU is a configuration file belonging to the target FRU type.

Optionally, the sending unit 901 is specifically configured to: in response to the creation instruction, send a creation request to the first device based on a third interface; the third interface supports transmission of data in JSON format.

For specific descriptions of the above optional methods, please refer to the foregoing method embodiments, and will not be described again here. In addition, the explanation and description of the beneficial effects of any of the field replaceable unit FRU management devices 900 provided above may refer to the above corresponding method embodiments, and will not be described again.

An embodiment of the present application also provides a computer device. The computer device includes a processor and a memory. The processor is connected to the memory. The memory stores computer execution instructions. When the processor executes the computer execution instructions, the data processing in the above embodiments is implemented. method. The embodiments of this application do not place any restrictions on the specific form of the computer equipment. For example, the computer device may be a terminal device or a network device. Wherein, the terminal device may be called: terminal, user equipment (UE), terminal equipment, access terminal, user unit, user station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user device, etc. The terminal device may be a mobile phone, an augmented reality (AR) device, a virtual reality (VR) device, a tablet computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, or a personal computer. Digital assistant (personal digital assistant, PDA), etc. The network device may specifically be a server, etc. Among them, the server can be a physical or logical server, or there can be two or more physical or logical servers that share different responsibilities and cooperate with each other to realize various functions of the server.

Embodiments of the present application also provide a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is run on a computer, it causes the computer to execute any of the computer devices provided above. The method performed.

For explanations of relevant contents and descriptions of beneficial effects in any of the computer-readable storage media provided above, reference may be made to the corresponding embodiments described above and will not be described again here.

An embodiment of the present application also provides a chip. The chip integrates a control circuit and one or more ports for realizing the functions of the above computer device. Optionally, the functions supported by this chip can be referred to above and will not be described again here. Those of ordinary skill in the art can understand that all or part of the steps to implement the above embodiments can be completed by instructing relevant hardware through programs. The program may be stored in a computer-readable storage medium. The storage medium mentioned above may be a read-only memory, a random access memory, etc. The above-mentioned processing unit or processor may be a central processing unit, a general-purpose processor, an application specific integrated circuit (ASIC), a microprocessor (digital signal processor, DSP), or a field programmable gate array (FPGA). ) or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

Embodiments of the present application also provide a computer program product containing instructions. When the instructions are run on a computer, they cause the computer to perform any of the methods in the above embodiments. The computer program product includes one or more computer instructions. When computer program instructions are loaded and executed on a computer, processes or functions according to embodiments of the present application are generated in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device. Computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, e.g., computer instructions may be transmitted from a website, computer, server or data center via a wired (e.g. Coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means to transmit to another website, computer, server or data center. Computer-readable storage media can be any available media that can be accessed by a computer or include one or more data storage devices such as servers and data centers that can be integrated with the media. Available media may be magnetic media (eg, floppy disk, hard disk, magnetic tape), optical media (eg, DVD), or semiconductor media (eg, SSD), etc.

It should be noted that the above-mentioned devices for storing computer instructions or computer programs provided by the embodiments of the present application, such as but not limited to the above-mentioned memories, computer-readable storage media, communication chips, etc., are all non-transitory. .

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When computer program instructions are loaded and executed on a computer, processes or functions according to embodiments of the present application are generated in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device. Computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, e.g., computer instructions may be transmitted from a website, computer, server or data center via a wired (e.g. Coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means to transmit to another website, computer, server or data center. Computer-readable storage media can be any available media that can be accessed by a computer or include one or more data storage devices such as servers and data centers that can be integrated with the media. Available media may be magnetic media (eg, floppy disk, hard disk, magnetic tape), optical media (eg, DVD), or semiconductor media (eg, solid state disk (SSD)), etc.

Although the present application has been described herein in connection with various embodiments, in practicing the claimed application, those skilled in the art can understand and implement the disclosure by reviewing the drawings, the disclosure, and the appended claims. Other variations of the embodiment. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may perform several of the functions recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be combined to advantageous effects.

Although the present application has been described in conjunction with specific features and embodiments thereof, it will be apparent that various modifications and combinations may be made without departing from the spirit and scope of the application. Accordingly, the specification and drawings are intended to be merely illustrative of the application as defined by the appended claims and are to be construed to cover any and all modifications, variations, combinations or equivalents within the scope of the application. Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. In this way, if these modifications and variations of the present application fall within the scope of the claims of the present application and equivalent technologies, the present application is also intended to include these modifications and variations.

Claims (16)

1. A field replaceable unit FRU management method, characterized in that it is used for a first device, the first device includes a target FRU; the method includes: Receive a creation request, where the creation request includes the configuration content in the configuration file of the target FRU; In response to the creation request, create a configuration file of the target FRU based on the configuration content in the configuration file of the target FRU; The target FRU is managed based on the configuration file of the target FRU. 2. The method according to claim 1, characterized in that, The creation request is sent by the client device in response to a creation instruction. The creation instruction is used to instruct the first device to send a creation request for the configuration file of the target FRU. The client device stores the target. Configuration content in the FRU configuration file; or The method also includes: when the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device; the second device stores the configuration file of the target FRU, and the acquisition request Used to request to obtain the configuration content in the configuration file; wherein the creation request is sent by the second device in response to the acquisition request. 3. The method according to claim 2, characterized in that, when the first device does not configure the configuration file of the target FRU, sending an acquisition request to the second device includes: In response to the received target instruction, send the acquisition request to the second device; the target instruction is used to instruct to obtain the configuration content in the configuration file of the target FRU from the second device, and the target instruction is Sent when the first device does not configure the configuration file of the target FRU; or In response to a target scan result, an acquisition request is sent to the second device; the target scan result includes that the configuration file of the target FRU is not scanned on the first device. 4. The method according to any one of claims 1-3, characterized in that, in response to the creation request, the configuration of the target FRU is created based on the configuration content in the configuration file of the target FRU. Documents, including: If the configuration content in the configuration file meets the preset conditions, in response to the creation request, create a configuration file for the target FRU based on the configuration content in the configuration file. 5. The method according to claim 4, characterized in that, The configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; wherein, the configuration content The attribute name includes at least one of the target FRU's manufacturer identification, PN component identification, SN serial number, model, and name; and/or The configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; wherein, the configuration content The attribute name includes the model identification and/or FRU type of the target FRU. 6. The method according to any one of claims 2, 3 or 5, characterized in that, The acquisition request includes the name of the target FRU, and the acquisition request is used to request to obtain the configuration content in the configuration file indicated by the name of the target FRU; or The acquisition request includes the model identification of the first device. The acquisition request is used to request to obtain the configuration content in the configuration file supported by the model corresponding to the model identification. The configuration file of the target FRU is the The above model identification supports configuration files. 7. The method according to claim 5, characterized in that, In the case where the acquisition request includes the model identification of the first device, the acquisition request may also include a target FRU type, and the target FRU type is an FRU type supported by the first device. The acquisition request Used to request to obtain configuration content in a configuration file belonging to the target FRU type, where the configuration file of the target FRU is a configuration file belonging to the target FRU type. 8. The method according to any one of claims 1-7, characterized in that the configuration content in the configuration file is in JSON format; the receiving a creation request includes: Based on the first interface, the creation request is received; the first interface supports transmitting data in JSON format. 9. A field replaceable unit FRU management method, characterized in that it is used in a second device, and the configuration file of the target FRU is stored in the second device; the method includes: Receive an acquisition request; the acquisition request is used to request to obtain the configuration content in the configuration file of the target FRU; In response to the acquisition request, send a creation request to the device that sent the acquisition request; the creation request includes the configuration content in the configuration file of the target FRU, and the creation request is used to request the creation of the configuration of the target FRU. file, the configuration file of the target FRU is used to manage the target FRU on the device that sends the acquisition request; or In response to the acquisition request, the configuration content in the configuration file of the target FRU is sent to the device that sent the acquisition request. 10. The method according to claim 9, characterized in that The acquisition request is sent by the client device in response to an acquisition instruction; or The acquisition request is sent by the first device when the first device does not configure the configuration file of the target FRU. 11. The method according to claim 9 or 10, characterized in that the response to the acquisition request includes: If the configuration content in the configuration file meets the preset conditions, respond to the acquisition request. 12. The method according to claim 11, characterized in that, The configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the field type of the configuration content is the same as the preset field type; wherein, the configuration content The attribute name includes at least one of the target FRU's manufacturer identification, PN component identification, SN serial number, model, and name; and/or The configuration content in the configuration file meets the preset conditions, including: the attribute name of the configuration content is the same as the preset attribute name, and the attribute value of the configuration content is the same as the preset attribute value; wherein, the configuration content The attribute name includes the model identification and/or FRU type of the target FRU. 13. The method according to any one of claims 9-12, characterized in that, The acquisition request includes the name of the target FRU, and the acquisition request is used to request acquisition of the configuration file indicated by the name of the target FRU; or The acquisition request includes the model identification of the first device. The acquisition request is used to request to obtain the configuration file supported by the model identification. The configuration file supported by the model identification includes the configuration file of the target FRU. . 14. The method according to any one of claims 9-13, characterized in that the configuration content in the configuration file is in JSON format; In response to the acquisition request, sending a creation request to the device that sent the acquisition request includes: in response to the acquisition request, based on a second interface, sending a creation request to the device that sent the acquisition request; the second interface Supports transmitting data in JSON format; or In response to the acquisition request, sending the configuration content in the configuration file of the target FRU to the device that sent the acquisition request includes: responding to the acquisition request, based on the second interface, sending the configuration content in the configuration file of the target FRU to the device that sent the acquisition request. Send the configuration content in the configuration file of the target FRU. 15. A field replaceable unit FRU management method, characterized in that it is used for client equipment, and the client equipment stores the configuration content in the configuration file of the target FRU; the method includes: In response to the creation instruction, a creation request is sent to the first device; the creation request is used to request creation of a configuration file of the target FRU; the creation request includes configuration content in the configuration file. 16. A computing device, characterized by comprising: a processor; The processor is connected to a memory, the memory is used to store computer execution instructions, and the processor executes the computer execution instructions stored in the memory, so that the computing device implements any one of claims 1-8 method described in the item.