Virtual cluster-based group scheduling system and apparatus

Abstract

Embodiments of the present disclosure disclose a virtual cluster-based crowd scheduling system and device. A specific implementation of the system includes: a trace synchronization module that automatically identifies a load object created by a user in a virtual cluster, synchronizes task annotation metadata corresponding to the load object to a corresponding execution unit in a host cluster, and writes address annotation metadata corresponding to the load object in the execution unit; a scheduling module that reads task annotation metadata of each execution unit, generates a scheduling score value corresponding to each execution unit in each execution unit according to the read task annotation metadata set, and batches each execution unit to a corresponding resource adaptation node, the scheduling module being deployed in the host cluster; and a billing module configured to generate a task billing sheet. The implementation improves the versatility and resource utilization efficiency of the system.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the fields of computer technology, cloud computing technology, and container scheduling technology, and specifically to a group scheduling system and apparatus based on virtual clusters. Background Technology

[0002] In large-scale modeling and AIGC (Artificial Intelligence Generated Content) business scenarios, building GPU (Graphics Processing Unit) computing power platforms based on Kubernetes (container orchestration system) for effective management and scheduling of computing power has become the mainstream choice in the industry. A key function of GPU computing power platforms is to sell idle computing power at low prices through preemption, thereby increasing cluster capacity and meeting diverse customer needs; this is commonly referred to as Spot (preemptive instance) scheduling.

[0003] However, existing cloud platforms supporting Spot scheduling only allow schedulers to configure priorities at the Pod (container) level, lacking awareness of top-level workload semantics. This necessitates users explicitly declaring priorities, preemption levels, or group scheduling parameters (Gang parameters, Gang Scheduling) on ​​each Pod or Job, increasing configuration complexity. Furthermore, such solutions typically rely heavily on deeply coupled CRDs (Custom Resource Definitions), requiring the scheduler to understand specific controller logic, hindering true transparency in multi-tenant environments. Therefore, achieving a lightweight system within a virtual cluster architecture that is independent of a specific scheduling framework, automatically traces workload annotations, and supports unified gang scheduling has become a pressing technical challenge. Summary of the Invention

[0004] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0005] Some embodiments of this disclosure propose a group scheduling system and apparatus based on virtual clusters to solve the technical problems mentioned in the background section above.

[0006] Firstly, some embodiments of this disclosure provide a group scheduling system based on a virtual cluster. The system includes: a source tracing and synchronization module, configured to: automatically identify load objects created by users in the virtual cluster, synchronize the task annotation metadata corresponding to the load object to the corresponding execution unit in the host cluster, and write address annotation metadata corresponding to the load object into the execution unit. The task annotation metadata includes task priority and minimum task start batch, and the address annotation metadata includes the object identifier code corresponding to the load object. The source tracing and synchronization module is deployed in the control plane of the virtual cluster. A scheduling module, configured to: for each execution unit corresponding to the same object identifier code, read the task annotation metadata of each execution unit. According to the read task annotation metadata dataset, a scheduling score value is generated for each execution unit in each execution unit. Based on the generated scheduling score value set and the minimum batch size for task startup included in the task annotation metadata set, each execution unit is batch-scheduled to the corresponding resource adaptation node. The scheduling module is deployed on the host cluster. The billing module is configured to: for each execution unit, in response to successful scheduling, generate a task billing statement based on the execution unit's task priority, cluster billing value, unit billing value, and task runtime. The task runtime is the duration from the time of successful task scheduling to the time of task termination. The billing module is also deployed on the host cluster.

[0007] Secondly, some embodiments of this disclosure provide a group scheduling device based on a virtual cluster, the device comprising:

[0008] The traceability and synchronization component includes a traceability and synchronization module configured to: automatically identify the load objects created by the user in the virtual cluster, synchronize the task annotation metadata corresponding to the load objects to the corresponding execution units in the host cluster, and write the address annotation metadata corresponding to the load objects into the execution units. The task annotation metadata includes task priority and minimum task batch size, and the address annotation metadata includes the object identifier code corresponding to the load objects. The traceability and synchronization module is deployed in the control plane of the virtual cluster. The scheduling component includes a scheduling module configured to: for each execution unit corresponding to the same object identifier code, read the task annotation metadata of each execution unit and, based on the read task annotation... The metadata set generates a scheduling score value for each execution unit. Based on the generated scheduling score value set and the minimum task start batch included in the task annotation metadata set, each execution unit is batch-scheduled to the corresponding resource adaptation node. The scheduling module is deployed on the host cluster. The billing component includes a billing module configured to generate a task billing statement for each execution unit in response to successful scheduling, based on the execution unit's task priority, cluster billing value, unit billing value, and task runtime. The task runtime is the duration from the time of successful task scheduling to the time of task termination. The billing module is also deployed on the host cluster.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the system described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the system described in any of the implementations of the first aspect above.

[0011] The embodiments disclosed above have the following beneficial effects: By introducing a unified scheduling identifier and group scheduling annotation into the top-level workload (the workload object created by the user in the virtual cluster) through the source tracing and synchronization module and the scheduling module, the system can automatically complete the identification and inheritance of task group relationships and priorities, thereby achieving consistent gang scheduling logic across virtual clusters corresponding to different users. Simultaneously, this solution achieves the transparent transmission of unified scheduling annotations from workload to Pod through the source tracing and synchronization module, completely decoupling the scheduler and controller. This avoids a strong, hard-coded dependency between the scheduler and the controller or virtual cluster management framework related to gang scheduling, allowing the system to flexibly adapt to new requirements and avoiding the limitation of scalability of the virtual cluster management framework. Therefore, it improves the system's versatility and resource utilization efficiency. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of a group scheduling system based on a virtual cluster according to the present disclosure;

[0014] Figure 2 This is a flowchart of a group scheduling method based on virtual clusters;

[0015] Figure 3 This is a schematic diagram of the structure of some embodiments of the group scheduling device based on virtual clusters according to the present disclosure;

[0016] Figure 4 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] Figure 1 This is a schematic diagram of an application scenario of a group scheduling system based on a virtual cluster, which is one of the embodiments of this disclosure.

[0024] exist Figure 1 In the application scenario, the group scheduling system 101 based on a virtual cluster may include a source tracing and synchronization module 102, a scheduling module 103, and a billing module 104. Wherein:

[0025] The aforementioned source tracing and synchronization module (Annotation Syncer) 102 is configured to: automatically identify the load object 1022 created by the user in the virtual cluster 105, synchronize the task annotation metadata 1023 corresponding to the load object 1022 to the corresponding execution unit 1024 in the host cluster 106, and write the address annotation metadata 1025 corresponding to the load object 1022 into the execution unit 1024. The task annotation metadata 1023 includes the task priority and the minimum batch size for task startup, and the address annotation metadata 1025 includes the object identifier code corresponding to the load object. The aforementioned source tracing and synchronization module 102 is deployed in the control plane of the virtual cluster 105.

[0026] The aforementioned scheduling module (Scheduler) 103 is configured to: for each execution unit 1024 corresponding to the same object identifier code, read the task annotation metadata 1023 of each execution unit 1024, generate a scheduling score value 1031 corresponding to each execution unit 1024 in each execution unit according to the read task annotation metadata dataset, and schedule each execution unit 1024 to the corresponding resource adaptation node in batches according to the generated scheduling score value set and the minimum batch of task start included in the task annotation metadata set. The aforementioned scheduling module 103 is deployed on the host cluster 106.

[0027] The billing module 104 is configured to generate a task billing statement 1041 for each execution unit 1024 in response to successful scheduling of the execution unit 1024, based on the task priority, cluster billing value, unit billing value and task runtime of the execution unit 1024. The task runtime is the duration from the time point when the task scheduling of the execution unit 1024 is successful to the time point when the task scheduling ends. The billing module (billing-controller) 104 is deployed on the host cluster 106.

[0028] It should be noted that the aforementioned group scheduling system 101 can be either hardware or software. When the group scheduling system is hardware, it can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or terminal device. When the group scheduling system is software, it can be installed on the hardware devices listed above. It can be implemented as, for example, multiple software programs or software modules used to provide distributed services, or as a single software program or software module. No specific limitations are made here. It should be understood that... Figure 1 The number of group scheduling systems in the system can be arbitrary, depending on the implementation requirements.

[0029] According to some embodiments of the present disclosure, a virtual cluster-based group scheduling system includes: a source tracing and synchronization module, a scheduling module, and a billing module.

[0030] In some embodiments, the above-mentioned source tracing and synchronization module is configured to:

[0031] The system automatically identifies workload objects created by users in the virtual cluster, synchronizes the task annotation metadata corresponding to the workload object to the corresponding execution unit in the host cluster, and writes the address annotation metadata corresponding to the workload object into the execution unit. The task annotation metadata includes task priority and minimum task batch size, while the address annotation metadata includes the object identifier code corresponding to the workload object. This traceability and synchronization module is deployed in the control plane of the virtual cluster. The minimum task batch size is a preset number of tasks that need to be executed synchronously when starting a task in the execution unit.

[0032] Specifically, a workload object can be an object created by the user in a Pod container within the virtual cluster via the API Server (Application Programming Interface Server). For example, a workload object can include a Deployment (deployment controller), a Job (task controller), or a CRD (Custom Resource Definition). Therefore, the tracing and synchronization module can automatically identify workload objects created by the user in the virtual cluster through the Watch API (interface listening) module. Task priority can be the order in which tasks are executed by the execution unit. A virtual cluster is a logically isolated cluster running on top of a host Kubernetes cluster, implementing an independent API Server and control plane through virtualized control plane components. The host cluster can be a Kubernetes container orchestration platform used for automating the deployment, scaling, and management of containerized applications. The scheduler is the core component responsible for allocating nodes to Pods within the cluster.

[0033] Here, when creating a workload object, users can add task annotation metadata. Task annotation metadata represents the task annotation information associated with the workload object. For example, the task annotation metadata might be: [queue-Ln: task priority; scheduling.k8s.io / gang-min-member: minimum batch size for task startup]. Here, "queue-Ln" represents the task priority corresponding to the aforementioned workload object. "scheduling" represents the functional domain identifier. "k8s.io" represents the domain namespace prefix. "gang-min-member" represents the core semantic identifier of the aforementioned workload object. Additionally, when a user creates a workload object in a Pod container within a virtual cluster, the virtual cluster can synchronize the Pod container (including the workload object and its corresponding task annotation metadata) to the host cluster as an execution unit. Here, the execution unit can be a container used to execute the user-defined tasks, i.e., a Pod container. Therefore, the source synchronization module can add the task annotation metadata and address annotation metadata corresponding to the workload object to the execution unit. This ensures that the synchronized Pod has complete scheduling semantics in the host cluster, without relying on a specific controller. This enables unified scheduling annotation pass-through from the load object to the host cluster Pod, completely decoupling the scheduler and controller, and allowing it to run in any standard Kubernetes environment.

[0034] Secondly, address annotation metadata is data used to transmit the object identifier associated with the payload object. The data format of address annotation metadata is [scheduling.k8s.io / workload-id: "object identifier"]. For example, the object identifier of the payload object is: "290909ca-e0a8-4346-aecb-db98080d67ab".

[0035] Therefore, the address annotation metadata could be: [scheduling.k8s.io / workload-id: "290909ca-e0a8-4346-aecb-db98080d67ab"].

[0036] In some embodiments, the scheduling module is configured to: for each execution unit corresponding to the same object identifier, read the task annotation metadata of each execution unit, generate a scheduling score value corresponding to each execution unit in each execution unit based on the read task annotation metadata dataset, and schedule each execution unit to the corresponding resource adaptation node in batches according to the generated scheduling score value set and the minimum batch of task startup included in the task annotation metadata set. The scheduling module is deployed on the host cluster.

[0037] Optionally, the aforementioned execution entity (the virtual cluster-based group scheduling system 101) generates a scheduling score value for each execution unit based on the read task annotation metadata dataset, including:

[0038] Step S1: Based on the task priorities included in the task annotation metadata set, determine the priority score value corresponding to each execution unit in each execution unit, thus obtaining a priority score value set. For each task priority, a corresponding priority score can be pre-set in a data table. Therefore, the priority score value corresponding to each execution unit in each execution unit can be determined by looking up the table, resulting in the priority score value set. The priority score value represents the degree of priority of the task; the higher the task priority, the larger the corresponding priority score value.

[0039] Step S2: Based on the current cluster resource status, determine the node resource matching degree corresponding to each execution unit in each execution unit, and obtain the node resource matching degree set. Here, the current cluster resource status can characterize the status of the available computing resources of the host cluster. Specifically, the current cluster resource status may include the upper limit of the available computing resources of the host cluster.

[0040] Specifically, Node Resource Fit is a metric used to measure the rationality of resource requests made by an execution unit. The formula for calculating Node Resource Fit is as follows:

[0041] If `limit-request` <= 1, then `ResourceFit` = 1. If `limit` or `request` does not exist (i.e., no corresponding value was detected), then `ResourceFit` is set to 0 (i.e., the task of the execution unit is paused by setting the node resource matching degree to zero). If `limit-request` > 1, then `ResourceFit` = 1 / (limit-request). Therefore, the larger the difference between `limit` and `request`, the smaller `ResourceFit`. Here, `limit` represents the resource limit, and `request` represents the resource request amount. Additionally, the resource request amount can be the total value of computing resources required to execute the tasks corresponding to each execution unit. The resource requirement for each execution unit can be actively declared when creating the workload object or a default value automatically filled by the system. For example, if actively declared when creating the workload object, it can be actively declared through the `spec.template.spec.resources` field when creating a `Job` type workload object.

[0042] Therefore, the closer the node resource matching degree is to 1 (i.e., the smaller the difference between the available computing resources of the node and the computing resources required by the execution unit), the more compact the resource request is (i.e., the more suitable the available computing resources of the node allocated to the execution unit are to the computing resources required by the execution unit), and the less redundant computing resources (computing resources not used when the node executes the task). Thus, the resource utilization efficiency of the node after scheduling is higher; conversely, the resource redundancy is large and the utilization efficiency is low.

[0043] Step S3: Based on the aforementioned node resource matching set and priority score set, a multi-dimensional weighting model is used to calculate the scheduling score for each execution unit. Specifically, for each execution unit, the scheduling score can be calculated using the following multi-dimensional weighting model: Scheduling score = α × Priority(Ln) + β × ResourceFit. Here, Priority(Ln) represents the priority score for the execution unit. α and β represent preset weighting coefficients. For example, weighting coefficient α is 0.5, and weighting coefficient β is 0.5.

[0044] Optionally, execution units with the same object identifier can be assigned to the same task queue. Here, the scheduler can allocate execution units with the same object identifier to the same task queue.

[0045] Optionally, the aforementioned execution entity can schedule each execution unit to the corresponding resource adaptation node in batches based on the generated scheduling score set and the task start minimum batch included in the task annotation metadata set, including:

[0046] Step S1: Determine the maximum minimum task start batch size for each execution unit as the target batch size. Here, selecting the maximum minimum task start batch size can cover the task batch requirements of each execution unit under the same task queue.

[0047] Step S2: In response to determining that each execution unit meets the preset computing resource conditions, determine whether the queue length of the task queue is greater than or equal to the target batch size. The computing resource conditions can be that the node resource matching degree corresponding to the execution unit is greater than a preset threshold, meaning that the remaining computing resources in the host cluster (or the remaining computing resources of a task node in the host cluster used for task execution) can meet the computing resource requirements of each execution unit.

[0048] Step S3: In response to determining that the queue length of the task queue is greater than or equal to the target batch size, based on the generated scheduling score set, each execution unit corresponding to the task queue is batch-scheduled to the corresponding resource adaptation node for execution of the corresponding task. The queue length being greater than or equal to the target batch size indicates that the task batch size requirements of each execution unit have met the minimum batch start condition. Here, the minimum batch start condition can be that the number of execution units under the same task queue is greater than the corresponding target batch size. Therefore, the scheduling module can batch-schedule each execution unit corresponding to the task queue to the corresponding resource adaptation node for execution of the corresponding task. Here, the scheduler of the scheduling module can allocate resource adaptation nodes based on the current cluster resource status and priority score. Specifically, the resource adaptation node can be the node with the highest scheduling score value corresponding to the execution unit selected by the scheduling module (the scheduler); or the resource adaptation node can be obtained by the scheduling module through matching the computational resource requirements of each execution unit under the task queue.

[0049] Optionally, the aforementioned execution entity can, based on the generated scheduling score set and the task startup minimum batch included in the task annotation metadata set, batch schedule each execution unit to the corresponding resource adaptation node, and further include:

[0050] Step S1: In response to determining that each execution unit does not meet the aforementioned computing resource conditions, determine whether each execution unit in the task queue with a task priority higher than a preset priority meets the aforementioned computing resource conditions. The fact that each execution unit does not meet the aforementioned computing resource conditions indicates that the remaining computing resources of the host cluster (or the remaining computing resources of a task node in the host cluster used to execute tasks) do not meet the computing resource requirements of each execution unit. Therefore, it can be determined whether each execution unit in the task queue with a task priority higher than a preset priority (e.g., the third task priority L3) meets the aforementioned computing resource conditions. This can be used to prioritize determining whether high-priority execution units meet the aforementioned computing resource conditions.

[0051] Step S2: In response to determining that each execution unit in the task queue with a task priority higher than the preset priority satisfies the aforementioned computing resource conditions, each execution unit in the task queue with a task priority lower than or equal to the preset priority is evicted in reverse order to generate a target task queue. The execution units corresponding to the target task queue satisfy the aforementioned computing resource conditions. Here, the fact that each execution unit corresponding to the target task queue satisfies the aforementioned computing resource conditions indicates that after removing low-priority execution units, the remaining computing resources of the task nodes meet the task requirements of the execution units, and that adding any one of the evicted execution units to the target task queue causes the execution units in the target task queue to no longer satisfy the aforementioned computing resource conditions.

[0052] Specifically, to maximize the batch processing capacity of tasks, a reverse eviction process is used to sequentially remove the lowest-priority execution units from the task queue. After removing all execution units of the same priority level each time, it is determined whether the remaining execution units meet the aforementioned computational resource conditions. Thus, the high-priority execution units that precisely meet the aforementioned computational resource conditions can be selected, and their corresponding task queues are designated as the target task queues.

[0053] Optionally, if the execution units corresponding to the expulsion task queue do not meet the above computing resource conditions, the queue status of the expulsion task queue can be adjusted from the pending execution state to the queuing state until there are enough computing resources to schedule the expulsion task queue.

[0054] Step S3: In response to determining that the queue length of the target task queue is greater than or equal to the target batch, each execution unit corresponding to the target task queue is batch-scheduled to the corresponding resource adaptation node according to the generated scheduling score set. Here, the queue length of the target task queue being greater than or equal to the target batch indicates that the queue length of the target task queue has met the minimum batch start condition for tasks.

[0055] Optionally, if the queue length of the target task queue is less than the target batch size, the queue status of the target task queue (or task queue) can be changed from the pending execution state to the queued state until the number of execution units in the target task queue (or task queue) meets the minimum batch start condition for the task.

[0056] In practice, the source tracing and synchronization module can automatically propagate scheduling information (i.e., user-created workload objects) from the top-level workload to the execution unit without modifying the user controller logic. The scheduling module can execute a priority-reverse eviction policy when resources are insufficient. This enables the swarm scheduling system to support compatibility with any Kubernetes scheduler plugin, achieving decoupling between the scheduler and controller logic.

[0057] In some embodiments, the billing module is configured to generate a task billing statement for each execution unit in response to successful scheduling of the execution unit, based on the task priority, cluster billing value, unit billing value, and task runtime of the execution unit, wherein the task runtime is the duration from the time point when the task scheduling of the execution unit is successful to the time point when the task scheduling ends, and the billing module is deployed on the host cluster.

[0058] In some embodiments, the execution entity may, for each execution unit, generate a task billing statement in response to successful scheduling of the execution unit, based on the task priority, cluster billing value, unit billing value, and task runtime of the execution unit, including:

[0059] Step S1: Determine the discount coefficient corresponding to the task priority included in the task annotation metadata of the above execution unit. This can be done by pre-storing the corresponding discount coefficient for each task priority in a discount data table, thus determining the discount coefficient corresponding to the task priority included in the task annotation metadata of the above execution unit by looking up the table.

[0060] Step S2: Based on the aforementioned discount coefficient, cluster billing value, unit billing value, and task runtime, a task billing order is generated, and the task billing order is pushed to the control plane of the corresponding virtual cluster and written to the billing database. The total billing value can be generated using the following formula: Total Billing Value = Billing Weight × Discount Coefficient × Cluster Billing Value × Unit Billing Value × Billing Duration. Here, the billing weight can be a preset value. Furthermore, the aforementioned discount coefficient, cluster billing value, unit billing value, task runtime, and total billing value can be used to determine the task billing order. Here, the task billing order represents task billing information. The billing database can be a database used to store task billing orders.

[0061] In practice, cluster billing values ​​can be pre-set for a user's specific cluster. Unit billing values ​​can be pre-selected based on the resource type chosen by the user. For example, resource types can be categorized as GPU and CPU. A GPU type can include multiple GPU subtypes, each corresponding to a preset GPU graphics card model. A CPU type can include multiple CPU subtypes, each corresponding to a preset CPU processor model. Therefore, different resource types selected by the user result in different unit billing values.

[0062] For example, the billing database could be a MySQL (relational database management system) database.

[0063] In addition, the timer stops when the execution unit is removed, the task is completed, or the execution unit is deleted, thus obtaining the task runtime.

[0064] Optional, see Figure 2 The flowchart 200 of the group scheduling method based on virtual clusters shown in this disclosure, and some embodiments of the group scheduling method based on virtual clusters, include:

[0065] Step 201: The source tracing and synchronization module automatically synchronizes the annotations to the execution unit.

[0066] In some embodiments, the aforementioned execution entity can automatically identify the load object created by the user in the virtual cluster, synchronize the task annotation metadata (annotation) corresponding to the load object to the corresponding execution unit in the host cluster, and write the address annotation metadata corresponding to the load object into the execution unit.

[0067] As an example, annotations can be divided into task annotation metadata and address annotation metadata. For example, task annotation metadata could be: [queue-Ln,scheduling.k8s.io / gang-min-member]. Address annotation metadata could be: [scheduling.k8s.io / workload-id].

[0068] Step 202: The host cluster performs task scheduling based on the annotations.

[0069] In some embodiments, the execution entity can control the scheduling module under the host cluster to perform the following steps: for each execution unit corresponding to the same object identifier code, read the task annotation metadata of each execution unit, generate a scheduling score value corresponding to each execution unit in each execution unit according to the read task annotation metadata dataset, and schedule each execution unit to the corresponding resource adaptation node in batches according to the generated scheduling score value set and the task startup minimum batch included in the task annotation metadata set. The scheduling module is deployed in the host cluster.

[0070] Step 203: After successful scheduling, the billing module starts billing.

[0071] In some embodiments, the execution entity may control the billing module to start billing after successful scheduling, specifically including: for each execution unit, in response to successful scheduling of the execution unit, generating a task billing bill based on the task priority, cluster billing value, unit billing value and task runtime of the execution unit.

[0072] Step 204: Billing stops after the task ends or the user is expelled.

[0073] In some embodiments, for each execution unit, the execution entity stops billing and writes the task billing statement to the billing database after the task corresponding to the execution unit ends or is expelled.

[0074] In practice, the above-described embodiments of this application have the following significant advantages:

[0075] 1. Top-level annotation tracing: There is no need to configure annotations separately on each Pod. The group scheduling system can automatically inherit the gang information of the scheduling and load objects from the top-level workload.

[0076] 2. Native gang scheduling support: Users can implement gang scheduling control through the source tracing and synchronization module, which is completely decoupled from external controllers and schedulers;

[0077] 3. Decoupling of scheduler and controller: The scheduling logic is implemented entirely through the source synchronization module, and any scheduling framework can be connected to it;

[0078] 4. Unified group scheduling: Priority scheduling and the gang mechanism can be executed in parallel to achieve fair and efficient resource utilization;

[0079] 5. Flexible billing methods: Billing can be based on task priority, virtual clusters, and other dimensions.

[0080] The embodiments disclosed above have the following beneficial effects: By introducing a unified scheduling identifier and group scheduling annotation into the top-level workload (the workload object created by the user in the virtual cluster) through the source tracing and synchronization module and the scheduling module, the system can automatically complete the identification and inheritance of task group relationships and priorities. Thus, consistent gang scheduling logic is achieved across virtual clusters corresponding to different users. Simultaneously, this scheme achieves the transparent transmission of unified scheduling annotations from workload to Pod through the source tracing and synchronization module, completely decoupling the scheduler and controller. This avoids a strong, hard-coded dependency between the scheduler and the controller or virtual cluster management framework related to gang scheduling, allowing the system to flexibly adapt to new requirements and avoiding the limitation of the scalability of the virtual cluster management framework. Therefore, the system's versatility and resource utilization efficiency are improved.

[0081] Further reference Figure 3 As an implementation of the systems shown in the above figures, this disclosure provides some embodiments of a group scheduling device based on a virtual cluster. These device embodiments are similar to... Figure 1 Corresponding to the embodiments described above, this virtual cluster-based group scheduling device can be specifically applied to various electronic devices.

[0082] like Figure 3As shown, some embodiments of the virtual cluster-based group scheduling device 300 include: a source tracing and synchronization component 301, a scheduling component 302, and a billing component 303. The source tracing and synchronization component 301 includes a source tracing and synchronization module configured to: automatically identify load objects created by users in the virtual cluster, synchronize the task annotation metadata corresponding to the load object to the corresponding execution unit in the host cluster, and write the address annotation metadata corresponding to the load object into the execution unit. The task annotation metadata includes task priority and minimum task start batch, and the address annotation metadata includes the object identifier code corresponding to the load object. The source tracing and synchronization module is deployed in the control plane of the virtual cluster. The scheduling component 302 includes a scheduling module configured to: for each execution unit corresponding to the same object identifier code, read the task annotation metadata of each execution unit, and, based on the read task annotation metadata... The task annotation metadata dataset generates a scheduling score value for each execution unit. Based on the generated scheduling score value set and the minimum batch size of task startup included in the task annotation metadata set, each execution unit is batch-scheduled to the corresponding resource adaptation node. The scheduling module is deployed on the host cluster. Billing component 303 includes a billing module configured to generate a task billing statement for each execution unit in response to successful scheduling, based on the execution unit's task priority, cluster billing value, unit billing value, and task runtime. The task runtime is the duration from the time of successful task scheduling to the time of task scheduling end. The billing module is also deployed on the host cluster.

[0083] It is understandable that the units described in the virtual cluster-based group scheduling device 300 are related to the reference... Figure 1 The various modules in the described system correspond to each other. Therefore, the operations, characteristics, and beneficial effects described above for the system also apply to the virtual cluster-based group scheduling device 300 and the units contained therein, and will not be repeated here.

[0084] The following is for reference. Figure 4 It shows a schematic diagram of the structure of an electronic device 400 (e.g., a computing device) suitable for implementing some embodiments of the present disclosure. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0085] like Figure 4As shown, the electronic device 400 may include a processing unit 401 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. The random access memory 403 also stores various programs and data required for the operation of the electronic device 400. The processing unit 401, the read-only memory 402, and the random access memory 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0086] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 4 Each box shown can represent a device or multiple devices as needed.

[0087] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 409, or installed from a storage device 408, or installed from a read-only memory 402. When the computer program is executed by the processing device 401, it performs the functions defined in the methods of some embodiments of this disclosure.

[0088] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0089] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0090] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device: automatically identifies the load objects created by the user in the virtual cluster, synchronizes the task annotation metadata corresponding to the load objects to the corresponding execution units in the host cluster, and writes the address annotation metadata corresponding to the load objects into the execution units; for each execution unit corresponding to the same object identifier, reads the task annotation metadata of each execution unit, generates a scheduling score value corresponding to each execution unit based on the read task annotation metadata dataset, and schedules each execution unit to the corresponding resource adaptation node in batches based on the generated scheduling score value set and the minimum task start batch included in the task annotation metadata set. The aforementioned scheduling module is deployed in the host cluster; for each execution unit, in response to the successful scheduling of the aforementioned execution unit, generates a task billing statement based on the task priority, cluster billing value, unit billing value, and task runtime of the execution unit, wherein the task runtime is the duration from the time point of successful task scheduling of the aforementioned execution unit to the time point of task scheduling end. The aforementioned billing module is deployed in the host cluster.

[0091] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A group scheduling system based on a virtual cluster, characterized in that, include: The traceability and synchronization module is configured to: automatically identify the load objects created by the user in the virtual cluster, synchronize the task annotation metadata corresponding to the load objects to the corresponding execution units in the host cluster, and write the address annotation metadata corresponding to the load objects into the execution units. The task annotation metadata includes task priority and minimum batch size for task startup, and the address annotation metadata includes the object identifier code corresponding to the load objects. The traceability and synchronization module is deployed in the control plane of the virtual cluster. A scheduling module is configured to: for each execution unit corresponding to the same object identifier code, read the task annotation metadata of each execution unit; determine the priority score value corresponding to each execution unit in each execution unit according to the task priority included in the task annotation metadata set, and obtain a priority score value set; determine the node resource matching degree corresponding to each execution unit in each execution unit according to the current cluster resource status, and obtain a node resource matching degree set; calculate the scheduling score value corresponding to each execution unit in each execution unit using a multi-dimensional weight model according to the node resource matching degree set and the priority score value set; and schedule each execution unit to the corresponding resource adaptation node in batches according to the generated scheduling score value set and the minimum task start batch included in the task annotation metadata set, wherein the scheduling module is deployed on the host cluster; A billing module is configured to generate a task billing statement for each execution unit in response to successful scheduling of the execution unit, based on the task priority, cluster billing value, unit billing value, and task runtime of the execution unit. The task runtime is the duration from the time point when the task scheduling of the execution unit is successful to the time point when the task scheduling ends. The billing module is deployed on the host cluster.

2. The group scheduling system based on virtual clusters according to claim 1, characterized in that, Each execution unit with the same object identifier code corresponds to the same task queue. The step of batch scheduling each execution unit to the corresponding resource adaptation node based on the generated scheduling score set and the minimum task start batch included in the task annotation metadata set includes: The target batch is determined by the minimum batch size of the largest task in each execution unit. In response to determining that each execution unit meets preset computing resource conditions, it is determined whether the queue length of the task queue is greater than or equal to the target batch. In response to determining that the queue length of the task queue is greater than or equal to the target batch, each execution unit corresponding to the task queue is batch-scheduled to the corresponding resource adaptation node according to the generated scheduling score value set, so as to execute the corresponding task.

3. The group scheduling system based on virtual clusters according to claim 2, characterized in that, The step of batch scheduling each execution unit to the corresponding resource adaptation node based on the generated scheduling score set and the minimum task start batch included in the task annotation metadata set of the task annotation metadata set further includes: In response to determining that each execution unit does not meet the computing resource conditions, it is determined whether each execution unit in the task queue with a task priority higher than a preset priority meets the computing resource conditions; In response to determining that each execution unit in the task queue whose task priority is higher than the preset priority satisfies the computing resource conditions, each execution unit in the task queue whose task priority is lower than or equal to the preset priority is evicted in reverse order to generate a target task queue, wherein each execution unit corresponding to the target task queue satisfies the computing resource conditions; In response to determining that the length of the target task queue is greater than or equal to the target batch, each execution unit corresponding to the target task queue is batch-scheduled to the corresponding resource adaptation node according to the generated scheduling score value set.

4. The group scheduling system based on virtual clusters according to claim 3, characterized in that, For each execution unit, in response to successful scheduling, a task billing statement is generated based on the execution unit's task priority, cluster billing value, unit billing value, and task runtime, including: Determine the discount coefficient corresponding to the task priority included in the task annotation metadata of the execution unit; Based on the discount coefficient, the cluster billing value, the unit billing value, and the task runtime, a task billing bill is generated, and the task billing bill is pushed to the control plane of the corresponding virtual cluster and written to the billing database.

5. A group scheduling device based on a virtual cluster, characterized in that, include: The traceability synchronization component includes a traceability synchronization module, which is configured to: automatically identify the load objects created by the user in the virtual cluster, synchronize the task annotation metadata corresponding to the load objects to the corresponding execution units in the host cluster, and write the address annotation metadata corresponding to the load objects into the execution units. The task annotation metadata includes task priority and minimum batch size for task startup, and the address annotation metadata includes the object identifier code corresponding to the load objects. The traceability synchronization module is deployed in the control plane of the virtual cluster. A scheduling component, comprising a scheduling module, is configured to: for each execution unit corresponding to the same object identifier, read the task annotation metadata of each execution unit; determine the priority score value corresponding to each execution unit in each execution unit according to the task priority included in the task annotation metadata set, thereby obtaining a priority score value set; determine the node resource matching degree corresponding to each execution unit in each execution unit according to the current cluster resource status, thereby obtaining a node resource matching degree set; calculate the scheduling score value corresponding to each execution unit in each execution unit using a multi-dimensional weight model based on the node resource matching degree set and the priority score value set; and schedule each execution unit in batches to the corresponding resource adaptation node according to the generated scheduling score value set and the minimum task start batch included in the task annotation metadata set, wherein the scheduling module is deployed on the host cluster; A billing component, comprising a billing module configured to: for each execution unit, in response to successful scheduling of the execution unit, generate a task billing statement based on the task priority, cluster billing value, unit billing value, and task runtime of the execution unit, wherein the task runtime is the duration from the time point of successful task scheduling of the execution unit to the time point of task scheduling completion, and the billing module is deployed on the host cluster.

6. An electronic device, characterized in that, include: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the group scheduling system based on a virtual cluster as described in any one of claims 1 to 4.

7. A computer-readable medium, characterized in that, It stores a computer program, wherein the computer program, when executed by a processor, implements the group scheduling system based on a virtual cluster as described in any one of claims 1 to 4.

Images