Unified scheduling method and system for heterogeneous computing loads

Abstract

The invention relates to the technical field of computer resource management, and provides a unified scheduling method for heterogeneous computing loads, which comprises the following steps: receiving a task creation request submitted by a client; in response to the task creation request, performing resource allocation according to the resource specification and the global resource view, and generating scheduling decision data; generating a scheduling arrangement instruction sent to the target physical node based on the scheduling decision data; and sending a scheduling arrangement instruction to the target physical node through the standard management interface so as to drive an execution environment adapter which is deployed on the target physical node and corresponds to the operation environment type identifier to complete the deployment of the task instance according to the resource specification. By setting the standard management interface and the global resource view which are decoupled from the specific running environment form, unified abstraction and scheduling of heterogeneous computing loads such as a virtual machine, a container and a physical machine process are realized, so that more refined resource regulation and integration are realized in a heterogeneous hybrid cluster, and the overall resource utilization rate is improved.

Description

Technical Field

[0001] This invention relates to the field of computer resource management technology, and in particular to a unified scheduling method and system for heterogeneous computing loads. Background Technology

[0002] In the fields of cloud computing and data center technology, with the increasing complexity of business models, computing infrastructure exhibits significant heterogeneity. A typical modern computing cluster usually manages multiple heterogeneous computing workloads simultaneously, including virtual machines based on hardware virtualization technology, containers based on operating system-level virtualization, and physical machine processes running directly on the host operating system. These workloads differ fundamentally in terms of resource isolation granularity, startup speed, image format, and lifecycle management interfaces, forming isolated resource silos. However, enterprises have an increasingly urgent need to improve overall resource utilization, reduce operational complexity, and achieve flexible and elastic scaling, thus placing core technical requirements on the underlying infrastructure for unified resource abstraction, scheduling, and orchestration across heterogeneous workloads.

[0003] Currently, most mainstream resource management systems in the industry are designed for specific types of workloads, and they have inherent limitations when dealing with hybrid deployment scenarios. For example, platforms such as OpenStack specialize in virtual machine lifecycle management, but have insufficient support for lightweight workloads such as containers and have a heavy architecture. Kubernetes has become the de facto standard for container orchestration. It abstracts different container runtimes through the container runtime interface, but this interface and its core resource model are deeply coupled with the container concept. Although there are solutions that integrate virtual machines and other workloads into Kubernetes through custom resource definitions and operators, such solutions are actually complex adaptations on top of containerized architectures. They do not achieve native unified abstraction of heterogeneous workloads at the architectural level, which directly leads to complex system architecture, fragmented management plane, and the inability to achieve efficient and unified scheduling and allocation of resources among different workloads such as virtual machines and containers. This limits the potential for optimizing the overall resource utilization of the cluster and increases the complexity of system operation and maintenance. Summary of the Invention

[0004] In view of this, the present invention proposes a unified scheduling method and system for heterogeneous computing loads. By setting a standard management interface and a global resource view that are decoupled from specific runtime environment forms, it realizes unified abstraction and scheduling of heterogeneous computing loads such as virtual machines, containers, and physical machine processes. This avoids the resource silo problem caused by the fragmented management framework in the prior art. Furthermore, by using a scheduling decision process and a common command issuance path, it simplifies the operation and maintenance complexity of hybrid cloud environments. At the same time, the global resource view provides unified resource measurement and status awareness across all load types, enabling the scheduler to allocate resources based on the principle of global optimization. This allows for more refined resource allocation and integration in heterogeneous hybrid clusters, thereby improving overall resource utilization.

[0005] The technical solution of this invention is implemented as follows: On the one hand, the present invention provides a unified scheduling method for heterogeneous computing loads, including: Receive a task creation request submitted by a client. The task creation request includes the resource specifications and runtime environment type identifier of the task to be executed. The runtime environment type identifier is used to distinguish at least two heterogeneous runtime environment types. In response to a task creation request, resources are allocated according to resource specifications and a global resource view, and scheduling decision data is generated. The scheduling decision data is used to allocate resources to the task to be executed in the global resource view and to determine the target physical node of the task to be executed. The global resource view is used to characterize the resources consumed by different operating environment modes on each physical node. Based on scheduling decision data, scheduling and orchestration instructions are generated and sent to the target physical node; Through the standard management interface, scheduling and orchestration instructions are sent to the target physical node to drive the execution environment adapter deployed on the target physical node, which corresponds to the runtime environment type identifier, to complete the deployment of task instances according to resource specifications. The standard management interface provides a set of atomic operations, which are decoupled from the specific runtime environment and are used to manage the entire lifecycle of task instances.

[0006] Based on the above technical solutions, preferably, at least two heterogeneous runtime environment forms are used, including any two or a combination of three runtime environment forms from containers, virtual machines, and physical machine processes; wherein, The container runtime environment is a runtime environment based on operating system kernel virtualization and namespace isolation technology, with images as the packaging unit. The virtual machine runtime environment is a runtime environment based on hardware virtualization technology, with complete operating system instances as the unit. The physical machine process runtime environment is a process instance that is directly scheduled and executed on the host operating system without additional virtualization layer isolation.

[0007] Based on the above technical solutions, preferably, the step of allocating resources according to resource specifications and a global resource view to generate scheduling decision data includes the following sub-steps: The resource specifications are analyzed to extract the quantitative requirements for the number of CPU cores, memory capacity, and storage space. Query the global resource view to obtain the remaining allocable amount of the above-mentioned types of resources for each physical node in the cluster; Based on a preset node filtering strategy, candidate nodes are selected from the set of physical nodes whose remaining resource quantity meets the quantification requirements. According to the preset node scoring strategy, the comprehensive load score of the candidate nodes is calculated, and the candidate node with the best score is determined as the target physical node. At the same time, scheduling decision data containing the specific amount of allocated resources and the unique identifier of the target physical node is generated.

[0008] Based on the above technical solutions, preferably, the standard management interface provides a set of atomic operations, including a creation operation for initializing workloads, a start operation for starting stopped and created workloads, a stop operation for terminating running workloads, a delete operation for removing stopped workloads, and a query status operation for obtaining current details of the workload. The calling semantics and implementation logic of each operation are independent of the specific runtime environment of the task instance below it.

[0009] Based on the above technical solutions, preferably, the step of generating scheduling and orchestration instructions for the target physical node based on scheduling decision data includes parsing and translating the resources specified in the scheduling decision data, converting them from the unified resource description model within the system into resource configuration instructions that can be recognized and executed by a specific execution environment adapter corresponding to the runtime environment type identifier, associating and encapsulating the identifier information of the target physical node with the translated resource configuration instructions, and attaching a unique identifier for the task instance to generate structured scheduling and orchestration instructions.

[0010] Based on the above technical solutions, a preferred embodiment also includes dynamic maintenance of the global resource view, the dynamic maintenance process including: When a task instance is successfully deployed, an atomic deduction operation is performed in the global resource view from the total available resources of the target physical node where the task is located, based on the number of CPU cores, memory capacity and storage space declared in its resource specifications. When a task instance is terminated through stop and delete operations, its resource release is confirmed by the final status reported by the execution environment adapter. In the global resource view, the previously deducted resource amount is fully returned to the resource availability pool of its original target physical node to ensure that the data in the global resource view and the actual resource usage on the cluster physical nodes always maintain strong consistency.

[0011] More preferably, the preset node scoring strategy is a scoring strategy to optimize the overall resource utilization balance of the cluster. The step of comprehensively scoring candidate nodes includes calculating a comprehensive load score for each candidate node. The lower the comprehensive load score, the more suitable it is for deploying new tasks. The comprehensive load score S of candidate node i is... i for: S i =w c ×(C usedi / C totali ) + w m × (M usedi / M totali )+w d ×(D usedi / D totali ) Among them, C usedi M usedi D usedi C represents the amount of CPU, memory, and disk bandwidth resources allocated to node i, respectively. totali M totali D totali w represents the total CPU, memory, and disk bandwidth resources of node i, respectively. c w m w d Let w represent the weight coefficients of the corresponding resources, and w satisfy the condition w. c +w m +w d =1.

[0012] On the other hand, the present invention provides a unified scheduling system for heterogeneous computing loads, used to execute the above-described unified scheduling method for heterogeneous computing loads, the system comprising: The request receiving module is used to receive task creation requests submitted by the client; The scheduling decision module is communicatively connected to the request receiving module and is used to respond to the task creation request, allocate resources according to the resource specifications and global resource view, and generate scheduling decision data. The instruction generation module is communicatively connected to the scheduling decision module and is used to generate scheduling and orchestration instructions to be sent to the target physical node based on the scheduling decision data. The interface communication and driver module is connected to the instruction generation module and is used to send the scheduling and orchestration instructions to the target physical node through a standard management interface, so as to drive the execution environment adapter deployed on the target physical node, which corresponds to the runtime environment type identifier, to complete the deployment of the task instance according to the resource specifications.

[0013] On the other hand, the present invention provides an electronic device including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the above-described method.

[0014] On the other hand, the present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0015] The unified scheduling method and system for heterogeneous computing loads of the present invention have the following advantages over the prior art: 1. By setting up a standard management interface and a global resource view that are decoupled from the specific runtime environment, a unified abstraction and scheduling of heterogeneous computing loads such as virtual machines, containers, and physical machine processes is achieved. This avoids the resource silo problem caused by the fragmented management framework in existing technologies. Furthermore, the scheduling decision process and common command issuance path simplify the operation and maintenance complexity of the hybrid cloud environment. At the same time, the global resource view provides unified resource measurement and status awareness across all load types, enabling the scheduler to allocate resources based on the principle of global optimization. This allows for more refined resource allocation and integration in heterogeneous hybrid clusters, thereby improving overall resource utilization. 2. By defining a standard management interface that is completely decoupled from the specific runtime environment and a set of common atomic operations, a clear contract layer is established between the upper-layer scheduling logic and the underlying heterogeneous runtime. This allows the scheduler to drive all types of loads without needing to be aware of or have built-in support for any specific runtime. The global resource view unifies the CPU, memory, and other resources consumed by various loads into standardized metrics, providing a single trusted data source for cluster resources. These two technical features work together to shield the underlying heterogeneity from both the interface and data model dimensions, laying a solid architectural foundation for unified scheduling. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the unified scheduling method for heterogeneous computing loads according to the present invention. Figure 2 This is a block diagram illustrating the working principle of the unified scheduling method for heterogeneous computing loads according to the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0019] like Figure 1-2 As shown, the unified scheduling method for heterogeneous computing loads of the present invention addresses the problems of architectural fragmentation, low resource scheduling efficiency, and complex management caused by the tight coupling of existing resource management systems with specific load types. It constructs an abstract layer between a unified scheduler and heterogeneous execution environments. This layer defines a set of standardized atomic operation interfaces decoupled from specific runtime environments and maintains a unified view representing the resource consumption of various loads. When the system receives a task creation request containing a runtime environment type identifier, the scheduler makes resource allocation decisions based on the global view, generating scheduling decision data. Subsequently, the system converts the decision data into orchestration instructions that can be issued through the standard interfaces, driving the deployment of specific execution environment adapters corresponding to the load type on the target physical node, ultimately completing the deployment of the task instance. Through this architecture, the upper-layer scheduling logic is freed from the differences in the underlying heterogeneous environment, achieving truly unified orchestration and resource management for various computing loads.

[0020] In some embodiments, it is first necessary to receive a task creation request submitted by a client. The task creation request includes the resource specifications and runtime environment type identifier of the task to be executed. The runtime environment type identifier is used to distinguish at least two heterogeneous runtime environment types.

[0021] The first step of this method is to receive the task creation request submitted by the client. This is the trigger point and data input source of the entire unified scheduling process. It provides an entry point for upper-layer users or management systems to define and submit loads that are independent of the underlying heterogeneous environment. Thus, it shields the differences between different running forms such as virtual machines, containers, and processes from the starting point of the process. Specifically, the task creation request is a structured data object or file, whose core fields must include resource specifications and runtime environment type identifiers.

[0022] Here, the runtime environment type identifier is a key metadata element that clearly tells the system whether the workload to be created is essentially a container, virtual machine, or process. This directly determines which type of execution environment adapter will be called in subsequent processes. The resource specifications define the amount of computing resources required for the task instance, such as the number of CPU cores, memory capacity, and storage space. These quantitative indicators are the core basis for subsequent global resource matching and scheduling. This step transforms the creation intent of heterogeneous workloads into internal analysis objects that the system can process uniformly through standardized request formats, laying the foundation for subsequent scheduling and unified execution.

[0023] At least two heterogeneous runtime environment forms include any two or three runtime environment forms from containers, virtual machines, and physical machine processes. These forms are explicitly defined and used as the basic units of management because they represent different levels of computational abstraction in the current data center in terms of technical principles.

[0024] Container runtime environments are based on operating system kernel virtualization and namespace isolation technologies, using images as the packaging unit. Their key feature is packaging applications and their dependencies into images, achieving process-level resource isolation and rapid startup. For example, a Docker container image contains a streamlined application runtime environment. Virtual machine runtime environments are based on hardware virtualization technologies, such as Intel VT-x or AMD-V. They create and run isolated virtual machines by running a complete virtual machine monitor on top of physical hardware. For example, an Ubuntu virtual machine created using KVM has independent kernel and user space. Physical machine process runtime environments specifically refer to process instances that are directly scheduled and executed on the host operating system without relying on additional virtualization layers for isolation. These are typically used for high-performance computing tasks that are extremely sensitive to performance overhead or require direct access to specific hardware. These three types constitute a continuous technology spectrum in terms of isolation, overhead, startup speed, and compatibility. This method manages them through a unified framework, allowing users to create and manage an Nginx container, a Windows virtual machine, and a directly compiled and executed C++ computing process using the same set of interfaces and processes, thereby truly achieving unified scheduling of heterogeneous computing resources at the technical level.

[0025] After successfully receiving and parsing the task creation request, the system enters the core scheduling decision phase, which involves responding to the task creation request, allocating resources according to resource specifications and the global resource view, and generating scheduling decision data. This scheduling decision data is used to allocate resources to the task to be executed in the global resource view and to determine the target physical node for the task. The global resource view is used to characterize the resources consumed by different operating environments on each physical node.

[0026] The purpose of this step is to perform globally optimal resource planning for load requests from different operating modes on a unified abstraction layer, thereby breaking down resource silos and achieving unified scheduling. Specifically, the system understands the heterogeneous attributes of the load based on the runtime environment type identifier in the request. Its decision engine locks onto the quantitative requirements defined by the resource specifications in the request, such as needing 4 CPU cores and 16GB of memory. The core basis for this decision is the global resource view, a dynamic and unified data model that aggregates and standardizes in real time the total amount of resources actually consumed and the remaining available resources on all physical nodes in the cluster, including load instances of different types such as containers, virtual machines, and processes. For example, in this view, the CPU and memory usage of a node running 3 Docker containers and a node running 2 KVM virtual machines on a host machine are converted into a unified unit of measurement and summarized. The system scheduler performs matching and calculations on this global view based on preset scheduling strategies, such as minimum resource fragmentation strategy, load balancing strategy, or affinity strategy. Its output is scheduling decision data, which is a structured intermediate product. Its core function is to logically accomplish two things: First, in the global resource view, lock and allocate the requested resource quota for the current task to be executed; Second, determine the optimal node as the target physical node from all physical nodes that meet the resource conditions.

[0027] In some specific embodiments, the generation of scheduling decision data can be broken down into several sub-steps.

[0028] First, the resource specifications are parsed to extract the quantitative requirements for the number of CPU cores, memory capacity, and storage space. This step is the starting point for precise resource allocation. Its purpose is to transform the resource requests submitted by the user in declarative or configuration languages ​​into discrete values ​​that the scheduling engine can perform mathematical calculations and logical comparisons. The system performs syntax parsing and semantic extraction on the resource specification fields to identify the quantitative requirements for core computing resources and extended resources. For example, specific values ​​such as cpu_cores: 4, memory_mb: 8192, and storage_gb: 100 are parsed from the request. This process ensures that the user's intent is unambiguously converted into the system's internal standard resource measurement units, providing accurate input for subsequent resource matching.

[0029] Next, the global resource view is queried to obtain the remaining allocable resources of each physical node in the cluster. This step is the data acquisition stage for decision-making. The global resource view queried by the system is a dynamic metadata store that aggregates and reflects the total resource capacity, current allocated amount, and remaining allocable amount of all physical nodes in the entire cluster in real time. During the query, the system traverses the view to obtain the remaining available amount of each physical node for each type of resource extracted in the previous step at the current moment. For example, the query result may show that node Node-01 has 5.2 CPU cores and 15.3 GiB of memory remaining, and node Node-02 has 3.1 CPU cores and 8.5 GiB of memory remaining. This transforms the abstract global state into a node-level resource dataset that can be used for specific decision-making.

[0030] Based on this, the system, according to a preset node filtering strategy, selects candidate nodes from the set of physical nodes whose remaining resource quantity meets the quantified requirements. This step performs hard constraint matching of resources and is a preliminary filtering. The system compares all acquired nodes with the extracted resource requirements according to the preset node filtering strategy, filtering out physical nodes whose remaining quantity for all requested resource types is not less than the required quantity, forming a candidate node set. The filtering strategy is based on ensuring sufficient resources, but may also include other hard constraints, such as node label matching, specific hardware architecture requirements, or fault domain isolation. For example, for a task requiring 4 CPU cores and 8 GiB of memory, only nodes with ≥4 CPU cores and ≥8 GiB of memory remaining can pass this round of filtering, thus effectively avoiding resource overload allocation.

[0031] Finally, based on the preset node scoring strategy, the comprehensive load score of each candidate node is calculated, and the candidate node with the best score is determined as the target physical node. Simultaneously, scheduling decision data containing the specific values ​​of the allocated resources and the unique identifier of the target physical node is generated. The generated set of candidate nodes is then refined using another, more complex node scoring strategy. This strategy calculates a comprehensive load score for each candidate node. The scoring model aims to optimize specific system objectives, such as load balancing, reducing resource fragmentation, or improving data locality. After scoring, the system selects the node with the best score and formally determines it as the target physical node. The system then generates structured scheduling decision data, which contains at least two core pieces of information: the specific values ​​of the resources allocated for this task and the unique identifier of the target physical node. This data is the culmination of all preceding intelligent decisions and serves as an unalterable blueprint for subsequent execution phases.

[0032] In a further embodiment, the preset node scoring strategy is a scoring strategy that optimizes the overall resource utilization balance of the cluster. The step of comprehensively scoring candidate nodes includes calculating a comprehensive load score for each candidate node. The lower the comprehensive load score, the more suitable it is for deploying new tasks. The comprehensive load score S of candidate node i is... i for: S i =w c ×(C usedi / C totali ) + w m × (M usedi / M totali )+w d ×(D usedi / D totali ) Among them, C usedi M usedi D usedi C represents the amount of CPU, memory, and disk bandwidth resources allocated to node i, respectively. totali M totali D totali w represents the total CPU, memory, and disk bandwidth resources of node i, respectively. c w m w d Let w represent the weight coefficients of the corresponding resources, and w satisfy the condition w. c +w m +w d =1.

[0033] After generating scheduling decision data, scheduling and orchestration instructions to be sent to the target physical nodes can be generated based on the scheduling decision data. The core role of this step is to act as a precise translator and instruction assembler between decision-making and execution, thereby transforming the scheduling intent abstracted at the platform layer into action commands that can be recognized and operated by the downstream heterogeneous execution environment.

[0034] Specifically, after receiving the scheduling decision data generated in the previous step, the system parses and translates the resources specified in the scheduling decision data, converting them from the system's unified resource description model into resource configuration instructions that can be recognized and executed by a specific execution environment adapter corresponding to the runtime environment type identifier. The scheduling decision data received by the system carries allocation results generated under the platform's global resource model and are independent of the specific runtime. The primary task of the instruction generation engine is to parse this data, especially the part specifying the allocated resources. Subsequently, based on the key runtime environment type identifier in the task creation request, the engine initiates the corresponding translation logic. The essence of translation is to map the system's unified resource description model into resource configuration instructions or parameter files that can be recognized and executed by the specific execution environment adapter on the target node.

[0035] The system associates and encapsulates the target physical node's identification information with the translated resource configuration instructions, appending a unique identifier for the task instance to generate structured scheduling and orchestration instructions. After translating the resource description, the system needs to create an instruction unit that can be executed atomically by downstream nodes. To this end, the instruction generation engine associates and encapsulates the translated resource configuration instructions with necessary metadata, including at least: the target physical node's identification information for routing; and the task instance's unique identifier for uniquely tracking the instance throughout its lifecycle. The encapsulation result is a structured scheduling and orchestration instruction, which typically uses a serialized format. Its structure clearly defines the operation type, target location, resource parameters, and task identity. This final generated instruction package is the actual operation command sent to the target node to drive the execution environment adapter to perform the creation action.

[0036] After the scheduling and orchestration instructions are generated, the system executes the final driving and deployment steps. Through a standard management interface, it sends the scheduling and orchestration instructions to the target physical node to drive the execution environment adapter deployed on that target physical node, corresponding to the runtime environment type identifier, and completes the deployment of task instances according to resource specifications. This step is the key bridge and final implementation link for achieving unified scheduling to heterogeneous execution. The system reliably sends the structured scheduling and orchestration instructions encapsulated in the previous step to the target physical node via a predefined standard management interface, using communication methods such as remote procedure calls. The core feature of this interface is that it provides a set of atomic operations decoupled from the specific runtime environment, allowing the upper-layer scheduler to be unconcerned about whether the lower layer is Docker, KVM, or other custom runtimes; it only needs to call the unified Create method and pass in the instruction package.

[0037] On the target node, the execution environment adapter deployed on that node is responsible for receiving scheduling and orchestration instructions. Each adapter is a lightweight agent that, on the one hand, implements the aforementioned standard management interface and is the provider of the interface specification; on the other hand, it deeply understands and tightly integrates with a specific runtime environment—for example, a container adapter integrates DockerEngine, and a virtual machine adapter integrates QEMU-KVM. After receiving the instructions, the adapter parses them, identifies the native resource configuration instructions of the task instance's local environment, and then calls the native API of its integrated underlying runtime environment to precisely create and initialize the task instance according to the resource specifications in the instructions, ultimately completing its deployment and bringing it into a runnable state. Through this mechanism, unified scheduling instructions can achieve correct execution results in different runtime environments, thereby achieving truly unified lifecycle management of heterogeneous workloads such as virtual machines, containers, and processes at the architectural level.

[0038] The standard management interface provides a set of atomic operations, decoupled from specific runtime environments, for full lifecycle management of task instances. These operations are designed with minimization, completeness, and runtime decoupling in mind, providing the upper-layer scheduler with a command set that covers the basic management needs of all heterogeneous workloads without exposing any implementation details specific to any particular runtime environment.

[0039] In one specific embodiment, the set of atomic operations provided by the standard management interface may include a creation operation for initializing workloads, a start operation for starting stopped and created workloads, a stop operation for terminating running workloads, a delete operation for removing stopped workloads, and a query status operation for obtaining current details of the workloads.

[0040] The invocation semantics and implementation logic of each operation are independent of the specific runtime environment of the task instance it carries. The implementation logic of this operation in the container adapter calls the Docker API, while in the virtual machine adapter it calls the Libvirt API. This design contrasts with interfaces such as Kubernetes CRI, where the operation semantics are deeply bound to the container concept, making seamless mapping to virtual machines difficult. This invention's set of atomic operations, by abstracting to a more fundamental computing resource lifecycle level, lays the foundation for true heterogeneous unified management.

[0041] In addition, in some embodiments, to ensure data consistency, resource accountability, and the effectiveness of scheduling decisions across the entire unified scheduling system, it is necessary to dynamically maintain the global resource view. This dynamic maintenance process is a critical data flow loop that runs throughout the entire lifecycle of a task instance and is automatically triggered by the system. This process strictly follows the accounting principles of resource allocation to ensure that the virtual global view is always consistent with the actual resource usage of the physical cluster.

[0042] Its maintenance mechanism is specifically divided into two symmetric and atomic operations: When a task instance is successfully deployed on the target physical node, the system immediately triggers an update to the resource view. Based on the number of CPU cores, memory capacity, and storage space values ​​in the instance's resource specifications, the system performs an atomic deduction operation in the global resource view from the total available resources record corresponding to the target physical node. For example, if an instance declares that it requires 2 CPU cores and 4 GiB of memory, then at the moment of its successful deployment, the available CPU field value of that node in the view is reduced by 2, and the available memory field value is reduced by 4. Note that this operation must be atomic to prevent resource overselling in concurrent scheduling scenarios.

[0043] When a task instance is terminated normally through the Stop and Remove operations of the standard management interface, or is reclaimed by the system due to a fault, the maintenance mechanism is triggered again. The system first confirms that the instance's resources have been completely released by executing the final status reported by the environment adapter. Then, in the global resource view, the system performs the opposite operation to the deduction: all resource quotas previously recorded for the instance are completely returned to the resource availability pool of its original target physical node.

[0044] The purpose of this mechanism is to ensure that the data in the global resource view remains strongly consistent with the actual resource usage on the cluster's physical nodes. This ensures that the resource view upon which the scheduling decision module relies is accurate and reliable, fundamentally avoiding scheduling conflicts or resource idleness caused by data asynchrony.

[0045] The unified scheduling system for heterogeneous computing loads of the present invention is used to execute the unified scheduling method for heterogeneous computing loads described above. The system includes a request receiving module, a scheduling decision module, an instruction generation module, and an interface communication and driver module.

[0046] The request receiving module is used to receive task creation requests submitted by clients.

[0047] The scheduling decision module is communicatively connected to the request receiving module. It is used to respond to the task creation request, allocate resources according to the resource specifications and global resource view, and generate scheduling decision data.

[0048] The instruction generation module is communicatively connected to the scheduling decision module and is used to generate scheduling and orchestration instructions to be sent to the target physical node based on the scheduling decision data.

[0049] The interface communication and driver module is connected to the instruction generation module and is used to send the scheduling and orchestration instructions to the target physical node through a standard management interface, so as to drive the execution environment adapter deployed on the target physical node, which corresponds to the runtime environment type identifier, to complete the deployment of the task instance according to the resource specifications.

[0050] The electronic device of the present invention includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the above-described method.

[0051] The present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0052] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0053] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0054] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0055] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0056] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0057] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0058] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A unified scheduling method for heterogeneous computing loads, characterized in that, include: Receive a task creation request submitted by a client. The task creation request includes the resource specifications and runtime environment type identifier of the task to be executed. The runtime environment type identifier is used to distinguish at least two heterogeneous runtime environment types. In response to a task creation request, resources are allocated according to resource specifications and a global resource view, and scheduling decision data is generated. The scheduling decision data is used to allocate resources to the task to be executed in the global resource view and to determine the target physical node of the task to be executed. The global resource view is used to characterize the resources consumed by different operating environment modes on each physical node. Based on scheduling decision data, scheduling and orchestration instructions are generated and sent to the target physical node; Through the standard management interface, scheduling and orchestration instructions are sent to the target physical node to drive the execution environment adapter deployed on the target physical node, which corresponds to the runtime environment type identifier, to complete the deployment of task instances according to resource specifications. The standard management interface provides a set of atomic operations, which are decoupled from the specific runtime environment and are used to manage the entire lifecycle of task instances.

2. The unified scheduling method for heterogeneous computing loads as described in claim 1, characterized in that, At least two heterogeneous runtime environment types, including any two or a combination of three runtime environment types from containers, virtual machines, and physical machine processes; wherein, The container runtime environment is a runtime environment based on operating system kernel virtualization and namespace isolation technology, with images as the packaging unit. The virtual machine runtime environment is a runtime environment based on hardware virtualization technology, with complete operating system instances as the unit. The physical machine process runtime environment is a process instance that is directly scheduled and executed on the host operating system without additional virtualization layer isolation.

3. The unified scheduling method for heterogeneous computing loads as described in claim 1, characterized in that, The step of allocating resources based on resource specifications and a global resource view to generate scheduling decision data includes the following sub-steps: The resource specifications are analyzed to extract the quantitative requirements for the number of CPU cores, memory capacity, and storage space. Query the global resource view to obtain the remaining allocable amount of various resources for each physical node in the cluster; Based on a preset node filtering strategy, candidate nodes are selected from the set of physical nodes whose remaining resource quantity meets the quantification requirements. According to the preset node scoring strategy, the comprehensive load score of the candidate nodes is calculated, and the candidate node with the best score is determined as the target physical node. At the same time, scheduling decision data containing the specific amount of allocated resources and the unique identifier of the target physical node is generated.

4. The unified scheduling method for heterogeneous computing loads as described in claim 1, characterized in that, The standard management interface provides a set of atomic operations, including creation operations for initializing workloads, start operations for starting stopped and created workloads, stop operations for terminating running workloads, delete operations for removing stopped workloads, and query status operations for obtaining current details of workloads. The calling semantics and implementation logic of each operation are independent of the specific runtime environment of the task instance that carries it.

5. The unified scheduling method for heterogeneous computing loads as described in claim 1, characterized in that, The process of generating scheduling orchestration instructions for the target physical node based on scheduling decision data includes parsing and translating the resources specified in the scheduling decision data, converting them from the unified resource description model within the system into resource configuration instructions that can be recognized and executed by a specific execution environment adapter corresponding to the runtime environment type identifier, associating and encapsulating the identifier information of the target physical node with the translated resource configuration instructions, and attaching a unique identifier for the task instance to generate structured scheduling orchestration instructions.

6. The unified scheduling method for heterogeneous computing loads as described in claim 1, characterized in that, It also includes dynamic maintenance of the global resource view. The dynamic maintenance process includes: When a task instance is successfully deployed, an atomic deduction operation is performed in the global resource view from the total available resources of the target physical node where the task is located, based on the number of CPU cores, memory capacity and storage space declared in its resource specifications. When a task instance is terminated through stop and delete operations, its resource release is confirmed by the final status reported by the execution environment adapter. In the global resource view, the previously deducted resource amount is fully returned to the resource availability pool of its original target physical node to ensure that the data in the global resource view and the actual resource usage on the cluster physical nodes always maintain strong consistency.

7. The unified scheduling method for heterogeneous computing loads as described in claim 3, characterized in that, The preset node scoring strategy is a scoring strategy to optimize the overall resource utilization balance of the cluster. The steps for comprehensively scoring candidate nodes include calculating a comprehensive load score for each candidate node. The lower the comprehensive load score, the more suitable it is for deploying new tasks. The comprehensive load score S of candidate node i is... i for: S i =w c ×(C usedi / C totali ) + w m × (M usedi / M totali )+w d ×(D usedi / D totali ) Among them, C usedi M usedi D usedi C represents the amount of CPU, memory, and disk bandwidth resources allocated to node i, respectively. totali M totali D totali w represents the total CPU, memory, and disk bandwidth resources of node i, respectively. c w m w d Let w represent the weight coefficients of the corresponding resources, and w satisfy the condition w. c +w m +w d =1.

8. A unified scheduling system for heterogeneous computing workloads, characterized in that, A unified scheduling method for executing heterogeneous computing loads as described in any one of claims 1-7, the system comprising: The request receiving module is used to receive task creation requests submitted by the client; The scheduling decision module is communicatively connected to the request receiving module and is used to respond to the task creation request, allocate resources according to the resource specifications and global resource view, and generate scheduling decision data. The instruction generation module is communicatively connected to the scheduling decision module and is used to generate scheduling and orchestration instructions to be sent to the target physical node based on the scheduling decision data. The interface communication and driver module is connected to the instruction generation module and is used to send the scheduling and orchestration instructions to the target physical node through a standard management interface, so as to drive the execution environment adapter deployed on the target physical node, which corresponds to the runtime environment type identifier, to complete the deployment of the task instance according to the resource specifications.

9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1-7.

Images