Distributed computing power management system, distributed computing power management method and computing device

Abstract

This application provides a distributed computing power management system, a distributed computing power management method, and a computing device. It includes a registration node and multiple management nodes, including a first management node and at least one second management node. The first management node sends a registration request to the registration node. The registration node returns network endpoint information of currently registered second management nodes to the first management node and notifies the second management node of the network endpoint information of newly registered first management nodes. The first management node also establishes a communication connection with the second management node based on the network endpoint information of the second management node and synchronizes their respective total computing power resources with the established communication connection second management node. By constructing a decentralized distributed architecture, each management node can directly communicate with each other and share the total computing power resources after registration, achieving resource discovery and state synchronization, and improving the availability and robustness of the system.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a distributed computing power management system, a distributed computing power management method, and a computing device. Background Technology

[0002] Artificial intelligence, big data analytics, and edge intelligence applications typically involve massive data processing, complex model inference, or real-time response requirements. Their computational intensity far exceeds the processing power of general-purpose central processing units (CPUs). Therefore, in practical deployments, dedicated hardware devices are used to provide the necessary computing power. To achieve unified scheduling of these geographically dispersed and heterogeneous computing devices, the industry generally adopts a centralized architecture of "central platform + computing devices."

[0003] However, this centralized architecture has a significant single point of failure risk: once the central platform fails, the entire system will lose its scheduling and management capabilities, resulting in a global service interruption and severely impacting the system's availability and robustness. Summary of the Invention

[0004] This application provides a distributed computing power management system, a distributed computing power management method, and a computing device. By constructing a decentralized distributed architecture, it no longer relies on a single central platform for global scheduling and management. After completing registration, each management node can directly communicate with each other and share the total amount of computing power resources, thereby realizing resource discovery and state synchronization and improving the availability and robustness of the system.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a distributed computing power management system, which includes: a registration node and multiple management nodes, the multiple management nodes including a first management node and at least one second management node; the first management node is used to send a registration request to the registration node; the registration node is used to, upon receiving the registration request sent by the first management node, return the network endpoint information of the currently registered second management node to the first management node, and notify the second management node of the network endpoint information of the newly registered first management node; wherein, the network endpoint information is used to characterize the communication access address of the corresponding management node; the first management node is also used to establish a communication connection with the second management node based on the network endpoint information of the second management node, and synchronize the total computing power resources of each with the second management node with which the communication connection has been established.

[0006] Based on this scheme, by introducing a registration node and multiple management nodes (including a first management node and at least one second management node) to replace the traditional single central node, the management capabilities originally centralized in the central platform are distributed to each management node. After registering with the registration node, each management node can obtain each other's network endpoint information and directly establish a communication connection. Then, it can autonomously exchange the total computing power resources of the connected computing devices, realizing resource discovery, state synchronization, and collaborative scheduling. In this way, the architecture no longer relies on a single central node (central platform) for global scheduling and management. After completing registration, each management node can directly establish mutual communication, share the total computing power resources, realize resource discovery and state synchronization, and improve the availability and robustness of the system.

[0007] In one possible implementation, the first management node includes a resource consensus module, and the registration node includes a registration module. The resource consensus module is used to send a registration request for the first management node to the registration module. The registration request includes the identity identifier and network endpoint information of the first management node. The registration module is used to authenticate the first management node based on the identity identifier and pre-stored legitimate nodes, and determine that the first management node's identity authentication is successful if the identity identifier matches the pre-stored legitimate node information and is not marked as invalid or revoked. If the first management node's identity authentication is successful, the module sends the network endpoint information to the resource consensus module of the second management node. The module also returns the network endpoint information of the currently registered second management node to the resource consensus module.

[0008] Based on this scheme, a resource consensus module is set up in the first management node to send a registration request containing its own identity and network endpoint information to the registration module of the registration node. Correspondingly, a registration module is set up in the registration node to authenticate the identity. This identity authentication mechanism ensures that only legitimate first management nodes that have not been marked as invalid or revoked can successfully join the distributed computing power management system, thereby preventing unauthorized management nodes from accessing the system and ensuring its security and trustworthiness. After authenticating the first management node, the registration module not only returns the network endpoint information of other registered second management nodes to the first management node but also proactively notifies existing second management nodes of the network endpoint information of newly added nodes, thus achieving a bidirectional, real-time node discovery mechanism. This enables bidirectional, real-time discovery between new and existing nodes, facilitating communication and resource sharing among subsequent nodes. It allows management nodes at the same level to promptly perceive each other's existence, laying the foundation for subsequent autonomous communication connections, collaborative scheduling, and resource sharing, significantly improving the system's collaborative efficiency.

[0009] In another possible implementation, the resource consensus module is further configured to send and receive neighbor probe messages with the resource consensus module of the second management node; wherein the neighbor probe message carries the network endpoint information of the corresponding first management node; the resource consensus module is further configured to query the neighbor list in response to the neighbor probe message sent by the second management node to determine the existence status of the second management node; wherein the existence status is used to characterize the connection status between the second management node and the first management node; the resource consensus module is further configured to establish a communication connection with the second management node when the existence status indicates that the network endpoint information of the second management node does not exist in the neighbor list; wherein the neighbor list is used to record the network endpoint information of the second management node that has established a communication connection with the first management node.

[0010] Based on this scheme, by sending and receiving neighbor probe messages carrying network endpoint information between the resource consensus modules of each management node, and combining this with the locally maintained neighbor list for dynamic comparison and connection management, proactive awareness and adaptive maintenance of the communication status between management nodes are achieved. This enhances the real-time performance and consistency of the topology relationships between nodes, as well as the connection stability and resource coordination reliability under dynamic joining, leaving, or network fluctuation scenarios, thereby improving the system's availability and robustness.

[0011] In another possible implementation, the first management node further includes a device access module and a resource management module; the device access module is used to connect to at least one computing power device, and when any computing power device is detected to be online, it obtains the computing power resource information of the computing power device and reports it to the resource management module; the resource management module is used to update the total computing power resource of the first management node based on the computing power resources of the computing power device, and send the total computing power resource to the resource consensus module.

[0012] Based on this scheme, the first management node, through the collaborative work of the device access module, resource management module, and resource consensus module, achieves automatic access of computing devices and efficient dynamic maintenance and synchronization of local resource status. In this way, each management node can autonomously perceive and integrate the total computing resources of the first management node, improving the overall collaborative efficiency of the system.

[0013] In another possible implementation, the resource consensus module is used to send and receive resource status announcement messages with the resource consensus module of the second management node, and forward the resource status announcement messages of the second management node to the resource management module; wherein, the resource status announcement message includes the total computing power resources of the second management node; the resource management module is also used to parse the resource status announcement messages sent by the resource consensus module of the second management node, extract the total computing power resources of the second management node contained therein, and store the total computing power resources of the second management node in a local database.

[0014] Based on this scheme, the first management node achieves efficient synchronization of cross-node resource information through the collaborative work of the resource management module and the resource consensus module. In this way, each management node can continuously acquire and maintain a global computing power view of other management nodes without centralized coordination, thereby providing accurate and real-time resource information for distributed task scheduling and significantly improving the overall collaborative efficiency of the system.

[0015] In another possible implementation, the resource consensus module is also used to send and receive resource request messages with the resource consensus module of the second management node, and report the received resource request messages to the resource management module; wherein, the resource request message includes resource identification information of the computing power resources to be allocated; the resource management module is used to query the total amount of computing power resources based on the resource identification information, and perform computing power resource allocation processing based on the query results, and update the total amount of computing power resources; the resource consensus module is also used to synchronize the updated total amount of computing power resources to the resource consensus module of the second management node.

[0016] Based on this scheme, a resource consensus module and a resource management module are set up in each management node. The resource consensus module is responsible for receiving and forwarding cross-node resource request messages and status synchronization information, while the resource management module queries the total local computing power resources based on the request content, performs resource allocation processing after obtaining the resource status, and updates the local total resource amount. In this way, through the close cooperation between the resource consensus module and the resource management module, each management node can efficiently and accurately coordinate and process cross-node resource requests and synchronize resource status in a decentralized architecture, avoiding resource conflicts or duplicate allocation, and realizing the coordinated utilization of computing power resources.

[0017] In another possible implementation, the resource consensus module is used to send and receive resource release messages with the resource consensus module of the second management node, and report the received resource release messages to the resource management module; wherein, the resource release message includes resource identification information of the computing power resources to be released; the resource management module is also used to query the total amount of computing power resources based on the resource identification information, and perform the release processing of computing power resources based on the query results, and update the total amount of computing power resources; the resource consensus module is also used to synchronize the updated total amount of computing power resources to the resource consensus module of the second management node.

[0018] Based on this scheme, the resource consensus module receives and reports resource release messages. The resource management module verifies the local holding status based on the resource identifier information in the message, performs resource release, and updates the local status. Then, the resource consensus module synchronizes the updated computing power resource status to the second management node. In this way, each management node can complete the release operation in a timely and accurate manner after the computing power resources are used up and synchronize the status to other nodes, ensuring the consistency of the global resource view. This effectively avoids resource leakage or misallocation caused by status asynchrony or release failure, further enhancing the availability and robustness of the system.

[0019] In another possible implementation, the first management node also includes a device management module; the device management module is used to perform lifecycle management on the computing devices connected through the device access module; wherein, lifecycle management includes device registration, status monitoring, configuration update, fault handling and offline recycling.

[0020] Based on this solution, by setting up a device management module in the first management node, full lifecycle management (including device registration, status monitoring, configuration updates, fault handling and offline recycling, etc.) can be implemented for computing power devices connected through the device access module, thereby achieving refined and automated control of underlying computing power resources.

[0021] Secondly, embodiments of this application provide a distributed computing power management method applied to a registration node of a distributed computing power management system. The distributed computing power management method includes: receiving a registration request sent by a first management node; returning network endpoint information of a currently registered second management node to the first management node; and sending the network endpoint information of the currently registered second management node to the second management node; wherein the network endpoint information is used to characterize the communication access address of the corresponding management node.

[0022] In one possible implementation, the first management node is authenticated based on its identity identifier and pre-stored legitimate nodes. If the identity identifier matches the pre-stored legitimate node information and is not marked as invalid or revoked, the first management node is determined to be successfully authenticated. If the first management node is successfully authenticated, network endpoint information is sent to the resource consensus module of the second management node. The network endpoint information of the currently registered second management node is returned to the resource consensus module.

[0023] Thirdly, embodiments of this application provide a distributed computing power management method, applied to a first management node among multiple management nodes in a distributed computing power management system. The distributed computing power management method includes: sending a registration request to a registration node; the first management node receiving network endpoint information of a currently registered second management node sent by the registration node; establishing a communication connection with the second management node based on the network endpoint information of the second management node, and sending its total computing power resources to the second management node. In one possible implementation, establishing a communication connection with the second management node based on the network endpoint information of the second management node includes: responding to a neighbor probe message sent by the second management node, querying a neighbor list to determine the existence status of the second management node; wherein the neighbor probe message carries the network endpoint information of the corresponding second management node; and establishing a communication connection with the second management node if the existence status indicates that the network endpoint information of the second management node does not exist in the neighbor list; wherein the neighbor list is used to record the network endpoint information of the second management node currently establishing a communication connection with the first management node.

[0024] In another possible implementation, it also includes: responding to the second management node sending a resource announcement message; wherein the resource announcement message includes the total computing power resources of the first management node; and storing the total computing power resources of the first management node in a local database.

[0025] Fourthly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to run the distributed computing power management system as described in the first aspect and the method of the second aspect.

[0026] Fifthly, embodiments of this application provide a chip for running the distributed computing power management system as described in the first aspect and the method of the second aspect.

[0027] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which are used by a computer to run the distributed computing power management system as described in the first aspect and the method of the second aspect.

[0028] In a seventh aspect, embodiments of this application provide a program product including a computer program that is processed to run the distributed computing power management system as described in the first aspect and the method of the second aspect. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of a distributed computing power management system provided in an embodiment of this application; Figure 2This is a schematic diagram of the internal module framework of the distributed computing power management system provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the allocation of computing resources in a resource management module according to an embodiment of this application; Figure 4 This is a first flowchart illustrating a distributed computing power management method provided in an embodiment of this application; Figure 5 This is an interactive schematic diagram of a distributed computing power management method provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating a process for establishing a communication connection between management nodes, provided in an embodiment of this application. Figure 7 This is a schematic flowchart of a method for synchronizing computing resource information provided in an embodiment of this application; Figure 8 This is a schematic flowchart of a computing resource scheduling method provided in an embodiment of this application; Figure 9 This is an interactive schematic diagram of a computing resource scheduling method provided in an embodiment of this application; Figure 10 This is a schematic flowchart of a method for releasing computing resources provided in an embodiment of this application; Figure 11 This is an interactive schematic diagram of a method for releasing computing resources provided in an embodiment of this application; Figure 12 This is a second flowchart illustrating a distributed computing power management method provided in an embodiment of this application; Figure 13 This is a third flowchart illustrating a distributed computing power management method provided in an embodiment of this application; Figure 14 This is a fourth flowchart illustrating a distributed computing power management method provided in an embodiment of this application; Figure 15 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

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

[0031] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of this application.

[0032] It should be noted that many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

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

[0034] Computing power resources are the sum of hardware and software capabilities used to perform computing tasks. They mainly include processors, such as graphics processors, memory, storage, network bandwidth, and system software that schedules and manages these resources (such as operating systems, virtualization platforms, container engines, resource schedulers, etc.). Essentially, it is the ability to complete computing operations per unit of time.

[0035] Computing power devices refer to hardware entities with computing capabilities, such as servers, personal computers, smartphones, edge computing nodes, or embedded devices. Their core function is to perform data processing and computation tasks using resources such as processors (CPU / GPU / NPU, etc.), memory, and storage. In centralized architectures, most computing power devices exist as edge nodes. Although they possess local computing resources, they are typically only responsible for input / output, request initiation, or lightweight preprocessing, while core computing, decision-making, and data management are handled by the central node. Computing power devices can be divided into two categories: IT Nodes, which can include computing devices, storage devices, and switches, primarily used for data processing and communication within data centers; and non-IT Nodes, which can include industrial control computers, charging stations, and other operational technology (OT) objects.

[0036] A centralized architecture is a form of organization for a system or network. Its core characteristic is that all key functions, control logic, or data processing are concentrated in a central node. Other nodes (such as clients, terminal devices, etc.) are mainly responsible for requesting services or displaying results, and do not have the ability to make independent decisions or handle core business.

[0037] The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] With the rapid development of artificial intelligence, big data analysis and real-time interactive applications, a single computing device can no longer cope with increasingly complex and high-load business scenarios, and multiple devices need to work together. To this end, this application proposes a distributed computing power management system. Before the collaborative scheduling of computing power resources is required, registration and communication connection need to be established to support the dynamic discovery, autonomous registration and collaborative scheduling of computing power resources.

[0039] The following combination Figure 1 The embodiments of this application are illustrated in the diagram.

[0040] Figure 1 This is a schematic diagram of a distributed computing power management system provided in an embodiment of this application.

[0041] like Figure 1 As shown, the distributed computing power management system 100 includes a registration node 101 and multiple management nodes 102 (not shown in the figure). The multiple management nodes 102 include a first management node 102A and at least one second management node 102B. For example, there are second management nodes 102B1, 102B2, and 102B3 (not shown in the figure). The first management node 102A represents a newly added management node to the distributed computing power management system 100, while the second management nodes 102B represent existing management nodes that have completed registration in the distributed computing power management system 100 and established communication connections with each other. Specifically, the first management node 102A is used to send a registration request to the registration node; the registration node 101 is used to return the network endpoint information of the currently registered second management node 102B to the first management node 102A after receiving the registration request sent by the first management node 102A, and to notify the second management node 102B of the network endpoint information of the newly registered first management node 102A; the first management node 102A is also used to establish a communication connection with the second management node 102B based on the network endpoint information of the second management node 102B, and to synchronize the total amount of computing resources of each of the two nodes with the established communication connection.

[0042] In summary, by constructing a decentralized distributed architecture, management nodes no longer rely on a single central platform for global scheduling and management. This enables low-latency, highly stable computing resource collaboration. After registration, management nodes can communicate directly point-to-point, sharing the total amount of computing resources, achieving resource discovery and synchronization. This architecture supports both dedicated and non-dedicated network lines, and nodes do not need to rely on consensus algorithms to maintain global resource consistency. Thus, through point-to-point network topology design, high efficiency in resource scheduling, low communication latency, and simplified maintenance are achieved, while simultaneously improving system availability and robustness.

[0043] To better illustrate the operation of a distributed computing power management system in practical applications, the following will combine... Figure 2 As shown, this application uses one registration node and four management nodes as an example within the aforementioned distributed decentralized framework. The four management nodes include a newly joined first management node and three second management nodes that have completed registration and established communication connections. By providing an illustrative description of their internal modules, the registration, communication, and computing resource synchronization processes between the nodes can be understood more intuitively.

[0044] Figure 2 This is a schematic diagram of the internal module framework of the distributed computing power management system provided in the embodiments of this application.

[0045] like Figure 2 As shown, the registration node 101 can function as a hub node for centralized management and coordination. In this embodiment, the registration node 101 is used to register multiple management nodes. Further, the registration node 101 may include a registration module 1011, which receives a registration request from a management node (such as the first management node 102A) and registers the management node (such as the first management node 102A) accordingly.

[0046] The internal modules of the first management node 102A are the same as those of each of the second management nodes (including 102B1, 102B2, and 102B3). The following explanation uses the first management node 102A as an example. It should be noted that... Figure 2 This application only illustrates one interaction method and is not limited to it. The first management node 102A can also interact with the second management node 102B3.

[0047] The first management node 102A may include multiple functional modules such as a device access module 1021, a resource management module 1022, a resource consensus module 1023, a device management module 1024, and a software deployment module 1025. These modules work collaboratively to achieve core functions such as accessing, managing, scheduling, and deploying computing resources. The device access module 1021 is used to discover and manage computing devices. It can actively scan or passively listen to identify computing devices manageable by the first management node 102A, then authenticate the identified devices, and finally include them in its local management scope. Simultaneously, the first management node 102A can assess the capabilities of the computing devices based on their hardware specifications (such as central processing unit, graphics processing unit, memory, and storage) and report this assessment to the resource management module 1022.

[0048] The resource management module 1022 is used to provide users with computing, storage, and network resources. The resource management module 1022 can uniformly manage the resources of at least one computing device connected to the first management node 102A. The resource management module 1022 can classify and divide the resources of these computing devices in the form of resource pools.

[0049] Figure 3 This is a schematic diagram illustrating the allocation of computing resources in a resource management module provided in an embodiment of this application.

[0050] like Figure 3 As shown in (a) above, the resource management module 1022 can divide resources according to the type of computing power equipment. For example, resource pools can be divided into server resource pools, storage volume resource pools, IP address resource pools, switch resource pools, etc. Figure 3 As shown in (b), the resource management module 1022 can also divide resources into two main categories: local resource pool and other regional resource pools. For example, local resource pool, other resource pool 2 and other resource pools. Among them, other resource pool 2 and other resource pool 3 include the local resource pools corresponding to the two second management nodes.

[0051] The resource consensus module 1023 is used in a geographically distributed network to coordinate and synchronize the resource status among different management nodes. Resource coordination ensures that management nodes can efficiently and accurately collaborate on resource requests and release operations. Status synchronization, through periodic or event-driven methods, synchronizes the local resource status updates of each management node to the entire network, ensuring that all management nodes reach a consensus on the final state of the network's resources. Based on this, all management nodes can maintain a unified understanding of the final state of the network's computing power resources, thereby supporting the resource management module 1022 in maintaining a globally consistent resource view.

[0052] The device management module 1024 can provide lifecycle management functions for the connected computing devices, including device registration, status monitoring, configuration updates, fault handling and offline recycling of computing devices, and provide usable physical computing resources for the resource management module 1022.

[0053] Device registration refers to the process by which the device management module 1024 registers the computing power device after it is connected, thus incorporating it into the unified management of the distributed computing power management system. During registration, the basic information and relevant operating parameters of the computing power device are recorded, and a corresponding device identifier is assigned to it. This allows the distributed computing power management system to uniquely identify and subsequently manage the device. The basic information and operating parameters characterize the hardware capabilities, operating characteristics, or access status of the computing power device for subsequent computing resource management.

[0054] Status monitoring refers to the continuous or periodic monitoring of the operating status of registered computing devices by the device management module 1024 to obtain the current working status and availability of the computing devices. The operating status includes the online status, operating load or resource usage of the computing devices. In addition, the operating status also includes status information such as whether the computing devices are operating abnormally or whether their performance has degraded. Through status monitoring, the distributed computing power management system can promptly perceive changes in the status of computing devices, providing a basis for subsequent computing power resource scheduling.

[0055] Configuration update refers to the device management module 1024 issuing configuration adjustment instructions to the connected computing devices to update the operating configuration of the computing devices according to operating requirements or management strategies. The operating configuration may include the operating parameters, resource usage, or related software configuration of the computing devices.

[0056] Fault handling refers to the process by which the device management module 1024 performs corresponding processing operations on the computing power device when it detects an abnormal state during status monitoring. These processing operations may include triggering alarms, isolating or restricting the abnormal computing power device from participating in computing power scheduling, and performing recovery operations when conditions are met, thereby ensuring the overall stability of the distributed computing power management system.

[0057] Offline recycling refers to the process by which the device management module 1024 removes a computing power device from the distributed computing power management system when the device no longer meets the usage conditions or is taken out of service. This process includes severing the association between the computing power device and the distributed computing power management system, and removing the computing power resources provided by the device from the total computing power resources corresponding to the management node, thereby avoiding the scheduling of resources from unusable computing power devices.

[0058] The software deployment module 1025 can apply to the resource management module 1022 for computing power resources from local or other management nodes (second management nodes), install different software on the corresponding computing power devices, perform relevant configurations, and build corresponding infrastructure services, middleware services, and AI services, such as bare metal, virtual machines, container clusters, databases, AI inference, etc.

[0059] In summary, the device access module 1021 can actively scan IT Node devices or passively monitor non-IT Node devices to determine whether a computing power device is connected to the first management node 102A. Next, the device access module 1021 assesses the computing power capabilities of the connected computing power devices and reports the assessment results to the resource management module 1022. Simultaneously, the device management module 1024 is responsible for implementing full lifecycle management of these computing power devices on the first management node 102A, while the software deployment module 1025 installs the appropriate software on the corresponding computing power devices and completes the relevant configurations according to resource requirements to support task execution.

[0060] The following describes a specific embodiment of the distributed computing power management method of the distributed computing power management system with reference to the accompanying drawings.

[0061] Figure 4 This is the first flowchart of a distributed computing power management method provided in the embodiments of this application.

[0062] like Figure 4 As shown, the distributed computing power management method is applied to the aforementioned distributed computing power management system, and the method includes the following steps: S1: The first management node determines its total computing resources.

[0063] The first management node can include a total local computing power resource and a total shared computing power resource. The total local computing power resource is the total computing power resource of the first management node itself; the total shared computing power resource is the total computing power resource from other management nodes.

[0064] Figure 5 This is an interactive schematic diagram of a distributed computing power management method provided in an embodiment of this application.

[0065] like Figure 5 As shown, step S1 includes steps S1001-S1002.

[0066] S1001: When the device access module of the first management node detects that any computing power device is online, it obtains the computing power resources of the computing power device and reports them to the resource management module.

[0067] When the device access module detects that any computing power device is online, it will obtain the computing power resources of that computing power device, such as processor type, memory capacity, storage space and network capabilities, and report them to the resource management module.

[0068] For example, the device access module detects that a computing power device M1 has come online and uploads the computing power resource M2 of the computing power device to the resource management module.

[0069] S1002: The resource management module of the first management node updates the total amount of computing resources of the first management node based on the computing resources of the computing devices, and sends the updated total amount of computing resources to the resource consensus module.

[0070] The resource management module can connect to a local database storing computing resources, enabling it to read and schedule computing resource data from the database. Whenever a new computing device connects to the system, the resource management module must include that device's computing resources in its own current total computing resources, thus dynamically updating the total computing resources of the management node. Its own total computing resources are the directly accessible computing resources managed by that management node (the first management node).

[0071] Continuing with the example above, at a certain moment, the total computing power resources of the first management node already include the total computing power resources of the three connected computing power devices. When a new computing power device (whose resource information is denoted as M2) goes online and is reported, the resource management module integrates M2 into the existing state to form an updated total computing power resources covering the computing power resources of the four devices, and immediately synchronizes the updated total computing power resources to the resource consensus module.

[0072] It should be noted that after updating the total amount of computing power resources and synchronizing the latest information with the resource consensus module, in order to formally incorporate the newly added computing power devices into the unified management and scheduling system of the entire system, the first management node needs to further initiate a registration request to the registration node in the system. The following will continue to explain in conjunction with step S2.

[0073] S2: The first management node sends a registration request to the registration node.

[0074] Continue as Figure 5 As shown, step S2 includes step S1003.

[0075] S1003: The resource consensus module of the first management node sends a registration request to the registration module of the registration node.

[0076] In one example, the registration module includes a built-in central coordinator that listens for registration requests from different management nodes. Once a request is received, the central coordinator initiates a series of verification and processing procedures, such as verifying the identity of the management node.

[0077] The registration request is used to characterize the current operating status of the management node initiating the registration and its available service capabilities. Specifically, the registration request may include the identity identifier and network endpoint information of the first management node. The network endpoint information characterizes the communication access address of the corresponding management node; the network endpoint information includes a public IP address and the corresponding communication port. The identity identifier of the first management node is used to uniquely identify the management node. It can be a system-assigned unique name, such as "node-001"; it can also be a non-repeatable code, such as a Universally Unique Identifier (UUID); it can be a device serial number; or a hash value generated from the node key, etc. A public IP address is a globally unique IP address on the Internet that can be publicly routable. Unlike private IP addresses (such as 192.168.xx, 10.xxx, etc.) which are only valid within a local area network, public IP addresses are uniformly assigned by Internet Assigned Numbers Authorities (such as IANA, Regional Internet Registries) and can be directly accessed and communicated with by other devices worldwide. In a distributed computing power management system, the management node reports its public IP address so that registered nodes or other peer nodes can establish connections with it via the Internet. A port is a logical identifier in network communication used to distinguish different applications or services on the same computing device. In the TCP / IP protocol, ports are used in conjunction with IP addresses to form a complete network communication address (i.e., "IP address:port"), ensuring that data is accurately delivered to the target computing device.

[0078] For example, the resource consensus module of the first management node sends a registration request M3 to the registration module of the registration node.

[0079] S3: After receiving the registration request from the first management node, the registration node performs identity authentication on the first management node.

[0080] Continue to combine Figure 5 As shown, step S3 includes step S1004.

[0081] S1004: The registration module of the registration node performs identity authentication on the first management node based on the identity identifier.

[0082] Optionally, the registration module authenticates the first management node based on an identity identifier and an authentication policy. The authentication policy can include at least one of the following: authentication based on the identity identifier and a pre-stored list of legitimate nodes, authentication based on a digital certificate, authentication based on a signing key, or authentication based on an access control policy. For example, if authentication is based on the identity identifier and a pre-stored list of legitimate nodes, the registration module of the registration node will compare the identity identifier (such as "node-001", UUID, or device serial number, etc.) submitted by the first management node in the registration request with a pre-configured or dynamically maintained whitelist of legitimate nodes in the system. If the identity identifier exists in the list of legitimate nodes and is not marked as invalid or revoked, the authentication is considered successful; otherwise, the authentication is considered to have failed, and the subsequent registration process is terminated.

[0083] Continuing with the example above, assuming the identity of the first management node is node-001, if it matches the identity of node-001 in the pre-stored list of valid nodes, it means that the first management node has been successfully authenticated; otherwise, it means that the first management node has failed to be authenticated.

[0084] S4: If the identity authentication of the first management node is successful, the registration module of the registration node sends network endpoint information to the resource consensus module of the second management node; and returns the network endpoint information of the currently registered second management node to the resource consensus module.

[0085] Continue to combine Figure 5 As shown, step S4 includes steps S1005-S1006.

[0086] S1005: If the first management node successfully authenticates its identity, the registration module of the registration node sends the network endpoint information of the first management node to the resource consensus module of the second management node.

[0087] Continuing with the example above, assume the first management node's identity is node-001, its public IP address is 203.0.113.10, and its communication port is 8080. Then, the network endpoint information of this first management node can be represented as M4 = {"identity": "node-001", "public_ip":"203.0.113.10","port":8080}. After confirming successful authentication of the first management node, the registration module of the registration node sends the network endpoint information M4 to one or more registered second management nodes in the system (e.g., existing management nodes node-002, node-003, etc.). The resource consensus modules of these second management nodes receive and store the network endpoint information M4 to facilitate subsequent communication and resource coordination with newly joined first management nodes.

[0088] S1006: The registration module of the registered node returns the network endpoint information of the currently registered second management node to the resource consensus module of the first management node.

[0089] Continuing with the example above, assume there are two registered second management nodes in the system. For instance, the network endpoint information for second management node node-002 is M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081}. The network endpoint information for second management node node-003 is M4-3={"identity":"node-003","public_ip":"203.0.113.12","port":8082}. The registration module of the registered node returns the set of network endpoint information M4'=[M4-2 M4-3] for these two second management nodes to the resource consensus module of the first management node. After receiving the network endpoint information M4', the first management node stores it in its local database (resource management module) for subsequent communication and task allocation with other management nodes.

[0090] After the newly added first management node is fully registered, a communication connection is then established between the first management node and at least one second management node. The following explanation will continue using a second management node as an example.

[0091] S5: The first management node establishes a communication connection with the second management node based on the network endpoint information of the second management node.

[0092] Figure 6 This is a schematic diagram illustrating a process for establishing a communication connection between management nodes, provided in an embodiment of this application.

[0093] like Figure 6As shown, step S5 includes steps S51-S52.

[0094] S51: The first management node and the second management node send and receive neighbor probe messages to each other.

[0095] Continue to combine Figure 5 As shown, step S51 includes step S1007.

[0096] S1007: The resource consensus module receives the neighbor probe message sent by the resource consensus module of the second management node.

[0097] Neighbor probe messages are lightweight probe packets used to exchange node identity and reachability information, and carry the network endpoint information of the sender (e.g., the first management node). For example, this network endpoint information can be represented as: M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081}.

[0098] Continuing with the example above, after the first management node completes registration, the resource consensus module of the second management node sends a neighbor probe message (e.g., M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081}) to the resource consensus module of the first management node.

[0099] It should be noted that the above description of the first management node as the receiver of neighbor probe messages is merely illustrative; in reality, the first management node can also act as the sender, sending neighbor probe messages to the resource consensus module of the second management node. The roles of the two parties can be dynamically interchanged according to the actual network topology and runtime state, and this solution does not impose specific limitations on this.

[0100] S52: The first management node responds to the neighbor probe message sent by the second management node, queries the neighbor list, and determines the existence status of the second management node.

[0101] The neighbor list records the network endpoint information of the second management node that has established a communication connection with the first management node. The presence status characterizes the connection status between the second and first management nodes; presence indicates a connection has been established, while absence indicates no connection has been established. Continuing with the example above, when the resource consensus module of the first management node receives a neighbor probe packet carrying network endpoint information (e.g., M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081}), it immediately checks the neighbor list to see if a corresponding entry exists, i.e., the presence status.

[0102] It should be noted that the neighbor list is only an exemplary term used to refer to the data structure that records the network endpoint information of the second management node that has established a communication connection with the first management node. In actual implementation, this data structure may also be called an adjacency table, peer node registry, connection node cache, or other names with similar functions, and no specific limitation is made here.

[0103] Continue to combine Figure 5 As shown, step S52 includes step S1008 or S1009.

[0104] S1008: If the network endpoint information of the second management node already exists in the state indicator neighbor list, the resource consensus module of the first management node maintains the communication connection with the resource consensus module of the second management node.

[0105] Continuing with the example above, if the network endpoint information of the second management node already exists in the neighbor list, when the resource consensus module finds an entry such as M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081} in the neighbor list, it considers the second management node to be online and the connection to be valid, and updates its last communication time or heartbeat status accordingly to maintain the communication connection with the resource consensus module of the second management node.

[0106] S1009: If the network endpoint information of the second management node does not exist in the neighbor list, store the network endpoint information of the second management node in the neighbor list, and establish a communication connection with the second management node based on the network endpoint information.

[0107] Continuing with the previous example, if the network endpoint information of the second management node already exists in the neighbor list, and the resource consensus module does not find an entry like M4-2={"identity":"node-002","public_ip":"203.0.113.11","port":8081} in the neighbor list, then it determines that the second management node is a newly discovered management node. At this time, the resource consensus module adds the network endpoint information shown in M4-2 to the neighbor list and initiates a connection request based on the IP address and port in the network endpoint information to establish a bidirectional communication link with the resource consensus module of the second management node.

[0108] After establishing communication connections between management nodes, it is necessary to synchronize the local computing resource status between management nodes to achieve cross-node resource coordination and scheduling. The following example, using step S6, provides an illustration.

[0109] S6: The first management node synchronizes its total computing resources with the second management node, which has established a communication connection.

[0110] The total computing power resource refers to the computing capacity of the corresponding management node. The total computing power resource includes idle resources and occupied resources. Idle resources indicate computing capacity that has not yet been allocated or occupied, and can be used to receive and allocate new computing power resource requests. Occupied resources indicate computing capacity that has been allocated or is currently in use, reflecting the resource status of the management node that has been occupied by tasks.

[0111] Figure 7 This is a schematic diagram of a method for synchronizing computing resource information provided in an embodiment of this application.

[0112] like Figure 7 As shown, the method for synchronizing computing resource information includes the following steps: S61: The first management node and the second management node send and receive resource status announcement messages to each other.

[0113] Continue to combine Figure 5 As shown, taking the first management node receiving the resource status notification message from the second management node as an example, step S61 includes step S1010.

[0114] S1010: The resource consensus module of the first management node receives the resource status announcement message sent by the resource consensus module of the second management node.

[0115] The resource state advertisement (RSA) message includes the total amount of computing resources, such as the total storage capacity of the number of connected computing devices.

[0116] Continuing with the example above, when the resource consensus module of the second management node sends a resource status announcement message M5 to the first management node (such as carrying the total computing power resources of the second management node M5').

[0117] It should be noted that the above description of the first management node as the receiver of resource status announcement messages is merely illustrative; in reality, the first management node can also act as the sender, sending resource status announcement messages to the resource consensus module of the second management node. The roles of the two parties can be dynamically interchanged according to the actual network topology and runtime state, and this solution does not impose specific limitations on this.

[0118] S62: The first management node sends its total computing resources to the second management node with which a communication connection has been established.

[0119] Continue to combine Figure 5As shown, step S62 includes steps S1011-S1012.

[0120] S1011: The resource consensus module of the first management node forwards the resource status announcement message to the resource management module of the first management node.

[0121] Continuing with the example above, after the resource consensus module of the first management node receives a resource status announcement message (e.g., M5) carrying the total computing power resources of the second management node, it will completely transmit the message to the resource management module of the same first management node, so that the resource management module can know the resource status of the peer node in a timely manner, providing a foundation for subsequent global resource view construction, task scheduling or load coordination.

[0122] S1012: The resource management module of the first management node parses the resource status announcement message sent by the resource consensus module of the second management node, extracts the total computing power resources of the second management node contained therein, and stores the total computing power resources of the second management node in the local database.

[0123] Continuing with the example above, when the resource management module receives the resource status notification message M5 forwarded by the resource consensus module, it will parse its content to obtain the current total computing power resources of the second management node, i.e., M5'. Furthermore, the resource management module will use this information as the latest resource status of the second management node and write or update the corresponding record in the local database.

[0124] It should be noted that the above process is executed symmetrically on the second management node side: the resource management module of the second management node also receives and parses the resource status notification message from the first management node, extracts the local computing power resource status of the first management node, and updates it to its own local database. Thus, by exchanging and processing resource status notification messages, both parties achieve bidirectional synchronization of computing power resource information and consistency of the global view.

[0125] It should be noted that this application uses the total amount of synchronous computing resources as an example for illustration, but this application is not limited to this. The resource consensus module can send computing resource information, which may include the total amount of computing resources, or any one or more of the following indicators: the number of connected computing devices, the processor type of each device, available memory, storage capacity, network bandwidth, etc., without making a unique limitation here.

[0126] In summary, by constructing a decentralized distributed architecture, management nodes no longer rely on a single central platform for global scheduling and management. This enables low-latency, highly stable computing resource collaboration. After registration, management nodes can communicate directly point-to-point, sharing the total amount of computing resources, achieving resource discovery and synchronization. This architecture supports both dedicated and non-dedicated network lines, and nodes do not need to rely on consensus algorithms to maintain global resource consistency. Thus, through point-to-point network topology design, high efficiency in resource scheduling, low communication latency, and simplified maintenance are achieved, while simultaneously improving system availability and robustness.

[0127] After synchronizing the computing resource status among the management nodes, each management node has a global view of each other's available resources. Based on this, when a second management node finds that its local computing resources are insufficient to meet the current task requirements during actual business operations, it can initiate a computing resource scheduling request to other management nodes with surplus computing power (such as the first management node) based on the synchronized resource information. The following combines... Figure 8 An example is provided.

[0128] Figure 8 This is a schematic diagram of a method for scheduling computing resources provided in an embodiment of this application.

[0129] like Figure 8 As shown, the method for scheduling computing resources includes the following steps: S801: The first management node receives a resource request message sent by the second management node.

[0130] Figure 9 This is an interactive schematic diagram of a computing resource scheduling method provided in an embodiment of this application.

[0131] like Figure 9 As shown, step S801 includes step S2001.

[0132] S2001: The resource consensus module of the first management node receives the resource request message sent by the resource consensus module of the second management node.

[0133] The resource request message includes resource identification information of the computing resources to be allocated, such as computing device ID, computing type, required number of CPU / GPU cores, memory capacity, etc., to clarify the specific resource requirements of the request.

[0134] For example, when the local computing power of the second management node is insufficient, it can initiate a scheduling request to the first management node with surplus resources based on the synchronized global resource view, specifying the identifier and specifications of the required resources in the resource request message. For example, the resource identifier information may include the type of resource to be allocated (such as GPU or CPU), quantity (such as 2 GPU cards, 16GB of video memory), task priority, and expected usage duration. For example, the resource consensus module of the first management node receives a resource request message sent by the second management node (for example, requesting the allocation of computing power resources identified as "GPU-003").

[0135] It should be noted that, in this embodiment, the use of the first management node as the receiver of resource request messages is merely an illustrative description; in reality, the first management node can also act as the sender, sending resource request messages to the resource consensus module of the second management node. The roles of both parties can be dynamically interchanged according to the actual network topology and runtime state, and this solution does not impose specific limitations on this.

[0136] S802: The first management node queries the total computing power resources based on the resource request message and determines the first query result.

[0137] Continue as Figure 9 As shown, step S802 includes steps S2002-S2003.

[0138] S2002: The resource consensus module of the first management node sends a resource request message to the resource management module of the first management node.

[0139] Continuing with the example above, when the resource consensus module of the first management node receives a resource request message (e.g., a request to allocate computing resources identified as "GPU-003") sent by the second management node, it will immediately and completely transmit the message to the resource management module within this node.

[0140] S2003: The resource management module of the first management node queries the total amount of computing resources based on the resource request message and determines the first query result.

[0141] Continuing with the example above, after receiving a resource request message (such as a request to allocate a resource identified as "GPU-003"), the resource management module accesses the computing resource registry in the local database to retrieve the current usage status of the computing resource, i.e., the first query result. The first query result is used to indicate the allocability of the computing resource to be allocated. If the first query result shows that "GPU-003" has been occupied by other tasks, it is determined that it has been allocated; if the first query result shows no occupied record or the status is idle, it is determined that it is allocable, thus providing a basis for subsequent scheduling decisions.

[0142] Optionally, if the first query result indicates that the computing power resource to be allocated is already allocated, step S803 is executed; if the first query result indicates that the computing power resource to be allocated is available for allocation, step S804 is executed.

[0143] S803: The first management node performs a failure handling of computing resource allocation based on the first query result.

[0144] Continue as Figure 9 As shown, step S803 includes steps S2004–S2005, which will be explained as follows: S2004: If the computing power resources to be allocated have been allocated, the resource management module of the first management node generates an allocation response of "application failed" and returns the allocation response to the resource consensus module of the second management node through the resource consensus module.

[0145] Continuing with the example above, once the resource management module confirms that the requested "GPU-003" has been occupied by task T1, it determines that the resource is unavailable, and then generates an allocation response containing the rejection status and reason (such as "resource has been occupied"), and sends it to the resource consensus module of the second management node via the resource consensus module of this node.

[0146] S2005: The resource management module of the first management node triggers the sending of a resource status announcement message, which is then sent to the resource consensus module of the second management node through the resource consensus module.

[0147] Continuing with the example above, after generating the "application failed" response, to ensure that all nodes in the system maintain a consistent understanding of the current resource status, the resource management module of the first management node proactively triggers a Resource Status Announcement (RSA) process. This announcement message contains its latest total computing resources (e.g., "GPU-003" is still in the allocated state), which is encapsulated by the resource consensus module and sent to the second management node. This prevents the second node from repeatedly initiating invalid requests due to status lag, thereby maintaining the real-time nature of the global resource view.

[0148] S804: The first management node performs the allocation of computing resources based on the first query result.

[0149] Continue as Figure 9 As shown, step S804 includes steps S2006–S2008, which will be explained as follows: S2006: When the computing power resources to be allocated are available, the resource management module of the first management node generates an allocation response of "application successful" and allocates the resources, and returns the resource consensus module of the second management node through the resource consensus module.

[0150] Continuing with the example above, once the resource management module confirms that the requested "GPU-003" is in an idle state, it immediately marks it as allocated and binds it to the current scheduling request, and generates a success response containing the resource identifier, allocation status, and validity period; this response is sent to the resource consensus module of the second management node via the resource consensus module of this node.

[0151] S2007: The resource management module records the application log.

[0152] Following the example above, the resource management module writes key information about this scheduling process into the log, such as the requester's identity (e.g., the second management node identifier), the allocated resource identifier (e.g., "GPU-003"), the allocation timestamp, the operation result (success), and related context (e.g., request ID, validity period, etc.).

[0153] It should be noted that the application log is only an exemplary name used to refer to log entries that record information related to resource application operations. In actual implementation, this log may also be called scheduling request log, resource allocation record, computing power application audit log, or other names with similar functions. This solution does not make specific limitations on this.

[0154] S2008: The resource management module of the first management node triggers the sending of an updated resource status announcement message, which is then sent to the resource consensus module of the second management node through the resource consensus module.

[0155] Following the example above, after "GPU-003" is successfully allocated, the resource management module immediately triggers a Resource Status Announcement (RSA) process, encapsulates the updated local computing power resource status (e.g., the GPU has changed from idle to allocated) into a resource status announcement message, and submits it to the resource consensus module of this node; subsequently, the resource consensus module is responsible for forwarding the message to the resource consensus module of the second management node to ensure that the peer synchronizes the latest resource occupancy information in a timely manner and maintains the global resource view.

[0156] In summary, by sharing computing resource information, each management node can initiate cross-node resource scheduling requests when needed, thereby achieving cross-node computing power collaboration and elastic scheduling, and improving overall resource utilization and task execution efficiency.

[0157] To ensure efficient resource reuse and the overall sustainable scheduling capability of the system, the scheduled remote computing resources must be released promptly after the task is completed. The following section combines... Figure 10 This will be illustrated by example.

[0158] Figure 10 This is a schematic diagram of a method for releasing computing resources provided in an embodiment of this application.

[0159] like Figure 10 As shown, the method for releasing computing resources includes the following steps: S101: The first management node receives a resource release message sent by the second management node.

[0160] Figure 11 This is an interactive schematic diagram of a method for releasing computing resources provided in an embodiment of this application.

[0161] like Figure 11 As shown, step S101 includes step S3001.

[0162] S3001: The resource consensus module of the first management node receives the resource release message sent by the resource consensus module of the second management node.

[0163] For example, the first management node has previously successfully allocated computing resources identified as "GPU-003" to the second management node, and after the second management node completes the relevant tasks, it actively initiates a resource return operation. At this time, its resource consensus module will generate and send a resource release message to notify the first management node that the resource can be reclaimed.

[0164] S102: The first management node queries the total amount of computing resources based on the resource release message and determines the second query result.

[0165] The second query result is used to indicate the current holding status of the computing power resources to be released, so as to indicate whether the computing power resources to be released are held by the corresponding management node or whether they are in a releaseable state.

[0166] Continue to combine Figure 11 As shown, step S102 includes steps S3002-S3003.

[0167] S3002: The resource consensus module of the first management node sends a resource release message to the resource management module of the first management node.

[0168] The specific details of step S3002 can be found in step S2002 above, and will not be repeated here.

[0169] S3003: The resource management module of the first management node queries the total amount of computing resources based on the resource release message and determines the second query result.

[0170] Continuing with the example above, after receiving a resource release message (such as a request to release a resource identified as "GPU-003"), the resource management module will access the computing resource registry maintained in the local database to retrieve the current usage status of the computing resource, i.e., the second query result. If the second query result record shows that the computing resource to be released is currently held by the second management node and is in an allocated state, then the computing resource to be released is determined to meet the release conditions; if the second query result record shows that the computing resource to be released is not held by the second management node or is in an unallocated state, then the computing resource to be released is determined to not meet the release conditions.

[0171] Optionally, if the second query result indicates that the computing power resource to be released is currently held by the second management node and is in an allocated state, step S103 is executed; if the second query result indicates that the computing power resource to be released is not held by the second management node or is in an unallocated state, step S104 is executed.

[0172] S103: The first management node successfully released computing resources based on the second query result.

[0173] Continue to combine Figure 11 As shown, S103 includes steps S3004–S3005, which will be explained as follows: S3004: If the holding status of the computing power resources to be released has been allocated, the resource management module of the first management node generates an allocation response of "application successful" and returns the allocation response to the resource consensus module of the second management node through the resource consensus module.

[0174] The specific details of step S3004 can be found in step S2006 above, and will not be repeated here.

[0175] S3005: The resource management module of the first management node triggers the sending of a resource status announcement message, which is then sent to the resource consensus module of the second management node through the resource consensus module.

[0176] The specific details of step S3005 can be found in step S2005 above, and will not be repeated here.

[0177] S104: The first management node performs a failure to release computing resources based on the second query result.

[0178] Continue to combine Figure 11 As shown, step S104 also includes steps S3006-S3008.

[0179] S3006: If the holding status of the computing power resources to be released is not allocated, the resource management module of the first management node generates an allocation response of "application failed" and returns the allocation response to the resource consensus module of the second management node through the resource consensus module.

[0180] The specific details of step S3006 can be found in step S2004 above, and will not be repeated here.

[0181] Continuing with the example above, once the resource management module confirms that the requested "GPU-003" is in an idle state, it immediately marks it as allocated and binds it to the current scheduling request, and generates a success response containing the resource identifier, allocation status, and validity period; this response is sent to the resource consensus module of the second management node via the resource consensus module of this node.

[0182] S3007: The resource management module records release logs.

[0183] The specific content of step S3007 can be similar to step S2007 above, and will not be repeated here.

[0184] Following the example above, the resource management module writes key information about this release process into the log.

[0185] It should be noted that the release log is only an example name used to refer to log entries that record information related to resource release operations; in actual implementation, this log may also be called a recycling log, return record, resource release audit log or other names with similar functions, and this solution does not make specific limitations on this.

[0186] S3008: The resource management module of the first management node triggers the sending of an updated resource status announcement message, which is then sent to the resource consensus module of the second management node through the resource consensus module.

[0187] Among them, the updated resource status notification message includes an update on the total amount of computing resources.

[0188] The specific details of step S3008 can be found in step S2008 above, and will not be repeated here.

[0189] In summary, by sharing computing resource information, each management node can initiate cross-node resource release requests after the task is completed, thereby achieving cross-node computing power collaboration and elastic scheduling, and improving overall resource utilization and task execution efficiency.

[0190] Corresponding to the above embodiments, this application also provides a one-sided embodiment applied to the registration node, which is described below in conjunction with... Figure 12 An example is provided.

[0191] Figure 12 This is a second flowchart illustrating a distributed computing power management method provided in an embodiment of this application.

[0192] like Figure 12 As shown, the distributed computing power management method, applied to the registration node of the distributed computing power management system, includes the following steps: S121: Receive the registration request sent by the first management node.

[0193] The specific content of step S121 can be referred to in a similar manner to step S2 above, and will not be repeated here.

[0194] S122: Return the network endpoint information of the currently registered second management node to the first management node, and send the network endpoint information of the currently registered second management node to the second management node.

[0195] The specific details of step S122 can be found in step S3 above, and will not be repeated here.

[0196] In summary, by completing registration through the registration node, information on the second management nodes already registered in the current system can be obtained, providing a foundation for establishing communication connections with each second management node, thereby creating conditions for subsequent querying, allocation, and release of computing resources.

[0197] Corresponding to the above embodiments, this application also provides a single-sided embodiment applied to a first management node among multiple management nodes, which will be described below in conjunction with... Figure 13 An example is provided.

[0198] Figure 13 This is a third flowchart illustrating a distributed computing power management method provided in an embodiment of this application.

[0199] like Figure 13 As shown, the first management node in a distributed computing power management system is used. The distributed computing power management method includes the following steps: S131: The first management node receives the network endpoint information of the currently registered second management node sent by the registered node.

[0200] The specific content of step S131 can be referred to in a similar manner to step S4 above, and will not be repeated here.

[0201] S132: Based on the network endpoint information of the second management node, establish a communication connection with the second management node and send its total computing power resources to the second management node.

[0202] Continue to combine Figure 13 As shown, step S132 includes S1321-S1322.

[0203] S1321: In response to the neighbor probe message sent by the second management node, query the neighbor list to determine the existence status of the second management node.

[0204] Among them, the neighbor probe message carries the network endpoint information of the corresponding second management node.

[0205] The specific content of step S1321 can be referred to in the same way as step S52 above, and will not be repeated here.

[0206] S1322: If the network endpoint information of the second management node does not exist in the status indicator neighbor list, establish a communication connection with the second management node.

[0207] The neighbor list is used to record the network endpoint information of the second management node that has established a communication connection with the first management node.

[0208] The specific content of step S1322 can be referred to in the same way as step S52 above, and will not be repeated here.

[0209] In summary, by receiving registration information and establishing communication connections based on neighbor detection through the first management node, interconnection between the first management node and each of the second management nodes can be achieved, providing the foundation for the subsequent synchronization, allocation, and management of computing resources.

[0210] Corresponding to the above embodiments, this application also provides an embodiment of a method for scheduling computing resources, which will be described below in conjunction with... Figure 14 An example is provided.

[0211] Figure 14 This is a fourth flowchart illustrating a distributed computing power management method provided in an embodiment of this application.

[0212] like Figure 14 As shown, the distributed computing power management method includes the following steps: S141: The first management node is used to send a registration request to the registration node.

[0213] The specific details of step S141 can be found in step S2 above, and will not be repeated here.

[0214] S142: After receiving a registration request from the first management node, the registration node returns the network endpoint information of the currently registered second management node to the first management node, and notifies the second management node of the network endpoint information of the newly registered first management node.

[0215] The specific details of step S142 can be found in steps S3-S4 above, and will not be repeated here.

[0216] S143: The first management node is also used to establish a communication connection with the second management node based on the network endpoint information of the second management node, and to send its own computing power resource information to the second management node with which the communication connection has been established.

[0217] The specific details of step S143 can be found in steps S5-S6 above, and will not be repeated here.

[0218] In summary, by constructing a decentralized distributed architecture, management nodes no longer rely on a single central platform for global scheduling and management. This enables low-latency, highly stable computing resource collaboration. After registration, management nodes can communicate directly point-to-point, sharing the total amount of computing resources, achieving resource discovery and synchronization. This architecture supports both dedicated and non-dedicated network lines, and nodes do not need to rely on consensus algorithms to maintain global resource consistency. Thus, through point-to-point network topology design, high efficiency in resource scheduling, low communication latency, and simplified maintenance are achieved, while simultaneously improving system availability and robustness. Figure 15 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0219] like Figure 15 As shown, the computing device 1500 includes a processor 1501 and a memory 1502. Exemplarily, the computing device 1500 may also include a communications interface 1503 and a communications bus 1504.

[0220] The processor 1501, memory 1502, and communication interface 1503 communicate with each other via communication bus 1504. The communication interface 1503 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0221] In some embodiments, the processor 1501 is used to execute program 1505, specifically performing the relevant steps in the above-described distributed computing power management method embodiments. Specifically, program 1505 may include program code, which includes computer-executable instructions.

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

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

[0224] Specifically, program 1505 can be called by processor 1501 to enable computing device 1500 to perform distributed computing power management operations.

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

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

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

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

[0229] It should be noted that, in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0230] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0231] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0232] For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0233] More specific examples of computer-readable media (a non-exhaustive list) include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0234] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0235] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The above embodiments are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A distributed computing power management system, characterized in that, include: A registration node and multiple management nodes, wherein the multiple management nodes include a first management node and at least one second management node; The first management node is used to send a registration request to the registration node; The registration node is configured to, upon receiving a registration request from the first management node, return the network endpoint information of the currently registered second management node to the first management node, and notify the second management node of the network endpoint information of the newly registered first management node; wherein, the network endpoint information is used to characterize the communication access address corresponding to the management node; The first management node is also used to establish a communication connection with the second management node based on the network endpoint information of the second management node, and to synchronize their respective total computing resources with the second management node with which the communication connection has been established.

2. The distributed computing power management system according to claim 1, characterized in that, The first management node includes: The resource consensus module is used to send and receive neighbor probe messages with the resource consensus module of the second management node; wherein the neighbor probe message carries the network endpoint information of the corresponding first management node; The resource consensus module is further configured to respond to the neighbor probe message sent by the second management node, query the neighbor list, and determine the existence status of the second management node; wherein, the existence status is used to characterize the connection status between the second management node and the first management node; The resource consensus module is further configured to establish a communication connection with the second management node when the existence status indicates that the network endpoint information of the second management node does not exist in the neighbor list; wherein, the neighbor list is used to record the network endpoint information of the second management node that is currently establishing a communication connection with the first management node.

3. The distributed computing power management system according to claim 1 or 2, characterized in that, The first management node also includes a device access module and a resource management module; The device access module is used to connect to at least one computing power device, and when any computing power device is detected to be online, it acquires the computing power resources of the computing power device and reports them to the resource management module. The resource management module is used to update the total computing resources of the first management node based on the computing resources of the computing power device, and send the total computing resources to the resource consensus module of the first management node.

4. The distributed computing power management system according to claim 3, characterized in that, The resource consensus module is further configured to send and receive resource announcement messages with the resource consensus module of the second management node, and forward the resource announcement messages of the second management node to the resource management module; wherein, the resource announcement message includes the total computing power resources of the second management node; The resource management module is also used to parse the resource status notification message sent by the resource consensus module of the second management node, extract the total computing power resources of the second management node contained therein, and store the total computing power resources of the second management node in the local database.

5. The distributed computing power management system according to claim 4, characterized in that, The resource consensus module is further configured to send and receive resource request messages with the resource consensus module of the second management node, and report the received resource request messages to the resource management module; wherein, the resource request message includes resource identification information of the computing power resources to be allocated; The resource management module is also used to query the total amount of computing power resources based on the resource identification information, and to perform computing power resource allocation processing based on the first query result, and update the total amount of computing power resources; The resource consensus module is also used to synchronize the updated total computing power resources to the resource consensus module of the second management node.

6. The distributed computing power management system according to claim 4 or 5, characterized in that, The resource consensus module is further configured to send and receive resource release messages with the resource consensus module of the second management node, and report the received resource release messages to the resource management module; wherein, the resource release message includes resource identification information of the computing power resources to be released; The resource management module is also used to query the total amount of computing power resources based on the resource identification information, and to perform the release of computing power resources based on the second query result, and update the total amount of computing power resources. The resource consensus module is also used to synchronize the updated total computing power resources to the resource consensus module of the second management node.

7. A distributed computing power management method, characterized in that, The distributed computing power management method, applied to the registration node of a distributed computing power management system, includes: Receive the registration request sent by the first management node; The system returns the network endpoint information of the currently registered second management node to the first management node, and sends the network endpoint information of the currently registered second management node to the second management node; wherein, the network endpoint information is used to represent the communication access address corresponding to the management node.

8. A distributed computing power management method, characterized in that, The first management node in a distributed computing power management system is applied to multiple management nodes. The distributed computing power management method includes: Send a registration request to the registration node; Receive network endpoint information of the currently registered second management node sent by the registration node; Based on the network endpoint information of the second management node, a communication connection is established with the second management node, and the total amount of computing power resources is sent to the second management node.

9. The distributed computing power management method according to claim 8, characterized in that, The step of establishing a communication connection with the second management node based on the network endpoint information of the second management node includes: In response to a neighbor probe message sent by the second management node, the neighbor list is queried to determine the existence status of the second management node; wherein, the neighbor probe message carries the network endpoint information of the corresponding second management node; If the existence status indicates that the network endpoint information of the second management node does not exist in the neighbor list, a communication connection is established with the second management node; wherein, the neighbor list is used to record the network endpoint information of the second management node that is currently establishing a communication connection with the first management node.

10. A computing device, characterized in that, The computing device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the computing device to operate the distributed computing power management system as described in any one of claims 1 to 6 and to perform the distributed computing power management method as described in any one of claims 7 to 9.

Images