CN116048798A

CN116048798A - Resource traversing method and computing device

Info

Publication number: CN116048798A
Application number: CN202310025069.9A
Authority: CN
Inventors: 陈康
Original assignee: XFusion Digital Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2023-01-09
Filing date: 2023-01-09
Publication date: 2023-05-02

Abstract

The embodiment of the application discloses a resource traversing method and computing equipment, wherein the method comprises the following steps: acquiring related information of equipment to be traversed; based on the related information of the equipment to be traversed, at least one first resource link of the equipment to be traversed is obtained, and the at least one first resource link is ordered into a first queue; processing the resource links in the first queue in a multithreading parallel processing mode to obtain at least one resource data of the equipment to be traversed; and carrying out data processing on the at least one resource data. According to the method and the device, the efficiency of resource traversal can be improved through a multithreading parallel processing mode.

Description

Resource traversing method and computing device

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a resource traversing method and a computing device.

Background

With the progress of computer technology, the functions and performances of the server are continuously improved and perfected, and the server plays an increasingly important role in the fields of cloud computing, data centers, big data and the like. In order to reduce the complexity of server management and improve the operation and management efficiency of the server, server manufacturers generally provide centralized management software for users. In the case that the server supports the Redfish protocol, the centralized management software can manage the server through a Restful interface provided by the server, and can traverse related resources of the server through the Restful interface provided by the server so as to acquire resource data and the like of the server.

In addition, because the occurrence time of the Redfish protocol is shorter, different manufacturers may not completely meet the protocol standard in the implementation of the Redfish protocol, and therefore, related resources of the server generally need to be traversed to detect whether the resource data meets the specification of the Redfish protocol.

At the same time, how to efficiently traverse resources to a server is a matter of concern to the technician.

Disclosure of Invention

The embodiment of the application discloses a resource traversing method and computing equipment, which can improve the efficiency of resource traversing.

The first aspect discloses a resource traversing method, which may be applied to a computing device, a module (e.g., a chip) in the computing device, and a logic module or software that can implement all or part of the functions of the computing device, and is described below as applied to the computing device. The resource traversal method may include: acquiring related information of equipment to be traversed; based on the related information of the equipment to be traversed, at least one first resource link of the equipment to be traversed is obtained, and the at least one first resource link is ordered into a first queue; processing the resource links in the first queue in a multithreading parallel processing mode to obtain at least one resource data of the equipment to be traversed; and carrying out data processing on the at least one resource data.

In the embodiment of the application, the computing device can process the resource link in the first queue in a multithreading parallel processing mode to acquire at least one resource data of the device to be traversed, so that the duration of resource traversal can be shortened, and the efficiency of resource traversal is improved.

As a possible implementation manner, the processing the resource link in the first queue by using a multithreaded parallel processing manner to obtain at least one resource data of the device to be traversed includes: the method comprises the steps of carrying out parallel processing on resource links in a first queue through a first thread pool to obtain at least one first resource data, and sequencing the at least one first resource data into a second queue; the resource data in the second queue are processed in parallel through a second thread pool to obtain at least one second resource link and at least one second resource data, the at least one second resource link is ordered into the first queue, and the at least one second resource data is ordered into a third queue; the data processing of the at least one resource data includes: and carrying out parallel processing on the resource data in the third queue through a third thread pool.

In the embodiment of the application, the computing device may perform parallel processing on the resource link in the first queue through the first thread pool, may perform parallel processing on the resource data in the second queue through the second thread pool, and may perform parallel processing on the resource data in the third queue through the third thread pool, so that the resource traversing efficiency may be improved.

As a possible implementation manner, the first thread pool is used for acquiring resource data of the device to be traversed; the second thread pool is used for analyzing the resource data of the equipment to be traversed to obtain non-traversed resource links and resource data to be processed; the third thread pool is used for processing the resource data to be processed.

In the embodiment of the present application, the resource traversal process may be split into three sub-steps of resource data acquisition, resource data analysis, and resource data processing, and for these three sub-steps, three thread pools (i.e., a first thread pool, a second thread pool, and a third thread pool) may be created to perform processing respectively, so that the duration of resource traversal may be shortened.

As a possible implementation manner, the parallel processing, by the first thread pool, the resource link in the first queue to obtain at least one first resource data, and ordering the at least one first resource data into the second queue, includes: obtaining a third resource link from the first queue, wherein the third resource link is a resource link of the first queue head; acquiring a first thread from a first thread pool, wherein the first thread is any idle thread in the first thread pool; and processing the third resource link through the first thread, acquiring resource data corresponding to the third resource link, and sequencing the resource data corresponding to the third resource link into a second queue.

In this embodiment of the present application, in the case where an unprocessed resource link exists in the first queue, the computing device may sequentially take out the resource link from the first queue in a first-in first-out order, and then may distribute the taken out resource link to an idle thread in the first thread pool for processing, so that the idle thread in the first thread pool may be fully utilized, and efficiency of resource acquisition may be improved.

As a possible implementation manner, the obtaining the resource data corresponding to the third resource link includes: and acquiring the resource data corresponding to the third resource link in an expansion mode.

In the embodiment of the invention, when the resource data is acquired through the resource link, the computing device can access the device to be traversed in an expansion mode, so that the resource data corresponding to the resource link and the resource data corresponding to one or more layers of sub-resource links below the resource link can be acquired together, thereby reducing the access times of the device to be traversed, and obviously reducing the network access time aiming at the condition of poor network state.

As a possible implementation manner, the parallel processing, by the second thread pool, of the resource data in the second queue, to obtain at least one second resource link and at least one second resource data, and ordering the at least one second resource link into the first queue, and ordering the at least one second resource data into the third queue, including: acquiring third resource data from the second queue, wherein the third resource data is the resource data of the second queue head; acquiring a second thread from a second thread pool, wherein the second thread is any idle thread in the second thread pool; and processing the third resource data through the second thread, analyzing the resource links which are not traversed in the third resource data and the resource data to be processed, sequencing the resource links which are not traversed in the third resource data into the first queue, and sequencing the resource data to be processed in the third resource data into a third queue.

In this embodiment of the present application, when unprocessed resource data exists in the second queue, the computing device may sequentially take out the resource data from the second queue according to the first-in first-out order, and then may distribute the taken out resource data to the idle threads in the second thread pool for processing, so that the idle threads in the second thread pool may be fully utilized, and the efficiency of resource analysis may be improved.

As a possible implementation manner, the ordering the resource links that are not traversed in the third resource data into the first queue includes: ordering resource links meeting a first condition in the non-traversed resource links in the third resource data into the first queue; the first condition includes one or more of: the non-traversed resource links are in a preset resource link white list, and the non-traversed resource links are not in a resource link black list; the resource link whitelist includes one or more resource links, and the resource link blacklist includes one or more resource links.

In the embodiment of the application, the computing device can filter the parsed resource links through the resource link white list and/or the resource link black list, and can filter out the resources url which are not concerned by the service or the user, so that unnecessary processing can be reduced, and further the efficiency of resource traversal can be improved.

As a possible implementation manner, the method further comprises: and adding the traversed resource links in the third resource data into a traversed resource link table, wherein the traversed resource links in the third resource data are the resource links in the third resource data, which have acquired the corresponding resource data.

In the embodiment of the application, the traversed resource links can be added into the traversed resource link table, so that the computing equipment can conveniently screen the resource links which are not traversed from the parsed resource links, and the traversing of the resource links can be avoided.

As a possible implementation manner, the parallel processing, by the third thread pool, the resource data in the third queue includes: acquiring fourth resource data from the third queue, wherein the fourth resource data is the resource data of the third queue head; acquiring a third thread from a third thread pool, wherein the third thread is any idle thread in the third thread pool; and processing the fourth resource data through the third thread, and performing data synchronization and/or Redfish protocol standardability verification.

In this embodiment of the present application, in the case where unprocessed resource data exists in the third queue, the computing device may sequentially fetch the resource data from the third queue in a first-in first-out order, and then may distribute the fetched resource data to the idle threads in the third thread pool for processing, so that the idle threads in the third thread pool may be fully utilized, and the efficiency of resource processing may be improved.

As a possible implementation manner, the threads in the first thread pool, the second thread pool and the third thread pool are in a state of synchronous parallel processing.

In the embodiment of the present application, since the resource traversal process is split into three independent sub-steps of resource data acquisition, resource data analysis and resource data processing, threads in the first thread pool, the second thread pool and the third thread pool can be synchronously processed in parallel, so that the efficiency of resource traversal can be improved.

A second aspect discloses a computing device comprising a processor, a memory and a communication interface for receiving information from and outputting information to other electronic devices than the computing device, the processor invoking a computer program stored in the memory to implement a resource traversal method as provided in the first aspect and any of the possible implementations of the first aspect.

A third aspect discloses a computer readable storage medium having stored thereon a computer program or computer instructions which, when run, implement the resource traversal method as disclosed in the above aspects.

A fourth aspect discloses a chip comprising a processor for executing a program stored in a memory, which when executed causes the chip to perform the resource traversal methods disclosed in the above aspects.

As a possible implementation, the memory is located off-chip.

A fifth aspect discloses a computer program product comprising computer program code which, when executed, causes the resource traversal method disclosed in the above aspects to be performed.

It will be appreciated that the computing device provided in the second aspect, the computer readable storage medium provided in the third aspect, the chip provided in the fourth aspect and the computer program product provided in the fifth aspect described above are all for performing the resource traversal method provided in the first aspect and any possible implementation of the first aspect of the present application. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

The drawings in the following description will be presented to more clearly illustrate the embodiments of the present application and to provide a brief description of the drawings, it being apparent that the drawings in the following description are only some of the embodiments of the present application and that other drawings may be obtained from these drawings by those skilled in the art without inventive faculty.

FIG. 1 is a schematic diagram of a Redfish resource tree disclosed in an embodiment of the present application;

FIG. 2 is a schematic diagram of a system architecture disclosed in an embodiment of the present application;

FIG. 3 is a software architecture diagram of a computing device disclosed in an embodiment of the present application;

FIG. 4 is a software architecture diagram of another computing device disclosed in an embodiment of the present application;

FIG. 5 is a flow chart of a resource traversal method disclosed in an embodiment of the present application;

FIG. 6 is a flow chart of another resource traversal method disclosed by an embodiment of the present application;

FIG. 7 is a schematic diagram of a process flow of a resource data acquisition module according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a process flow of a resource data analysis module according to an embodiment of the present disclosure;

FIG. 9 is a schematic diagram of a process flow of a resource data processing module according to an embodiment of the present disclosure;

fig. 10 is a schematic structural diagram of a computing device disclosed in an embodiment of the present application.

Detailed Description

The embodiment of the application discloses a resource traversing method and computing equipment, which can improve the efficiency of resource traversing. The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

For a better understanding of the embodiments of the present application, the related art of the embodiments of the present application will be described first.

Redfish is a management standard intended to provide simple and secure management functions for converged, hybrid information technology (information technology, IT) and software defined data centers (softwares defined data center, SDDC). It uses the representational state transfer (representational state transfer, RESTful) interface semantics to access data defined in the model format to perform out-of-band system management (out of band systems management). The Redfish standard (i.e., protocol) is applicable to large-scale servers, from stand-alone servers to rack-and-blade server environments, as well as to large-scale cloud environments, data centers, and the like.

Wherein RESTful application programming interface (application programming interface, API) refers to an interface that meets REST design style. Presently, the Redfish protocol employs an open data protocol (open data protocol, OData), which is a structured information standards promotion organization (organization for the advancement of structured information standards, OASIS) standard that describes how RESTful services are created and accessed. By means of the OData protocol (e.g. OData v4 version), the queriable and operable RESTful API can be built in a simple and standard way.

A uniform resource identifier (uniform resource identifier, URI) may be used in the Redfish protocol to identify a resource, a service, or a set of resources (i.e., aggregate resources). In general, a URI may comprise three parts, a first part comprising the service means and the host internet protocol (internet protocol, IP) address or domain name (sometimes including port numbers), a second part comprising the root service and the Redfish protocol version, and a third part being a unique resource identifier. For example, the following uniform resource locator (uniform resource locator, URL): https, i.e. communication is carried out by adopting https protocol, and the host domain name is mgmt.vendor.com/edfish/v 1/Systems/1/Ethernet interfaces/1. The root services and the version of the Redfish protocol of the second part are the Redfish and v1,/Redfish/v1, respectively, also commonly referred to as root url. The third part's unique resource identifier is/Systems/1/Ethernet interfaces/1, which is also commonly referred to as a resource path.

In some embodiments, the resource paths of the root url of the second portion and the third portion may also be used as a URI of a resource, and the related resource of a Redfish device may be uniquely identified. For example, for a POST request sent by a client, the following URI may be returned at the head location of the response (i.e., the location indicating the new resource created by the POST): redfish/v1/Systems/2. Then, if the new resource is to be accessed, the content of the first part (i.e. the service mode, and the host IP address or domain name) needs to be added in front of the URI, and the domain name of the server is mgmt.

The Redfish protocol uses hypertext transfer protocol (hypertext transfer protocol, HTTP) or secure hypertext transfer protocol (hyper text transfer protocol secure, HTTPs) technology. Thus, in the Redfish protocol, the client may send a request (i.e., a request message) to the server, and the server may return a response (i.e., a response message) to the client. The request may generally include a request header and a request body (i.e., a request message body), and the response may generally include a response header, a response body (i.e., a response message body), and a response code (i.e., an http status code). The request types specified in the Redfish protocol may include GET, POST, PATCH, DELETE, etc. The GET request may obtain a representation of the resource (i.e., a description or data of the resource), the POST request may create a new resource, the PATCH request may modify the resource (e.g., modify an attribute of the resource), and the DELETE request may DELETE the specified resource. It will be appreciated that one resource may be represented using JSON (javascript object notation) media Type (i.e., "application/json") and that in an HTTP message, the media Type may be specified by a Content-Type attribute in the request header or the response header.

As can be seen from the above description, the Redfish protocol can abstract the device into individual resources and provide corresponding API interfaces in a Restful manner, so that the user can manage the device conveniently. Where/redfish/v 1 is the root url (i.e. root resource), all other resources start from the root resource, and these all resources can be seen as a resource tree, see in particular fig. 1.

As shown in FIG. 1, the next layer of root resources/redfish/v 1 may include sub-resources such as system resources (Systems), management resources (manager), chassis resources (Chassis), event resources (Event), task resources (Task), etc., and the next layer may include sub-resources such as Systems, managers, chassis, event, task, for example, the next layer of system resources may include one or more specific system resources (e.g., 437XR1138R 2), 437XR1138R2 may be an identification (identity document, ID) of a specific system resource, and may include sub-resources such as Bios resources (Bios), processor resources (Processors), etc., and may include other sub-resources such as Bios, processors. Similarly, for Chassis resources, one or more specific Chassis resources (e.g., 1U) may be included at a next level, and sub-resources such as Chassis heat sink resources (Thermal), power resources (Power), sensor resources (Sensor), controller resources (Controls) may be included at each specific Chassis resource, for which the next level may also include other resources, such as Sensor resources, and one or more specific Sensor resources (e.g., sensor-SersorX) may be included at the next level. It should be understood that the resource tree shown in fig. 1 is merely illustrative and not limiting. For example, as the version of the Redfish protocol is updated to v2, the root resource may also be/Redfish/v 2. It should also be appreciated that one resource and one resource url (resource link) may correspond, for example, a resource url corresponding to a Systems resource may be/redfish/v 1/Systems, or/redfish/v 1/Systems may be regarded as Systems resources.

With the progress of computer technology, the functions and performances of the server are continuously improved and perfected, and the server plays an increasingly important role in the fields of cloud computing, data centers, big data and the like. In addition, in order to reduce the complexity of server management and improve the operation and management efficiency of the server, server manufacturers generally provide centralized management software for users. In the case that the server supports the Redfish protocol, the centralized management software may manage the server through a Restful interface provided by the server, and may traverse related resources (such as all the resources of the resource tree shown in fig. 1) of the server through the Restful interface provided by the server, so as to obtain resource data of the server, and so on. In addition, because the occurrence time of the Redfish protocol is shorter, different manufacturers may not completely meet the protocol standard in the implementation of the Redfish protocol, so that related resources of a server generally need to be traversed to detect whether resource data meet the specification of the Redfish protocol. It should be understood that the Redfish resource traversal is a process of accessing all resources provided by a Redfish device (such as a server), that is, a process of accessing all Restful resource interfaces provided by the Redfish device, that is, a process of accessing all nodes of a resource tree corresponding to the Redfish device, and all resource data of the Redfish device can be obtained through the Redfish resource traversal.

At present, the Redfish resource traversal generally adopts a serial execution mode to carry out resource traversal, and the whole resource traversal process generally comprises the following steps:

step 1: a first-in first-out queue with the length of N is created, then the/redfish/v 1 root resource url is added into the queue, and the value of N is generally larger than the maximum subtree number of the current resource tree.

Step 2: and (3) taking one resource url from the queue, judging whether the resource url is traversed, if the resource url is not traversed, executing the step (3), otherwise, repeatedly executing the step (2), namely taking the next resource url from the queue, and continuously judging whether the next resource url is traversed.

Step 3: based on the IP, the port and the authentication information of the Redfish device and the resource url extracted in the step 2, acquiring resource data corresponding to the resource url from the Redfish device through an http client (namely an http client) component, and marking the resource url as traversed after successfully acquiring the data.

Step 4: and 3, analyzing the sub-resource url corresponding to the resource url from the resource data acquired in the step, and then adding the analyzed sub-resource url into a queue.

Step 5: and processing the attribute data of the Redfish equipment, wherein if the attribute data are in order to perform data synchronization, the acquired resource data can be stored in a database according to a corresponding format, and if the attribute data are in order to perform the Redfish protocol compliance test, the acquired resource data can be compared with a schema file provided by a Redfish standard for verification, so that whether the acquired resource data meet the Redfish protocol specification can be determined.

It should be understood that steps 2-5 above may be repeated until the queue is empty, i.e. there are no resources url in the queue, at which point it may be determined that all resource url traversals of the Redfish device are complete.

In the above-mentioned Redfish resource traversing manner, it is necessary to access the full interfaces of the Redfish device (i.e. access all the resource urls of the Redfish device), so that the entire resource traversing process can call the interfaces of the Redfish device in a large amount, and therefore, the time required in the entire resource traversing process can be long, and factors such as the number of resources (i.e. the number of resource urls) and the network state can greatly influence the resource traversing duration. In addition, the above-mentioned resource traversal process is performed serially, and one resource url in the resource tree is accessed at a time, so that the resource traversal efficiency is low.

In order to solve the above problem, in the embodiment of the present application, the Redfish resource traversal process may be split into three sub-steps of resource data acquisition, resource data analysis and resource data processing, and then the three sub-steps may be executed in parallel, and at the same time, for each sub-step, parallel processing may also be performed through a thread pool, so that the duration of resource traversal may be shortened, and the resource traversal efficiency may be improved. In addition, when the resource data is acquired through the resource url, the Redfish device can be accessed in an expansion (expansion) mode, so that the resource data corresponding to the resource url and the resource data corresponding to one or more layers of sub-resource url below the resource url can be acquired together, the access times to the Redfish device can be reduced, and the network access time can be obviously reduced for the situation of poor network state. In addition, in the embodiment of the application, a filtering mechanism of the resource url is added, so that the service can be filtered out of paying no attention to the resource url, unnecessary traversal of the resource url can be avoided, and further the duration of resource traversal can be shortened.

For a better understanding of the embodiments of the present application, the system architecture used by the embodiments of the present application is described below.

Referring to fig. 2, fig. 2 is a schematic diagram of a system architecture according to an embodiment of the present application. As shown in fig. 2, the system architecture may include: a computing device 201, a network 202, and a repash device (device to be traversed) 203. Wherein the computing device 201 and the Redfish device 203 may be respectively connected to the network 202, and communicate with each other through the network 202.

In some embodiments, computing device 201 may remotely manage (including status monitoring, power up and power down control, etc.) Redfish device 203. The computing device 201 may be a server or an electronic device with remote management functions, etc.

It should be noted that the Redfish device refers to a device supporting the Redfish protocol. In the embodiment of the present application, the Redfish device may be a blade server, a high-density server, a rack server, or the like that supports the Redfish protocol.

It should be appreciated that for any server, it will typically be provided with an out-of-band controller. Wherein the out-of-band controller may be an out-of-band processor independent of the central processing unit (central processing unit, CPU). The out-of-band controller may include a monitoring management unit external to the computer device, a management system in a management chip external to the processor, a computer device baseboard management unit (baseboard management controller, BMC), a system management module (system management mode, SMM), and the like.

The out-of-band controller is mainly used for monitoring, managing and the like of the server and supporting remote management (such as server reset, power on and power off and the like) through a management network port. For example, the out-of-band controller may monitor the status (e.g., humidity, temperature, voltage, current, etc.) of various hardware devices in the server. For another example, system configuration, firmware upgrades, fault diagnostics, etc. may be performed by the out-of-band controller. In this embodiment, the computing device 201 may implement remote management (including status monitoring, power-on and power-off control, etc.) of each Redfish device through a management portal provided by the out-of-band controller of the Redfish device 203.

In some embodiments, the computing device 201 and the Redfish device 203 described above may also include a processor, memory, or the like. The memory may include, but is not limited to, memory such as random access memory (random access memory, RAM), read-only memory (ROM), erasable programmable read-only memory (erasable programmable read only memory, EPROM), or portable read-only memory (compact disc read-only memory, CD-ROM). The processor may be a CPU, complex programmable logic device, general purpose processor, digital signal processor, application specific integrated circuit, field programmable gate array, or other programmable logic device, transistor logic device, hardware component, or any combination thereof.

It should be noted that the system architecture shown in fig. 2 is only exemplary, and is not limited to the configuration thereof. In other embodiments of the present application, the system architecture shown in FIG. 2 may include more or fewer devices than shown.

Referring to fig. 3, fig. 3 is a schematic software architecture of a computing device according to an embodiment of the present application. Among other things, the computing device 201 may include a resource traversal module 2011. The resource traversal module 2011 may include three sub-modules, such as a resource data acquisition (Downloader) module 20111, a resource data analysis module (i.e., analyzer) 20112, and a resource data processing (data processing) module 20113.

The resource traversal module 2011 may traverse the resources of the Redfish device. The resource data acquiring module 20111 is mainly configured to acquire all resource data (i.e., resource data corresponding to all resource url) of the Redfish device. When acquiring the resource data, the resource data acquiring module 20111 may acquire the resource data corresponding to different resource urls in parallel through the thread pool, and may perform traversal optimization in an expansion mode under the condition that the Redfish device supports the expansion mode. It should be understood that, by accessing the Redfish device in the expansion mode, the current resource and the resource data corresponding to one or more sub-resources of the next layer or layers of the current resource can be acquired at a time.

The resource data analysis module 20112 is mainly used for extracting resource url of a lower resource (such as sub-resource, sun Ziyuan, etc.) from the resource data acquired by the resource data acquisition module 20111. When extracting the resource url of the lower resource, the resource data analysis module 20112 may process different resource data acquired by the resource data acquisition module 20111 in parallel through a thread pool, and may screen the extracted resource url according to a resource filtering table (such as a resource url blacklist or a resource url whitelist), filter out some resource urls that are not concerned, and then may return the filtered resource url to the resource data acquisition module 20111. In addition, the resource data analysis module 20112 may also send the filtered resource data (i.e. the resource data to be processed) to the resource data processing module 20113.

The resource data processing module 20113 is mainly configured to process the resource data from the resource data analysis module 20112, so as to complete specific business related processing (such as data synchronization, protocol compliance test, etc.) on the data of the Redfish device. When the resource data processing module 20113 processes resource data, different resource data can be processed in parallel through the thread pool. It should be appreciated that in some embodiments, the resource data analysis module 20112 and the resource data processing module 20113 may be combined into one module. But the resource data processing module 20113 is independent, so that analysis of url and understanding of the resource data can be conveniently coupled, and related processing can be independently performed between the resource data processing module 20113, and thus, the resource data processing module 20113 can perform self-defined optimization (such as data merging, batch processing and the like) on the resource data processing.

The processing flows of the resource data acquisition module 20111, the resource data analysis module 20112, and the resource data processing module 20113 are exemplarily described below with reference to fig. 4.

As shown in fig. 4, the resource data obtaining module 20111, the resource data analyzing module 20112 and the resource data processing module 20113 may have separate queues and thread pools, where the initial length and the thread pool size of each queue may be preconfigured, or may receive user input to configure. For example, the resource traversal module 2011 may receive configuration information input by a user, where the configuration information may include a size of each thread pool, and a default length of each queue. In addition, in order to traverse the resources of the Redfish device, the configuration information may further include related information of the Redfish device, such as a protocol (https/http), an IP address and a port of the Redfish device, a traversal starting resource (such as a root resource/Redfish/v 1), authentication information (such as an account number and a password), a root certificate, whether to open an expansion access, an expansion layer number, a resource filtering table (a resource url blacklist or a resource url whitelist), and the like.

When the resource data acquisition module 20111, the resource data analysis module 20112 and the resource data processing module 20113 are started, initialization is performed, and a queue and a thread pool can be created according to the configured thread pool size and the default queue length. After the resource url queue (i.e., the first queue) of the resource data obtaining module 20111 is created, step (1) may be performed, and the configured traversal start resource url (/ repaish/v 1) is added to the queue. Thereafter, the first Scheduler (Scheduler) of the resource data obtaining module 20111 may perform step (2), take the element to be processed (i.e. the resource url) from the resource url queue, and then may perform step (3) to dispatch the resource url to the idle thread in the first thread pool for processing. The idle thread may obtain, through the URLDownloader module, resource data corresponding to the resource url from the Redfish device according to the resource url and a configured protocol, an IP address, a port, authentication information, and a root certificate of the Redfish device (i.e., perform steps (4) and (5)). In some embodiments, the resource url and the resource data corresponding to one or more sub-resource urls below the resource url may be acquired through an expand access manner. After the thread acquires the corresponding resource data, step (6) may be performed, the resource data may be returned to the first scheduler of the resource data analysis module 20112, and then the first scheduler may perform step (7) and send the resource data to the resource data analysis module 20112.

After the resource data analysis module 20112 receives the resource data from the resource data acquisition module 20111, the resource data may be added to the created first resource data queue (i.e., the second queue). The second scheduler of the resource data analysis module 20112 may perform step (8) to fetch the element to be processed (i.e., the resource data) from the first resource data queue, and then may perform step (9) to distribute the resource data to the idle threads in the second thread pool for processing. The idle thread can execute step (A) and recursively analyze the @ odata.id and Members@odata.nextlink key in the resource data by the url parser to obtain all the child resource urls in the resource data. Thereafter, the idle thread may perform the steps of

All the sub-resources url analyzed are filtered through a resource filter table, and then the step +.>

The filtered resource url is returned to the second scheduler of the resource data analysis module 20112, and the second scheduler may be returned to the resource data acquisition module 20111 (i.e. execute step +_>

) The resource data acquisition module 20111 may then add these resource urls to the resource url queue. In addition, the resource data analysis module 20112 may also return the filtered resource data to the second scheduler, which may then send this The resource data are sent to the resource data processing module 20113 (i.e. execute step +.>

)。

After the resource data processing module 20113 receives the resource data from the resource data analysis module 20112, the resource data may be added to the created second resource data queue (i.e., the third queue). The third scheduler of the resource data processing module 20113 may perform the steps of

The element to be processed, i.e. the resource data, is taken from the second resource data queue and then the steps +.>

And distributing the resource data to idle threads in a third thread pool for processing. The idle thread can process the resource data of the Redfish device according to the service scene (namely executing the step +.>

)。

It will be appreciated that the end condition of the entire resource traversal process is that the data in the queues of the resource data acquisition module 20111, the resource data analysis module 20112, and the resource data processing module 20113 are processed (i.e. each queue is empty), and no thread is running in each thread pool. It should be noted that, the queues of the resource data acquiring module 20111, the resource data analyzing module 20112, and the resource data processing module 20113 may be automatically expanded. For example, in the case where the queue is full, the queue may be expanded by a factor of 2 at present. It should be appreciated that the threads in the first thread pool of the resource data acquisition module 20111, the second thread pool of the resource data analysis module 20112, and the third thread pool of the resource data processing module 20113 may be in a state of synchronous parallel processing.

It should be understood that the resource traversing method provided in the embodiment of the present application may be applicable to any scenario in which resources of a Redfish device are traversed. For example, the centralized management software manages a server scenario supporting the Redfish protocol, and for example, a scenario in which protocol normalization test is performed on the Redfish device.

It should be noted that the software structures shown in fig. 3 and fig. 4 are only exemplary, and are not limited to the configuration. In other embodiments of the present application, the software structures shown in fig. 3 and 4 may include more or fewer software modules than shown.

Based on the above system architecture, please refer to fig. 5, fig. 5 is a flowchart of a resource traversing method disclosed in an embodiment of the present application. As shown in fig. 5, the resource traversal method may include, but is not limited to, the steps of:

501. the computing device obtains relevant information of the device to be traversed.

Specifically, in order to traverse the Redfish resource of the device to be traversed, the computing device may first obtain relevant information of the device to be traversed. Specifically, the method can include protocols (https/http), IP addresses, ports of the Redfish devices, traversal starting resources (such as root resources/Redfish/v 1), authentication information (such as account numbers and passwords), root certificates, whether to open expansion access, expansion layer numbers, a resource filtering list (resource url blacklist or resource url whitelist) and the like.

502. The computing device obtains at least one first resource link of the device to be traversed based on the related information of the device to be traversed, and sorts the at least one first resource link into a first queue.

Specifically, the related information of the device to be traversed may include a traversal start resource, which may be one traversal start resource or multiple traversal start resources. Thereafter, the computing device may sort the traversal start resource (i.e., the at least one first resource link) in the relevant information of the device to be traversed into a first queue, awaiting processing.

503. The computing device processes the resource links in the first queue in a multithreading parallel processing mode to obtain at least one resource data of the device to be traversed.

Specifically, in order to accelerate the speed of resource traversal, the computing device may process the resource link in the first queue in a multithreaded parallel processing manner, so as to obtain at least one resource data of the device to be traversed. For example, the computing device may process the 5 threads in parallel, so that the 5 resource links in the first queue may be processed at a time, resulting in resource data corresponding to the 5 resource links.

504. The computing device performs data processing on the at least one resource data.

After the computing device obtains at least one resource data of the device to be traversed, the at least one resource data may be data processed. In some embodiments, the computing device may perform data processing on the at least one resource data, then perform data synchronization, update corresponding data in the database, or perform a Redfish protocol normalization check.

Based on the above system architecture, please refer to fig. 6, fig. 6 is a flowchart of another resource traversing method disclosed in an embodiment of the present application. As shown in fig. 6, the resource traversal method may include, but is not limited to, the following steps:

601. the computing device acquires resource data of the Redfish device in a multithreading parallel processing mode.

Specifically, in the process of traversing all resources of the Redfish device, in order to improve the resource traversing efficiency, the computing device may acquire resource data of the Redfish device in a multithreading parallel processing manner. Then, in order to traverse all the resources of the Redfish device, the computing device may parse the obtained resource data of the Redfish device, and extract the resources url that are not traversed therein, i.e. execute step 602.

In some embodiments, to reduce the number of accesses to the Redfish device, the computing device may acquire resource data of the Redfish device in an expand manner. The expansion mode (expansion query mode) can acquire one resource url and resource data corresponding to one or more sub-resource urls of the next layer of the resource url at a time, namely, the resource data of a plurality of resource urls of the Redfish device can be acquired at a time.

It should be noted that, when the computing device acquires the resource data of the Redfish device, the computing device may acquire, in parallel, resource data corresponding to a plurality of different resource urls through the thread pool. Specifically, the computing device may perform parallel processing on the resource links in the first queue through the first thread pool to obtain at least one first resource data, and may sort the at least one first resource data into the second queue. A more detailed description of step 601 and the resource data acquisition module may be found in fig. 7. Fig. 7 is a schematic process flow diagram of a resource data acquisition module according to an embodiment of the present application. As shown in fig. 7, the process flow of the resource data acquisition module may include, but is not limited to, the following steps:

701. the computing device initializes a resource url queue and a first thread pool.

Specifically, in order to improve the efficiency of resource traversal, when the resource data acquisition module is started, the resource url queue (i.e., the first queue) and the first thread pool may be initialized, i.e., the resource url queue and the first thread pool may be created according to the configured thread pool size and the default queue length. The first thread pool may include a plurality of threads, and the plurality of threads may be used for processing different resource urls in the resource url queue in parallel to obtain resource data of the device to be traversed.

After creating the resource url queue, the traversal start resource url (i.e., the first resource link) may be added to the resource url queue waiting for processing. It should be appreciated that the thread pool size, default queue length, traversal starting resource url may be preconfigured (e.g., preconfigured as root resource/redfish/v 1) or may be configured by receiving user input. It should also be appreciated that in some embodiments, the traversal start resource url may not be a root resource, for example, may be a child resource/redfish/v 1/Systems of the root resource as shown in fig. 1, so that the child resource and the underlying resources of the child resource may be traversed in a targeted manner.

702. The scheduler of the resource data acquisition module determines whether the extended query is enabled, and if the extended query is enabled, step 703 is executed, and if the extended query is not enabled, step 709 is executed.

The scheduler of the resource data acquisition module is mainly responsible for judging whether the Redfish device supports the expansion mode access according to the configured expansion switch, expansion layer number (expansion level) and the like, and determining the expansion query layer number actually supported.

Specifically, the scheduler of the resource data acquisition module may determine whether an extended query (i.e., an expand query) is enabled, in which case step 703 may be performed, and in which case step 709 may be performed without the extended query being enabled. Whether to enable the extended query may be preconfigured or configured by receiving user input.

703. And the scheduler of the resource data acquisition module performs N-layer expansion inquiry on the root resource url according to expansion inquiry configuration.

Specifically, the number of layers N of the extended query may be preconfigured or configured by receiving a user input. However, the number of extended query layers actually supported by the Redfish device may not be equal to N, so the scheduler of the resource data acquisition module may first test for N-layer extended query on the root resource url. The url performing the N-layer extended query on the root resource url may be: http(s):// { ip: port }/{ root resource url? Expansion= ($levels=n). It should be understood that the protocols supported by the Redfish device (https/http), the IP address, port, etc. of the Redfish device may be preconfigured or may be configured by receiving user input. N is an integer greater than or equal to 2. It will be appreciated that when N is 1 and the Redfish device supports a layer 1 extended query, by accessing http(s):// { ip: port }/{ root resource url }? The root resource url and the resource data corresponding to the next sub-resource url of the root resource url may be acquired at one time ($extension= ($levels=1). When N is 2 and the Redfish device supports a 2-layer extended query, by accessing http(s):// { ip: port }/{ root resource url }? The root resource url and resource data corresponding to the lower two layers of sub-resources url of the root resource url can be acquired at one time.

704. The scheduler of the resource data acquisition module determines whether the N-layer extended query is successful, and executes step 705 if the N-layer extended query is successful, and executes step 706 if the N-layer extended query is not successful.

After the scheduler of the resource data acquisition module performs N-layer expansion query on the root resource url, it may determine whether the N-layer expansion query is successful, if the N-layer expansion query is successful, it indicates that the Redfish device supports the N-layer expansion query, step 705 may be executed, and if the N-layer expansion query fails, it indicates that the Redfish device does not support the N-layer expansion query, and further, the number of expansion query layers actually supported by the Redfish device may be determined, and step 706 may be executed.

In some embodiments, after the scheduler of the resource data acquisition module performs the N-layer expansion query on the root resource url, if the resource data corresponding to the root resource url and the N-layer sub-resource url below the root resource url sent by the Redfish device is received, at this time, the scheduler of the resource data acquisition module may determine that the N-layer expansion query is successful. In contrast, if the resource data corresponding to the root resource url and the sub-resource url of the lower N layer of the root resource url sent by the Redfish device is not received, or a status code (e.g. 404) of response failure is received, etc., at this time, the scheduler of the resource data obtaining module may determine that the N layer expansion query fails.

705. The scheduler of the resource data acquisition module records that the number of the extended query layers supported by the Redfish equipment is N.

Under the condition that the N-layer expansion inquiry is successful, the scheduler of the resource data acquisition module records that the expansion inquiry layer number supported by the Redfish equipment is N.

706. And the scheduler of the resource data acquisition module sequentially performs (N-K) layer expansion query on the root resource url according to expansion query configuration.

In order to determine the number of expansion query layers actually supported by the Redfish device, the scheduler of the resource data acquisition module may sequentially perform (N-K) layer expansion query on the root resource url according to expansion query configuration, where K is an integer less than N and greater than or equal to 1.

Specifically, the scheduler of the resource data acquisition module may test the number of layers in a decreasing order based on N layers, i.e. the value of K may be increased from 1 to N-1. For example, assuming that N is 4, the scheduler of the resource data acquisition module may perform a 3 (i.e. 4-1) layer expansion query on the root resource url first, if the 3 layer expansion query is successful, it may record that the number of expansion query layers supported by the Redfish device is 3, if the 3 layer expansion query is unsuccessful, it may continue to perform a 2 (i.e. 4-2) layer expansion query on the root resource url, if the 2 layer expansion query is successful, it may record that the number of expansion query layers supported by the Redfish device is 2, if the 2 layer expansion query is unsuccessful, it may continue to perform a 1 (i.e. 4-3) layer expansion query on the root resource url, if the 1 layer expansion query is successful, it may record that the number of expansion query layers supported by the Redfish device is 1, if the 1 layer expansion query is unsuccessful, it indicates that the Redfish device does not support the expansion query, and it may record that the number of expansion query layers supported by the Redfish device is 0.

707. The scheduler of the resource data acquisition module determines whether the (N-K) layer expansion query is successful, and if the (N-K) layer expansion query is successful, step 708 is executed, and if the (N-K) layer expansion query is unsuccessful, step 709 is executed.

When the scheduler of the resource data acquisition module sequentially performs (N-K) layer expansion query on the root resource url, it may be determined whether the (N-K) layer expansion query is successful, if the (N-K) layer expansion query is successful, it indicates that the Redfish device supports the (N-K) layer expansion query, step 708 may be performed, but if the (N-K) layer expansion query fails, it indicates that the Redfish device does not support the expansion query, step 709 may be performed.

708. The scheduler of the resource data acquisition module records that the number of the extended query layers supported by the Redfish device is (N-K).

And under the condition that the (N-K) layer expansion inquiry is successful, the scheduler of the resource data acquisition module records that the number of expansion inquiry layers supported by the Redfish equipment is (N-K).

709. The scheduler of the resource data acquisition module records that the number of the extended query layers supported by the Redfish device is 0.

And under the condition that the (N-K) layer expansion inquiry fails, the scheduler of the resource data acquisition module records that the number of expansion inquiry layers supported by the Redfish equipment is 0.

710. The scheduler of the resource data acquisition module determines whether the resource url queue is empty, and if the resource url queue is not empty, step 711 is executed, and if the resource url queue is empty, the scheduler may block and wait for the resource url queue to be not empty, and then step 711 is executed.

After determining the number of extended query layers supported by the Redfish device, the scheduler of the resource data acquisition module may acquire resource url from the resource url queue and then allocate the resource url to a free thread in the first thread pool for processing.

Specifically, the scheduler of the resource data obtaining module may determine whether the resource url queue is empty, if the resource url queue is not empty, step 711 may be executed, if the resource url queue is empty, which indicates that there is no resource url to be processed currently, blocking may occur, the resource data analyzing module may wait for extracting sub-resource url from the obtained resource data, and when the resource url queue is not empty, step 711 may be executed.

711. The scheduler of the resource data acquisition module acquires a third resource url from the resource url queue.

In the case that the resource url queue is not empty, the scheduler of the resource data acquisition module may acquire a third resource url (third resource link) from the resource url queue. The resource url queue may be a first-in first-out (first input first output, FIFO) queue, and the third resource url may be a resource url that first enters the resource url queue (i.e., a resource url that is located at a head of the resource url queue) among all the resource urls in the resource url queue.

712. The scheduler of the resource data obtaining module determines whether there is an idle thread in the first thread pool, and if there is an idle thread in the first thread pool, step 713 is executed, and if there is no idle thread in the first thread pool, the scheduler may block, wait for the thread to be idle, and then step 713 is executed.

Specifically, after the scheduler of the resource data obtaining module obtains the third resource url, it may determine whether the first thread pool has a free thread, if the first thread pool has a free thread, step 713 may be executed, if the first thread pool has no free thread, which indicates that there is no currently available thread, the scheduler may block, wait for other threads to complete processing, and then execute step 713.

713. The scheduler of the resource data acquisition module acquires the first thread from the first thread Cheng Chizhong.

Specifically, in the case of a free thread in the first thread pool, the scheduler of the resource data acquisition module may acquire the first thread from the first thread Cheng Chizhong and then allocate a third resource url to the first thread for processing. The first thread may be any idle thread of the first thread Cheng Chizhong. It is understood that the idle thread in the first thread pool refers to a thread that is not allocated resources url by the scheduler of the resource data acquisition module or a thread that has processed resources url allocated by the scheduler of the resource data acquisition module.

It should be noted that, after the scheduler of the resource data obtaining module distributes the third resource url to the first thread in the first thread pool, if the first thread Cheng Chizhong still has an idle thread and there is a resource url to be processed in the resource url queue, the scheduler of the resource data obtaining module may continue to obtain other resource urls from the resource url queue, and then distribute the obtained resource url to the idle thread in the first thread pool for processing. If there is no free thread in the first thread pool, the scheduler of the resource data acquisition module may wait for the processing of other threads to complete, or if there is no pending resource url in the resource url queue, the scheduler of the resource data acquisition module may wait for the resource data acquisition module to put a new resource url into the resource url queue.

It should be appreciated that in some embodiments, the scheduler of the resource data acquisition module may perform step 712 first, and when there are free threads in the first thread pool, steps 710 and 711 may be performed again according to the number of free threads. For example, when there are three idle threads and there are three pending resource urls in the resource url queue, three resource urls at the head of the resource url queue may be obtained from the resource url queue for processing.

714. And the first thread acquires resource data corresponding to the third resource url from the Redfish device according to the configured protocol, IP address, port, authentication information, root certificate, extended query layer number and the third resource url.

After the scheduler of the resource data acquisition module acquires the first thread from the first thread pool and distributes the third resource url to the first thread, the first thread can acquire resource data corresponding to the third resource url from the Redfish device according to the configured protocol, the IP address, the port, the authentication information, the root certificate, the extended query layer number and the third resource url.

Specifically, the first thread may determine a complete url to access the Redfish device according to the configured protocol, IP address, port (i.e., port number), extended query layer number, and third resource url. For example, assuming that the protocol supported by the Redfish device is https, the number of supported extended query layers is K, and the third resource url is/Redfish/v 1/Systems, the obtaining the complete url of the resource data corresponding to the third resource url may be: https? Expansion= ($levels=k). If the number of the extended query layers supported by the Redfish device is 0, it indicates that the Redfish device does not support the expand query, and the obtaining of the complete url of the resource data corresponding to the third resource url may be: https:// IP address of the Redfish device: port/Redfish/v 1/Systems.

After the first thread determines to access the complete url of the Redfish device, the URLDownloader module may be invoked to obtain detailed resource data corresponding to the third resource url. Specifically, the URLDownloader module may obtain data corresponding to the third resource url according to the determined complete url of the access Redfish device, and in the case of adopting K-layer expansion query, the obtained data corresponding to the third resource url may include resource data corresponding to a K-layer sub-resource url below the third resource url. The URLDownloader module is an http client component, needs to support an https mode, and can adopt an existing http client library according to an implementation language.

It should be appreciated that the number of extended query layers used by the first thread to access the Redfish device may be the number of extended query layers actually supported by the Redfish device as determined above. It should also be appreciated that the computing device may send authentication information (e.g., account numbers and passwords) or the like to the Redfish device, which may be used to authenticate the identity of the Redfish device when sending messages to the computing device. And, when the https certificate of the Redfish device needs to be checked, the checking can be performed based on the root certificate.

It should be noted that, for the third resource url, when the Redfish device does not support the expand mode, the computing device may acquire resource data corresponding to the third resource url, where the resource data may include an access path of a child resource url included in a layer below the third resource url. For example, in connection with fig. 1, it is assumed that the third resource url is a sub-resource url such as/refsh/v 1, and the resource data corresponding to/refsh/v 1/Systems,/refsh/v 1/manager,/refsh/v 1/Chassis,/refsh/v 1/Event,/refsh/v 1/Task may be included in the resource data corresponding to/refsh/v 1/Systems, but the resource data corresponding to these sub-resource urls is not included.

Under the condition that the Redfish device supports the expansion mode, the computing device can acquire resource data corresponding to the third resource url, wherein the resource data can include one or more layers of resource data corresponding to the sub-resource url below the third resource url. For example, in conjunction with fig. 1, assume that the third resource url is/refsh/v 1, and the number of extended query layers supported by the refsh device is 1, where the resource data corresponding to/refsh/v 1 acquired by the computing device may include sub-resources url such as/refsh/v 1/Systems,/refsh/v 1/manager,/refsh/v 1/Chassis,/refsh/v 1/Event,/refsh/v 1/Task, and may further include resource data corresponding to these sub-resources url. The resource data corresponding to the sub-resource url may include the access path of the sub-resource url of the lower layer, but does not include the resource data corresponding to the sub-resource url of the lower layer. Taking the example of the resource data corresponding to the/redfish/v 1/Systems, the resource data corresponding to the/redfish/v 1/Systems may include the sub-resource url such as the/redfish/v 1/Systems/437XR1138R2, but does not include the resource data corresponding to the sub-resource url such as the/redfish/v 1/Systems/437XR1138R 2.

It will be appreciated that in the case where an extended query is not employed for the third resource url, this is equivalent to the GET request being initiated for the third resource url. In the case of an extended query for the third resource url, this is equivalent to the GET request being initiated for the third resource url and one or more layers of child resource url below the third resource url. In connection with fig. 1, assuming that the third resource url is/refish/v 1, if no extended query is employed, it is equivalent to only issuing GET requests to/refish/v 1. If an extended query is employed, and the number of employed extended query layers is 1, then a GET request is initiated corresponding to the child resources url of/refsh/v 1, and/refsh/v 1 (i.e.,/refsh/v 1/Systems,/refsh/v 1/manager,/refsh/v 1/Chassis,/refsh/v 1/Event,/refsh/v 1/Task, etc.).

715. And the first thread returns the resource data corresponding to the acquired third resource url to a scheduler of the resource data acquisition module.

After the first thread acquires the resource data corresponding to the third resource url, the resource data corresponding to the third resource url may be returned to the scheduler of the resource data acquisition module.

716. The first thread becomes an idle thread.

After the first thread returns the resource data corresponding to the acquired third resource url to the scheduler of the resource data acquisition module, the first thread can become an idle thread, and the scheduler of the resource data acquisition module waits for the allocation of other resources url to be processed.

717. And the scheduler of the resource data acquisition module sends the resource data corresponding to the third resource url to the resource data analysis module.

After receiving the resource data corresponding to the third resource url from the first thread, the scheduler of the resource data acquisition module may send the resource data corresponding to the third resource url to the resource data analysis module. Correspondingly, the resource data analysis module can receive the resource data corresponding to the third resource url from the resource data acquisition module, and then can put the resource data corresponding to the third resource url into the first resource data queue, and wait for the scheduler of the resource data analysis module to be distributed to the idle threads in the second thread pool for processing.

602. The computing device analyzes the acquired resource data of the Redfish device, and extracts the resource url which is not traversed.

After the computing device obtains the resource data of the Redfish device, the computing device can analyze the resource data of the Redfish device and extract the resource url which is not traversed. Then, the computing device may continue to acquire the resource data of the Redfish device in the expansion mode based on the non-traversed resource url, that is, the computing device may repeatedly execute the step 601 and the step 602 until all the resource data of the Redfish device are acquired, that is, all the resources of the Redfish device are traversed.

It should be noted that, when the computing device parses the resource data of the Redfish device, the thread pool may parse the resource data corresponding to a plurality of different resource urls in parallel. Specifically, the computing device may perform parallel processing on the resource data in the second queue through the second thread pool to obtain at least one second resource link and at least one second resource data, and may sort the at least one second resource link into the first queue and sort the at least one second resource data into the third queue. A more detailed description of step 602 and the resource data analysis module may be found in fig. 8. Fig. 8 is a schematic process flow diagram of a resource data analysis module according to an embodiment of the present application. As shown in fig. 8, the process flow of the resource data analysis module may include, but is not limited to, the following steps:

801. The computing device initializes a first resource data queue and a second thread pool.

Specifically, in order to improve the efficiency of the resource data analysis, when the resource data analysis module is started, the first resource data queue and the second thread pool may be initialized, i.e. the first resource data queue and the second thread pool may be created according to the configured thread pool size and the default queue length. The second thread pool may include a plurality of threads, where the plurality of threads may be configured to process different resource data (i.e., elements) in the first resource data queue in parallel, and extract non-traversed resource links and resource data to be processed therein.

After the first resource data queue is created, the resource data analysis module may wait to receive the resource data from the resource data acquisition module, and then may add the received resource data (e.g., the resource data corresponding to the third resource url described above) to the first resource data queue, and wait to perform processing. It should be appreciated that the size of the second thread pool, the default queue length of the first resource data queue, may be pre-configured or may be configured to receive user input. It should be noted that, when the resource data analysis module places the resource data corresponding to the third resource url into the first resource data queue, the resource data corresponding to the third resource url may be used as an element in the first resource data queue.

802. The scheduler of the resource data analysis module determines whether the first resource data queue is empty, and if the first resource data queue is not empty, step 803 is executed, and if the first resource data queue is empty, the scheduler may block and wait for the first resource data queue to be not empty, and then step 803 is executed.

After initializing the first resource data queue and the second thread pool, the scheduler of the resource data analysis module may obtain resource data to be parsed (i.e., to be processed) from the first resource data queue and then assign the resource data to free threads in the second thread pool for processing.

Specifically, the scheduler of the resource data analysis module may determine whether the first resource data queue is empty, if the first resource data queue is not empty, step 803 may be executed, if the first resource data queue is empty, which indicates that there is no resource data to be parsed currently, blocking may be performed, waiting for the resource data acquisition module to acquire the resource data from the Redfish device, and when the first resource data queue is not empty, step 803 may be executed again.

803. The scheduler of the resource data analysis module obtains third resource data from the first resource data queue.

The scheduler of the resource data analysis module may obtain the third resource data from the first resource data queue if the first resource data queue is not empty. The first resource data queue may be a first-in first-out queue, and the third resource data may be resource data (i.e. resource data located at a first resource data queue head) that first enters the first resource data queue among all resource data in the first resource data queue.

804. The scheduler of the resource data analysis module determines whether there is an idle thread in the second thread pool, and if there is an idle thread in the second thread pool, step 805 is executed, and if there is no idle thread in the second thread pool, the scheduler may block, wait for the thread to be idle, and then step 805 is executed.

Specifically, after the scheduler of the resource data analysis module obtains the third resource data, it may determine whether there is an idle thread in the second thread pool, if there is an idle thread in the second thread pool, step 805 may be executed, if there is no idle thread in the second thread pool, which indicates that there is no currently available thread, and then step 805 may be executed after waiting for processing of other threads to complete.

805. The scheduler of the resource data analysis module obtains a second thread from a second thread pool.

Specifically, in the case that there is a free thread in the second thread pool, the scheduler of the resource data analysis module may obtain the second thread from the second thread pool, and then allocate third resource data to the second thread for processing. The second thread may be any idle thread in the second thread pool. It can be understood that the idle threads in the second thread pool refer to threads not allocated with the resource data to be parsed by the scheduler of the resource data analysis module, or threads already processed with the resource data to be parsed allocated by the scheduler of the resource data analysis module.

It should be noted that, after the scheduler of the resource data analysis module distributes the third resource data to the second thread in the second thread pool, if there is an idle thread in the second thread pool and there is resource data to be analyzed in the first resource data queue, the scheduler of the resource data analysis module may continue to acquire other resource data to be analyzed from the first resource data queue, and then distribute the acquired resource data to be analyzed to the idle thread in the second thread pool for processing. If there is no free thread in the second thread pool, the scheduler of the resource data analysis module may wait for the processing of other threads to complete, or if there is no resource data to be parsed in the first resource data queue, the scheduler of the resource data analysis module may wait for the resource data analysis module to put new resource data to be parsed into the first resource data queue.

It should be appreciated that in some embodiments, the scheduler of the resource data analysis module may perform step 804 first, and when there are free threads in the second thread pool, steps 802 and 803 may be performed again according to the number of free threads. For example, when there are three idle threads and there are three resource data to be processed in the first resource data queue, three resource data of the first resource data queue head may be acquired from the first resource data queue for processing.

806. The second thread analyzes the third resource data and extracts the resource url which is not traversed in the third resource data.

The scheduler of the resource data analysis module acquires the second thread from the second thread pool, and after distributing the third resource data to the second thread, the second thread can analyze the third resource data and extract the resource url which is not traversed in the second thread.

Specifically, the second thread may call a url parser to parse the third resource data, and extract a resource url that is not traversed in the third resource data. The url parser can parse the keywords of @ odata.id, members@odata.nextlink and the like in the resource data to obtain all the resource urls in the resource data, and then extract the resource urls which are not traversed. The @ odata.id generally indicates a link to a resource (i.e., access path to the resource), and Members@odata.nextlink generally indicates a link to a paged resource. Further, since the resource data is generally represented in JSON format, and the resource data in JSON format may have data type nesting (such as nesting of multiple arrays), parsing @ odata.id and Members@odata.nextlink keywords also requires recursive parsing according to whether the fields are arrays or map types. It should be understood that the resource data to be parsed is generally one JSON object, which is located in brackets { }, each JSON object may include a plurality of key/value pairs, and the value in each key value pair may be a string, a JSON object, or an array, etc., and recursive parsing is that parsing is performed for each layer of data, respectively.

The following lists an example of resource data of the Redfish device, where the resource url corresponding to the resource data may be/Redfish/v 1/ServiceConditions, which is specifically shown as follows:

wherein the Conditions are array types, each element of the Conditions is a complex object (i.e. JSON object), and a field of the complex object, such as origin ofcondition, includes an @ odata.id key.

For the above example, the second thread invoking url parser may extract four resource urls of/reffish/v 1/Chassis/1/Power,/reffish/v 1/manager/1/LogServices/Entricies/1,/reffish/v 1/Systems/cpu-memory-sample,/reffish/v 1/ServiceCondition, and since the resource data is the resource data corresponding to/reffish/v 1/ServiceCondition, it has already been traversed, so that three non-traversed resource urls may be finally obtained.

It should be appreciated that in some embodiments, where an extended query is employed, the second thread may parse out all resource urls in the third resource data, and then may cull the resource urls that have been extended therein (i.e., the resource url for which the corresponding resource data has been obtained), and may obtain the resource url in the third resource data that is not traversed.

It should be noted that, in the case of using the extended query, the resource data corresponding to each resource url may include the resource data corresponding to one or more layers of sub-resource urls below the resource url. In this case, it is equivalent to that one or more layers of sub-resource url below the resource url have been traversed, so in one possible implementation, the sub-resource url in the resource data corresponding to the last layer of resource url may be extracted.

807. And the second thread filters the resource url which is not traversed in the third resource data according to the resource filtering table.

Specifically, because the Redfish device includes more resources (i.e., resource url), and some of the resources or resource url may not be considered by the service or the user, the second thread may filter the non-traversed resource url extracted from the third resource data through the resource filtering table (resource url white list, resource url black list, etc.), and may filter the resource url that is not considered by the service or the user, thereby reducing unnecessary processing and further improving efficiency of resource traversal.

The resource url white list (i.e. the resource link white list) may be a resource list set composed of the resources url of interest to the service or the user, where the resource list set may include a specific resource url, and may also include a resource url in a regular expression form. It should be appreciated that a particular resource url may match one particular resource, while a resource url in the form of a regular expression may match multiple particular resources with greater flexibility.

An example of a resource url whitelist is listed below:

{"/redfish/v1/systems/[^/]+/storages/[^/]+/？$":

"/redfish/v1/systems/[^/]+/storages/[^/]+/volumes/[^/]+/？$":

"/redfish/v1/systems/[^/]+/memory/[^/]+/？$":

"/redfish/v1/systems/[^/]+/processors/[^/]+/？$":}

wherein the resource url whitelist includes four regular expressions, [ ≡may represent all contents of not "/", and + may represent the previous contents at least once, and thus, [ ≡/] + may represent the contents of not "/", once or more. ? May indicate that the previous content appears at most once and therefore,/? It may be indicated that one "/", or none, is present. And $ is a locator, which can match the end position of the string.

For example, when the non-traversed resource url extracted from the third resource data includes "/refish/v 1/systems/1/memory/1" and the second thread matches it with the regular expression in the above-mentioned resource url whitelist, it can be determined that the resource url matches the above-mentioned regular expression "/refish/v 1/systems/[ ] +/memory/[/] +/? The second thread may determine that "/reconfish/v 1/systems/1/memory/1" is in the default resource url whitelist.

It will be appreciated that, for different Redfish devices, the resources url concerned by the user may be different, so in some embodiments, if the resources of the different Redfish devices need to be traversed, different whitelists of the resources url may be preset for the different Redfish devices, so that the resources url may be filtered more accurately, unnecessary processing may be avoided, and thus the efficiency of resource traversal may be improved.

The resource url blacklist (i.e. the resource link blacklist) can be a resource list set composed of resources url which are not concerned by business or users, wherein the resource list set can comprise specific resources url and also can comprise the resources url in the form of regular expression. In particular, since in a real scenario, some resources url may be business or not of interest to the user, processing these resources url consumes a large amount of processing resources of the computing device, resulting in waste of processing resources. Therefore, the second thread can filter the non-traversed resource url extracted from the third resource data through the resource url blacklist, and can filter the resource url which does not need to be processed, so that the processing resource of the computing device can be saved.

It will be appreciated that, for different Redfish devices, resources url that the user does not pay attention to may be different, so in some embodiments, if the resources of the different Redfish devices need to be traversed, different blacklists of resources url may be preset for the different Redfish devices, so that the resources url may be filtered more accurately, unnecessary processing may be avoided, and thus efficiency of resource traversal may be improved.

It should be appreciated that the resource url whitelist and the resource url blacklist may be used simultaneously, or one of them may be used.

808. And the second thread returns the filtered resource url in the third resource data and the filtered resource data in the third resource data to the scheduler of the resource data analysis module.

Specifically, after the second thread filters the extracted non-traversed resource url according to the resource filtering table, the filtered resource url may be returned to the scheduler of the resource data analysis module.

It should be noted that, in the case of using the extended query, the resource data corresponding to each resource url may include the resource data corresponding to one or more layers of sub-resource urls below the resource url. Therefore, the second thread can filter the resource data according to the resource filtering table, can filter the resource data corresponding to the resource url which is not concerned, extract the resource data corresponding to the url which is concerned by the service or the user, and can then return the resource data corresponding to the url which is concerned by the service or the user to the scheduler of the resource data analysis module. In the case that the extended query is not employed, the third resource data may be directly returned to the scheduler of the resource data analysis module without filtering.

809. The second thread marks the traversed resource url in the third resource data as processed.

Specifically, to avoid repeatedly traversing or processing the same resource url, the second thread may mark the traversed resource url in the third resource data as processed, so that when the resource url is later extracted from the resource data, the traversed resource url may be filtered out.

It should be understood that the traversed resource url in the third resource data is the resource url in the third resource data for which the corresponding resource data has been acquired. In the case that the extended query is not adopted, the traversed resource url in the third resource data can comprise one resource url, and the third resource data comprises resource data corresponding to the one resource url. In the case of using the extended query, the traversed resource url in the third resource data may include one or more resources, and the third resource data includes resource data corresponding to the one or more resource urls.

It should be noted that in some embodiments, the traversed (processed) resource url may be added to the traversed resource url table (i.e., the traversed resource link table). Thus, the extracted resource url may then be screened through the traversed resource url table.

810. The second thread becomes an idle thread.

After marking the traversed resource url in the third resource data as processed, the second thread can become an idle thread, and waits for a scheduler of the resource data analysis module to allocate other resource data to be processed.

811. The scheduler of the resource data analysis module sends the filtered resource url in the third resource data to the resource data acquisition module, and sends the filtered resource data in the third resource data to the resource data processing module.

After receiving the filtered resource url in the third resource data from the second thread, the scheduler of the resource data analysis module may return the filtered resource url in the third resource data to the resource data acquisition module, so that the resource data acquisition module may acquire the resource data of the Redfish device according to the resource url.

Similarly, after the scheduler of the resource data analysis module receives the filtered resource data in the third resource data from the second thread, the filtered resource data in the third resource data may be sent to the resource data processing module, so that the resource data processing module may further process the resource data. Correspondingly, the resource data processing module can receive the filtered resource data in the third resource data from the resource data analysis module, and then the resource data processing module can put the filtered resource data in the third resource data into the second resource data queue, and wait for a scheduler of the resource data processing module to be distributed to idle threads in the third thread pool for processing.

603. The computing device processes the resource data of the Redfish device.

After the computing device obtains the resource data of the Redfish device, the resource data of the Redfish device can be processed, for example, the resource data of the Redfish device is processed according to a service scene. In some embodiments, the computing device may perform data synchronization based on the acquired resource data, updating corresponding data in the database. In other embodiments, the computing device may perform a Redfish protocol normalization check based on the acquired resource data.

It should be noted that, when the computing device processes the resource data of the Redfish device, the thread pool may process the resource data corresponding to a plurality of different resource urls in parallel. In particular, the computing device may process the resource data in the third queue in parallel through the third thread pool. See fig. 9 for a more detailed description of step 603 and the resource data processing module. Fig. 9 is a schematic process flow diagram of a resource data processing module according to an embodiment of the present application. As shown in fig. 9, the process flow of the resource data processing module may include, but is not limited to, the following steps:

901. the computing device initializes a second resource data queue and a third thread pool.

Specifically, in order to improve the efficiency of the resource data processing, when the resource data processing module is started, the second resource data queue and the third thread pool may be initialized, i.e. the second resource data queue and the third thread pool may be created according to the configured thread pool size and the default queue length. Wherein the third thread pool may include a plurality of threads, and the plurality of threads may be used for processing different resource data (to-be-processed resource data) in the second resource data queue in parallel.

After creating the second resource data queue, the resource data processing module may wait to receive the resource data from the resource data analysis module, and then may add the received resource data (e.g., the filtered resource data in the third resource data) to the second resource data queue, waiting to be processed. It should be appreciated that the size of the third thread pool, the default queue length of the second resource data queue, may be pre-configured or may be configured to receive user input. It should be noted that, when the resource data processing module puts the filtered resource data in the third resource data into the second resource data queue, the resource data corresponding to each url (for example, the resource data corresponding to each url, sun Ziyuan url, etc. of the sub-resources) may be split, so that each element in the second resource data queue may include the resource data corresponding to one url of the resources.

902. The scheduler of the resource data processing module determines whether the second resource data queue is empty, and if the second resource data queue is not empty, step 903 is executed, and if the second resource data queue is empty, the scheduler may block and wait for the second resource data queue to be not empty, and then step 903 is executed.

After initializing the second resource data queue and the third thread pool, the scheduler of the resource data processing module may acquire resource data to be processed from the second resource data queue and then allocate the resource data to the idle thread in the third thread pool for processing.

Specifically, the scheduler of the resource data processing module may determine whether the second resource data queue is empty, if the second resource data queue is not empty, step 903 may be performed, if the second resource data queue is empty, which indicates that there is no resource data to be processed currently, blocking may occur, waiting for the resource data analysis module to send the resource data to be processed, and when the second resource data queue is not empty, step 903 may be performed again.

903. The scheduler of the resource data processing module obtains fourth resource data from the second resource data queue.

The scheduler of the resource data processing module may obtain the fourth resource data from the second resource data queue in case the second resource data queue is not empty. The second resource data queue may be a first-in first-out queue, and the fourth resource data may be resource data (i.e. resource data located at a head of the second resource data queue) that first enters the second resource data queue among all resource data in the second resource data queue.

904. The scheduler of the resource data processing module determines whether there is an idle thread in the third thread pool, and executes step 905 if there is an idle thread in the third thread pool, and may block and wait for the thread to be idle if there is no idle thread in the third thread pool, and then executes step 905.

Specifically, after the scheduler of the resource data processing module obtains the fourth resource data, it may determine whether there is an idle thread in the third thread pool, if there is an idle thread in the third thread pool, step 905 may be executed, if there is no idle thread in the third thread pool, which indicates that there is no currently available thread, and may block, wait for processing of other threads to complete, and then execute step 905.

905. The scheduler of the resource data processing module obtains the third thread from the third line Cheng Chizhong.

Specifically, in the case where there are free threads in the third thread pool, the scheduler of the resource data processing module may obtain the third thread from the third thread Cheng Chizhong and then allocate fourth resource data to the third thread for processing. The third thread may be any idle thread of the third thread Cheng Chizhong. It is understood that the idle thread in the third thread pool refers to a thread to which the resource data to be processed is not allocated by the scheduler of the resource data processing module, or a thread to which the resource data to be processed allocated by the scheduler of the resource data processing module has been processed.

It should be noted that, after the scheduler of the resource data processing module distributes the fourth resource data to the third thread in the third thread pool, if the third thread Cheng Chizhong still has an idle thread and the second resource data queue still has resource data to be processed, the scheduler of the resource data processing module may continue to acquire other resource data to be processed from the second resource data queue, and then distribute the acquired resource data to be processed to the idle thread in the third thread pool for processing. If there is no free thread in the third thread pool, the scheduler of the resource data processing module may wait for the processing of the other threads to complete, or if there is no resource data to be processed in the second resource data queue, the scheduler of the resource data processing module may wait for the resource data processing module to put new resource data to be processed into the second resource data queue.

It should be appreciated that in some embodiments, the scheduler of the resource data processing module may perform step 904 first, and when there are free threads in the third thread pool, step 902 and step 903 may be performed again according to the number of free threads. For example, when there are three idle threads and there are three resource data to be processed in the second resource data queue, three resource data of the first resource data queue head may be acquired from the second resource data queue for processing.

906. The third thread processes the fourth resource data.

Specifically, after the scheduler of the resource data processing module allocates the fourth resource data to the third thread, the third thread may process the fourth resource data, perform data synchronization, update the corresponding data in the database, or perform the Redfish protocol normalization check.

In the case where the third thread processes the fourth resource data for data synchronization, the third thread may extract the values of the respective attribute fields in the fourth resource data, and then may update the related data (i.e., newly added data, deleted data, modified data, etc.) in the database. For example, assuming that the fourth resource data is related data of the memory resource, the fourth resource data may include information such as a temperature of the memory (e.g., 30 ℃), a utilization rate of the memory (e.g., 50%), a health status of the memory (e.g., 'ok'), and the like. Therefore, when the third thread processes the fourth resource data, the related data of the memory stored in the current database can be updated, the temperature of the memory can be updated to 30 ℃, the utilization rate of the memory can be updated to 50%, and the health state of the memory can be updated to 'ok'. It should be understood that the database may be mysql, oracle, etc., or may be a cloud database, which is not limited herein.

It should be noted that, the state data of the Redfish device may be synchronized by performing resource traversal on the Redfish device, and the state data of the Redfish device may be stored in the database. The state data of the Redfish device may include state data of individual hardware devices in the Redfish device. For example, the temperature, humidity, voltage, current, etc. of the devices such as a processor, a memory, a hard disk, a power supply, etc. collected by the sensors such as a temperature sensor, a humidity sensor, a voltage sensor, a current sensor, etc. further, for example, the CPU temperature, the memory health status, the power consumption, the firmware information (such as firmware version) of each hardware device, etc. of the Redfish device. In addition, the data of virtual resources such as storage, network, virtual machine and the like in the Redfish device can be included. It will be appreciated that the state data of the Redfish device may include data for various resources specified in the Redfish protocol.

Under the condition that the third thread processes the fourth resource data and performs the Redfish protocol standardability check, the third thread can compare the fourth resource data with the standard defined data format, if the format and the like of the fourth resource data are the same as the standard defined data format, the fourth resource data can be determined to accord with the Redfish protocol standardability, and if the format and the like of the fourth resource data are different from the standard defined data format, the fourth resource data can be determined to not accord with the Redfish protocol standardability.

Specifically, for each resource of the Redfish device, there may be a corresponding schema file, where the schema file corresponding to each resource indicates a data format of the resource, and specifically may include: the resource includes an essential attribute field, an optional attribute field, and the like, and for each attribute field, a type of value, a value range, and the like are defined. Therefore, for each resource url, the resource data may be compared with the corresponding schema file, so as to determine whether the format of the resource url corresponds to the resource data conforms to the Redfish protocol specification. It should be understood that the format of each resource or the schema file corresponding to each resource url may be JSON format.

It should be noted that, when the resource data processing module processes the data in the second resource data queue, the resource data processing module may perform self-defined optimization for data processing, for example, batch processing (such as processing the resource data corresponding to multiple sub-resources under one resource together), data merging, and so on.

It will be appreciated that in some embodiments, the thread pool of the resource data acquisition module, the resource data parsing module, and the resource data processing module may each include one thread, and in this case, the three threads may be processed in parallel.

In the method flow, the Redfish resource traversal process is divided into three sub-steps of resource data acquisition, resource data analysis and resource data processing, and then the three sub-steps can be executed in parallel, and each sub-step also adopts a thread pool to work in parallel, so that the resource traversal process can be accelerated, and the resource traversal efficiency is improved. And when the resource data of the Redfish device is acquired, the resource data can be acquired in an expansion mode, so that the number of times of calling the interface of the Redfish device can be reduced. In addition, the resource data analysis module can filter the extracted resource url through the resource filtering table, and can filter the resource url which is not concerned by the service or the user, so that unnecessary resource traversal, processing and the like can be reduced, processing resources of the computing equipment can be saved, and traversal time can be shortened.

It should be noted that, the related information (i.e., the same information or similar information) and the related description in the above different embodiments may refer to each other.

It should be understood that the relevant steps in fig. 5, 6, 7, 8, and 9 may be performed by a computing device, but the application is not limited to this execution subject. For example, the relevant steps of fig. 5, 6, 7, 8, and 9 may also be performed by a chip, a system-on-chip, or a processor supporting the computing device to implement the method, or may be performed by logic modules or software capable of implementing all or part of the computing device functions.

Based on the above system architecture, please refer to fig. 10, fig. 10 is a schematic structural diagram of a computing device according to an embodiment of the present application. Wherein the computing device 1000 may comprise: a processor 1001, a communication interface 1002, and a memory 1003. The processor 1001, the communication interface 1002, and the memory 1003 may be connected to each other or connected to each other through a bus 1004.

By way of example, memory 1003 is used to store computer programs and data for computing device 1000, and memory 1003 may include, but is not limited to, random access memory (random access memory, RAM), read-only memory (ROM), erasable programmable read-only memory (erasable programmable read only memory, EPROM), or portable read-only memory (compact disc read-only memory, CD-ROM), etc. The communication interface 1002 is used to support communication by the computing device 1000, such as receiving or transmitting data.

By way of example, the processor 1001 may be a CPU, complex programmable logic device, general purpose processor, digital signal processor, application specific integrated circuit, field programmable gate array or other programmable logic device, transistor logic device, hardware component, or any combination thereof. A processor may also be a combination that performs a computational function, such as a combination comprising one or more microprocessors, a combination of a digital signal processor and a microprocessor, and so forth.

In one embodiment, the computing device 1000 may be the computing device, and the processor 1001 may be configured to read the program stored in the memory 1003, and execute the operations performed by the computing device or the components in the computing device in the method embodiments shown in fig. 5, fig. 6, fig. 7, fig. 8, and fig. 9, which are described above, and will not be described in detail herein.

It should be noted that the computing device 1000 shown in fig. 10 is merely an implementation of an embodiment of the present application, and in practical applications, the computing device 1000 may further include more or fewer components, which is not limited herein.

The present application also discloses a computer-readable storage medium having stored thereon instructions that, when executed, perform the method of the above-described method embodiments.

The present application also discloses a computer program product comprising instructions which, when executed, perform the method of the above-described method embodiments.

It will be apparent that the embodiments described above are only some, but not all, of the embodiments of the present application. Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application for the embodiment. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure. The terms "first," second, "" third and the like in the description and in the claims and drawings are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a series of steps or elements may be included, or alternatively, steps or elements not listed or, alternatively, other steps or elements inherent to such process, method, article, or apparatus may be included. It should be understood that the equal sign of the above condition judgment may be larger than one end or smaller than one end, for example, the above condition judgment for a threshold value being larger than, smaller than or equal to one end may be changed to the condition judgment for the threshold value being larger than or equal to one end or smaller than one end, which is not limited herein.

It is to be understood that only some, but not all, of the details relating to the present application are shown in the accompanying drawings. It should be appreciated that some example embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.

As used in this specification, the terms "component," "module," "system," "unit," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution. For example, a unit may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or being distributed between two or more computers. Furthermore, these units may be implemented from a variety of computer-readable media having various data structures stored thereon. The units may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., second unit data from another unit interacting with a local system, distributed system, and/or across a network).

The foregoing embodiments have been provided for the purpose of illustrating the technical solution and advantageous effects of the present application in further detail, and it should be understood that the foregoing embodiments are merely illustrative of the present application and are not intended to limit the scope of the present application, and any modifications, equivalents, improvements, etc. made on the basis of the technical solution of the present application should be included in the scope of the present application.

Claims

1. A method of resource traversal, comprising:

acquiring related information of equipment to be traversed;

based on the related information of the equipment to be traversed, at least one first resource link of the equipment to be traversed is obtained, and the at least one first resource link is ordered into a first queue;

processing the resource links in the first queue in a multithreading parallel processing mode to obtain at least one resource data of the equipment to be traversed;

and carrying out data processing on the at least one resource data.

2. The method according to claim 1, wherein the processing the resource link in the first queue by multithreaded parallel processing to obtain at least one resource data of the device to be traversed includes:

Carrying out parallel processing on the resource links in the first queue through a first thread pool to obtain at least one first resource data, and sequencing the at least one first resource data into a second queue;

the resource data in the second queue are processed in parallel through a second thread pool to obtain at least one second resource link and at least one second resource data, the at least one second resource link is ordered into the first queue, and the at least one second resource data is ordered into a third queue;

the data processing of the at least one resource data includes:

and carrying out parallel processing on the resource data in the third queue through a third thread pool.

3. The method of claim 2, wherein the first thread pool is used to obtain resource data of the device to be traversed; the second thread pool is used for analyzing the resource data of the equipment to be traversed to obtain non-traversed resource links and resource data to be processed; and the third thread pool is used for processing the resource data to be processed.

4. A method according to claim 2 or 3, wherein the parallel processing of the resource links in the first queue by the first thread pool to obtain at least one first resource data, and ordering the at least one first resource data into the second queue, comprises:

Obtaining a third resource link from the first queue, wherein the third resource link is a resource link of the first queue head;

acquiring a first thread from a first thread pool, wherein the first thread is any idle thread in the first thread pool;

and processing the third resource link through the first thread, acquiring resource data corresponding to the third resource link, and sequencing the resource data corresponding to the third resource link into a second queue.

5. The method of claim 4, wherein the obtaining the resource data corresponding to the third resource link comprises:

and acquiring the resource data corresponding to the third resource link in an expansion mode.

6. The method according to any one of claims 2-5, wherein the parallel processing of the resource data in the second queue by the second thread pool to obtain at least one second resource link and at least one second resource data, and ordering the at least one second resource link into the first queue, and ordering the at least one second resource data into a third queue, comprises:

acquiring third resource data from the second queue, wherein the third resource data is the resource data of the second queue head;

Acquiring a second thread from a second thread pool, wherein the second thread is any idle thread in the second thread pool;

and processing the third resource data through the second thread, analyzing the resource links which are not traversed in the third resource data and the resource data to be processed, sequencing the resource links which are not traversed in the third resource data into the first queue, and sequencing the resource data to be processed in the third resource data into a third queue.

7. The method of claim 6, wherein ordering the non-traversed resource links in the third resource data into the first queue comprises:

ordering resource links meeting a first condition in the resource links which are not traversed in the third resource data into the first queue; the first condition includes one or more of: the non-traversed resource links are in a preset resource link white list, and the non-traversed resource links are not in a resource link black list; the resource link whitelist includes one or more resource links, and the resource link blacklist includes one or more resource links.

8. The method according to claim 6 or 7, characterized in that the method further comprises:

And adding the traversed resource links in the third resource data into a traversed resource link table, wherein the traversed resource links in the third resource data are the resource links in the third resource data, which have acquired the corresponding resource data.

9. The method of any of claims 2-8, wherein the parallel processing of resource data in the third queue through a third thread pool comprises:

acquiring fourth resource data from the third queue, wherein the fourth resource data is the resource data of the third queue head;

acquiring a third thread from a third thread pool, wherein the third thread is any idle thread in the third thread pool;

and processing the fourth resource data through the third thread, and performing data synchronization and/or Redfish protocol standardability verification.

10. A computing device comprising a processor, a memory, and a communication interface for receiving information from and outputting information to other electronic devices than the computing device, the processor invoking a computer program stored in the memory to implement the method of any of claims 1-9.