Interface design and implementation method of BMC remote management system based on Redfish

Abstract

The invention discloses an interface design and implementation method of a BMC (Baseboard Management Controller) remote management system based on Redfish. According to the method, a multi-module resource model conforming to Redfish specifications is constructed in a baseboard management controller (BMC), management modules including Systems, Chassis, Managers, Account Service, Session Service, TaskService, Update Service, FRU and the like are integrated, and a unified RESTful interface architecture is formed. The method supports standardized access to management functions such as a server system state, hardware assets, a user account, remote control and firmware upgrading, and meanwhile, a unified authentication mechanism and an asynchronous task mechanism are introduced, so that an efficient and safe out-of-band management process is realized. The system has the advantages of uniform interface, clear structure, safety, controllability, high expandability and the like, and is suitable for various data center and server remote management scenes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to an interface design and implementation method of a BMC remote management system based on Redfish. BACKGROUND

[0002] With the increase of the scale and complexity of data centers, remote monitoring and management of servers becomes increasingly important. BMC, as a dedicated management controller of servers, undertakes key management functions such as monitoring hardware health status, controlling power switch, log collection, etc. Traditionally, the industry widely uses out-of-band management standards such as IPMI (Intelligent Platform Management Interface) to control BMC. However, IPMI only provides a limited set of commands (such as power on, power off, restart, read temperature, text console, etc.). Due to the lack of uniformity in vendor extensions, IPMI is difficult to meet the complex management needs of modern large-scale, multi-node servers or hybrid infrastructure.

[0003] In recent years, a new generation of server management standard Redfish proposed by DMTF organization has emerged. Redfish adopts RESTful architecture and JSON data model to provide a uniform and interoperable management interface for servers. Redfish interface has the advantages of discoverability, scalability, ease of management and security, etc., and can further enrich the remote management functions of servers. In the Redfish model, all management resources are accessed through a unified service entry point. Different types of resources are modeled according to an object-oriented hierarchy and divided into several collections (Collections), such as Systems, Managers and Chassis, etc., which are used to represent the logical view of computer systems, management controllers and physical chassis, etc. In addition, Redfish also provides account, secure session, event, task, firmware update, etc. service sub-modules for unified processing of user authentication, session management, event notification, asynchronous task and firmware upgrade, etc. management transactions.

[0004] Although the Redfish standard provides a comprehensive interface system, how to design and implement a unified remote management platform architecture in BMC, organically integrate each Redfish module, and fully exert the advantages of object-oriented interface layering design and RESTful resource path mapping, still faces many challenges and technical problems. For example, how do the interfaces of each module work together to maintain data consistency, how to implement unified permission control to ensure secure access, how to map the underlying complex management logic through the standard REST path, and how to feedback the system status in real time during remote control, are all problems that existing technical personnel need to solve.

[0005] In summary, the prior art lacks a BMC remote management scheme that unifies the numerous management interface modules under the Redfish architecture, and cannot fully utilize the advantages of the Redfish standard to simplify operation and maintenance management. Therefore, it is of important practical value to develop an interface design and implementation method for a BMC remote management system based on the Redfish architecture to realize the coordinated work, unified control, and efficient feedback of each management interface.

[0006] The technical comparison is as follows:

[0007] Comparison with patent CN 117827161 A "Server management system and method based on Redfish interface"

[0008] Patent CN 117827161 A is through encapsulating Redfish API from the client side to perform command calling, while the present patent scheme constructs a native Redfish service from the BMC side to realize unified resource mapping. There is an essential difference in the interface architecture design idea between the two.

[0009] Patent CN 117827161 A relies on the existing Redfish implementation for synchronous control, while the present patent scheme supports an asynchronous Task mechanism and deeply couples Redfish resources with firmware, power supply, and state modules to realize unified resource management. There is an essential difference in the Redfish task execution mechanism and module coordination strategy between the two. SUMMARY

[0010] The present invention aims to solve the problems in the background art and provides an interface design and implementation method for a BMC remote management system based on the Redfish architecture. By integrating each interface module defined by the Redfish specification into an object-oriented management platform, comprehensive remote control and state monitoring of servers are realized, and innovative mechanisms such as unified permission control, programmable actions, and separated firmware updates are introduced to improve the security, flexibility, and reliability of management.

[0011] Technical solution: To achieve the above invention purpose, the present invention provides an interface design and implementation method for a BMC remote management system based on Redfish, specifically including the following steps:

[0012] 1. Deploy a Redfish service framework on the BMC, initialize HTTP / HTTPS network services and authentication mechanisms, and provide a unified Redfish interface entry;

[0013] 2. Integrate multiple BMC management resource modules, including Systems module, Chassis module, Managers module, AccountService module, SessionService module, TaskService module, UpdateService module and FRU module, to build the resource model of Redfish interface; embed each management resource module into BMC firmware system and run it;

[0014] 3. Interactively map each management resource module with BMC underlying hardware and firmware, provide RESTful API access externally through Redfish service framework, enable remote client to perform query or control operation on the module, and obtain response data in standard format;

[0015] 4. When the operation involves a long-time task (such as firmware upgrade), the corresponding management resource module generates an asynchronous task by calling TaskService module, and returns a task ID to the client, so as to facilitate the client to continuously query the task progress;

[0016] 5. When the interface call is completed, the Redfish service returns the corresponding HTTP status code and structured response data to the client to identify the operation result status; the status code is used to indicate the success or failure of the execution, and the structured data includes standard resource information or error description, which facilitates the client to perform automatic management and status identification.

[0017] Further, in step 1, the Redfish service process is deployed on the BMC, and a unified service root (ServiceRoot) entry point is set, with the address / redfish / vl. The service root serves as a unified entry point for the entire management system, exposing the top-level access path for each management resource to remote clients, and providing metadata information about the Redfish service version, host name, etc. By initializing the HTTP / HTTPS protocol stack and authentication mechanisms (such as HTTP Basic or Session-based authentication), it is ensured that clients can securely connect to the Redfish interface of the BMC. With this unified entry point, clients can discover and traverse all management resource subtrees provided by the BMC. For example, accessing / redfish / vl will return a "site map" style JSON object listing the links to the main resource collections such as Systems, Chassis, Managers, etc., as well as the service resources such as AccountService, SessionService, etc. The purpose of this design is to provide a consistent interface entry point to facilitate client self-discovery and use of all management functions. By deploying the Redfish service framework, the BMC has standard REST API service capabilities, laying the foundation for subsequent integration of various management modules.

[0018] Further, in step 2, each management module implements specific management functions and REST interfaces, and the specific functions and implementation methods of each management resource module are as follows:

[0019] 1) Managers module: corresponding to the management controller (Managers) resource in Redfish, used to manage the BMC itself. The Managers module provides interfaces to obtain BMC firmware version, manufacturer information, network configuration, etc., and supports management operations on the BMC, such as remote resetting of the BMC, setting network parameters, etc. The Managers module usually handles requests for the " / redfish / vl / Managers" path, returning information about the BMC

[0020] (management controller). If remote updating of BMC configuration or restarting of the BMC is required, it can also be implemented through the operation interfaces provided by this module.

[0021] 2) Systems module: corresponding to the computer system (Systems) resource in Redfish, used to provide a management interface for the overall system state of the server. The Systems module is connected with the power control, power state sensor, BIOS interface and other subsystems at the BMC bottom layer, and realizes functions such as reading / setting the server power state, obtaining CPU and memory configuration, setting the boot device order, executing the power on / power off / restart command, etc. When the Redfish client issues a GET request to the resource under “ / redfish / v1 / Systems”, the Systems module collects the current server processor, memory, storage and other configurations and running states, and returns them as JSON data; when receiving a PATCH / POST request to the Systems resource, it parses the parameters contained in the request and calls the underlying interface to perform the corresponding changes (such as triggering server restart or updating the boot order). Through the Systems module, the Redfish client can manage the server hardware and power and other core functions in a standardized manner.

[0022] 3) Chassis module: corresponding to the Chassis resource in Redfish, used to manage the physical chassis and its component information of the server. The Chassis module is connected with various sensors and monitoring circuits of the BMC, and obtains the identification, model, serial number of the chassis and the state parameters of each FRU component (such as fans, power modules, etc.) in the chassis. Through this module, users can query the type, installation location, environmental temperature and other information of the chassis. When the client accesses the “ / redfish / v1 / Chassis” resource, the Chassis module returns JSON data containing chassis overview, environmental sensor readings and replaceable component list, etc.

[0023] 4) AccountService module: used to manage user account information of the BMC. The AccountService module maintains the account list and permission policy of remote management users on the BMC, and realizes operations such as adding, deleting, modifying and querying user accounts. When the client issues a POST request to the “ / redfish / v1 / AccountService / Accounts” resource to create a new account, the module verifies the legality of the input information and calls the BMC user management subsystem to establish a new account; for DELETE request, it deletes the specified user account; for GET request, it returns the current user list. Through the AccountService module, unified management and access control configuration of BMC management users can be realized.

[0024] 5) SessionService module: used for managing Redfish session and authentication mechanism. The SessionService module handles the creation and maintenance of login sessions, such as when a client submits a username and password to log in at “ / redfish / v1 / SessionService / Sessions”. If the authentication is successful, a new session is created, a session token (Token) is generated and returned to the client, and information such as the session validity period and the last activity time is recorded to support subsequent session verification and timeout processing. The module also provides a logout interface to allow the client to terminate a specified session. Through the SessionService module, it is ensured that only users who have passed legitimate authentication can access the Redfish interface resources of the BMC, thereby ensuring the security of interface use.

[0025] “ / redfish / v1 / SessionService / Sessions” submits a username and password to log in, a new session is created if the authentication is passed, a session token (Token) is generated and returned to the client, and information such as the session validity period and the last activity time is recorded to support subsequent session verification and timeout processing. The module also provides a logout interface to allow the client to terminate a specified session. Through the SessionService module, it is ensured that only users who have passed legitimate authentication can access the Redfish interface resources of the BMC, thereby ensuring the security of interface use.6) TaskService module: used for processing asynchronous management tasks. Some management operations may take a long time (such as firmware update, system restart, etc.), and the TaskService module provides task creation, state monitoring and result query functions. When other modules (such as the UpdateService module) trigger operations that need to be executed asynchronously, a task object can be generated through the TaskService module and a task ID is returned to the client. The client can then query “ / redfish / v1 / TaskService / Tasks / {taskId}” to obtain the execution status and result of the task. When the task is completed or an error occurs, the TaskService module updates the task status and saves the necessary log information for query. Through the TaskService module, the management efficiency of long-time operations is greatly improved, the client does not need to keep connected for a long time, and the concurrent processing capability of the system is improved.

[0026] 7) UpdateService module: used for managing the firmware upgrade process of the server and the BMC. The UpdateService module provides interfaces such as checking the current firmware version, uploading a new firmware image, executing an upgrade, and monitoring the upgrade process. For example, the client can obtain the available update list or submit an upgrade request through “ / redfish / v1 / UpdateService”. When receiving a firmware image upload request, the UpdateService module safely saves the image file to the storage space of the BMC and calls the underlying upgrade mechanism to start the update process. During the upgrade process, the UpdateService module can create an upgrade task in combination with the TaskService module to track the upgrade progress. After the upgrade is completed, the module updates the firmware version information of the system or device. Through the UpdateService module, the automation and standardization of server firmware lifecycle management are realized.

[0027] 8) FRU module: used to manage the field replaceable unit information of the server. The FRU module reads the asset tags and information of each hardware component from the FRU memory of the server (usually through the I 2 The C bus is connected to the EEPROM of the BMC. The asset tags and information of each hardware component, including the manufacturer, product name, component number, serial number, factory date, asset tag, etc. of the server chassis, mainboard and other components, are read from the EEPROM of the BMC. The FRU module parses and collates these information and provides query in JSON format through the Redfish interface. For example, access

[0028] The “ / redfish / v1 / Chassis / {ChassisId} / Oem / FRU” can obtain the chassis-related FRU data. The introduction of the FRU module enables the management system to conveniently obtain and maintain the asset information of the key hardware of the server; when the components are replaced on site, the administrator can update the records in time to maintain the consistency of asset management.

[0029] The above modules are implemented according to the resource model and interface path defined in the Redfish specification, work together, and constitute a complete BMC remote management REST architecture. By embedding these modules in the BMC firmware and running, the BMC can provide a unified management interface covering from device hardware to user management, firmware maintenance, etc. Each module corresponds to a resource type or service in the Redfish data model, interacts with the standard JSON data format, and ensures the interoperability and compatibility of devices from different manufacturers on the management interface.

[0030] Further, in step 3, when the external management client accesses the BMC through the Redfish interface, the request first reaches the interface service entrance, and the service framework determines the target resource according to the URI path to determine the module to which the target resource belongs (for example, the URI contains “ / Systems”, which is processed by the Systems module, contains “ / Chassis”, which is processed by the Chassis module, contains “ / FRU”, which is processed by the FRU module, etc.). After receiving the request, the corresponding management module interacts with the BMC underlying hardware or firmware to obtain the required data or perform the corresponding operation, and then generates a JSON format response according to the Redfish specification. Through the above process, the organic integration of each management module is realized, and a unified and standard management interface can be provided externally. Preferably, in the implementation process, the interface security and performance are also optimized, for example, all requests are authenticated and permission checked through the SessionService module, and the response efficiency of long-time operation is improved through the task asynchronous mechanism, etc.

[0031] Further, in step 4, when the operation involves a long-lasting task (e.g. firmware upgrade, diagnostic scan, etc. that takes tens of seconds or minutes), the corresponding management resource module creates an asynchronous task by invoking the TaskService module, thus achieving non-blocking request processing. Specifically, when the client initiates such a request, the Redfish service does not wait for the underlying operation to complete before returning; instead, it immediately returns a response indicating that the task has been accepted, including an ID or URI identifying the asynchronous task. According to the Redfish specification, when accepting a request that needs to be executed asynchronously, the server should return an "HTTP 202 Accepted" status code, indicating that the request has been accepted for processing. At the same time, the "Location" in the response header is set to the task monitoring URI (Task Monitor) related to the task, usually in the form of " / redfish / v1 / TaskService / Tasks / {TaskId}", which the client can use to query the task status. The response can also include a "Retry-After" header to prompt the client to wait for how long before querying the task status. According to the specification, the message body of the 202 response should include a JSON representation of the Task resource, providing information such as the current state of the task. For example, when starting a firmware upgrade through the UpdateService module, the service may return "202 Accepted", with the Location pointing to the URL of the newly created task, and the initial state of the task (e.g. TaskState as Running, etc.) in the response JSON.

[0032] After creating the task, the actual long-time operation begins to execute in the background of the BMC. The TaskService module asynchronously monitors and updates the task status, including the possible progress percentage, start and end time, current stage description, and any error information, etc. When the client subsequently initiates a GET request to the task monitoring URI provided by the Location, the Redfish service will return an update of the current state of the task without blocking the client's request. During the task process, the task monitoring URI will continuously return a 202 status, indicating that the task has not been completed, and can provide partial progress information in the response. The client can poll the URI as needed to obtain the latest status of the task (e.g. the polling interval is indicated by "Retry-After"), or choose to wait for a period of time in the background before querying. This design allows the client to avoid maintaining a long connection to wait, thus not blocking the parallel performance of other management operations.

[0033] Once the background task is completed (either successfully or with an error), the TaskService updates the final status and records the task result in the task resource. At this point, a GET request to the task monitor URI will no longer return 202, but instead will return the final result: if the task completed successfully, the task monitor will return "HTTP 200 OK" and include the result data that the originally requested operation should have produced in the response body (just as if the operation completed synchronously); if an error occurred during task execution, the task monitor will return an error status code and include a standard error response (in JSON format) in the response body describing the error type and details. The Redfish specification requires that, when a task fails, the response body should provide an ErrorResponse structure containing the error code, message, and possibly extended information to help the user understand the problem. In addition, the service may delete the task resource after the task is completed for resource cleanup considerations; in this case, the corresponding task URI will likely return "410 Gone" indicating that the task resource is no longer available. In summary, the asynchronous task processing mechanism implemented by the TaskService ensures efficient management of time-consuming operations - the interface call returns an accepted status immediately, and the client can query the progress at any time through the task ID, which not only ensures the timeliness of the user experience, but also improves the system's concurrent processing capability.

[0034] Further, in step 5, when the interface call (whether synchronous or asynchronous) is completed, the Redfish service returns an appropriate HTTP status code and structured response data to the client to clearly indicate the operation result. The HTTP status code follows the general REST convention: 2XX indicates success, 4XX indicates client request error, and 5XX indicates server error. For example, "200 OK" is returned when reading a resource successfully, "201 Created" is returned when creating a resource successfully, "202 Accepted" is returned when accepting an asynchronous task, and "204 No Content" is returned when there is no content; common errors such as "400 Bad Request" for incorrect request format or parameters, "401 Unauthorized" for unauthorized access, "403 Forbidden" for forbidden access, "404 Not Found" for missing resource, and "500 Internal Server Error" for server internal error, etc. Through the status code, the client can quickly determine whether the request was successfully executed or an error occurred, and thus perform appropriate subsequent processing.

[0035] Besides the status code, Redfish specifies that all response data is in structured JSON format for machine readability and automation processing. For a successful request, the response data usually contains the standardized information of the requested resource. For example, a GET request to the Systems resource will return a JSON of the server system’s detailed information; a POST request to create an Account will return a JSON representation of the new account resource; a PATCH request to a setting operation may return the updated resource information or a 204 status to indicate no content but the operation is successful. All these data formats are based on Redfish’s data model architecture, containing fixed fields and structures, so that the client program can parse and extract the required information.

[0036] If the request execution fails, the Redfish service returns a structured data describing the error, i.e., an error response. The error response is also a JSON object, usually containing an "error" node with a standard error code and a human-readable error message, and an array of extended information (@Message.ExtendedInfo) providing more detailed error sources or correction suggestions. For example, when the request parameters do not meet the requirements, the error response may contain a MessageId identifying the specific error type (such as PropertyValueNotInList), and a description in the Message. Such structured error description facilitates the client program to automatically identify the problem type, and even perform specific processing logic according to the MessageId.

[0037] By returning standard HTTP status codes and structured JSON response data, the Redfish interface enables the client to easily automate management and status recognition. The client script can directly determine the success or failure of the operation according to the status code, and use the parsed JSON response to obtain resource data when successful or error details when failed. This consistent interface behavior greatly simplifies the operation and management work: when performing batch management tasks, the program does not need to customize parsing logic for different devices, but only needs to follow the Redfish specification to handle all returns. In practice, this ensures that management tools across manufacturers and devices can be compatible with each other, and provides strong support for automated operation and maintenance of data centers. Whenever a Redfish interface call is completed, the operation and maintenance personnel or script can clearly know the operation result status and obtain structured information to determine the next action, achieving closed-loop automated management.

[0038] Beneficial effects: compared with the prior art, the application integrates complete Redfish service architecture in BMC firmware, combines device system management, chassis resource management, management control module, account and session management, task and firmware upgrade management and other multi-module functions, realizes standardized modeling and unified interface access of various management resources of the server. Compared with the traditional way of converting Redfish request into private interface protocol through an external independent management platform, the application directly deploys the Redfish native interface in the BMC, saves the protocol conversion and intermediate platform deployment, avoids the deployment complexity, interface adaptation difficulty and performance bottleneck brought by multi-layer architecture, realizes the unified standardization of the interface and the simplicity of the architecture. Unlike the common management mode which only collects node device state information or only provides basic monitoring function, the application provides device monitoring, asset management, remote operation, permission configuration, firmware upgrade and other full-dimensional management capabilities based on the Redfish architecture, greatly improving the management function coverage and operation depth of the BMC. For the traditional scheme of relying on external client to call the basic Redfish interface provided by the BMC to realize management, the application deeply integrates various management modules and Redfish interfaces in the BMC firmware, realizes the unification of interface, service and resource model, reduces the dependence on external tools, and improves the standard consistency and local autonomy of management operation. Compared with the traditional way of realizing multi-device management by using external management tools or batch scripts, the application designs a standardized task service module in the BMC, supports asynchronous task processing and task state tracking, avoids long-time operation blocking, and improves the multi-task concurrent management capability and operation efficiency. In addition, the application uses standard RESTful API combined with structured error feedback to improve the interface usability and development friendliness. Through the standard account and session service module, unified authentication, permission management and security control of multiple users are realized, and the system security is enhanced. The overall scheme adopts modular architecture design, has good scalability and platform compatibility, can adapt to multiple brands and multiple models of servers, does not need hardware modification, and can be deployed only by BMC firmware upgrade, which has stronger deployment flexibility and applicability. In summary, the application realizes overall optimization and improvement in interface standardization, management function integrity, task processing efficiency, security and system compatibility compared with the traditional scheme, significantly improves the intelligentization, automation and operation convenience of the out-of-band management of the server. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 A schematic diagram of a server management architecture with Redfish as an interface,

[0040] Figure 2 A schematic diagram of a communication process based on the Redfish architecture in the BMC,

[0041] Figure 3Service framework diagram for Redfish as BMC. DETAILED DESCRIPTION

[0042] The embodiments of the present application will be described in detail hereinafter with reference to the drawings and embodiments, so that how the present application applies technical means to solve technical problems and achieves technical effects can be fully understood and implemented. It should be noted that, as long as there is no conflict, each embodiment in the present application and each feature in each embodiment can be combined with each other, and the technical solutions formed thereby are all within the protection scope of the present application.

[0043] Embodiment: see Figure 1 , Figure 2 , Figure 3 A design and implementation method of a Redfish-based BMC remote management system interface, comprising the following steps:

[0044] 1. Deploying a Redfish service framework on the BMC, initializing an HTTP / HTTPS network service and an authentication mechanism, and providing a unified Redfish interface entry;

[0045] 2. Integrating multiple BMC management resource modules, including Systems module, Chassis module, Managers module, AccountService module, SessionService module, TaskService module, UpdateService module, and FRU module, to build a resource model of the Redfish interface; embedding each management resource module into the BMC firmware system and running it;

[0046] 3. Interactively mapping each management resource module with the underlying hardware and firmware of the BMC, providing RESTful API access to the outside through the Redfish service framework, so that the remote client can perform query or control operations on the modules and obtain response data in a standard format;

[0047] 4. When the operation involves a long-time task (such as firmware upgrade), the corresponding management resource module generates an asynchronous task by calling the TaskService module and returns a task ID to the client, so as to facilitate the client to continuously query the task progress;

[0048] 5. When the interface call is completed, the Redfish service returns the corresponding HTTP status code and structured response data to the client to identify the operation result status; the status code is used to indicate success or failure of the execution, and the structured data includes standard resource information or error description, which facilitates the client to perform automatic management and status identification.

[0049] In Step 1, the Redfish service process is deployed on the BMC, setting up a unified ServiceRoot entry point at the address / redfish / v1. This ServiceRoot serves as the unified entry point for the entire management system, exposing the top-level access paths for various management resources to remote clients, and providing metadata information such as Redfish service version, host name, etc. By initializing the HTTP / HTTPS protocol stack and authentication mechanisms (such as HTTP Basic or Session-based authentication), it ensures that clients can securely connect to the Redfish interface of the BMC. With this unified entry point, clients can discover and traverse all management resource subtrees provided by the BMC. For example, accessing / redfish / v1 will return a "sitemap"-like JSON object listing the links to main resource collections such as Systems, Chassis, Managers, and service resources such as AccountService, SessionService, etc. The purpose of this design is to provide a consistent interface entry point, making it easy for clients to discover and use all management functions. By deploying the Redfish service framework, the BMC has standard REST API service capabilities, laying the foundation for subsequent integration of various management modules.

[0050] In Step 2, each management module implements specific management functions and REST interfaces, and the specific functions and implementation methods of each management resource module are as follows:

[0051] 1) Managers module: corresponding to the management controller (Managers) resource in Redfish, used to manage the BMC itself. The Managers module provides interfaces to obtain BMC firmware version, manufacturer information, network configuration, etc., and supports management operations on the BMC, such as remote resetting the BMC, setting network parameters, etc. The Managers module usually handles requests for the " / redfish / v1 / Managers" path and returns information about the BMC

[0052] (management controller). If remote updating of BMC configuration or BMC reboot is required, it can also be implemented through the operation interfaces provided by this module.

[0053] 2) Systems module: corresponding to the computer system (Systems) resource in Redfish, used to provide a management interface for the overall system state of the server. The Systems module is connected with the power control, power state sensor, BIOS interface and other subsystems at the BMC bottom layer, and realizes functions such as reading / setting the server power state, obtaining CPU and memory configuration, setting the boot device order, executing the power on / power off / restart command, etc. When the Redfish client issues a GET request to the resource under “ / redfish / v1 / Systems”, the Systems module collects the current server processor, memory, storage and other configurations and running states, and returns them as JSON data; when receiving a PATCH / POST request to the Systems resource, it parses the parameters contained in the request and calls the underlying interface to perform the corresponding changes (such as triggering server restart or updating the boot order). Through the Systems module, the Redfish client can manage the server hardware and power and other core functions in a standardized manner.

[0054] 3) Chassis module: corresponding to the Chassis resource in Redfish, used to manage the physical chassis and its component information of the server. The Chassis module is connected with various sensors and monitoring circuits of the BMC, and obtains the identification, model, serial number of the chassis and the state parameters of each FRU component (such as fans, power modules, etc.) in the chassis. Through this module, users can query the type, installation location, environmental temperature and other information of the chassis. When the client accesses the “ / redfish / v1 / Chassis” resource, the Chassis module returns JSON data containing chassis overview, environmental sensor readings and replaceable component list, etc.

[0055] 4) AccountService module: used to manage user account information of the BMC. The AccountService module maintains the account list and permission policies of remote management users on the BMC, and realizes operations such as adding, deleting, modifying and querying user accounts. When the client issues a POST request to the “ / redfish / v1 / AccountService / Accounts” resource to create a new account, the module verifies the legality of the input information and calls the BMC user management subsystem to establish a new account; for DELETE request, it deletes the specified user account; for GET request, it returns the current user list. Through the AccountService module, unified management and access control configuration of BMC management users can be realized.

[0056] 5) SessionService module: Used to manage Redfish sessions and authentication mechanisms. The SessionService module handles the creation and maintenance of login sessions, for example, when a client accesses the system via...

[0057] When a user submits a username and password to log in via " / redfish / v1 / SessionService / Sessions", if authentication is successful, a new session is created, a session token is generated and returned to the client. Simultaneously, information such as session validity and last activity time is recorded to support subsequent session verification and timeout handling. This module also provides a logout interface, allowing clients to terminate a specified session. Through the SessionService module, it is ensured that only legitimately authenticated users can access Redfish interface resources in the BMC, thereby guaranteeing the security of interface usage.

[0058] 6) TaskService Module: Used to handle asynchronous management tasks. Some management operations may be time-consuming (e.g., firmware updates, system restarts, etc.). The TaskService module provides task creation, status monitoring, and result query functions. When other modules (such as the UpdateService module) trigger operations that need to be executed asynchronously, the TaskService module can generate a task object and return the task ID to the client. The client can then query " / redfish / v1 / TaskService / Tasks / {taskId}" to obtain the execution status and result of the task. When a task is completed or an error occurs, the TaskService module updates the task status and saves necessary log information for querying. Through the TaskService module, the management efficiency of long-running operations is greatly improved, and the client does not need to maintain a connection for a long time, thus improving the system's concurrent processing capabilities.

[0059] 7) UpdateService module: used for managing firmware upgrade process of the server and BMC. The UpdateService module provides interfaces for checking current firmware version, uploading new firmware image, performing upgrade, and monitoring upgrade process, etc. For example, the client can get the list of available updates or submit an upgrade request through “ / redfish / v1 / UpdateService”. When receiving a firmware image upload request, the UpdateService module saves the image file securely to the storage space of the BMC and invokes the underlying upgrade mechanism to start the update process. During the upgrade process, the UpdateService module can create an upgrade task in combination with the TaskService module to track the upgrade progress. After the upgrade is completed, the module updates the firmware version information of the system or device. Through the UpdateService module, the automation and standardization of server firmware life cycle management are realized.

[0060] 8) FRU module: used for managing field replaceable unit (FRU) information of the server.

[0061] The FRU module reads the asset tags and information of each hardware component from the FRU memory (usually through the I 2 C bus and the EEPROM connected to the BMC) of the server, including the manufacturer, product name, part number, serial number, date of manufacture, asset tag, etc. of the server chassis, motherboard and other components. The FRU module parses and organizes these information and provides query in JSON format through the Redfish interface. For example, accessing

[0062] “ / redfish / v1 / Chassis / {ChassisId} / Oem / FRU” can get the FRU data related to the chassis. The introduction of the FRU module enables the management system to easily obtain and maintain the asset information of the key hardware of the server; when replacing components on site, the administrator can update the records in time to maintain the consistency of asset management.

[0063] The above modules are implemented according to the resource model and interface path defined in the Redfish specification, work collaboratively with each other, and constitute a complete BMC remote management REST architecture. By embedding these modules in the BMC firmware and running, the BMC can provide a unified management interface covering various aspects from device hardware to user management, firmware maintenance, etc. Each module corresponds to a resource type or service in the Redfish data model, interacts with the standard JSON data format, and ensures the interoperability and compatibility of devices from different manufacturers on the management interface.

[0064] In Step 3, when the external management client accesses the BMC through the Redfish interface, the request first arrives at the interface service entry. The service framework parses the URI path to determine the target resource module (for example, if the URI contains " / Systems", it is processed by the Systems module, if it contains " / Chassis", it is processed by the Chassis module, if it contains " / FRU", it is processed by the FRU module, etc.). After the corresponding management module receives the request, it interacts with the BMC underlying hardware or firmware to obtain the required data or perform the corresponding operation, and then generates a JSON format response according to the Redfish specification requirements. Through the above process, the organic integration of each management module is realized, and a unified and standard management interface can be provided externally. Preferably, in the implementation process, interface security and performance are also optimized, for example, all requests are authenticated and permission checked through the SessionService module, and the response efficiency of long-time operations is improved through the task asynchronous mechanism, etc.

[0065] In Step 4, when the operation involves a time-consuming task (such as firmware upgrade, diagnostic scanning, etc. which requires tens of seconds or minutes of operation), the corresponding management resource module will create an asynchronous task by calling the TaskService module to achieve non-blocking request processing. Specifically, when the client initiates such a request, the Redfish service does not wait for the underlying operation to complete before returning; instead, the service immediately returns a response indicating that the task has been accepted, which contains an ID or URI identifying the asynchronous task. According to the Redfish specification, when accepting a request that needs to be executed asynchronously, the server should return an "HTTP 202 Accepted" status code, indicating that the request has been accepted and started processing. At the same time, the "Location" in the response header will be set to the task monitoring URI (Task Monitor) related to the task, usually in the form of " / redfish / v1 / TaskService / Tasks / {TaskId}", and the client can query the task status through this URI. The response can also contain a "Retry-After" header to prompt the client to wait for how long before querying the task status. According to the specification requirements, the message body of the 202 response should contain a JSON representation of the Task resource, providing information such as the current state of the task. For example, when starting firmware upgrade through the UpdateService module, the service may return "202 Accepted", with the Location pointing to the URL of the newly created task, and the initial state of the task (such as TaskState as Running, etc.) is given in the response JSON.

[0066] After a task is created, the actual long-running operation starts in the background on the BMC. The TaskService module asynchronously monitors and updates the task status, including possible progress percentage, start and end time, current stage description, and any error information, etc. When the client later initiates a GET request to the task monitoring URI provided by the Location, the Redfish service will return the update of the current status of the task without blocking the client request. During the task progress, the task monitoring URI will continuously return 202 status, indicating that the task is not yet completed, and can provide partial progress information in the response. The client can poll the URI as needed to obtain the latest status of the task (for example, the polling interval is indicated by "Retry-After"), or choose to wait for a period of time in the background before querying. This design allows the client to not maintain a long connection to wait, so as not to block the parallel performance of other management operations.

[0067] Once the background task execution is completed (whether successful or failed), the TaskService updates the final status and records the task result in the task resource. At this time, the GET request to the task monitoring URI will no longer return 202, but will return the final result: if the task is successfully completed, the task monitor will return "HTTP 200 OK" and include the result data that the initial request operation should produce in the response (just like the operation is completed synchronously); if an error occurs during task execution, the task monitor will return an error status code and include a standard error response (JSON format) in the response body, describing the error type and details. The Redfish specification requires that, when the task fails, the response body should provide the ErrorResponse structure, including error code, message, and possible extended information, to help users understand the problem. In addition, the service may delete the task resource after the task is completed for resource cleaning consideration; in this case, the corresponding task URI will possibly return "410 Gone", indicating that the task resource is no longer available. In general, the asynchronous task processing mechanism implemented by the TaskService ensures efficient management of time-consuming operations - the interface call returns the acceptance state immediately, and the client queries the progress at any time through the task ID, which not only guarantees the timeliness of user experience, but also improves the system concurrent processing capability.

[0068] In Step 5, when the interface call (whether synchronous or asynchronous) is completed, the Redfish service returns an appropriate HTTP status code and structured response data to the client to explicitly indicate the operation result. The HTTP status code follows the general REST convention: 2XX indicates success, 4XX indicates client request error, and 5XX indicates server error. For example, "200 OK" is returned when reading a resource successfully, "201 Created" is returned when creating a resource successfully, "202 Accepted" is returned when accepting an asynchronous task, and "204 No Content" is returned when there is no content; common errors such as "400 Bad Request" for incorrect request format or parameters, "401 Unauthorized" for unauthorized access, "403 Forbidden" for forbidden access, "404 Not Found" for resource not found, and "500 Internal Server Error" for server internal error, etc. Through the status code, the client can quickly determine whether the request is successfully executed or an error occurs, and then perform the corresponding subsequent processing.

[0069] In addition to the status code, Redfish specifies that all response data is in structured JSON format for machine readability and automated processing. For successful requests, the response data usually contains standardized information of the requested resource. For example, a GET request for the Systems resource will return a JSON of the server system's detailed information; a POST request for Account creation will return a JSON representation of the new account resource; and a PATCH request for a setting operation may return updated resource information or 204 indicating no content but the operation is successful. All these data formats are based on the Redfish data model architecture, containing fixed fields and structures, so that the client program can parse and extract the required information.

[0070] If the request execution fails, the Redfish service returns structured data describing the error, i.e., an error response. The error response is also a JSON object, usually containing an "error" node that includes a standard error code and a human-readable error message, as well as an array of extended information (@Message.ExtendedInfo) that provides more detailed error sources or correction suggestions. For example, when the request parameters do not meet the requirements, the error response may contain a MessageId that identifies a specific error type (such as PropertyValueNotInList), and a Message that provides an explanation. Such structured error description facilitates the client program to automatically identify the problem type, and even perform specific processing logic based on the MessageId.

[0071] The Redfish interface makes it easy for clients to automate management and identify states by returning standard HTTP status codes and structured JSON response data. Client scripts can directly determine the success or failure of an operation based on the status code, and use the parsed JSON response to obtain resource data when successful or error details when failed. This consistent interface behavior greatly simplifies operations and management work: when performing management tasks in batches, programs do not need to customize parsing logic for different devices, but only need to follow the Redfish specification to handle all returns. In practice, this ensures that management tools across vendors and devices can be compatible with each other, and provides strong support for automated operations in data centers. Whenever a Redfish interface call is completed, the operator or script can clearly know the operation result status and obtain structured information to determine the next action, achieving closed-loop automated management.

[0072] Figure 1 The server management architecture of Redfish as an interface is described, and the management and monitoring platform interacts with the operating system (OS) and baseboard management controller (BMC) on the server through in-band or out-of-band management.

[0073] Figure 2 The communication process based on the Redfish architecture in the BMC is described, and the client and the server transmit request and response data on the network through IP, TCP, and HTTP protocol layers in turn.

[0074] Figure 3 The service framework of Redfish as a BMC is described, which includes multiple open modules such as Managers, Systems, Chassis, AccountService, and provides standardized remote management functions.

[0075] Table 1 describes the program and design of the RESTful interface in Redfish. The RESTful program uses a simple form to complete data transmission, and the specific operation is only in the form of the four in the table.

[0076] Table 2 describes the application of the HTTP status code in Redfish and the corresponding description.

[0077] Table 1:

[0078] Operation Description POST (Create) Create a new resource or execute a method on a specified resource. GET (Read) Return the description of the requested resource. PATCH (Update) Modify the current resource properties. DELETE (Delete) Delete the specified resource.

[0079] Table 2:

[0080] Status Code Description 200 Request successful 201 Resource created successfully 202 Task execution successful 204 Parameter set successfully 400 Illegal request, error on the client side and return error message 401 Invalid user request 403 Server rejects the request 404 Request resource does not exist 405 Unsupported operation 409 There is a direct conflict in the status of the requested resource 412 Precondition (such as OData-Version, If-Match) check failed 415 Request specifies a Content-Type for an unsupported message body 428 Precondition (If-Match) is missing 500 Server internal error 501 The requested function is not currently implemented

[0081] Although the embodiments of the present application have been disclosed with reference to the above embodiments, the above description is merely used to understand the present application and is not used to limit the present application. Any person skilled in the art, without departing from the spirit and scope of the present application, can make any modification and change in the form and details of the embodiments, but the patent protection scope of the present application should be subject to the scope defined by the appended claims.

Claims

1. An interface design and implementation method for a Redfish-based BMC remote management system, characterized in that, include: Step 1) Deploy the Redfish service framework on BMC, initialize HTTP / HTTPS network services and authentication mechanisms, and provide a unified Redfish interface entry point; Step 2) Integrate multiple BMC management resource modules, including the Systems module, Chassis module, Managers module, AccountService module, SessionService module, TaskService module, UpdateService module, and FRU module, to build a resource model for the Redfish interface; embed each management resource module into the BMC firmware system and run it. Step 3) Map each management resource module to the underlying hardware and firmware of the BMC, and provide RESTful API access to the outside world through the Redfish service framework, so that remote clients can perform query or control operations on the module and obtain response data in a standard format. Step 4) When the operation involves a long-running task, the corresponding management resource module generates an asynchronous task by calling the TaskService module and returns the task ID to the client, so that the client can continuously query the task progress. Step 5) After the interface call is completed, the Redfish service returns the corresponding HTTP status code and structured response data to the client to identify the operation result status; the status code is used to indicate whether the execution was successful or failed, and the structured data includes standard resource information or error descriptions, which facilitates automated management and status identification by the client.

2. The interface design and implementation method of a BMC remote management system based on Redfish architecture according to claim 1, characterized in that: In step 1), the Redfish service process is deployed on the BMC, and a unified service root entry point is set at / redfish / v1. This service root serves as the unified entry point for the entire management system, exposing the top-level access path of each management resource to remote clients and providing metadata information such as the Redfish service version and hostname. By initializing the HTTP / HTTPS protocol stack and authentication mechanism, it ensures that clients can securely connect to the Redfish interface of the BMC. With the help of this unified entry point, the client discovers and traverses all the management resource subtrees provided by the BMC. Accessing / redfish / v1 will return a "site map" style JSON object, which lists the links to the main resource collections of Systems, Chassis, and Managers, as well as the link information of the AccountService and SessionService service resources.

3. The interface design and implementation method of a BMC remote management system based on Redfish architecture according to claim 1, characterized in that: In step 2), each management module implements specific management functions and REST interfaces. The specific functions and implementation methods of each management resource module are as follows: 1) Managers Module: Corresponding to the Management Controller (Managers) resource in Redfish, this module manages the BMC itself. It provides interfaces for obtaining the BMC firmware version, manufacturer information, and network configuration data, and supports management operations on the BMC. The Managers module typically handles requests to the " / redfish / v1 / Managers" path and returns information about the BMC (Management Controller). Remote updates to the BMC configuration or restarts can be achieved through the operation interfaces provided by this module. 2) Systems Module: Corresponding to the Systems resource in Redfish, this module provides an interface for managing the overall system status of the server. It connects to the underlying power control, power status sensors, and BIOS interface subsystems of the BMC, enabling functions such as reading / setting the server's power status, obtaining CPU and memory configurations, setting the boot device order, and executing power-on / power-off / reboot commands. When the Redfish client sends a GET request to a resource under " / redfish / v1 / Systems", the Systems module collects the current server's processor, memory, storage, and other configurations and operating statuses, encapsulates them into JSON data, and returns it. When it receives a PATCH / POST request to a Systems resource, it parses the parameters contained in the request and calls the underlying interface to execute the corresponding changes. Through the Systems module, the Redfish client can manage core functions such as server hardware and power in a standardized manner. 3) Chassis Module: Corresponding to the Chassis resource in Redfish, this module manages the physical chassis of the server and its component information. It connects to various sensors and monitoring circuits in the BMC to obtain the chassis's identification, model, serial number, and the status parameters of each FRU component within the chassis. Through this module, users can query the chassis type, installation location, and ambient temperature information. When a client accesses the " / redfish / v1 / Chassis" resource, the Chassis module returns JSON data containing chassis overview, environmental sensor readings, and a list of replaceable components. 4) AccountService module: Used to manage BMC user account information. The AccountService module maintains the account list and permission policies of remote management users on BMC, and realizes the addition, deletion, modification and query operations of user accounts. When the client sends a POST request to the " / redfish / v1 / AccountService / Accounts" resource to create a new account, this module verifies the legality of the input information and calls the BMC user management subsystem to create a new account. A DELETE request deletes the specified user account; a GET request returns a list of all current users. The AccountService module enables unified management and access control configuration for BMC-managed users. 5) SessionService Module: This module manages Redfish sessions and authentication mechanisms. It handles the creation and maintenance of login sessions. When a client logs in via " / redfish / v1 / SessionService / Sessions" with a username and password, if authentication is successful, a new session is created, a session token is generated and returned to the client. It also records session validity, last activity time, and other information to support subsequent session verification and timeout handling. This module also provides a logout interface, allowing clients to terminate a specified session. Through the SessionService module, it ensures that only legitimately authenticated users can access Redfish interface resources on the BMC, thereby guaranteeing the security of interface usage. 6) TaskService module: Used to handle asynchronous management tasks. Some management operations can be time-consuming. The TaskService module provides task creation, status monitoring, and result query functions. When other modules trigger operations that need to be executed asynchronously, the TaskService module can generate a task object and return the task ID to the client. The client can then query " / redfish / v1 / TaskService / Tasks / {taskId}" to obtain the execution status and result of the task. When a task is completed or an error occurs, the TaskService module updates the task status and saves necessary log information for querying. Through the TaskService module, the management efficiency of long-running operations is greatly improved, and the client does not need to maintain a connection for a long time to wait, thus improving the system's concurrent processing capabilities. 7) UpdateService Module: This module manages the firmware upgrade process for the server and BMC. It provides interfaces for checking the current firmware version, uploading new firmware images, performing upgrades, and monitoring the upgrade process. When a firmware image upload request is received, the UpdateService module securely saves the image file to the BMC's storage space and calls the underlying upgrade mechanism to begin the update process. During the upgrade, the UpdateService module can work with the TaskService module to create an upgrade task to track the upgrade progress. After the upgrade is complete, this module updates the firmware version information of the system or device. Through the UpdateService module, the server firmware lifecycle management is automated and standardized. 8) FRU Module: Used to manage the server's Field Replaceable Unit (FRU) information. The FRU module reads the asset tags and information of each hardware component from the server's FRU memory, including the manufacturer, product name, part number, serial number, manufacturing date, and asset tag of the server chassis, motherboard, and other components. The FRU module parses and organizes this information, then provides it in JSON format via the Redfish interface for querying. The modules described above are implemented in accordance with the resource model and interface paths defined by the Redfish specification. They work together to form a complete BMC remote management REST architecture. By embedding these modules into the BMC firmware and running them, BMC can provide a unified management interface covering all aspects from device hardware to user management and firmware maintenance. Each module corresponds to a resource type or service in the Redfish data model and interacts using the standard JSON data format, ensuring interoperability and compatibility of management interfaces for devices from different manufacturers.

4. The interface design and implementation method of a BMC remote management system based on Redfish architecture according to claim 1, characterized in that: In step 3), when an external management client accesses the BMC through the Redfish interface, the request first reaches the interface service entry point. The service framework determines the module to which the target resource belongs based on the URI path resolution. After receiving the request, the corresponding management module interacts with the underlying hardware or firmware of the BMC to obtain the required data or perform corresponding operations. Then, it generates a JSON format response according to the Redfish specification requirements. Through the above process, the organic integration of various management modules is realized, which can provide a unified and standard management interface to the outside world. At the same time, the interface security and performance are also optimized during the implementation process.

5. The interface design and implementation method of a BMC remote management system based on Redfish architecture according to claim 1, characterized in that: In step 4), when the operation involves a time-consuming task, the corresponding management resource module will create an asynchronous task by calling the TaskService module, thereby achieving non-blocking request processing. Specifically, when a client initiates such a request, the Redfish service will not synchronously wait for the underlying operation to complete before returning; instead, the service immediately returns a response indicating that the task has been accepted, which includes the ID or URI identifying the asynchronous task. According to the Redfish specification, when accepting a request that needs to be executed asynchronously, the server should return an "HTTP 202 Accepted" status code, indicating that the request has been accepted and processing has begun. At the same time, the "Location" in the response header will be set to the task monitor URI associated with the task, usually in the form of " / redfish / v1 / TaskService / Tasks / {TaskId}". The client can query the task status through this URI. The response also includes a "Retry-After" header to indicate how long the client should wait before querying the task status again. After a task is created, the actual long-running operation begins in the BMC background. The TaskService module asynchronously monitors and updates the task status, including possible progress percentages, start and end times, current stage descriptions, and any error messages. When a client subsequently sends a GET request to the task monitoring URI provided by Location, the Redfish service will return an update on the task's current status without blocking the client's request. During the task's execution, the task monitoring URI will continuously return a 202 status, indicating that the task is not yet complete, and will provide some progress information in the response. Clients can poll this URI as needed to obtain the latest task status, or choose to wait in the background for a period of time before querying. Once the background task is completed, TaskService will update the final state and record the task result in the task resource. At this time, GET requests to the task monitoring URI will no longer return 202, but will instead return the final result: if the task is completed successfully, the task monitor will return "HTTP 200 OK" and include the result data that the initial request operation should have produced in the response. If an error occurs during task execution, the task monitor will return an error status code and include a standard error response (JSON format) in the response body, describing the error type and details. The Redfish specification requires that when a task fails, the response body should provide an ErrorResponse structure containing the error code, message, and possible extended information to help users understand the problem. Furthermore, the service may delete task resources after task completion for cleanup purposes; in this case, the corresponding task URI may return "410Gone," indicating that the task resource is no longer available. In summary, the asynchronous task processing mechanism implemented through TaskService ensures efficient management of time-consuming operations—the interface call immediately returns an accepted status, and the client can query the progress at any time using the task ID, guaranteeing both a timely user experience and improved system concurrency capabilities.

6. The interface design and implementation method of a BMC remote management system based on Redfish architecture according to claim 1, characterized in that: In step 5), after the API call is completed, the Redfish service returns an appropriate HTTP status code and structured response data to the client to clearly indicate the operation result. The HTTP status codes follow the general REST convention: 2XX classes indicate success, 4XX classes indicate client request errors, and 5XX classes indicate server errors. Through the status codes, the client can quickly determine whether the request was executed successfully or encountered an error, and thus perform appropriate follow-up processing. In addition to status codes, Redfish requires all response data to be in a structured JSON format for machine readability and automated processing. For successful requests, the response data typically contains standardized information about the requested resource. All of these data formats are based on Redfish's data model architecture, containing fixed fields and structures that enable client programs to parse and extract the required information. If the request fails, the Redfish service returns structured data describing the error, known as an error response. The error response is also a JSON object, typically containing an "error" node, which includes the standard error code and a human-readable error message, as well as an array of extended information providing more detailed information about the error source or corrective suggestions. By returning standard HTTP status codes and structured JSON response data, the Redfish interface enables clients to easily perform automated management and status recognition. Client scripts can directly determine whether an operation is successful or failed based on the status code and use parsing of the JSON response to obtain resource data when successful or error details when unsuccessful.

Images