Heterogeneous server management method, device and equipment based on redfish

Abstract

The invention provides a redfish-based heterogeneous server management method, a redfish-based heterogeneous server management device and redfish-based heterogeneous server management equipment. The method comprises the following steps: receiving a server operation request sent by a client and performing request verification; after the verification is passed, establishing a session with the target server; verifying whether the hardware of the target server supports the server operation request; if the hardware of the target server supports the server operation request, performing heterogeneous server operation request packaging adaptation on a non-universal operation request in the server operation request through a pre-configured Redfish interface, and issuing the packaged non-universal operation request to the target server, converting a non-general operation response result of the target server into a general operation response result; and performing field standardization and unification on the general operation response result of the target server, and then returning the result to the client for display. The method has the beneficial effect that automatic operation and maintenance operation management of mass servers can be realized.

Description

Technical Field

[0001] The present invention relates to the technical field of server management, and in particular to a method, device and equipment for heterogeneous server management based on Redfish. Background Art

[0002] As the digital transformation process continues to deepen, cloud and AI continue to affect all walks of life. At the same time, the scale and number of corresponding cloud data centers continue to grow rapidly, and the automated management of large-scale heterogeneous servers has become particularly urgent. Traditional server automated management is usually divided into in-band management and out-of-band management.

[0003] In-band management means that after the server has installed the operating system, it is installed in the operating system and communicates with the management server through the network within the operating system (also called the business network). Common forms are agents, services, or daemons. This type of management can achieve refined management of the CPU, memory, processes, file systems, etc. within the operating system, but its life cycle changes with the start and stop of the operating system, and there is a problem of intrusion into customer business systems.

[0004] Out-of-band management is managed through the firmware system of the server, and the server startup sequence, power management, disk and network card hardware management, status and monitoring alarm management are managed through the baseboard management controller BMC (Baseboard Management Controller). In the past, the out-of-band management interaction interface was mainly managed through the intelligent platform management interface IPMI (Intelligent Platform Management Interface), which usually calls IPMI commands through ansible or scripts to achieve simple out-of-band management. However, as the scale of cloud data centers gradually increases, especially in private cloud scenarios, heterogeneous servers from multiple vendors are often required, and more abundant out-of-band management methods and interactive content are needed for servers. Although the BMC system that comes with the server can be managed in an interface and refined, the interface of each server vendor is too different and is not suitable for large-scale server automation management. The traditional IPMI can only cooperate with scripts or ansible to execute commands, and then parse the IPMI command response results, which makes the parsing of IPMI response results particularly complicated, and the management methods supported by IPMI are very limited, which cannot meet the rich server out-of-band management needs. The Redfish protocol standard can meet these requirements. It has high scalability, supports RESTful API calls, can easily perform program calls and task scheduling, and implements secure operations and access through HTTPS. Currently, most server vendors are compatible with the Redfish standard. The shortcoming of existing technologies is that each server vendor supports inconsistent granularity. If out-of-band management of heterogeneous servers from different server vendors is required, multi-version compatibility must be achieved. Summary of the invention

[0005] The technical problem to be solved by the present invention is to provide a redfish-based heterogeneous server management method, device and equipment, aiming to perform out-of-band management on heterogeneous servers of different manufacturers.

[0006] In a first aspect, a heterogeneous server management method based on redfish is provided, comprising:

[0007] Receive server operation requests sent by the client and verify the server operation requests;

[0008] After the server operation request is verified, a session with the target server is established;

[0009] Perform business logic verification on the target server to determine whether the hardware of the target server supports the server operation request;

[0010] If the hardware of the target server supports the server operation request, the non-universal operation request in the server operation request is encapsulated and adapted through the pre-configured Redfish interface, the encapsulated non-universal operation request is sent to the target server, and the non-universal operation response result of the target server is converted into a universal operation response result;

[0011] The target server's common operation response results are standardized and unified in fields and then returned to the client for display.

[0012] In a second aspect, a heterogeneous server management device based on redfish is provided, comprising:

[0013] The request verification module is used to receive the server operation request sent by the client and verify the server operation request;

[0014] A session establishment module is used to establish a session with a target server after the server operation request is verified;

[0015] A business logic verification module is used to perform business logic verification on the target server to determine whether the hardware of the target server supports the server operation request;

[0016] The non-universal operation module is used to encapsulate and adapt the non-universal operation request in the server operation request through a pre-configured Redfish interface if the hardware of the target server supports the server operation request, send the encapsulated non-universal operation request to the target server, and convert the non-universal operation response result of the target server into a universal operation response result;

[0017] The response return module is used to standardize the fields of the common operation response results of the target server and return them to the client for display.

[0018] In a third aspect, a computer device is provided, the computer device comprising a memory and a processor, the memory storing a computer program, and the processor implementing the above-mentioned redfish-based heterogeneous server management method when executing the computer program.

[0019] In a fourth aspect, a storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the heterogeneous server management method based on redfish as described above can be implemented.

[0020] In the scheme implemented by the above-mentioned heterogeneous server management method, device and equipment based on Redfish, the non-universal operation request in the server operation request is encapsulated and adapted through the pre-configured Redfish interface, the encapsulated non-universal operation request is sent to the target server, and the non-universal operation response result of the target server is converted into a universal operation response result; the universal operation response result of the target server is standardized and unified in fields and then returned to the client for display. The differentiated parameters or differentiated functional interfaces of heterogeneous servers from different manufacturers are adapted in parameters or functional interfaces, which ensures the consistency of the business call layer, shields the hardware differences caused by the inconsistent support granularity of servers from different manufacturers, and can be compatible with servers from different manufacturers, so as to efficiently carry out large-scale automated operation and maintenance management of servers. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The specific structure of the present invention is described in detail below in conjunction with the accompanying drawings.

[0022] Figure 1 This is a schematic diagram of an application scenario of a heterogeneous server management method based on redfish according to an embodiment of the present invention;

[0023] Figure 2 This is a system architecture diagram of a heterogeneous server management method based on redfish according to an embodiment of the present invention;

[0024] Figure 3 It is a flow chart of a heterogeneous server management method based on redfish according to an embodiment of the present invention;

[0025] Figure 4 This is another flow chart of a heterogeneous server management method based on redfish according to an embodiment of the present invention;

[0026] Figure 5 It is a block diagram of a heterogeneous server management device based on redfish according to an embodiment of the present invention;

[0027] Figure 6 It is a block diagram of another heterogeneous server management device based on redfish according to an embodiment of the present invention;

[0028] Figure 7 A schematic block diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0030] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0031] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0032] It should be further understood that the term "and / or" used in the present description and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0033] The embodiments of the present application provide a heterogeneous server management method, apparatus and device based on Redfish.

[0034] For ease of understanding, the application scenario composition applicable to the redfish-based heterogeneous server management method of the embodiment of the present application is first introduced.

[0035] like Figure 1 As shown, Figure 1 A schematic diagram of an application scenario of a heterogeneous server management method based on Redfish provided in an embodiment of the present invention. Figure 2 A system architecture diagram of a heterogeneous server management method based on Redfish provided in an embodiment of the present invention, wherein a business layer, an adaptation layer and a hardware layer are arranged on multiple heterogeneous servers. Figure 3 Flowchart of the heterogeneous server management method based on redfish provided by the embodiment of the present invention. The heterogeneous server management method based on redfish is applied to Figure 1In an application environment, the client communicates with multiple heterogeneous servers through a network. The interfaces of multiple heterogeneous servers can receive server operation requests sent by the client and verify the server operation requests; after the server operation request verification is passed, a session with the target server is established; the target server is verified for business logic to determine whether the hardware of the target server supports the server operation request; if the hardware of the target server supports the server operation request, the non-universal operation request in the server operation request is encapsulated and adapted for the heterogeneous server operation request through a pre-configured Redfish interface, the encapsulated non-universal operation request is sent to the target server, and the non-universal operation response result of the target server is converted into a universal operation response result; the universal operation response result of the target server is standardized and unified in fields and returned to the client for display. In the present invention, by performing parameter adaptation or functional interface adaptation on the differentiated parameters or differentiated functional interfaces of heterogeneous servers of different manufacturers, the consistency of the business call layer is guaranteed, the hardware differences caused by the inconsistent granularity of support of servers of different manufacturers are shielded, and the servers of different manufacturers can be compatible, so that large-scale server automated operation and maintenance operation management can be efficiently performed. The client may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The server side is implemented by a server cluster consisting of multiple heterogeneous servers with inconsistent support granularity. The present invention is described in detail below through specific embodiments.

[0036] like Figure 2 As shown, the system architecture adopted by the heterogeneous server management method based on redfish of the present invention includes three layers: business layer, adaptation layer and hardware layer.

[0037] Business layer: The business layer mainly designs the business logic of out-of-band management operations of the server. The business functions implemented by the heterogeneous server management method based on redfish include: server management, API interface authentication and parameter verification of server operation requests, establishment of a session with the target server, business logic verification or status verification of the target server, general operations on the target server, non-general (heterogeneous) operations on the target server, and serialized responses to the operation results of the target server. When performing general operations on the target server, it is necessary to call the functions provided by the general SDK of the adaptation layer. When performing non-general (heterogeneous) operations on the target server, it is necessary to call the pre-configured Redfish interface of the adaptation layer to adapt non-passed operation requests.

[0038] Adaptation layer: The adaptation layer is mainly used to adapt the compatibility of different Redfish versions of heterogeneous servers from different manufacturers, encapsulate differentiated operation requests and responses into unified operation requests, and shield the hardware layer differences from the business layer. For example: heterogeneous adapter manufacturer 1 has functions 1 and 2; heterogeneous adapter manufacturer 2 has functions 1 and 3; heterogeneous adapter manufacturer 3 has functions 4 and 5.

[0039] Hardware layer: The hardware layer is servers from different manufacturers. The servers come with BMC firmware. The BMC firmware supports different versions of Redfish interfaces and needs to be debugged with the manufacturer. In some scenarios, firmware upgrades are required to support certain functions. For example: the adapter interface between X86 server manufacturer 1 and the adapter layer is Redfish1.0X; the adapter interface between X86 server manufacturer 2 and the adapter layer is Redfish1.2; and the adapter interface between X86 server manufacturer 3 and the adapter layer is Redfish1.5.

[0040] like Figure 3 As shown, the embodiment of the present invention provides a heterogeneous server management method based on redfish, comprising the steps of:

[0041] S10: Receive a server operation request sent by the client, and verify the server operation request.

[0042] Step S10 may include the following steps: S11-S12.

[0043] S11, receiving a server operation request sent from the client;

[0044] S12: Authenticate and authenticate the server operation request to confirm the legitimacy of the server operation request.

[0045] In this embodiment, all batch or single operations on the server are exposed in the form of RESTful API, supporting server power management, disk / network card management, startup sequence management, log alarm management, etc. When a server operation request comes in, it will be verified by multiple middlewares, including authentication, authorization, tracking, logging, exception capture and other general capabilities. When the server operation request is forwarded to the specified interface through multi-level routing, the parameter verification of the specified operation will be performed first to ensure the legitimacy of the server operation request.

[0046] S20. After the server operation request is verified, a session with the target server is established.

[0047] In this embodiment, all single or multiple operations on the server are based on the establishment of a session with the target server. GetPhys icalServerBMCCl ient is called to obtain the session client of the target server. The main process is to create a session through the connection information stored in the database and create a short session connection. All subsequent operations will carry the token of this session. When this request is completed, the session will be destroyed.

[0048] S30: Perform a business logic check on the target server to determine whether the hardware of the target server supports the server operation request.

[0049] In this embodiment, before performing a real server change operation, a business logic check or a status check is performed first. For example, when starting up the server, the server should first be in a shutdown state, and then a sys.Reset request is executed. For example, when configuring the server RAID disk, a business logic judgment is required on the RAID hardware and request parameters of the server to avoid the current hardware being unable to support the requested operation. After all checks are completed, a CreateVolume request is executed.

[0050] S40. If the hardware of the target server supports the server operation request, the non-universal operation request in the server operation request is encapsulated and adapted through a pre-configured Redfish interface, the encapsulated non-universal operation request is sent to the target server, and the non-universal operation response result of the target server is converted into a universal operation response result.

[0051] In this embodiment, when there is an operation of a heterogeneous server that is not applicable to the functions provided by the general SDK, it is necessary to perform Redfish adaptation of the differentiated operations of the heterogeneous servers. Generally speaking, it is to complete the encapsulation of the current heterogeneous server operation request and convert the response result into a general operation response, which ensures the consistency of the business call layer and shields the hardware differences. For heterogeneous server function adaptation, there are two types: operation parameter adaptation and function interface adaptation. The operation parameters refer to the number of parameters, parameter types, and parameter value ranges supported by different manufacturers. An interface needs to be defined. The differentiated parameters of each manufacturer are implemented by the standard interface to achieve unified parameter adaptation; function interface adaptation refers to the inconsistency of the business logic of the functions of different manufacturers. It is difficult to meet the requirements through a single request, and a new implementation method needs to be defined according to the interface.

[0052] In a further embodiment, the step S40 may include the following steps: S41-S42.

[0053] S41. If the operation parameters of the non-universal operation request in the server operation request are different from the operation parameters of the target server, the operation parameters of the non-universal operation request in the server operation request are encapsulated and adapted through a pre-configured Redfish interface, and the encapsulated non-universal operation request is sent to the target server;

[0054] S42: If the functional interface of the non-universal operation request in the server operation request is different from the functional interface of the target server, the non-universal operation request in the server operation request is encapsulated and adapted through a pre-configured Redfish interface, and the encapsulated non-universal operation request is sent to the target server.

[0055] Among them, there are two types of differences in non-universal operation requests. One is that the operation parameters of the non-universal operation requests are different from those of the target server. The other is that the functional interface of the non-universal operation request is different from the functional interface of the target server. By performing different packaging adaptations for the two different differences, requests from heterogeneous servers from different manufacturers can be uniformly adapted.

[0056] In a further embodiment, the step S41 may include the following steps: S411 - S417 .

[0057] S411, define interface variables of operation parameters;

[0058] S412, converting the common operation parameters into operation parameters that can be supported by servers of different manufacturers;

[0059] S413, if the common operation parameters are inconsistent with the number of operation parameters supported by the target server, the default parameters are set to default values ​​according to the default requirements of the target server;

[0060] S414: If the common operation parameter is inconsistent with the operation parameter type supported by the target server, convert the common operation parameter type into the operation parameter type supported by the target server;

[0061] S415: If the common operating parameters are inconsistent with the operating parameter range supported by the target server, define the value range of the common operating parameters as a subset of the value range supported by all target servers;

[0062] S416, assigning the converted operation parameters to the interface variables;

[0063] S417, calling the general operation request and passing in the assigned interface variable to initiate an operation request to the target server.

[0064] In this embodiment, it is implemented based on the Go language. Go (Golang) is a statically strongly typed, compiled language that can provide a concise, efficient, and reliable software development solution. Taking the creation of a logical RAID disk as an example, it is explained how to complete the unified Redfish adaptation of heterogeneous servers from different manufacturers through parameter adaptation. Traverse all storage controllers of the target server, match the specified RAID card controller according to the request parameters, and define the general RAID card creation request VolumeCreateOptsBuilder interface variable X (because this operation is mainly inconsistent for each manufacturer, the adaptation layer needs to be processed. If the current server manufacturer is manufacturer A, call the request encapsulation interface A.FromVolumeCreateOpts of the adaptation layer manufacturer A. If the current manufacturer is manufacturer B, call the request encapsulation interface B.FromVolumeCreateOpts of the adaptation layer manufacturer B. If the Redfish standard supported by the current manufacturer is consistent with the default standard, call the default request redfish.FromVolumeCreateOpts, and FromVolumeCreateOpts mainly converts the general request parameters into parameters that can be supported by different manufacturers, and returns a VolumeCreateOpts variable). The definition of the VolumeCreateOpts structure of each manufacturer is independent, which is manifested in inconsistent field types, inconsistent serialization, inconsistent field values, and inconsistent number of fields. However, if these differently defined structures all implement VolumeCreateOptsBuilder, The ToCreateMap method supported by the lder interface can assign different structure variables to variable X, and then call the unified CreateVolume method and pass in variable X to complete the operation.

[0065] Converting common operation requests to vendor-differentiated requests FromVolumeCreateOpts is mainly to solve the conversion between the standard functions exposed by the service and the functions provided by the vendor. For example, the VolumeCreateOpts structures of different vendors will have the RaidLevel field, but the definition range and content of the field value between vendors are inconsistent. For example, the range and value of one vendor is "raid0 / raid1 / raid5 / raid6 / raind10", while the range and value of another vendor is "Raid0 / Raid 1 / Raid 5 / Raid 6 / Raid 10 / Raid 50 / Raid 60". It can be seen that the range and value are different. Then the range exposed by the service needs to be the intersection of the two to ensure that the management capabilities of all servers are consistent. The second is the differentiated processing of field values. This can be achieved through each vendor's FromVolumeCreateOpts interface to implement a mapping table mapVals from standard field values ​​to vendor-supported field values ​​for conversion. Other differentiated fields and interfaces are similar.

[0066] Go language is used to create logical RAID disks. The program syntax is concise and clear, and it can directly call the request encapsulation interface of different server manufacturers in the adaptation layer, which is direct and efficient. In addition, Go language can easily implement concurrent execution, improving the performance and response speed of the program.

[0067] In a further embodiment, the step S42 may include the following steps: S421 - S425 .

[0068] S421, define the function type of the non-general operation request;

[0069] S422, performing request adaptation on the non-universal operation request and the target server;

[0070] S423: If the URL of the non-universal operation request is inconsistent with the URL of the target server, encapsulate the URL of the target server into the non-universal operation request;

[0071] S424, performing corresponding business logic arrangement according to the non-general operation request;

[0072] S425. Call the corresponding non-universal operation request address, pass in the corresponding operation parameters, and initiate an operation request to the target server.

[0073] In this embodiment, when there is a difference between the non-universal operation request and the target server, the function interface encapsulation adaptation is performed so that the non-universal operation request can successfully initiate an operation request to the target server. The function of the interface is realized by the function, and the function interface is not compatible, that is, the function in the function interface is not compatible; for example: X86 server manufacturer 1 supports a certain function, while X86 server manufacturer 2 does not support it. When requesting the function of X86 server manufacturer 1, function type adaptation is required. URL is a uniform resource locator, that is, the address of a standard resource.

[0074] S50: Standardize and unify the fields of the common operation response result of the target server and return it to the client for display.

[0075] In this embodiment, when a server operation is completed and a response is obtained from the server BMC segment, in order to ensure the uniformity of the front-end display, the response result needs to be standardized, that is, some fields are extended so that the current operation response to the server is consistent with other API request response structures.

[0076] like Figure 4 As shown, in one embodiment, before step S10, the following steps are also included:

[0077] S10', managing the heterogeneous server through the user name, user password and HTTP protocol type of the heterogeneous server out-of-band management BMC, and saving the obtained information of the heterogeneous server to the database.

[0078] In this embodiment, similar to IPMI, the server can be managed by providing the user account, user password and HTTP protocol type of the server out-of-band management BMC. By obtaining the server information, the basic information of the server can be obtained, and the connection information and the basic information of the server can be saved in the database.

[0079] In one embodiment, the heterogeneous server management method based on redfish further includes the following steps:

[0080] S40': If the hardware of the target server supports the server operation request, the Redfish SDK is called to send the general operation request in the server operation request to the target server.

[0081] In this embodiment, after completing the business logic verification or status check of the target server, the Redfish SDK can be called to send a request to the target server, such as querying the basic information of the server. The redfish versions used by various manufacturers support this operation in a consistent manner, except that some fields are not supported, but the overall structure is consistent with redfish.ComputerSystem.

[0082] In summary, this method ensures the consistency of the business call layer by adapting the differentiated parameters or differentiated functional interfaces of heterogeneous servers from different manufacturers, shielding the hardware differences caused by inconsistent support granularity of servers from different manufacturers, thereby enabling efficient automated operation and maintenance management of large quantities of servers.

[0083] like Figure 5 As shown, in a specific embodiment, a heterogeneous server management device based on redfish is provided, comprising:

[0084] The request verification module 10 is used to receive the server operation request sent by the client and verify the server operation request;

[0085] The request verification module 10 is specifically used for:

[0086] Receive server operation requests sent from the client;

[0087] Authenticate and authenticate server operation requests to confirm the legitimacy of server operation requests.

[0088] The session establishment module 20 is used to establish a session with the target server after the server operation request is verified;

[0089] The business logic verification module 30 is used to perform business logic verification on the target server to determine whether the hardware of the target server supports the server operation request;

[0090] The non-universal operation module 40 is used to encapsulate and adapt the non-universal operation request in the server operation request through a pre-configured Redfish interface if the hardware of the target server supports the server operation request, send the encapsulated non-universal operation request to the target server, and convert the non-universal operation response result of the target server into a universal operation response result;

[0091] The non-universal operation module 40 includes:

[0092] An operation parameter adaptation unit, configured to encapsulate and adapt the operation parameters of the non-universal operation request in the server operation request through a pre-configured Redfish interface if the operation parameters of the non-universal operation request in the server operation request are different from the operation parameters of the target server, and send the encapsulated non-universal operation request to the target server;

[0093] The functional interface adaptation unit is used to encapsulate and adapt the non-universal operation request in the server operation request through a pre-configured Redfish interface if the functional interface of the non-universal operation request in the server operation request is different from the functional interface of the target server, and send the encapsulated non-universal operation request to the target server.

[0094] The operation parameter adaptation unit is specifically used to:

[0095] Define interface variables for operation parameters;

[0096] Convert common operating parameters into operating parameters that can be supported by servers from different manufacturers;

[0097] If the number of common operation parameters is inconsistent with the number of operation parameters supported by the target server, the default parameters are set to default values ​​according to the default requirements of the target server;

[0098] If the common operation parameter is inconsistent with the operation parameter type supported by the target server, the common operation parameter type is converted to the operation parameter type supported by the target server;

[0099] If the common operation parameters are inconsistent with the operation parameter range supported by the target server, the value range of the common operation parameters is defined as a subset of the value range supported by all target servers;

[0100] Assign the converted operation parameters to the interface variables;

[0101] Call the general operation request and pass in the assigned interface variable to initiate an operation request to the target server.

[0102] The functional interface adaptation unit is specifically used for:

[0103] Defines the function type for non-generic operation requests;

[0104] Adapt non-generic operation requests to the target server;

[0105] If the URL of the non-generic operation request is inconsistent with the URL of the target server, the URL of the target server is encapsulated into the non-generic operation request;

[0106] Perform corresponding business logic arrangement based on non-general operation requests;

[0107] Call the corresponding non-universal operation request address, pass in the corresponding operation parameters, and initiate an operation request to the target server.

[0108] The response returning module 50 is used to standardize the fields of the general operation response results of the target server and return them to the client for display.

[0109] In one embodiment, if Figure 6 As shown, before requesting the verification module 10, it also includes:

[0110] The server management module 10' is used to manage the heterogeneous servers through the user name, user password and HTTP protocol type of the heterogeneous server out-of-band management BMC, and save the obtained information of the heterogeneous servers to the database.

[0111] In one embodiment, the heterogeneous server management device based on redfish further includes:

[0112] The general operation module is used to call RedfishSDK to send the general operation request in the server operation request to the target server if the hardware of the target server supports the server operation request.

[0113] It should be noted that technicians in the relevant field can clearly understand that the specific implementation process of the above-mentioned redfish-based heterogeneous server management device and each unit can refer to the corresponding description in the aforementioned method embodiment. For the convenience and conciseness of the description, it will not be repeated here.

[0114] The heterogeneous server management device based on redfish can be implemented in the form of a computer program. The computer program can be used in Figure 7 Runs on the computer device shown.

[0115] See also Figure 7 , Figure 7 5 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a terminal or a server, wherein the terminal may be an electronic device with communication functions such as a smart phone, a tablet computer, a laptop computer, a desktop computer, a personal digital assistant, and a wearable device. The server may be an independent server or a server cluster composed of multiple servers.

[0116] See also Figure 7 The computer device 500 includes a processor 502 , a memory and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0117] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, and when the program instructions are executed, the processor 502 can execute a heterogeneous server management method based on redfish.

[0118] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500 .

[0119] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a heterogeneous server management method based on redfish.

[0120] The network interface 505 is used to communicate with other devices over the network. Figure 7 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0121] The processor 502 is used to run the computer program 5032 stored in the memory to implement the heterogeneous server management method based on redfish as described above.

[0122] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0123] It can be understood by those skilled in the art that all or part of the processes in the method for implementing the above embodiment can be completed by instructing the relevant hardware through a computer program. The computer program includes program instructions, and the computer program can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiment of the above method.

[0124] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When the program instructions are executed by a processor, the processor executes the heterogeneous server management method based on redfish as described above.

[0125] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk, etc., which are computer-readable storage media that can store program codes.

[0126] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0127] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of each unit is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0128] The steps in the method of the embodiment of the present invention can be adjusted in order, combined and deleted according to actual needs. The units in the device of the embodiment of the present invention can be combined, divided and deleted according to actual needs. In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0129] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention.

[0130] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A heterogeneous server management method based on redfish, characterized in that: include: Receive server operation requests sent by the client and verify the server operation requests; After the server operation request is verified, a session with the target server is established; Perform business logic verification on the target server to determine whether the hardware of the target server supports the server operation request; If the hardware of the target server supports the server operation request, the non-universal operation request in the server operation request is encapsulated and adapted through the pre-configured Redfish interface, the encapsulated non-universal operation request is sent to the target server, and the non-universal operation response result of the target server is converted into a universal operation response result; The target server's common operation response results are standardized and unified in fields and then returned to the client for display.

2. The heterogeneous server management method based on redfish as claimed in claim 1, characterized in that: The encapsulating and adapting the heterogeneous server operation request through a pre-configured Redfish interface for the non-universal operation request in the server operation request, and sending the encapsulated non-universal operation request to the target server comprises: If the operation parameters of the non-universal operation request in the server operation request are different from the operation parameters of the target server, the operation parameters of the non-universal operation request in the server operation request are encapsulated and adapted through the pre-configured Redfish interface, and the encapsulated non-universal operation request is sent to the target server; If the functional interface of the non-universal operation request in the server operation request is different from the functional interface of the target server, the functional interface of the non-universal operation request in the server operation request is encapsulated and adapted through the pre-configured Redfish interface, and the encapsulated non-universal operation request is sent to the target server.

3. The heterogeneous server management method based on redfish as claimed in claim 2, characterized in that: The operation parameters of the non-general operation request in the server operation request are encapsulated and adapted through the pre-configured Redfish interface, and the encapsulated non-general operation request is sent to the target server, including: Define interface variables for operation parameters; Convert common operating parameters into operating parameters that can be supported by servers from different manufacturers; If the number of common operation parameters is inconsistent with the number of operation parameters supported by the target server, the default parameters are set to default values ​​according to the default requirements of the target server; If the common operation parameter is inconsistent with the operation parameter type supported by the target server, the common operation parameter type is converted to the operation parameter type supported by the target server; If the common operation parameters are inconsistent with the operation parameter range supported by the target server, the value range of the common operation parameters is defined as a subset of the value range supported by all target servers; Assign the converted operation parameters to the interface variables; Call the general operation request and pass in the assigned interface variable to initiate an operation request to the target server.

4. The heterogeneous server management method based on redfish as claimed in claim 2, characterized in that: The non-general operation request in the server operation request is encapsulated and adapted through the pre-configured Redfish interface, and the encapsulated non-general operation request is sent to the target server, including: Defines the function type for non-generic operation requests; Adapt non-generic operation requests to the target server; If the URL of the non-generic operation request is inconsistent with the URL of the target server, the URL of the target server is encapsulated into the non-generic operation request; Perform corresponding business logic arrangement based on non-general operation requests; Call the corresponding non-universal operation request address, pass in the corresponding operation parameters, and initiate an operation request to the target server.

5. The heterogeneous server management method based on redfish as claimed in claim 1, characterized in that: Before receiving the server operation request sent by the client, it also includes: Heterogeneous servers are managed through the user name, user password, and HTTP protocol type of the heterogeneous server out-of-band management BMC, and the obtained heterogeneous server information is saved to the database.

6. The heterogeneous server management method based on redfish as claimed in claim 1, characterized in that: The receiving the server operation request and verifying the server operation request includes: Receive server operation requests sent from the client; Authenticate and authenticate server operation requests to confirm the legitimacy of server operation requests.

7. The heterogeneous server management method based on redfish as claimed in claim 1, characterized in that: Also includes: If the hardware of the target server supports the server operation request, the Redfish SDK is called to send the general operation request in the server operation request to the target server.

8. A heterogeneous server management device based on redfish, characterized in that: include: The request verification module is used to receive the server operation request sent by the client and verify the server operation request; A session establishment module is used to establish a session with a target server after the server operation request is verified; A business logic verification module is used to perform business logic verification on the target server to determine whether the hardware of the target server supports the server operation request; The non-universal operation module is used to encapsulate and adapt the non-universal operation request in the server operation request through a pre-configured Redfish interface if the hardware of the target server supports the server operation request, send the encapsulated non-universal operation request to the target server, and convert the non-universal operation response result of the target server into a universal operation response result; The response return module is used to standardize the fields of the common operation response results of the target server and return them to the client for display.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the redfish-based heterogeneous server management method according to any one of claims 1 to 7 when executing the computer program.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the heterogeneous server management method based on redfish as described in any one of claims 1 to 7 can be implemented.

Images