Scheduling method, and system, computer program product and storage medium

Abstract

Provided in the embodiments of the present disclosure are a scheduling method, and a system, a computer program product and a storage medium. A second cluster management system originally used on a target cluster can be retained, and logical resource groups divided by the second cluster management system on the target cluster are mapped to virtual nodes in a container-based first cluster management system. On this basis, a user can submit task requirements in the first cluster management system, and the first cluster management system can create and schedule a container group, and if a target virtual node to which the container group is scheduled is mapped to a target logical resource group divided in the second cluster management system, a job task that meets the task requirements and conforms to a task format required by the second cluster management system can be submitted to the second cluster management system.

Description

[0001] A scheduling method, system, computer program product and storage medium

[0002]

[0001] The present disclosure relates to the technical field of cloud computing, and particularly relates to a scheduling method, system, computer program product and storage medium.

[0003]

[0002] High performance computing (HPC) clusters usually use Slurm system as a job scheduling and resource management system. Kubernetes, also known as k8s, is a container-based cluster management system used for container orchestration and management. Kubernetes has powerful container orchestration and management functions, and can automate the deployment, scaling and fault recovery of applications. It provides a more flexible and automated resource management mechanism, which can dynamically adjust and allocate resources according to the needs of applications.

[0004]

[0003] At present, it is expected that the flexibility and automation capability of Kubernetes can also cover HPC clusters. However, due to the specific hardware and network architecture of HPC clusters, precise resource scheduling and management are required, and therefore the default scheduler of Kubernetes is not suitable for HPC clusters and cannot meet the job scheduling requirements of HPC clusters in terms of priority and resource constraints.

[0005]

[0004] Aspects of the present disclosure provide a scheduling method, system, computer program product and storage medium to implement the coverage of container-based cluster management systems to more types of clusters.

[0006]

[0005] Embodiments of the present disclosure provide a scheduling method applicable to a first container-based cluster management system. A logical resource group divided by a second cluster management system adopted on a target cluster is mapped to a virtual node in the first cluster management system. The method comprises: creating a target container group for a task requirement submitted by a user in the first cluster management system; scheduling the target container group to a target virtual node meeting the task requirement; if the target virtual node is mapped to a target logical resource group divided by the second cluster management system, submitting a work task meeting the task requirement to the second cluster management system, so that the second cluster management system schedules the work task to the target logical resource group in the target cluster for execution; wherein the work task meets the task format required by the second cluster management system.

[0007]

[0006] Further, the method further comprises: creating a target container group for a task requirement submitted by a user in the first cluster management system, including: in response to monitoring that the user creates a custom workload resource based on the task requirement, creating a target container group for the custom workload resource; wherein the custom workload resource contains information items required in a task format required by the second cluster management system.

[0008]

[0007] Further, the first cluster management system is provided with a controller associated with the custom workload resource; in response to monitoring that the user creates a custom workload resource based on the task requirement, creating a target container group for the custom workload resource, including: monitoring the custom workload resource appearing in the first cluster management system by using the controller; creating a target container group for the monitored custom workload resource by using the controller.

[0009]

[0008] Further, the method further comprises: scheduling the target container group to a target virtual node meeting the task requirement, including: specifying a required target virtual node to which the target container group is scheduled in the target container group by using the controller, so as to schedule the target container group to the target virtual node.

[0010]

[0009] Further, the first cluster management system is provided with a logical resource group manager, and the method further comprises: monitoring an adding / deleting event of a logical resource group in the second cluster management system by using the logical resource group manager; creating / deleting a virtual node in the first cluster management system according to the monitored adding / deleting event.

[0011]

[0010] Further, the method further comprises: monitoring a resource water level state of a logical resource group in the second cluster management system by using the logical resource group manager; in a case where a change of the resource water level state of any logical resource group is monitored, updating a resource water level state corresponding to a virtual node mapped with the logical resource group in the first cluster management system.

[0012]

[0011] Further, the method further comprises: in a process in which the user submits the task requirement in the first cluster management system, showing the resource water level state corresponding to each virtual node to the user, so that the user indicates a required virtual node to be used in the task requirement based on the resource water level state as the target virtual node.

[0013]

[0012] Further, the second cluster management system is provided with an agent component for communicating with the first cluster management system; submitting a work task satisfying the task requirement to the second cluster management system comprises: generating, by the target virtual node, a work task conforming to a task format required by the second cluster management system based on the task requirement, the work task indicating execution in the target logical resource group; and submitting, by the target virtual node, the work task to the agent component in the second cluster management system, so that the agent component submits the work task to a task scheduler in the second cluster management system for task scheduling.

[0014]

[0013] Further, the method further comprises: obtaining, by the target virtual node, an execution status of the work task from the second cluster management system; updating, by the target virtual node, an execution status of the target container group according to the obtained execution status of the work task; and updating an execution status corresponding to the task requirement according to the state information of the target container group, for the user to query.

[0015]

[0014] Further, in addition to the target cluster, there is another cluster; a logical resource group divided in a cluster management system adopted by the other cluster is also mapped as a virtual node in the first cluster management system, to support the first cluster management system to submit a work task of a corresponding task format to the cluster management system adopted by the other cluster, so that the work task is scheduled to a logical resource group in the other cluster for execution.

[0016]

[0015] Further, the second cluster management system adopts a Slurm system, a load sharing scheduling system or a portable batch processing system, and the target cluster adopts a high-performance computing cluster.

[0017]

[0016] Further, the target container group does not occupy physical resources, and the virtual node in the first cluster management system also does not occupy physical resources.

[0018]

[0017] The embodiments of the present disclosure also provide a cluster management system, which is container-based, a logical resource group divided by a second cluster management system adopted by a target cluster is mapped as a virtual node in the cluster management system, and the cluster management system is used to execute the foregoing scheduling method, so as to submit a work task conforming to a required task format to the second cluster management system based on a task requirement submitted by a user in the cluster management system, and make the work task execute in a target logical resource group in the target cluster.

[0019]

[0018] The embodiments of the present disclosure further provide a computer readable storage medium storing a computer program, which, when executed by one or more processors, causes the one or more processors to perform the foregoing scheduling method.

[0020]

[0019] The embodiments of the present disclosure further provide a computer program product, comprising a computer program, which, when executed by one or more processors, causes the one or more processors to perform the foregoing scheduling method.

[0021]

[0020] In the embodiments of the present disclosure, for a target cluster expected to be covered, the second cluster management system originally used on the target cluster can be reserved, and the physical resources in the target cluster do not need to be managed into the first cluster management system based on containers, but the first cluster management system is used as a control plane to communicate to the second cluster management system originally used on the target cluster in a bridging manner. Under this concept, the logical resource groups divided by the second cluster management system on the target cluster can be mapped to virtual nodes in the first cluster management system, and the work tasks known by the second cluster management system can be abstracted as container groups in the first cluster management system. Based on this, a user can submit a task requirement in the first cluster management system, and the first cluster management system can create and schedule a container group. If the target virtual node scheduled is mapped to the logical resource group divided by the second cluster management system, a work task meeting the task requirement and conforming to the required task format can be submitted to the second cluster management system. In this way, the second cluster management system can manage the task requirement submitted by the user in the first cluster management system and complete the processing on the target cluster. Accordingly, the cluster management system based on containers can be seamlessly covered to more types of clusters.

[0022]

[0021] The accompanying drawings, which are included to provide a further understanding of the present disclosure and constitute a part of the present disclosure, illustrate certain illustrative embodiments of the present disclosure and are used to explain the present disclosure, but do not limit the present disclosure. In the drawings:

[0023]

[0022] FIG. 1 is a flowchart of a scheduling method according to an illustrative embodiment of the present disclosure;

[0024]

[0023] FIG. 2 is a logic diagram of a scheduling method according to an illustrative embodiment of the present disclosure;

[0025]

[0024] FIG. 3 is a logic diagram of an optional implementation of a scheduling method according to an illustrative embodiment of the present disclosure;

[0026]

[0025] FIG. 4 is an optional logic diagram of a scheduling method according to an example embodiment of the present disclosure;

[0027]

[0026] FIG. 5 is a structural diagram of a cluster management system according to another example embodiment of the present disclosure. DETAILED DESCRIPTION

[0028]

[0027] For the purpose of making the objectives, technical solutions and advantages of the present disclosure clearer, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the corresponding drawings of the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by a person of ordinary skill in the art without creative labor fall within the protection scope of the present disclosure.

[0029]

[0028] Before starting to describe the technical solutions provided by the embodiments of the present disclosure in detail, several technical concepts involved in the present disclosure are explained simply as follows.

[0030]

[0029] Kubernetes, or k8s, is a container-based cluster management system for container orchestration and management. Kubernetes has powerful container orchestration and management functions, and can automate the deployment, scaling and fault recovery of applications. It provides a more flexible and automated resource management mechanism, and can dynamically adjust and allocate resources according to the needs of applications.

[0031]

[0030] Slurm, which stands for Simple Linux Utility for Resource Management, is an open-source cluster management and job scheduling system for task scheduling and resource management in high-performance computing (HPC) environments.

[0032]

[0031] High performance computing (HPC) is a technology that uses high-performance servers (such as supercomputers, etc.) to realize parallel computing, and is a theory, method, technology and application of parallel computing.

[0033]

[0032] HPC cluster, which can be understood as a server cluster capable of performing high-performance computing. The servers in the HPC cluster are usually high-performance servers as described above.

[0033] As introduced in the background, the Slurm system is usually used on the HPC cluster as a job scheduling and resource management system. The inventors found in the research process that when the HPC cluster needs to be used to perform tasks, the user needs to create an HPC job in the native command line interface of the Slurm system, which brings a relatively high learning cost to the user. In addition, the inventors found that the cluster management system used on the HPC cluster is not limited to the Slurm system, but there are many other system types, such as Load Sharing Facility (LSF) or Portable Batch System (PBS), etc. For different cluster management systems, the user needs to learn the interaction knowledge respectively, which further increases the learning cost of the user. In addition, in addition to the HPC cluster, other types of clusters may also need to be used, and the types of cluster management systems used on other types of clusters are more diversified, which further aggravates the learning cost of the user.

[0034]

[0034] Therefore, the inventors expect to cover various types of clusters through a cluster management system familiar to the user to reduce the learning cost of the user. However, the inventors found in the research process that because different types of clusters usually have specific hardware and network architecture, the native scheduler in the unified cluster management system cannot be directly applied to various types of clusters. Accordingly, how to ensure that the unified cluster management system can be applied to various types of clusters becomes a technical problem to be solved.

[0035]

[0035] In order to solve the technical problem, a scheduling method is proposed in the embodiment, a container-based cluster management system is selected as a unified cluster management system, and it is proposed to retain the cluster management system originally used on various types of clusters, and use the container-based cluster management system as a control plane to adaptively connect the cluster management system originally used on various types of clusters.

[0036]

[0036] Under the guidance of this technical concept, the inventors further particularize the technical problem as how to adaptively connect other types of cluster management systems in the container-based cluster management system, and propose a technical solution.

[0037]

[0037] The technical solutions provided by the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0038]

[0038] FIG. 1 is a flowchart of a scheduling method provided by an example embodiment of the present disclosure, which can be executed by a container-based cluster management system that can be implemented as software, hardware, or a combination of software and hardware.

[0039]

[0039] In this embodiment, the container-based cluster management system can be the aforementioned Kubernetes, and of course, the present embodiment is not limited thereto. Other systems that perform scheduling and resource management based on containers can also be the execution subject in this embodiment, and no more examples are given here.

[0040]

[0040] The inventors have found in the research process that in a container-based cluster management system, a pod is used as the basic deployment unit. In a container-based cluster management system, the scheduling principle is roughly as follows: containers can be placed in a pod, and the pod is scheduled to a suitable node to execute a workload.

[0041] The inventors have also found in the research process that in other types of cluster management systems, logical resource groups are usually divided on the physical resources of the cluster, and received work tasks are usually scheduled to suitable logical resource groups to execute workloads through the physical resources occupied by the logical resource groups. For example, the logical resource groups divided in the aforementioned Slurm system are usually partitions, and the logical resource groups divided in the aforementioned LSP system are usually queues, and no more examples are given here.

[0041]

[0042] Based on this, in this embodiment, the logical resource groups divided in other types of cluster management systems can be abstracted as virtual nodes in a container-based cluster management system, and the work tasks required to be scheduled in other types of cluster management systems can be abstracted as pods in a container-based cluster management system. In this way, scheduling in a container-based cluster management system according to its own scheduling principle can reflect which logical resource group a work task should be scheduled to in other types of cluster management systems, thereby ensuring that a container-based cluster management system can provide accurate scheduling guidance for other types of cluster management systems.

[0042]

[0043] It should be noted that the node in the first cluster management system can be a physical machine or a virtual machine, etc. The virtual node in the embodiment has the attributes of the node in the first cluster management system, but the difference is that the virtual node in the embodiment does not occupy physical resources. That is, after the first cluster management system creates the virtual node, it does not need to allocate physical resources to the virtual node. The virtual node in the embodiment will not occupy the physical resources in the target cluster, nor will it occupy the physical resources managed by the first cluster management system. The virtual node in the embodiment can be understood as a process / thread.

[0043]

[0044] FIG. 2 is a logical schematic diagram of a scheduling method provided by an exemplary embodiment of the present disclosure. Referring to FIG. 2, for ease of description, the container-based cluster management system will be described as the first cluster management system in the following, and the description of the technical solutions will be based on any cluster that is expected to be covered as an example. In the following, the cluster of the example will be described as the target cluster, and the cluster management system used on the cluster of the example will be described as the second cluster management system.

[0044]

[0045] Exemplarily, the target cluster can be a high-performance computing (HPC) cluster, and the second cluster management system used on the target cluster can use a slurm system, an LSP system, or a PBS system, etc.

[0045]

[0046] It should be noted that, as mentioned above, the first cluster management system in the embodiment mainly serves as a control plane, and therefore, in the embodiment, the physical resources in the target cluster do not need to be managed in the first cluster management system, but can be managed in the second cluster management system originally used.

[0046]

[0047] On this basis, referring to FIG. 1, the method can include the following steps.

[0047]

[0048] Step 100, creating a target container group for a task demand submitted by a user in the first cluster management system.

[0049] Step 101, scheduling the target container group to a target virtual node that meets the task demand.

[0048]

[0050] In step 102, if the target virtual node is mapped to a target logical resource group divided in the second cluster management system, a work task meeting the task requirement is submitted to the second cluster management system, so that the second cluster management system schedules the work task to the target logical resource group in the target cluster for execution; wherein, the work task meets the task format required by the second cluster management system.

[0049]

[0051] In this embodiment, in step 100, the user can submit a task requirement in the first cluster management system. It should be understood that in this embodiment, the user only needs to learn the interaction knowledge in the first cluster management system, which can effectively reduce the learning cost of the user. For example, the user only needs to learn how to use Kubernetes, and does not need to learn to use the aforementioned Slurm or LSP system.

[0050]

[0052] The task requirement is used to reflect the physical resource specification expected to be used by the user and the work content expected to be completed, etc. The user can submit the task requirement according to the original interactive mode in the first cluster management system. It should be understood that the scheduling method provided in this embodiment is different from the original scheduling logic in the first cluster management system, so in step 100, the task requirement submitted by the user is different from the task requirement that needs to be processed on the physical resource managed by the first cluster management system, so as to trigger the first cluster management system to process it by using the scheduling method in this embodiment, instead of processing it according to the original scheduling logic. In this embodiment, a plurality of implementation manners can be used to support the specificity of the task requirement in step 100. An exemplary implementation manner is provided below.

[0051]

[0053] The inventors found in the research process that in the first cluster management system, everything is usually shown as a resource object (Resource), such as the container group mentioned above, and the first cluster management system is shown as a kind of resource object. Moreover, the first cluster management system usually provides an extension mechanism, i.e., a custom resource definition (CRD), which allows new resource types to be customized on demand.

[0052]

[0054] FIG. 3 is a logic diagram illustrating an optional implementation of a scheduling method according to an example embodiment of the present disclosure. Referring to FIG. 3, based on the extension mechanism, the example implementation can be that the first cluster management system extends a custom workload resource for the second cluster management system, where the custom workload resource can contain the information items required in the task format required by the second cluster management system. For example, if the second cluster management system is a Slurm cluster, the custom workload resource can contain various information items required in a Slurm job.

[0053]

[0055] Based on this, in the example implementation, the first cluster management system can present a task requirement submission page to the user, where the information items required in the task format required by the second cluster management system are provided as information items to be filled in by the user, so as to ensure that the custom workload resource created contains at least the information items required in the task format required by the second cluster management system.

[0054]

[0056] It is worth noting that there are various workload resources in the first cluster management system by default, such as Deployment, Replica Set, and StatefulSet. In the above example implementation, a new workload resource is customized for the second cluster management system. In addition, it is worth noting that considering that the task formats required by different types of cluster management systems are not completely the same, different workload resources can be customized for different types of cluster management systems in the first cluster management system, so as to ensure that the required information items can be comprehensively collected in the corresponding workload resources.

[0055]

[0057] The inventors have found in the research process that the first cluster management system supports using a workload resource to trigger the creation of a container group. Based on this, in the above example implementation, in step 100, the first cluster management system can create a target container group for the custom workload resource in response to monitoring that the user creates the custom workload resource based on the task requirement.

[0056]

[0058] Further, referring to FIG. 3, in the above example implementation, it is further proposed that a controller associated with the custom workload resource can be set in the first cluster management system, based on which, the controller can monitor the custom workload resource occurred in the first cluster management system, and be responsible for creating the target container group for the monitored custom workload resource. For example, in Kubernetes, the controller here can be implemented as an operator. The operator is an extension software of Kubernetes, which can manage applications and their components by using custom resource objects, and the implementation principle of the operator will not be elaborated here. In addition, in the first cluster management system, different controllers can be associated for different custom workload resources set for different types of cluster management systems.

[0057]

[0059] It should be understood that the above example implementation is optional, and in the present embodiment, other implementation manners can also be adopted in step 100 to support the particularity of the task requirement. For example, a special process can be set in the first cluster management system to guide the user to input the required information item for different cluster management systems, and a custom resource can be created based on the collected information item, which can be used to trigger the first cluster management system to create a container group, and in addition, the custom resource is no longer limited to the workload resource. No more details will be given here, and no more examples will be given.

[0058]

[0060] It is worth emphasizing that in the present embodiment, the target container group created in step 100 does not occupy physical resources, that is, after the first cluster management system creates the target container group, it does not need to allocate physical resources for the target container group. Therefore, the target container group created in step 100 will not occupy the physical resources in the target cluster; if the first cluster management system manages physical resources, the target container group will also not occupy the physical resources managed by the first cluster management system.

[0059]

[0061] With reference back to FIG. 1, in step 101, the first cluster management system can schedule the target container group to a target virtual node that meets the task requirement submitted by the user. In this regard, considering that other types of cluster management systems usually support user to specify the logical resource group desired to be used, in step 100, the first cluster management system also adaptively supports user to indicate the virtual node desired to be used in the task requirement. In this way, in step 101, the target container group can be scheduled to the virtual node indicated in the task requirement as the target virtual node. Of course, if the virtual node desired to be used is not indicated in the task requirement, in step 101, the first cluster management system can filter out the target virtual node that meets the task requirement submitted by the user based on the information about the physical resource specification desired to be used reflected in the task requirement and the scheduling strategy in the scheduling logic native to the first cluster management system.

[0060]

[0062] With reference to FIG. 3, continuing the controller associated with the custom workload resource in the foregoing exemplary implementation, in step 101, the controller can specify the target virtual node desired to be scheduled to in the target container group to schedule the target container group to the target virtual node.

[0061]

[0063] In this embodiment, the virtual nodes and the logical resource groups are mapped, and the first cluster management system can record this mapping relationship. For each logical resource group divided by the second cluster management system on the target cluster, a mapped virtual node is created in the first cluster management system. In this way, the target virtual node hit in step 101 will have a mapped logical resource group.

[0062]

[0064] With reference back to FIG. 1, in step 102, if the target virtual node is mapped to the target logical resource group divided by the second cluster management system, it can be determined that the work task needs to be submitted to the second cluster management system.

[0063]

[0065] Here, in this embodiment, the processing logic for creating the work task in the required task format is encapsulated in each virtual node. For example, the target virtual node described above encapsulates the processing logic for creating the work task in the required task format of the second cluster management system. Based on this, in step 102, the target virtual node can be used to submit the work task to the second cluster management system, of course, this is optional, and the execution subject of the operation of submitting the work task is not limited in this embodiment, and the operation can also be implemented by other components in the first cluster management system.

[0064]

[0066] Thus, in this embodiment, in step 102, for the target virtual node, a work task in a task format required by the second cluster management system can be generated based on the task requirement submitted by the user. Here, the target virtual node will indicate that the work task needs to be executed in the target logical resource group. It should be understood that the target virtual node can record the target logical resource group to which it is mapped, and when generating the work task, the identifier of the target logical resource group is written into the corresponding field in the work task.

[0065]

[0067] Up to now, the work task in the task format required by the second cluster management system has been generated on the target virtual node in the first cluster management system, and the work task can accurately reflect the task requirement submitted by the user.

[0068] Referring to FIG. 2, the target virtual node can submit the generated work task to the second cluster management system as the management and control outlet of the first cluster management system. Thus, the second cluster management system will receive the work task in the task format required by itself.

[0066]

[0069] On this basis, the second cluster management system can schedule the work task submitted by the target virtual node according to its original scheduling logic. Since the work task indicates that it needs to be executed in the target logical resource group, the second cluster management system can schedule the work task to the target logical resource group allocated on the target cluster, so that the work task will be executed on the physical resources occupied by the target logical resource group in the target cluster.

[0067]

[0070] It can be seen that, from the perspective of the user, in this embodiment, the user submits a task requirement in the first cluster management system, and only needs to learn the interaction knowledge of the first cluster management system. The user has no awareness of the second cluster management system used on the target cluster. From the perspective of the first cluster management system, the virtual node created therein is used to bridge different types of cluster management systems, and the virtual node can generate a work task in a suitable format and accurately guide other types of cluster management systems to schedule the work task to the logical resource group expected by the user. From the perspective of the second cluster management system, it can receive a work task in a task format required by itself from the first cluster management system, and the work task has indicated the target logical resource group required. Therefore, the second cluster management system can schedule the work task to the target logical resource group for execution according to its original scheduling logic.

[0068]

[0071] It is worth noting that Figure 4 is a schematic diagram of an optional scheduling method provided by an exemplary embodiment of the present disclosure. Referring to Figure 4, the first cluster management system in the present embodiment can cover multiple clusters, and the types of cluster management systems used on different clusters can be different. That is, in addition to the target cluster, there are other clusters. Moreover, the logical resource groups divided in the cluster management systems used on the other clusters are also mapped as virtual nodes in the first cluster management system to support the first cluster management system to submit work tasks in the corresponding task format to the cluster management systems used on the other clusters, so that the work tasks are scheduled to the logical resource groups in the other clusters for execution.

[0069]

[0072] In summary, in the present embodiment, for the target cluster expected to be covered, the second cluster management system originally used on the target cluster can be retained, and the physical resources in the target cluster do not need to be managed into the container-based first cluster management system, but the first cluster management system acts as a control plane and is connected to the second cluster management system originally used on the target cluster in a bridging manner. Under this concept, the logical resource groups divided by the second cluster management system on the target cluster can be mapped as virtual nodes in the first cluster management system, and the work tasks recognized by the second cluster management system can be abstracted as container groups in the first cluster management system. Based on this, the user can submit task requirements in the first cluster management system, and the first cluster management system can create and schedule container groups. If the target virtual node scheduled is mapped to the logical resource group divided in the second cluster management system, the second cluster management system can be submitted a work task that meets the task requirements and conforms to the required task format. In this way, the second cluster management system can take over the task requirements submitted by the user in the first cluster management system and complete the processing on the target cluster. Accordingly, the container-based cluster management system can be seamlessly covered to more types of clusters.

[0070]

[0073] In the above or the following embodiments, the first cluster management system can create a virtual node that is mapped to each logical resource group divided by the second cluster management system on the target cluster.

[0071]

[0074] Referring to Figure 3, the first cluster management system can be provided with a logical resource group manager. Based on this, the logical resource group manager can monitor the addition and deletion events of the logical resource groups in the second cluster management system, and be responsible for creating / deleting virtual nodes in the first cluster management system according to the monitored addition and deletion events.

[0072]

[0075] In this way, the virtual node creation process in the first cluster management system can be described as follows.

[0073]

[0076] The K logical resource group manager can request the second cluster management system to query information of all logical resource groups at fixed time intervals.

[0074]

[0077] 2. For each logical resource group existing in the second cluster management system, it is checked whether a corresponding virtual node already exists in the first cluster management system, and if not, a virtual node is created for the logical resource group, and a mapping relationship is recorded.

[0075]

[0078] 3. If it is queried that a certain logical resource group in the second cluster management system has been deleted, the virtual node in the first cluster management system mapped to the logical resource group is also deleted.

[0076]

[0079] This can effectively ensure that the virtual nodes in the first cluster management system are mapped to the logical resource groups divided in other cluster management systems and have a synchronous life cycle.

[0077]

[0080] In addition, the first cluster management system can also support monitoring of the resource water level state of each logical resource group divided in the second cluster management system. For this purpose, the resource water level state of each logical resource group in the second cluster management system can be mapped to the virtual node corresponding to it in the first cluster management system, so as to reveal the resource water level state of the corresponding logical resource group in the second cluster management system through the virtual node.

[0078]

[0081] In an optional implementation scheme: the logical resource group manager can monitor the resource water level state of the logical resource group in the second cluster management system; in the case where the resource water level state of any logical resource group changes, the logical resource group manager can update the resource water level state corresponding to the virtual node mapped to the logical resource group in the first cluster management system. In actual application, there is usually an interface APL for maintaining the resource water level state on each node in the first cluster management system. Based on this, in the case where the resource water level state of a certain logical resource group changes, the logical resource group manager can trigger the virtual node mapped to the logical resource group to call such an interface APL to update the resource water level state maintained for the virtual node in the first cluster management system.

[0079]

[0082] It can be understood that in the embodiment, the virtual nodes in the first cluster management system do not occupy physical resources, therefore, the first cluster management system will no longer record the actual resource water level state for the virtual nodes, but through the mapping operation described above, the resource water level state of the logical resource group is mapped to the corresponding virtual node. In this way, in the first cluster management system, the resource water level state of the virtual node is essentially exposed as the resource water level state of the logical resource group mapped thereto.

[0080]

[0083] On this basis, the embodiment further proposes that in the process that the user submits the task demand in the first cluster management system, the user can be shown the resource water level state corresponding to each virtual node, so that the user can specify the virtual node to be used based on the resource water level state as the target virtual node.

[0081]

[0084] In addition, the resource water level state maintained for the virtual node in the embodiment can also be used as a reference basis in the native scheduling logic of the first cluster management system, so that in the case that the virtual node is not specified in the task demand, it can be ensured that the target virtual node hit by the task demand can meet the resource specification expected to be used in the task demand, and further ensure that the second cluster management system can schedule the work task corresponding to the task demand to the logical resource group with sufficient resource water level.

[0082]

[0085] The resource water level state maintained for the virtual node in the embodiment can also be used as a reference basis in the native scheduling logic of the first cluster management system, so that in the case that the virtual node is not specified in the task demand, it can be ensured that the target virtual node hit by the task demand can meet the resource specification expected to be used in the task demand, and further ensure that the second cluster management system can schedule the work task corresponding to the task demand to the logical resource group with sufficient resource water level.

[0083]

[0086] Further, the embodiment further proposes that in addition to supporting the submission of work tasks to various cluster management systems according to task demands, the first cluster management system can also support monitoring the execution state of each work task submitted externally.

[0084]

[0087] To this end, in the embodiment, taking the target virtual node as an example, the target virtual node can obtain the execution state of the submitted work task from the second cluster management system; and the target virtual node updates the execution state of the target container group according to the obtained execution state of the work task. On this basis, the first cluster management system can update the execution state corresponding to the task demand according to the state information of the target container group, for the user to query.

[0085]

[0088] Referring to FIG. 3, in the example implementation provided in the foregoing, the target container group can be updated according to the state information of the work task monitored from the second cluster management system, and the field value recorded in the state field of the target container group corresponding to the work task can be updated to update the execution state of the target container group. After the controller associated with the custom workload resource set by the second cluster management system monitors the change of the field value in the state field in the target container group, the field value recorded in the state field in the corresponding custom workload resource created by the user can be updated to update the execution state of the custom workload resource.

[0086]

[0089] In an example practical application scheme, the target virtual node can update the field value recorded in the state field of the target container group corresponding to the work task according to the execution state of the work task monitored from the second cluster management system, so as to update the execution state of the target container group. After the controller associated with the custom workload resource set by the second cluster management system monitors the change of the field value in the state field in the target container group, the field value recorded in the state field in the corresponding custom workload resource created by the user can be updated to update the execution state of the custom workload resource.

[0087]

[0090] In addition, referring to FIG. 3, in the embodiment, the first cluster management system also deploys an agent component in each cluster management system required to be covered. Taking the second cluster management system adopted in the target cluster as an example, referring to FIG. 3, the agent component in the second cluster management system can be in communication connection with each native component in the second cluster management system, so as to obtain the resource level state of each logical resource group divided by the second cluster management system and the execution state of the work task and the like from these native components. In addition, these native components include the native scheduler in the second cluster management system, so that the target virtual node in the first cluster management system can submit a work task to the agent component in the second cluster management system, and the agent component can transfer the received work task to the native scheduler in the second cluster management system, so that the native scheduler schedules the work task to the target logical resource group for execution.

[0088]

[0091] It should be understood that, considering the difference in the interaction logic required by the native components in different types of cluster management systems, in the embodiment, different agent components can be designed for different types of cluster management systems to ensure the adaptability between the agent components and the cluster management systems, so as to ensure that the first cluster management system can realize the bridging between other cluster management systems through the agent components and the virtual nodes.

[0089]

[0092] Based on this, taking the first cluster management system as a Kubernetes system and the second cluster management system as a Slurm system as an example, the process of submitting and monitoring Slurm jobs in the Kubernetes system can be described as follows.

[0090]

[0093] 1. A user creates a custom workload resource corresponding to Slurm in the Kubernetes system.

[0091]

[0094] 2. The controller Operatr associated with the custom workload resource can monitor the appearance of a new custom workload resource in the Kubernetes system. The Operatr can parse the information items contained in the custom workload resource to understand the user's task requirements and create one or more target container groups, and specify the target virtual nodes to which the target container groups need to be scheduled inside the target container groups created.

[0092]

[0095] 3. The target virtual node creates a Slurm job for the target container group scheduled to the node and submits it to the agent component in the Slurm cluster. The target virtual node can also request the execution status of the Slurm job from the agent component in the Slurm cluster at fixed time intervals and synchronize the execution status of the target container group. The target virtual node can also be responsible for reading the log content of the Slurm job through the agent component in the Slurm cluster.

[0093]

[0096] 4. The aforementioned Operator can monitor the execution status of the target container group (e.g., Completed, Succeeded, Fail, etc.) and synchronize the execution status of the custom workload resource created by the aforementioned user.

[0094]

[0097] In summary, in this embodiment, not only can various types of work tasks be submitted in the first cluster management system, but the execution status of each submitted work task can also be monitored in the first cluster management system, and the physical resource usage in each cluster covered can also be indirectly exposed in the first cluster management system. This can enable the first cluster management system to exhibit its flexibility and automation capabilities.

[0095]

[0098] Several exemplary application scenarios suitable for the scheduling method of this embodiment are provided below.

[0096]

[0099] In an exemplary application scenario: the Kubernetes system is adopted as a scheduling and resource management system on the first cluster, and the first cluster is not a high-performance computing cluster. When a user needs to process an AI inference task, the physical resources in the first cluster are insufficient to support the completion of the AI inference task. In this case, the second cluster (a high-performance computing cluster) can be used as an external cluster of the first cluster by using the scheduling method provided in this embodiment. Assuming that the Slurm system is adopted as a scheduling and resource management system on the external cluster, the Slurm system can be bridged to the Kubernetes system according to the scheduling method provided in this embodiment.

[0097]

[0100] In this exemplary application scenario, a user can submit a task requirement to the Kubernetes system, and the Kubernetes system can submit a Slurm job to the Slurm system on the external cluster through a virtual node based on the scheduling method provided in this embodiment, so that the Slurm system schedules the Slurm job to a partition corresponding to the virtual node.

[0098]

[0101] It can be seen that, based on the scheduling method provided in this embodiment, the AI inference task that the user needs to process can be scheduled to the external cluster without obstacles, so that the physical resources of the external cluster can be used to process the AI inference task without the user's awareness.

[0099]

[0102] In another exemplary application scenario, the Kubernetes system does not manage any physical cluster, but only serves as a control plane. Multiple physical clusters can retain their respective cluster management systems, and these cluster management systems can be bridged to the Kubernetes system according to the scheduling method provided in this embodiment. Based on this, a user can submit a task requirement in the Kubernetes system, and the Kubernetes system can schedule the task requirement to a suitable virtual node by creating and scheduling a container group, and the virtual node can submit a work task to a cluster management system on a corresponding physical cluster through bridging, thereby scheduling the work task to a corresponding logical resource group on the physical cluster.

[0100]

[0103] It can be seen that, based on the scheduling method provided in this embodiment, a task requirement submitted by a user can be flexibly scheduled to a suitable physical cluster by the Kubernetes system, and further scheduled to a suitable logical resource group in the physical cluster to complete the processing of the task requirement.

[0101]

[0104] It should be understood that the above application scenarios are only exemplary, and the embodiments are not limited thereto. The scheduling method provided by the embodiments can also be applicable to other application scenarios, and no more examples are given herein.

[0102]

[0105] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that these operations can be executed or executed in parallel without the order in which they appear in this text. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and these operations can be executed in sequence or in parallel. It should be noted that the "first", "second", and the like described herein are used to distinguish different clusters, cluster management systems, etc., and do not represent the order of precedence, nor do they limit that the "first" and "second" are different types.

[0103]

[0106] FIG. 5 is a structural schematic diagram of a cluster management system according to another exemplary embodiment of the present disclosure. As shown in FIG. 5, the cluster management system can include a management and control component 50 and a virtual node. For ease of description, the cluster management system in FIG. 5 will be described as a first cluster management system. In the present embodiment, the first cluster management system is container-based, and the logical resource group divided in the second cluster management system adopted in the target cluster can be mapped to a virtual node in the first cluster management system.

[0104]

[0107] The management and control component 50 can be configured to create a target container group for a task requirement submitted by a user in the first cluster management system, schedule the target container group to a target virtual node 60 that meets the task requirement, and if the target virtual node 60 is mapped to a target logical resource group divided in the second cluster management system, submit a work task that meets the task requirement to the second cluster management system, so that the second cluster management system schedules the work task to the target logical resource group in the target cluster for execution. The work task meets the task format required by the second cluster management system.

[0105]

[0108] In an optional embodiment, the management component 50 can be specifically configured to, when creating a target container group for a task requirement submitted by a user in the first cluster management system: in response to monitoring that the user creates a custom workload resource based on the task requirement, create a target container group for the custom workload resource; wherein the custom workload resource contains information items required in a task format required by the second cluster management system.

[0106]

[0109] In an optional embodiment, the management component 50 can further include a controller 51 associated with the custom workload resource; the controller 51 can be specifically configured to: monitor the custom workload resource in the first cluster management system; and create a target container group for the monitored custom workload resource.

[0107]

[0110] In an optional embodiment, the controller 51 can be further specifically configured to: specify a target virtual node to which scheduling is required in the target container group, so as to schedule the target container group to the target virtual node.

[0108]

[0111] In an optional embodiment, the management component 50 can further include a logical resource group manager 52, which can be configured to: monitor addition and deletion events of logical resource groups in the second cluster management system; and create / delete virtual nodes in the first cluster management system according to the monitored addition and deletion events.

[0109]

[0112] In an optional embodiment, the logical resource group manager 52 can be further configured to: monitor resource water level states of logical resource groups in the second cluster management system; and in the case that a change in the resource water level state of any logical resource group is monitored, update the resource water level state corresponding to the virtual node mapped to the logical resource group in the first cluster management system.

[0110]

[0113] In an optional embodiment, the management component 50 can be further configured to: during the process in which the user submits the task requirement in the first cluster management system, display the resource water level state corresponding to each virtual node to the user, so that the user indicates the required virtual node to be used in the task requirement based on the resource water level state.

[0111]

[0114] In an optional embodiment, the second cluster management system is provided with an agent component 70 for communicating with the first cluster management system; the target virtual node 60 can be configured to: based on the task requirement, generate a work task in a task format required by the second cluster management system, the work task indicating execution in the target logical resource group; and submit the work task to the agent component 70 in the second cluster management system, so that the agent component 70 submits the work task to a task scheduler in the second cluster management system for task scheduling.

[0112]

[0115] In an optional embodiment, the target virtual node 60 can also be configured to: acquire an execution status of the work task from the second cluster management system; and update the execution status of the target container group according to the acquired execution status of the work task; and the controller 51 can also be configured to: update the execution status corresponding to the task requirement according to the status information of the target container group, for the user to query.

[0113]

[0116] In an optional embodiment, in addition to the target cluster, there is another cluster; a logical resource group divided in a cluster management system adopted by the other cluster is also mapped as a virtual node in the first cluster management system, to support the first cluster management system to submit a work task in a corresponding task format to the cluster management system adopted by the other cluster, so that the work task is scheduled to a logical resource group in the other cluster for execution.

[0114]

[0117] In an optional embodiment, the second cluster management system adopts a Slurm system, a load sharing scheduling system or a portable batch system, and the target cluster adopts a high-performance computing cluster.

[0115]

[0118] In an optional embodiment, the target container group does not occupy physical resources, and the virtual node in the first cluster management system also does not occupy physical resources.

[0116]

[0119] Further, only some components are shown in FIG. 5, which does not mean that the cluster management system only includes the components shown in FIG. 5. Each component involved in the cluster management system can be deployed in a container in the cluster management system.

[0117]

[0120] It is worth noting that the technical details in the above embodiments of the cluster management system can refer to the above-mentioned related descriptions of the first cluster management system in the method embodiments, and for the sake of brevity, will not be repeated here, but this should not cause the loss of the protection scope of the present disclosure.

[0118]

[0121] Accordingly, the embodiments of the present disclosure also provide a computer readable storage medium storing a computer program, the computer program being capable of implementing each step in the above method embodiments when executed.

[0119]

[0122] Accordingly, the embodiments of the present disclosure also provide a computer program product, the computer program included in the computer program product being capable of implementing each step in the above method embodiments when executed.

[0120]

[0123] Those skilled in the art will understand that the embodiments of the present disclosure can be provided as a method, a system, or a computer program product. Therefore, the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) containing computer usable program code.

[0121]

[0124] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions specified in the flowchart one or more flows and / or block diagram one or more blocks.

[0122]

[0125] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including instruction means, which implement the functions specified in the flowchart one or more flows and / or block diagram one or more blocks.

[0123]

[0126] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operational steps are performed on the computer or other programmable data processing apparatus to generate a computer implemented process, so that the instructions executed on the computer or other programmable data processing apparatus provide steps for implementing the functions specified in the flowchart one or more flows and / or block diagram one or more blocks.

[0124]

[0127] It should also be noted that the terms "comprising", "containing", or any other similar term are intended to encompass non-exclusive inclusions, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements, but can also include other elements not expressly listed, or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the phrase "comprising a" does not exclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0125]

[0128] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present disclosure are information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0126]

[0129] The above only describes the embodiments of the present disclosure and is not intended to limit the present disclosure. The present disclosure can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

CLAIM 1. A scheduling method, applicable to a first container-based cluster management system; The logical resource group divided by the second cluster management system adopted on the target cluster is mapped to a virtual node in the first cluster management system, and the method comprises: creating a target container group for a task demand submitted by a user in the first cluster management system; scheduling the target container group to a target virtual node meeting the task demand; if the target virtual node is mapped to a target logical resource group divided by the second cluster management system, submitting a work task meeting the task demand to the second cluster management system, so that the second cluster management system schedules the work task to the target logical resource group in the target cluster for execution; wherein the work task meets the task format required by the second cluster management system.

2. The method of claim 1, wherein, The target container group is created for the task demand submitted by the user in the first cluster management system, comprising: in response to monitoring that the user creates a custom workload resource based on the task demand, creating a target container group for the custom workload resource; wherein the custom workload resource contains information items required in the task format required by the second cluster management system.

3. The method of claim 2, wherein, The first cluster management system is provided with a controller associated with the custom workload resource; in response to monitoring that the user creates a custom workload resource based on the task demand, creating a target container group for the custom workload resource, comprising: monitoring the custom workload resource appearing in the first cluster management system by using the controller; creating a target container group for the monitored custom workload resource by using the controller.

4. The method according to claim 3, wherein, The target container group is scheduled to the target virtual node meeting the task demand, comprising: specifying the target virtual node required to be scheduled in the target container group by using the controller, so as to schedule the target container group to the target virtual node.

5. The method of claim 1, wherein, The first cluster management system is provided with a logical resource group manager, and the method further comprises: monitoring the addition and deletion events of the logical resource group in the second cluster management system by using the logical resource group manager; creating / deleting a virtual node in the first cluster management system according to the monitored addition and deletion events.

6. The method of claim 5, further comprising: Monitoring the resource water level state of the logical resource group in the second cluster management system by using the logical resource group manager In the case that the resource water level state of any logical resource group changes, updating the resource water level state corresponding to the virtual node mapped to the logical resource group in the first cluster management system.

7. The method of claim 6, further comprising: During the process that the user submits the task demand in the first cluster management system, displaying the resource water level state corresponding to each virtual node to the user, so that the user indicates the required virtual node to be used in the task demand based on the resource water level state, as the target virtual node.

8. The method of claim 1, wherein, The second cluster management system is provided with an agent component for communication with the first cluster management system; submitting a work task meeting the task requirement to the second cluster management system, including: generating, by the target virtual node, a work task in a task format required by the second cluster management system based on the task requirement, the work task indicating execution in the target logical resource group; submitting, by the target virtual node, the work task to the agent component in the second cluster management system, so that the agent component submits the work task to a task scheduler in the second cluster management system for task scheduling.

9. The method of claim 1, further comprising: updating, by the target virtual node, the execution state of the target container group according to the execution state of the work task obtained from the second cluster management system; and updating the execution state corresponding to the task requirement according to the state information of the target container group, for the user to query.

10. The method of claim 1, wherein, In addition to the target cluster, there is another cluster; The logical resource group divided in the cluster management system adopted in the other cluster is also mapped as a virtual node in the first cluster management system, to support the first cluster management system to submit a work task in a corresponding task format to the cluster management system adopted in the other cluster, so that the work task is scheduled to the logical resource group in the other cluster for execution.

11. The method according to claim 1 or 10, wherein, The second cluster management system adopts a Slurm system, a load sharing scheduling system, or a portable batch system, and the target cluster adopts a high-performance computing cluster.

12. The method according to claim 1, wherein, The target container group does not occupy physical resources, and the virtual node in the first cluster management system also does not occupy physical resources.

13. A cluster management system, wherein, The cluster management system is based on a container, and the logical resource group divided by the second cluster management system adopted in the target cluster is mapped as a virtual node in the cluster management system, The cluster management system is configured to perform the scheduling method of any one of claims 1-12, to submit a work task in a required task format to the second cluster management system based on a task requirement submitted by a user in the cluster management system, so that the work task is executed in a target logical resource group in the target cluster.

14. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by one or more processors, the one or more processors are caused to perform the scheduling method of any one of claims 1-12.

15. A computer program product comprising a computer program, wherein, When the computer program is executed by one or more processors, the one or more processors are caused to perform the scheduling method of any one of claims 1-12. ​

Images