Allocation of computing resources to workloads

Abstract

In certain implementations, a computer device contains a processor and a non-transitory, machine-readable storage medium that stores a program for execution by the processor. The program includes instructions for receiving a request to schedule a computer workload and for determining a resource type and the requested amount of resources for that workload. The program also includes instructions for obtaining a total licensed capacity for that resource type and for obtaining current resource usage across existing computer workloads for that resource type.The programming includes instructions to determine whether scheduling the computer workload would cause the total resource usage to exceed the total licensed capacity, and to release the computer workload for scheduling, at least based on the determination that the total resource usage does not exceed the total licensed capacity, or to queue the computer workload for later scheduling, at least based on the determination that the total resource usage exceeds the total licensed capacity.

Description

BACKGROUND

[0001] Modern computing environments often include complex rules for managing the planning and provisioning of computing loads. These environments can include, for example, cloud computing environments, on-premises computing environments, hybrid cloud computing environments, or other types of distributed computing environments. These environments may include features that allow users to adjust the level of computing resource utilization to the demands of the computing workload. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] For a better understanding of this revelation and its benefits, reference is now made to the following descriptions in conjunction with the accompanying drawings, in which: Fig. Figure 1 shows an example system for allocating computing resources to workloads according to specific implementations; Fig. Figure 2 shows an overview of an exemplary workload assessment process carried out by the planner according to certain implementations; Fig. Figure 3 illustrates an example procedure for allocating computing resources to workloads according to specific implementations; Fig. Figure 4 illustrates an example procedure for allocating computing resources to workloads according to specific implementations; Fig. Figure 5 illustrates an example procedure for identifying candidates for compute nodes and determining the associated allocation sets for compute resources according to certain implementations; Fig. Figure 6 illustrates an example procedure for allocating computing resources to workloads according to specific implementations; Fig. Figure 7 shows an example scenario for the allocation of data processing resources and related example licensing considerations according to certain implementations; Fig. Figure 8 illustrates an example scenario for the allocation of computer resources and related example licensing considerations according to certain implementations; and Fig. Figure 9 shows a block diagram of an example computer according to specific implementations. DESCRIPTION

[0003] Data processing resources such as software, services, and physical and virtual infrastructures can be marketed in various ways, for example, through paid, perpetual licenses or subscription-based licenses. License enforcement refers to mechanisms for managing license compliance. Software licensing plays a role in managing access to and use of various software applications and resources. In container orchestration environments, for example, different licensing models can be used to license resources for managing and running applications and frameworks. Two licensing models are the runtime capacity model and the consumption model.

[0004] The runtime capacity model can be based on a fixed runtime (e.g., one, three, or five years) and tied to a quantity (capacity) of one or more types of system resources. The quantity of system resources can include, for example, a number of CPU cores, CPUs, or graphics processing units (GPUs, which may include logical GPUs (loGPUs) and / or physical GPUs (GPUs or pGPUs)), or a quantity of storage space. With the capacity model, customers purchase licenses for their total system capacity, regardless of actual usage. In some implementations, a customer can increase capacity by either purchasing additional licensed capacity or releasing unused resources held by other applications and / or frameworks.

[0005] The consumption-based model can involve a customer paying for a specific amount of resource usage over a set period (e.g., CPU hours per month) and incurring an overage fee if they exceed this amount. The capacity-based model is similar to a mobile phone plan where a customer pre-purchases a certain number of minutes per month. If the actual minutes used in a given month exceed the pre-paid limit, the customer must pay for the additional minutes, possibly at a higher rate.

[0006] These licensing models can introduce one or more problems. For example, tying software licenses to static resource capacities (such as a specific number of CPU cores or a certain amount of memory) or to predetermined usage can be inflexible and force organizations to purchase licenses based on the maximum possible capacity / usage. Modern computing environments offer the ability to scale computing resources to match the actual computing workload. The advent of cloud computing and containerized applications, for instance, has transformed how software and computing resources are deployed and used. These distributed environments offer flexibility and allow organizations to quickly scale their resources in response to changing demands.This dynamic nature of cloud computing environments poses new challenges to software licensing models. For example, the dynamics of these environments make it difficult to predict resource capacity and / or utilization, often leading customers to purchase licenses for the maximum capacity they expect. Traditional licensing models may charge customers for the total capacity of their infrastructure, including the overhead resources required to run the container orchestration platform, rather than just the resources used by the customer's actual workloads. This can result in customers paying for more capacity than they actually use, frustrating stakeholders because these licensing models are unable to adapt to the fluid nature of cloud and container environments.Another example is that these licensing models can bill licensees for the entire infrastructure capacity, not just the resources used by the customer's workloads. Another example is that traditional licensing techniques may not offer granular licensing options for different types of workloads or resources.

[0007] Certain implementations of this disclosure provide an automated and computer-implemented licensing system that can track computing resource usage in real time and dynamically enforce license terms with minimal or no impact on the performance or flexibility of cloud-native applications. Certain implementations are able to address licensing concerns for various types of computing resources, from traditional CPU cores to more specialized hardware such as GPUs, each of which may have its own licensing considerations.

[0008] Certain implementations of this disclosure provide a dynamic system for enforcing software licenses for cloud environments. Certain implementations decouple licensing from the overall capacity of the infrastructure. Certain implementations attempt to tie licenses to the actual resource usage of workloads. Certain implementations provide a custom scheduler that enforces license terms when scheduling workloads. Certain implementations provide the ability to categorize different types of workloads and resources to improve licensing accuracy. Certain implementations enable dynamic tracking of resource usage across workloads to attempt to comply with license limits.Certain implementations queue workloads that would exceed license capacity until license capacity becomes available by releasing used resources or adding additional license capacity. Certain implementations support different resource types, such as vCPUs and GPUs, including proportional GPU usage.

[0009] Certain implementations can be integrated with container orchestration platforms such as Kubernetes, using a custom scheduler plugin to enforce licensing during the workload planning phase. Some implementations track resource usage for running and pending workloads and compare it to the purchased licensed capacity before allowing new workloads to run.

[0010] Fig. Figure 1 shows an example System 100 for allocating compute resources to workloads according to certain implementations. The Computing System 100 can be part of a compute environment, such as a containerized environment, a virtualized environment, an HPC environment, a cloud environment, an on-premises environment, or a hybrid cloud environment, some of which may overlap in type. In some implementations, the Computing System 100 is capable of executing computational processes, such as tasks of a workload, in parallel. In the example shown, the System 100 comprises a computer cluster 102, a manager node 104, and a network 106. Although this implementation of the System 100 is shown and described, the System 100 can be implemented in any suitable manner according to specific requirements within the scope of this disclosure.

[0011] The compute cluster 102 comprises one or more compute nodes 108, represented as compute nodes 108a, 108b, and 108n. Compute nodes 108a, 108b, and 108n can be referred to collectively as compute nodes 108 or compute nodes 108. In certain implementations, the compute nodes 108 can work together to perform processing operations, such as cluster operations, HPC operations, and / or other suitable types of computation. For example, a workload (such as the workloads 130 described below) can be divided into smaller segments or tasks that can be parallelized across the compute nodes 108. Processes can be executed on the compute nodes 108 to perform the processing operations associated with the workload. The compute nodes 108 can be implemented with any suitable combination of hardware, firmware, and software.For example, each compute node 108 can be an independent unit equipped with a processor, memory and similar components (as described below), which can be physical or virtual and / or local / distributed.

[0012] A workload, also known as a computer workload, can comprise a collection of one or more electronic processing tasks organized in any suitable way. For example, a workload might include one or more software applications, one or more containers, one or more Kubernetes pods, one or more virtual machines, batch jobs or batch processing tasks, continuous integration / continuous development (CI / CD) pipelines, serverless functions or Function-as-a-Service (FaaS) instances, KServe endpoints, notebooks (e.g., Jupyter), machine learning tasks (e.g., training and / or usage tasks), inference tasks for deployed artificial intelligence (AI) models, data analysis tasks (e.g.,SPARK tasks), HPC simulations, database instances or database operations, stream processing tasks, web servers, application servers, microservices, distributed ledger or blockchain tasks and / or any other suitable types of processing tasks, some of which may overlap in nature.

[0013] A workload can be executed using one or more compute nodes 108, which perform processing tasks, such as those of a workload, in a potentially parallel manner. For example, these processing tasks can be assigned to the compute nodes 108 (e.g., by the management node 104) as execution flows, in which the compute nodes 108 execute computer code, possibly in segments. To this end, the compute nodes 108 can execute one or more processes of the workload and work together to execute the workload.

[0014] Additional details of a compute node 108 (compute node 108a in the illustrated example) are shown, but in this disclosure, the compute node 108 will continue to be referred to generally as compute node 108. The compute node 108 comprises various compute resources 110. The compute resources 110 may include one or more processors 112, one or more accelerators 114, memory 116, and / or other suitable compute resources 110.

[0015] The processors 112 can be any suitable combination of central processing units, microprocessors, ASICs, microcontrollers, or the like, some of which may overlap in type. Although the plural is used, the processors 112 can include one or more processors (possibly of different types) at one or more locations. The processors 112 can include physical processors (e.g., pCPUs) and / or virtual processors (e.g., vCPUs). Although this disclosure primarily describes CPUs, the processors 112 can include any suitable type of processor, individually or in combination.

[0016] Accelerators 114 can include specialized processing devices capable of performing one or more processing tasks, such as those associated with specific types of workloads. Examples of accelerators 114 include GPUs, ASICs, FPGAs, VPUs (Vision Processing Units), NPUs (Neural Processing Units), TPUs (Tensor Processing Units), and / or other types of specialized processing devices integrated into or otherwise accessible to a compute node 108 to accelerate computations for workloads. An accelerator 114 can provide significant computing power, enabling faster execution of some tasks than a general-purpose processor (e.g., a processor 112). Accelerators 114 can include physical accelerators (e.g., pGPUs) and / or virtual accelerators (e.g., loGPUs).Examples of loGPUs may be virtual GPUs (vGPUs), partial GPUs, and / or other suitable types of partitioned GPUs. Although this disclosure primarily describes GPUs, it also includes accelerators 114, including all suitable types of accelerators, alone or in combination.

[0017] Memory 116 can comprise various types of memory, including volatile and non-volatile memory. For example, memory 116 can include random-access memory (RAM), ROM, a hard disk drive (HDD), and / or similar storage devices. Different memory types can be used for different data storage requirements. For example, the processor 112 can boot from ROM, maintain non-volatile memory on a hard disk, execute program code stored in RAM, and store data to be processed in RAM. In certain implementations, some or all of memory 116 can be or contain a database, such as one or more SQL (Structured Query Language) servers or relational databases. Memory 116 can also include non-transitory, machine-readable media that stores instructions for execution by the processor 112.One or more modules within the compute node 108 can be implemented wholly or partially as software and / or hardware to perform the functions described here. Although specified in the singular, the memory 116 can consist of multiple storage devices in one or more locations.

[0018] Computing nodes 108 can contain an interface 118, which can be used to connect to the network 106 (e.g., to communicate with the manager node 104 and / or other suitable units) and / or to connect to the link 120 for communication with other computing nodes 108 in the compute cluster 102. The interface 118 can conform to one or more network standards such as Ethernet, Wi-Fi, and the like. Although referred to in the singular as interface 118, there may be multiple interfaces. The link 120 can also conform to one or more network standards such as Ethernet, Wi-Fi, and the like. Although referred to in the singular as link 120, there may be multiple links. The design of at least one part of the link 120 can prioritize low latency and high throughput among the connected components.For example, part or all of the 120 connection can be based on a technology such as Ethernet, InfiniBand or similar.

[0019] The compute nodes 108 (e.g., compute nodes 108a to 108n) can be similar to each other, but they need not be. For example, certain compute nodes 108 may contain different compute resources 110 than other compute nodes 108. For instance, certain compute nodes 108 may contain one or more accelerators 114, while other compute nodes 108 may not have any accelerators 114. Another example is that certain compute nodes 108 may have a different number of processors 112, accelerators 114, and memory 116 than other compute nodes 108. In yet another special example, some or all of the compute nodes 108 may be configured with substantially identical compute resources 110.

[0020] Manager node 104 may be responsible for managing compute cluster 102, including compute nodes 108, where the components of compute cluster 102 are configured to execute a requested workload. Although depicted as being outside compute cluster 102, manager node 104 could actually be located within compute cluster 102, for example, as one of the compute nodes within compute cluster 102. Manager node 104 may serve as an entry point for administrative tasks for compute cluster 102 and may be responsible for controlling the compute nodes 108 within compute cluster 102.

[0021] The manager node 104 comprises a processor 122, a memory 124, and an interface 126. The processor 122 retrieves executable code from memory 124 and executes it. When executed by processor 122, the executable code can cause the processor 122 to implement any functionality described herein. The processor 122 can be a microprocessor, an application-specific integrated circuit, a microcontroller, or similar device. Although referred to in the singular as processor 122, it can consist of multiple processors located in one or more locations.

[0022] Memory 124 can comprise various memory types, including volatile and non-volatile memory. For example, memory 124 can include RAM, ROM, a hard disk, and / or similar storage media. Different memory types can be used for different data storage requirements. For instance, processor 122 can boot from ROM, maintain non-volatile memory on a hard disk, execute program code stored in RAM, and store the data to be processed in RAM. In certain implementations, some or all of memory 124 can be or contain a database, such as one or more SQL servers or relational databases. Memory 124 can also include non-transitory, machine-readable media that stores instructions for execution by processor 122.One or more modules within the manager node 104 can be implemented wholly or partially as software and / or hardware to perform the functions described here. Although specified in the singular, the memory 124 can consist of multiple memory devices in one or more locations.

[0023] Interface 126 can be used to establish a connection to network 106 and to communicate with other nodes over network 106. Interface 126 facilitates the transmission and reception of data packets between the management node 104 and the compute nodes 108 (e.g., over network 106) and can conform to one or more network standards such as Ethernet, Wi-Fi, and the like. Although the term "interface 126" is used in the singular, there may be multiple interfaces.

[0024] Network 106 can be any suitable type of communication network for electronic devices and can enable wired and / or wireless communication. For example, Network 106 can transmit IP packets, frame relay frames, ATM cells, voice, video, data, and other suitable information between network addresses. Network 106 can be any suitable combination of one or more local area networks (LANs), wireless access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), mobile networks (e.g., using WiMAX (802.16), WiFi (802.11), 3G, 4G, 5G, or other suitable wireless technologies in any combination), all or part of the global communication network known as the Internet, and / or any other communication system or systems at one or more locations, which can be any combination of wireless and wired.The 106 network can include controllers, APs, switches, routers, firewalls, or similar devices for forwarding data traffic.

[0025] Manager node 104 contains a scheduler 128. The scheduler 128 receives or otherwise accesses workloads (hereinafter referred to as workloads 130) and schedules the workloads 130 for deployment to one or more compute nodes 108 of the compute cluster 102 for execution using the compute resources 110 of the one or more compute nodes 108. The scheduler 128 can have access to information about the available compute resources 110 of the compute cluster 102 as well as about the compute resources 110 used by the applications to be executed. This information can be used by the scheduler 128 to make decisions about where the workloads 130 should be deployed.

[0026] For example, Scheduler 128 may contain or otherwise access a workload queue 129 that receives and stores workloads 130 in a pending state, waiting for the allocation of compute resources 110 from compute node 108 and the associated provisioning for execution. For example, the pending workloads 130 in the workload queue 129 (or another suitable type of data structure) may be waiting for the compute resources 110 to become available for allocation to the pending workload 130, for licensing conditions to be met (as described in more detail below), or for other suitable reasons. Workloads 130 are sometimes abbreviated as "WL," possibly with a number (as in "WL#"), as is the case with the workload queue 129 in Fig. 1 is the case.

[0027] A workload 130 can be scheduled based on a variety of factors, including the parameters requested in the workload 130, the states and capabilities of the compute nodes 108, the availability of compute resources 110 at the compute nodes 108, the ability to meet licensing restrictions using the available compute resources 110 at the available compute nodes 108, and / or based on a variety of other factors. The manager node 104 can monitor the states and capabilities of the compute nodes 108 (e.g., compute utilization, memory usage, etc.) and make workload scheduling decisions, at least in part, based on the states and capabilities of the compute nodes 108.

[0028] It may be possible to process certain workloads 130 wholly or partially using one or more combinations of compute resources 110 from the compute nodes 108. For example, some workloads 130 can be adequately processed using processors 112, while other workloads 130 require extensive use of accelerators 114. Certain workloads 130 may explicitly require processing with one or more accelerators 114, certain workloads 130 may permit processing with one or more accelerators 114, and still other workloads 130 may be configured in such a way that they are not suitable for processing with one or more accelerators 114. The manager node 104 may attempt to allocate one or more compute resources 110 to the workloads 130 to facilitate the processing of these workloads 130 according to the parameters of the workloads 130.

[0029] As described above, organizations intending to use System 100 to process workloads can purchase one or more software licenses to use System 100 and some or all of the services it offers. For example, software licenses might be offered by an organization that provides administrative services (and potentially the physical infrastructure) for System 100. These administrative services might include software running on System 100 to manage service delivery, such as cluster management, workload scheduling, and many other related functions. As a specific example, the software might include a container orchestration platform.

[0030] The manager node 104 can contain a license management module 132. The license management module 132 can receive licenses acquired by users of system 100 and store these licenses as licenses 136 in a storage device 134. The licenses 136 can, for example, contain copies of the software licenses held by entities (e.g., licensees, customers, etc.) that use services provided by system 100. In certain implementations, the license management module 132 can facilitate interaction with users of system 100 (e.g., via the management interface 142 described below) to obtain, update, modify, etc., one or more licenses 136.

[0031] Storage device 134 can contain various types of storage, including volatile and non-volatile memory. For example, storage device 134 can contain RAM, ROM, a hard disk, and / or similar storage. In certain implementations, part or all of storage device 134 may be or include a database, such as one or more SQL servers or relational databases. Although represented in the singular, storage device 134 can be multiple storage devices in one or more locations. Although represented separately from manager node 104, manager node 104 may, in certain implementations, contain storage device 134 (e.g., as part of memory 124).

[0032] According to certain implementations, a License 136 may contain one or more license terms relating to a licensee's ability to run software using compute resources 110 from compute nodes 108 of the compute cluster 102. The license terms may correspond to one or more license term categories, providing granular control over the terms of the License 136 and allowing the License 136 to be tailored to specific use cases for licensees.

[0033] According to certain implementations, the license terms categories can include one or more of the following categories: Resource Type, Framework Type, Application Type, Vendor Type, and / or any other appropriate category. For example, a Resource Type might include a type of computing resource being licensed, such as pCPU, vCPU, pGPU, loGPU, etc. As another example, a Framework Type might include a type of framework being licensed. A framework can be a structured platform that provides tools for managing clusters, containers, microservices, and / or other functionalities, and various frameworks can be available from different vendors. Some example frameworks might include Kubernetes, Kubeflow, Spark, Livy, Ray, user-provided frameworks, and / or other appropriate types of frameworks.As another example, an application type can encompass the type of application that the licensee intends to run with System 100, as distinct from the framework that can be used to run those applications. Another example: The vendor type can be the vendor of the framework, application, or other component that the licensee intends to run with System 100. For instance, some components may be provided by the operator of System 100, some components may be provided by third parties, or some components may be provided by the licensee, and the License 136 can be categorized accordingly. In certain implementations, the categories of license terms may be arranged and / or available in a category / subcategory relationship.For example, a license 136 can be specific to a particular framework and, furthermore, specific to a particular resource type for use with that framework.

[0034] License 136 can also specify a resource quantity (e.g., capacity) for one or more of the license term categories / subcategories associated with License 136. A resource quantity for License 136 can be bound to one or more license term categories, a combination of a license term category and subcategory, or similar. For example, License 136 can specify a pCPU resource type with a resource quantity of 100 units and an loGPU resource type with a resource quantity of 50 units. Alternatively, License 136 can specify a pCPU resource type with a resource quantity of 100 units and not include a license for GPUs (pGPUs or loGPUs) because the licensee might not require GPU resources for their Workload 130.As another example, a specific license 136 can specify a first framework and, for the first framework, a first resource type vCPU with a resource quantity of 100 units and a second resource type loGPU with a resource quantity of 50 units. The specific license can also specify a second framework and, for the second framework, a first resource type vCPU with a resource quantity of 50 units and a second resource type loGPU with a resource quantity of 75 units.

[0035] A licensor can determine which categories of license terms should be active / enforced, either generally or for specific licensees. In other words, the licensor can determine where granularity is allowed in the license terms by permitting the licensee to set specific values ​​for the license terms.

[0036] The above are just a few examples of the various combinations of license term categories / subcategories available, as Licenses 136 are offered with multiple license term categories / subcategories and associated resource amounts. The ability to select categories / subcategories for license terms and associated resource amounts can provide licensees (e.g., the company that purchases License 136 and uses the software / service) with a higher degree of granularity, allowing them to tailor the license to their specific goals and use cases. The ability to select categories / subcategories for license terms and associated resource amounts can also benefit licensors (e.g.,This provides the company that sells the license (136) and provides the software / service with a higher degree of granularity, allowing licensors to customize license terms at a more granular level. As described in more detail below, the ability to define license terms at the level of license term categories / subcategories and associated resource quantities allows the scheduler (128) to determine categories of workloads (130) according to workload parameters and correlate these workload categories (130) with specific license terms. This approach can offer improved licensing flexibility, potentially better cost optimization for the licensee, and the ability for software vendors to create more differentiated licensing models.This approach can offer a more dynamic, usage-specific approach that can adapt to the diverse and changing requirements of modern cloud and container environments.

[0037] In the further course of the license management module 132, the license management module 132 can be configured to generate license information 138 (e.g., for storage in the storage device 134) by analyzing the licenses 136 to extract specific information from them and linking certain usage information to the license terms, so that the scheduler 128 can use this information to make scheduling decisions for the workloads 130. The license information 138 can contain all relevant information obtained from the licenses 136. In certain implementations, the license information 138 can include information about specific license terms of the licenses 136, arranged in a more manageable and accessible manner.For example, the license information 138 may contain information about one or more categories of license terms and the associated resource quantities (e.g., capacities), if applicable. As specific examples, the license information 138 may specify one or more types of computing resources 110 (e.g., pCPUs, vCPUs, pGPUs, loGPUs, etc.) along with the corresponding resource quantities (e.g., capacities). As another example, the license information 138 may contain information about one or more frameworks and, for each framework, one or more resource quantities for one or more different resource types (e.g., pCPUs, vCPUs, pGPUs, loGPUs, etc.).

[0038] The manager node 104 can contain a monitoring module 133 that can receive or otherwise determine usage information and store this usage information as usage information 140 in the storage device 134. The usage information 140 can contain information about the current inventory, topology, status, and / or other details of the compute cluster 102, the compute nodes 108 of the compute cluster 102, and the compute resources 110 of the compute nodes 108. The usage information 140 can contain the current resource utilization across the existing compute workloads 130 for each type of compute resource 110. In other words, for one or more types of compute resources 110, the usage information 140 can contain the current allocations of compute resources 110 to existing workloads 130.The usage information 140 can contain current information about the utilization of the computing resources 110, so that the scheduler 128 can determine which computing resources 110 are already allocated to the workloads 130 (regardless of the licensee) and which computing resources are available.

[0039] Some or all of the usage information 140 can be stored per licensee, so that the scheduler 128 can access the usage information 140 of a specific licensee when evaluating the license terms associated with scheduling workloads 130. For example, the usage information 140 for a specific licensee can contain information about the amount of computer resources 110 currently allocated to the licensee's workloads 130 for one or more types of computing resources 110.

[0040] In certain implementations, some or all of the usage information 140 is retrieved and stored as time-series data in the storage device 134. For example, the storage device 134 can be implemented wholly or partially as PROMETHEUS or another suitable database type, configured to collect usage information 140 from the compute resources 110, the compute nodes 108, the compute cluster 102, and / or the monitoring module 133 at regular or irregular intervals.

[0041] Although this disclosure describes a specific division of operations between Scheduler 128, License Management Module 132, and Monitoring Module 133, any suitable division of operations is permissible, including a single unit (e.g., Scheduler 128) that performs all operations described with respect to these components. Furthermore, Scheduler 128, License Management Module 132, and Monitoring Module 133 can be implemented with any suitable combination of hardware, firmware, and software.

[0042] As described above, when scheduling workloads 130 for the allocation of one or more computing resources 110, the scheduler 128 can determine whether the allocation of the requested computing resources 110 to the workload 130 corresponds to a license associated with the workload 130 (e.g., with an entity submitting the workload 130). The scheduler 128 can receive a request to schedule a workload 130, which can also be considered simply receiving a workload 130 from a workload queue 129 or another suitable source. The request and / or the workload 130 can be associated with an entity (e.g., a customer) that may possess one or more licenses 136 associated with the use of the computer system 100.

[0043] The request and / or workload 130 can contain one or more parameters that can be used to determine whether the allocation of the requested compute resources 110 to the workload 130 matches a license 136 associated with the workload 130. A license 136 associated with a workload 130 can refer to a license 136 assigned to a licensee (e.g., an entity) that submits the workload 130 for processing by the system 100. The one or more parameters can provide an indication of one or more categories and, if applicable, associated resource quantities for the workload 130. Some or all of the categories of certain parameters can correspond to license term categories that can be specified for the license 136.In certain implementations, the parameters may include the resource type, framework type, application type, vendor type and / or other appropriate categories, possibly together with the associated resource sets.

[0044] For example, the parameters can contain information to determine one or more types of computing resources and corresponding quantities of computing resources associated with workload 130 and requested to be allocated to workload 130 for execution using one or more compute nodes 108 of compute cluster 102. A resource type can include a type of computing resource 110 requested for workload 130, such as pCPU, vCPU, pGPU, loGPU, etc. As another example, a framework type can include a type of framework associated with workload 130. Some example frameworks are described above in the context of possible license terms.Another example: An application type can encompass the type of application the licensee intends to run with System 100 and differs from the framework that can be used to run those applications. Another example: The vendor type can be the vendor of the framework, application, or other component that the licensee intends to run with System 100. For example, some components may be provided by the operator of System 100, some components by third parties, or some components by the licensee, and the workload can be categorized according to the vendor. In certain implementations, the categories of parameters may be arranged and / or available in a category / subcategory relationship.For example, a workload 130 can be specific to a particular framework and, furthermore, to a specific resource type for use with that framework.

[0045] Workload 130 can also specify a resource set for one or more of the categories / subcategories associated with it. A resource set for a workload 130 can be bound to a category, a category-subcategory combination, or similar. For example, a workload 130 can specify a pCPU resource type with a resource set of 5 units and an loGPU resource type with a resource set of 2 units. As another example, a workload 130 can specify a pCPU resource type with a resource set of 10 units and not include any GPU requests (pGPUs or loGPUs). Another example: A workload 130 can specify an initial framework and, for that framework, an initial vCPU resource type with a resource set of 20 units. These are just a few examples of the various combinations possible for workloads 130.

[0046] The scheduler 128 can attempt to schedule the workload 130 according to one or more parameters of the workload 130. In conjunction with attempting to schedule the workload 130 according to one or more parameters of the workload 130, the scheduler 128 can determine whether the allocation of compute resources 110 to the workload 130 from specific compute nodes 108 matches a license 136 assigned to the workload 130. For this purpose, the scheduler 128 can evaluate license restrictions that are specific to one or more parameters of the workload 130.

[0047] To evaluate workload 130 and determine whether to approve or deny its scheduling in accordance with the license restrictions associated with a license 136 assigned to workload 130, the scheduler 128 can obtain certain information that can be used by the workload license evaluation engine 202 to perform the evaluation. For example, the scheduler 128 can determine the requested computer resources 110 and the associated resource quantities from the request and / or work volume 130. As another example, the scheduler 128 can obtain selected portions of the license information 138 and usage information 140.

[0048] For example, one or more parameters of workload 130 can identify one or more resource types of computer resources 110 that are requested to process workload 130. The one or more parameters of workload 130 can identify corresponding resource quantities for the one or more resource types of computer resources 110 that are to be used to process workload 130. Scheduler 128 can obtain current resource usage for existing workloads 130 for one or more resource types for workload 130 for the licensee associated with workload 130 (e.g., from usage information 140). Scheduler 128 can obtain (e.g., from license information 138) the total licensed capacity for the one or more resource types associated with workload 130.

[0049] Based on the information obtained from workload 130 (and / or an associated request to schedule workload 130), license information 138, and usage information 140, scheduler 128 can determine for the licensee associated with workload 130 whether scheduling workload 130 would result in total resource usage exceeding the total licensed capacity. Additional details regarding the findings made by scheduler 128 (e.g., workload license evaluation module 202) are provided below with reference to the Fig. 3-8 described in more detail.

[0050] If the workload license evaluation engine 202 determines that the licensee does not have sufficient available computing resources 110 to process workload 130 (e.g., workload 130 is not approved), then the scheduler 128 can place workload 130 back in the workload queue 129 for re-evaluation at a later time. If the workload license evaluation engine 202 determines that the licensee has sufficient available computing resources 110 to process workload 130 (e.g., workload 130 is approved), the scheduler 128 can allocate computing resources 110 to workload 130 and schedule workload 130 for deployment on one or more compute nodes 108 of the compute cluster 102.

[0051] In certain implementations, Scheduler 128 can identify the licensee for a specific workload 130 and access the license information 138 for that licensee to determine which license term categories are active for that licensee. If multiple license term categories are active for the licensee, Scheduler 128 can evaluate multiple license term categories and their associated workload parameters to determine whether to allow or deny scheduling of the workload 130. For example, the license information 138 for a specific licensee might indicate that both CPU and GPU license restrictions are defined by license 136 for that licensee. Therefore, when deciding whether to allow or deny scheduling of a workload 130 for that licensee, Scheduler 128 can evaluate both the CPU and GPU values ​​for the workload 130.

[0052] Certain implementations of Scheduler 128 offer the possibility of determining an optimal allocation of compute resources 110 that complies with the license restrictions. For example, a first compute node 108 may have sufficient available compute resources 110 to allocate to the workload 130, but allocating these resources from the first compute node 108 to the workload 130 may result in the total resources allocated to the licensee associated with the workload 130 exceeding the license terms. A second compute node 108 may also have sufficient available compute resources 110 to allocate to the workload 130, but allocating these resources from the second compute node 108 may result in a total resource allocation for the licensee that remains within the license term. An example of such a scenario is described below with reference to Fig. 7, Example 1, is described in more detail. Scheduler 128 may be able to identify, from a number of possible compute nodes 108 that could process a workload 130, a specific compute node 108 that can do so within the limits set by a license 136 of the licensee.

[0053] In certain implementations, Scheduler 128 can be implemented as a standalone scheduler or as a plugin for another scheduler. For example, Scheduler 128 can be implemented as a standalone scheduler that includes standard scheduling functions in addition to those described here. Another example: Scheduler 128 can be implemented as a plugin that can be used alongside a standard scheduler to provide the functions described here. The standard scheduler can be one that provides standard scheduling functions compatible with the computer environment (e.g., Computer System 100). Fig. 1) are connected, such as a scheduler provided by a container orchestration platform / container framework on which the computer system 100 (see Fig. 1) works. As an example, the default scheduler could be a Kubernetes scheduler, which provides scheduling operations in the context of a Kubernetes system. In certain implementations, the scheduler plugin is integrated into an approval phase of the Kubernetes scheduling lifecycle.

[0054] In certain implementations, computer system 100 may include an administrative interface 142, which can be used to control the manager node 104 and, if applicable, other elements of computer system 100. A system administrator or other suitable human or machine user can access the manager node 104 via the administrative interface 142. The administrative interface 142 can be a central access point for the manager node 104, accessible via a public computer network, such as the Internet. The manager node 104 can receive commands via the administrative interface 142. The manager node 104 can process the commands from the administrative interface 142, validate the commands, and execute the logic specified by the commands. Furthermore, the administrative node 104 can output the results of the commands via the administrative interface 142.Examples of the administrative interface 142 include a command-line interface, a graphical user interface, a web interface, or similar.

[0055] In certain implementations, the management interface 142 can display information about workloads 130 and the use of computer resources 110 to process these workloads 130. For example, the management interface 142 can allow a system administrator to monitor the amount of licensed computer resources 110, the amount of licensed computer resources 110 used to process workloads 130, the amount of licensed computer resources 110 available to process workloads 130, and / or other relevant information.

[0056] As in Fig. As shown in Figure 1, the compute cluster 102, the compute nodes 108, and the manager node 104 can contain any suitable combination of hardware, firmware, and software that can work together to provide the features of the compute system 100. Furthermore, each of the compute clusters 102, compute nodes 108, and manager node 104 can optionally comprise one or more computer systems at one or more locations. Each computer system can contain any suitable input devices, output devices, mass storage media, processors, memory, or other suitable components for receiving, processing, storing, and communicating data. Although shown and described separately, the compute nodes 108 and the manager node 104 can be combined or further separated in any suitable way. For example, these components can be implemented with one or more compute devices at one or more geographical locations.Accordingly, the implementations disclosed here should not be based on those in . Fig. The configuration of components shown may be limited to 1.

[0057] Although the description is primarily in the context of a container cluster orchestration computing environment, the features described here can be used with any suitable type of computer system. For example, the functions described here can be used with any suitable type of computer system in which workloads are scheduled to allocate computing resources according to some kind of consumption limit, such as might be provided by a license.

[0058] Fig. Figure 2 shows an overview 200 of an exemplary workload assessment process performed by Scheduler 128 according to certain implementations. Overview 200 is described with reference to computer system 100, so that aspects of computer system 100 can be referenced even if these elements are not explicitly included in the overview. Fig. 2 are shown.

[0059] In the example shown, Scheduler 128 includes the Workload License Evaluation Engine 202, which can be implemented with any combination of hardware, firmware, and software. Generally, the Workload License Evaluation Engine 202 is configured to determine whether to approve or deny the scheduling of a Workload 130 based on the license restrictions associated with a License 136 for the entity assigned to Workload 130 and the current resource usage for that entity.

[0060] In the example shown, the workload is 130p (in Fig. 2 (abbreviated WL 130p) is the workload 130 that is being considered for the allocation of compute resources 110. Workload 130p is associated with a licensee who either has, or at this time (depending on the current use of compute resources 110 for other workloads 130 of the licensee), a suitable license 136 for the allocation of compute resources 110 to workload 130p. The scheduler 128 can obtain workload 130p from the workload queue 129, which may contain pending workloads 130. For example, queue 129 may be a FIFO queue, and workload 130p may be the next workload 130 in the queue. Additionally or alternatively, the scheduler 128 can use any suitable algorithm or factors to determine which workload 130 should be selected from the workload queue 129.

[0061] To evaluate the workload 130p, to determine whether the planning of the workload 130p should be approved or denied in accordance with the license restrictions associated with a license 136, the planner 128 can obtain certain information that can be used by the workload license evaluation engine 202 to perform the evaluation. For example, the planner 128 can determine the requested computer resources 110 and the associated resource quantities from the request and / or the workload 130p. As another example, the planner 128 can retrieve selected parts of the license information 138 and usage information 140.

[0062] Based on the information obtained from workload 130p (and / or an associated request to schedule workload 130p), license information 138, and usage information 140, the workload license evaluation engine 202 can determine for the licensee associated with workload 130p whether scheduling workload 130p would result in total resource usage exceeding the total licensed capacity. Additional details regarding the findings made by scheduler 128 (e.g., workload license evaluation engine 202) are provided below with reference to the Fig. 3-8 described in more detail.

[0063] If the workload license evaluation engine 202 determines that the licensee does not have sufficient available computing resources 110 to process workload 130p (e.g., workload 130p is not approved), then the scheduler 128 can place workload 130p back into the workload queue 129 for re-evaluation at a later time. If the workload license evaluation engine 202 determines that the licensee has sufficient available computing resources 110 to process workload 130p (e.g., workload 130p is approved), then the scheduler 128 can allocate computing resources 110 to workload 130p and schedule workload 130p for use on one or more compute nodes 108 of the compute cluster 102.

[0064] Fig. Figure 3 shows an example procedure 300 for allocating compute resources 110 to workloads 130 according to certain implementations. Some or all of the operations described with respect to procedure 300 can be performed by scheduler 128, including the potential workload license evaluation engine 202; however, for the sake of simplicity, the operations are described as if they were performed by scheduler 128.

[0065] In step 302, the planner 128 can receive a request to schedule a workload 130. The workload 130 can be any suitable type of workload 103 for scheduling an allocation of computing resources (e.g., computing resources 110 from compute node 108 of compute cluster 102 in the example of...). Fig. 1) The request can be associated with an entity that owns one or more licenses 136 in conjunction with the system 100. In certain implementations, the scheduler 128 can receive a workload 130 from the workload queue 129, which may contain pending workloads 130. In certain implementations, receiving a request to schedule a workload 130 involves simply retrieving a workload 130 from a workload queue 129 or another suitable source. For this purpose, the terms "request" and "workload 130" can be used interchangeably.

[0066] In certain implementations, the requirement to schedule workload 130 includes a requirement to schedule workload 130 to run using one or more resources of a computer cluster deployed in a cloud computing environment, and the cloud computing environment may include a container orchestration platform.

[0067] In step 304, the scheduler 128 can determine a resource type and the requested resource quantity for the computational workload 130 in accordance with the request. The request can contain at least one resource type and / or resource quantity for the computational workload 130. For example, the request can specify one or more types of computational resources 110 to process the initial computational workload 130 and / or associated resource quantities of one or more types of computational resources 110 to process the initial computational workload 130.

[0068] In certain implementations, the scheduler can determine one or more categories for computational effort. For example, a workload category can correspond to the resource type determined according to the request. Specific example resource types can include one or more pCPUs, one vCPU, one pGPU, one loGPU, a storage quantity, and / or other appropriate resource types. Another example: A first workload category can correspond to a specific computing framework, and another workload category can correspond to the resource type determined according to the request.

[0069] In step 306, the scheduler 128 can determine the total licensed capacity for the resource type associated with the request. For example, a license 136 for the entity associated with the request can specify a total licensed capacity for the resource type associated with the request. In certain implementations, the scheduler 128 can query the license management module 132 for the total licensed capacity for the resource type associated with the request. The license management module 132 can, in turn, obtain this information (for example, from the storage device 134) and return the total licensed capacity for the resource type to the scheduler 128. Additionally or alternatively, the scheduler 128 can simply retrieve license information 138 from the license management module 132 or directly from the storage device 134, and the license information 138 can include the total licensed capacity for the resource type.

[0070] As described above with reference to step 304, the planner 128 can determine one or more categories for the computer workload 130. The total licensed capacity and current resource utilization determined in step 306 can be specific to one or more computer workload 130 categories. For example, one workload category might correspond to a particular computer framework, and another workload category might correspond to the resource type determined according to the query. In certain implementations, and continuing with this example, the total licensed capacity for the resource type might be specific to the resource type of the particular data processing system.

[0071] In step 308, Scheduler 128 can determine the current resource utilization for the resource type associated with the request from existing compute workloads. For example, a licensee associated with the request to schedule workload 130 may have no workloads, one workload, or several workloads 130 running in cluster 102, to which compute resources 110 have been allocated. Scheduler 128 can obtain information indicating the current resource utilization (e.g., of compute resources 110 from compute node 108 of compute cluster 102) from existing compute workloads 130 for the resource type associated with the request. In certain implementations, Scheduler 128 can query the monitoring module 133 for the current resource utilization in existing compute workloads for the resource type associated with the request. The monitoring module 133 can, in turn, obtain this information (e.g.,from the usage information 140 of the storage device 134) and the current resource usage across existing computer workloads for the resource type associated with the request are returned to the scheduler 128. Additionally or alternatively, the scheduler 128 can simply retrieve some or all of the usage information 140 from the monitoring module 133 or directly from the storage device 134, and the usage information 140 can include the current resource usage across existing computer workloads for the resource type associated with the request.

[0072] In step 310, scheduler 128 can determine whether scheduling the workload 130 associated with the request would result in total resource utilization exceeding the total licensed capacity. For example, scheduler 128 can add the requested amount of resources for the workload 130 associated with the request (e.g., as determined in step 304) to the total current resource utilization across all existing workloads 130 for the resource type (associated with the workload in the request) and determine whether the sum exceeds the total licensed capacity for that resource type determined in step 306. In certain implementations, for GPU compute resources and / or similarly for other compute resources that may be partitioned, the total licensed capacity may be based on a number of licensed pGPUs, while the current resource utilization may be based on a fractional (e.g.,The process of determining whether the planned compute workload would result in total resource utilization exceeding the licensed total capacity involves converting the fractional GPU usage into a corresponding number of physical GPUs.

[0073] If, in step 310, scheduler 128 determines that scheduling the workload 130 associated with the request would cause total resource utilization to exceed the total licensed capacity, scheduler 128 can, in step 312, reject the request to schedule workload 130 and place workload 130 in a pending state. For example, scheduler 128 can place workload 130 in a queue 129 for pending workloads, which, if workload 130 was originally pulled from queue 129, may involve returning workload 130 to queue 129.

[0074] If, in step 310, the planner 128 determines that scheduling the workload 130 associated with the requirement would not result in the total resource utilization exceeding the total licensed capacity, the planner 128 may, in step 314, release the first computer workload 130 for scheduling, at least based on the finding that the total resource utilization does not exceed the total licensed capacity.

[0075] Fig. Figure 4 shows an example procedure 400 for allocating compute resources 110 to workloads 130 according to certain implementations. Some or all of the operations described in relation to procedure 400 can be performed by scheduler 128, including the potential workload license evaluation engine 202; however, for the sake of simplicity, the operations are described as if they were performed by scheduler 128.

[0076] In step 402, the scheduler 128 can receive a request to schedule a workload 130. The workload 130 can be any suitable type of workload 103 for scheduling an allocation of computing resources (e.g., computing resources 110 from compute node 108 of compute cluster 102 in the example of Fig. 1) The request can be associated with an entity that owns one or more licenses 136 in conjunction with the system 100. In certain implementations, the scheduler 128 can receive a workload 130 from the workload queue 129, which may contain pending workloads 130. In certain implementations, receiving a request to schedule a workload 130 involves simply retrieving a workload 130 from a workload queue 129 or another suitable source. For this purpose, the terms "request" and "workload 130" can be used interchangeably.

[0077] In step 404, the scheduler 128 can determine one or more parameters of the workload 130 in accordance with the request. In certain implementations, the one or more parameters may include a resource type and the requested resource quantity for the workload 130, but also one or more other types of parameters, some of which may correlate with one or more categories of license terms. The request can include at least one resource type and / or resource quantity for the workload 130. For example, the request may specify one or more types of compute resources 110 to process the workload 130 and / or associated resource quantities of one or more types of compute resources 110 to process the workload 130.

[0078] In step 406, the scheduler can determine whether the pre-check criteria are met. In certain implementations, determining the total licensed capacity for a resource type and the current resource utilization by existing workloads for that resource type (as performed in steps 408 and 410 below) are relatively expensive computational steps. Therefore, it can be beneficial to perform certain relatively inexpensive computational pre-checks on a request to determine whether allocating resources to the workload associated with the request is even possible. Pre-check criteria might include, for example, determining whether the entity associated with the request has an active license for the type of compute resources associated with the request.In certain implementations, the scheduler 128 can query the license management module 132 to determine whether the entity associated with the request has an active license for the type of computing resource associated with the request. The license management module 132 can query licenses 136 and / or license information 138 in the storage device 134 to determine whether the entity associated with the request has an active license for the type of computing resource associated with the request and can return a result to the scheduler 128.

[0079] Other possible pre-check criteria might include determining whether workload 130 has certain limits on compute resources (e.g., CPU limits) and whether workload 130 contains user or vendor identification (e.g., in annotations of a container or pod of workload 130), with one or both of these restrictions potentially being enforced in certain implementations. In general, this disclosure seeks to determine whether the request meets some appropriate type of pre-check criteria that can help filter requests before performing the relatively expensive computational steps to determine the total licensed capacity for a resource type and the current resource utilization by existing workloads for that resource type (as detailed in steps 408 and 410 below).

[0080] In some implementations, the set of eligible compute nodes 108 can be pre-filtered by Scheduler 128 before the license assessment process is applied. This pre-filtering process identifies a set of eligible compute nodes 108 that could handle the workload 130 based on factors other than the license restrictions that Scheduler 128 may consider. In some scenarios, Scheduler 128 may determine that there are not enough compute resources 110 available to process the workload 130 (e.g., during a filtering phase in a Kubernetes example), and therefore Scheduler 128 may refuse to schedule the workload 130 before reaching the licensing requirement (e.g., an approval phase in a Kubernetes example).

[0081] If, in step 406, the planner 128 determines that the criteria for the preliminary review are not met, procedure 400 can proceed to step 414, which is described below following a "no" decision for step 412. If, in step 406, the planner 128 determines that the preliminary review criteria are met, procedure 400 can proceed to step 408.

[0082] In step 408, the scheduler 128 can determine the total licensed capacity for the resource type associated with the request. For example, a license 136 for the entity associated with the request can specify a total licensed capacity for the resource type associated with the request. In certain implementations, the scheduler 128 can query the license management module 132 for the total licensed capacity for the resource type associated with the request. The license management module 132 can, in turn, obtain this information (for example, from the storage device 134) and return the total licensed capacity for the resource type to the scheduler 128. Additionally or alternatively, the scheduler 128 can simply retrieve license information 138 from the license management module 132 or directly from the storage device 134, and the license information 138 can include the total licensed capacity for the resource type.

[0083] In certain implementations, the workload planning requirement may include requirements for multiple categories of computing resources. As described above, licenses according to certain implementations of this disclosure may provide the ability to license computing resources across multiple different categories and / or subcategories, with potentially different licensing terms (e.g., prices and / or capacities) for each category and / or subcategory. These categories and / or subcategories may include one or more resource types, frameworks, applications, vendors, and / or other appropriate types of categories / subcategories, possibly in combination, along with the corresponding resource quantities.

[0084] In certain implementations, determining the total licensed capacity for the types of computing resources 110 in step 408 may involve the scheduler receiving multiple types of computing resources 110 to be allocated to the work volume 130 for processing the work volume 130, according to the categories and / or subcategories associated with the work volume 130 scheduling request and the license terms that apply to a license 136 for the entity associated with the request. For example, the work volume 130 scheduling request may include requests for multiple types of computing resources 110 to be allocated to the work volume 130 for processing the work volume 130.For example, the request might include requests for a specific amount of vCPU resources and a specific amount of loGPU resources to be allocated to workload 130 for processing workload 130. Therefore, determining the total licensed capacity for the resource type associated with the request might involve determining the total licensed capacity for multiple types of compute resources 110.

[0085] In step 410, Scheduler 128 can determine the current resource utilization for existing compute workloads for the one or more resource types associated with the request. For example, a licensee associated with the request to schedule workload 130 may have no, one, or several workloads 130 running in cluster 102, to which compute resources 110 have been allocated. Scheduler 128 can obtain information indicating the current resource utilization (e.g., of compute resources 110 from compute node 108 of compute cluster 102) of existing compute workloads 130 for the resource type associated with the request. In certain implementations, Scheduler 128 can query the monitoring module 133 for the current resource utilization in the existing compute workloads for the resource type associated with the request. The monitoring module 133 can, in turn, obtain this information (e.g.,B. from the usage information 140 of the storage device 134) and the current resource usage across existing computer workloads for the resource type associated with the request, return to the scheduler 128. Additionally or alternatively, the scheduler 128 can simply retrieve some or all of the usage information 140 from the monitoring module 133 or directly from the storage device 134, and the usage information 140 can include the current resource usage across existing computer workloads for the resource type associated with the request.

[0086] In step 412, based on the request parameters and the current resource utilization of existing workloads for one or more resource types in the request, scheduler 128 can determine whether there are candidates for compute nodes 108 that could handle the workload 130 according to the parameters determined from the request. For example, scheduler 128 can determine whether there are compute nodes 108 that have sufficient compute resources 110 to handle the resource quantities for workload 130. Filtering the compute nodes 108 that are candidates for allocation to workload 130 can reduce the processing in later steps to evaluate whether the use of compute resources 110 by these compute nodes 108 compute nodes compute within the license restrictions set by the license 136 associated with workload 130.If this is the second or subsequent pass through the determination in step 412 (see step 420), then the scheduler 128 can determine in step 412 whether another candidate compute node 108 exists.

[0087] If, in step 412, scheduler 128 determines that there are no eligible compute nodes 108, procedure 400 can proceed to step 414. In step 414, scheduler 128 can reject the request to schedule workload 130 and place workload 130 in a pending state. For example, scheduler 128 can place workload 130 in a queue 129 for pending workloads, which, if workload 130 was originally pulled from queue 129, may involve returning workload 130 to queue 129. In step 416, scheduler 128 can generate an alert, which can be logged by manager node 104, made available in the manager interface 142, and / or sent to a system administrator or other appropriate instance.

[0088] Returning to step 412: If, in step 412, Scheduler 128 determines that one or more candidate compute nodes 108 exist, Scheduler 128 may, in step 418, select a compute node 108 as a candidate to evaluate whether the allocation of compute resources 110 from that candidate compute node 108 to workload 130 would comply with the license restrictions of a license 136 associated with workload 130. Scheduler 128 may select a candidate for compute node 108 in any appropriate manner and according to any appropriate criteria. To the extent that Scheduler 128 iterates through multiple candidate compute nodes 108 to attempt to identify a compute node 108 that can be allocated to workload 130 in a manner consistent with the license restrictions of a license 136 associated with workload 130 (see, for example,(steps 412, 418 and 420), the planner can mark 128 rejected candidate compute nodes 108 as considered, so that the rejected candidate compute nodes 108 in step 418 are not selected again during the current evaluation of the workload 130.

[0089] In step 420, Scheduler 128 can determine whether scheduling the workload 130 associated with the request, using the compute resources 110 of the candidate compute node 108 selected in step 418, would result in total resource utilization exceeding the total licensed capacity. For example, Scheduler 128 can add the requested amount of resources for the workload 130 associated with the request (e.g., as determined in step 404) to the total current resource utilization across the existing workloads 130 for the resource type (associated with the workload 130 of the request) and determine whether the sum exceeds the total licensed capacity for that resource type determined in step 404. Scheduler 128 can perform the determination in step 420 for each resource type and / or resource category that is subject to a license restriction.

[0090] If, in step 420, the planner 128 determines that scheduling the workload 130 associated with the request would cause the total resource utilization to exceed the total licensed capacity, then the procedure 400 can return to step 412 so that the planner 128 can determine if there are any additional eligible compute nodes 108. If, in step 420, the planner 128 determines that scheduling the workload 130 associated with the request would not cause the total resource utilization to exceed the total licensed capacity, the planner 128 can, at least in step 422, approve the first compute workload 130 for scheduling using the compute resources 110 of the currently eligible compute node 108, based on the determination that the total resource utilization does not exceed the total licensed capacity.

[0091] Fig. Figure 5 illustrates an example procedure 500 for identifying candidates for compute node 108 and determining associated compute resource allocation sets according to certain implementations. Some or all of the operations described with reference to procedure 500 may be performed by scheduler 128, including the potential workload license evaluation engine 202; however, for the sake of simplicity, the operations are described as if they were performed by scheduler 128. Procedure 500 may be an example technique for performing step 412 of procedure 400 of Fig. 4. Furthermore, the procedure 500 is described using GPU devices as an example for the compute resources 110 that are the subject of a workload request. However, it is understood that the scheduler 128 can perform the procedure 500 for any suitable type of compute resources 110. A candidate node may refer to a compute node 108 that has sufficient compute resources 110 to process the workload 130, but which might be suitable or unsuitable with regard to license restrictions.

[0092] In step 502, the planner 128 can initialize a node counter. In certain implementations, initializing the candidate node counter involves setting the candidate node counter to zero, since no candidate nodes were identified.

[0093] In step 504, the planner 128 can determine whether compute nodes 108 are available. This determination can be a relatively simple one: whether compute nodes 108 exist and are operational in cluster 102. If the planner determines in step 504 that no compute nodes 108 are available (or no longer available, if in a second or subsequent pass), procedure 500 can proceed to step 522, described below. Conversely, if the planner 128 determines in step 504 that one or more compute nodes 108 are available, procedure 500 can proceed to step 506.

[0094] In step 506, the planner 128 can select a specific compute node 108 from the available compute nodes 108. In step 508, the planner 128 can determine the number of physical GPUs for the selected compute node 108. The planner 128 can determine the number of physical GPUs for the selected compute node 108 according to the usage information 140.

[0095] In step 510, scheduler 128 can determine the GPU capacity for the selected compute node 108. In some examples, GPU partitioning is possible. In this case, the GPU capacity available for workloads can be greater than the number of physical GPUs. Fig. Figure 7, described below, shows an example where physical GPU partitioning is permitted. In some examples, the GPU capacity may be equal to the number of physical GPUs, for example, when physical GPU partitioning is not available. The example described below Fig. Figure 8 shows an example where GPU partitioning is not possible.

[0096] In step 512, the scheduler 128 can determine the number of workloads 130 on the selected compute node 108. That is, the scheduler 128 can determine the number of workloads 130 already running on the selected compute node 108. These workloads may or may not be associated with the entity associated with the workload 130 to be scheduled. The scheduler 128 can determine the number of workloads 130 already running on the selected compute node 108 using usage information 140.

[0097] In step 514, the scheduler 128 can determine the number of GPUs allocated on the selected compute node 108. In an example where the GPU capacity equals the number of physical GPUs (for example, if no physical GPU partitioning is available), the number of allocated GPUs can be equal to the number of workloads 130 determined in step 512. In an example where GPU partitioning is available, the number of allocated GPUs on the selected compute node can be determined by dividing the number of workloads 130 on the selected compute node 108 (as determined in step 512) by the GPU capacity for the selected compute node 108 (as determined in step 510).

[0098] In step 516, the scheduler 128 can add the number of requested GPUs to the number of GPUs allocated on the selected compute node 108 to determine the total number of GPUs allocated to the selected compute node 108. In an example where the GPU capacity equals the number of physical GPUs (for example, if no physical GPU partitioning is available), the number of requested GPUs can simply be added to the number of GPUs allocated to the selected compute node 108. In an example where GPU partitioning is available, the number of requested GPUs can be divided by the GPU capacity for the selected compute node 108 (as determined in step 510), and then the quotient can be added to the number of GPUs allocated to the selected compute node, as determined in step 514.

[0099] In step 518, the scheduler 128 can determine whether the allocated GPUs for the selected compute node 108, plus the requested GPUs for the selected compute node 108 (a sum determined in step 516), exceed the capacity of the selected compute node 108 (as determined in step 510). If the scheduler 128 determines in step 518 that the capacity is exceeded, the procedure 500 can return to step 504 to determine whether additional compute nodes 108 are available. If the scheduler 128 determines in step 518 that the capacity is not exceeded, the procedure 500 can proceed to step 520.

[0100] In step 520, the scheduler 128 can identify the selected compute node 108 as candidate compute node 108 and increment the candidate node counter by 1. In conjunction with identifying the selected compute node 108 as candidate compute node 108, the scheduler 128 can also record the total GPUs allocated to the selected compute node 108, calculated in step 516, to assess whether allocating the GPU resources of candidate compute node 108 to workload 130 would comply with the license restrictions of license 136 associated with workload 130 (see Fig. 6, described below). After step 520, the scheduler 128 can return to step 504 to determine if any additional compute nodes 108 are available.

[0101] If one returns to step 504, either at the beginning or after step 518 or step 520, if the planner 128 determines in step 504 that there are no available compute nodes 108 (in a first pass of procedure 500) or no further available compute nodes 108 (in a second or subsequent pass of procedure 500), then procedure 500 can continue with step 522.

[0102] In step 522, scheduler 128 can determine if the candidate node counter is greater than 0. If scheduler 128 determines in step 522 that the candidate node counter is not greater than 0, procedure 500 can proceed to step 524. In step 524, scheduler 128 can determine that there are no candidate nodes 108 available to process workload 130 and can reject the request to schedule workload 130. If, instead, scheduler 128 determines in step 522 that the candidate node counter is greater than 0, procedure 500 can proceed to step 526. In step 526, scheduler 128 can return the list of candidates for compute nodes 108 and the total GPU allocated to each candidate for compute node 108.

[0103] Fig. Figure 6 illustrates an example procedure 600 for evaluating the allocated and requested resource utilization for one or more compute nodes 108 according to certain implementations. Some or all of the operations described with reference to procedure 600 can be performed by scheduler 128, including the potential workload license evaluation engine 202; however, for the sake of simplicity, the operations are described as if they were performed by scheduler 128. Procedure 600 can be an example technique for performing steps 310-314 of procedure 300. Fig. 3 and / or steps 418-422 of procedure 400 of Fig. 4. Furthermore, the procedure 600 is described using GPU devices as an example for the computing resources 110 that are the subject of a workload request. However, it is self-evident that the scheduler 128 can perform the procedure 600 for any suitable type of computing resources 110.

[0104] In step 602, the planner 128 can select a specific candidate node 108 from the possible candidate nodes 108, which are selected according to procedure 500 of Fig. 5 were determined. In step 604, the planner 128 can obtain the total allocated GPUs for the selected candidate node 108. For the selected candidate node 108, the sum of the allocated GPUs could, for example, be the value determined in step 516 of procedure 500. Fig. 5 was determined.

[0105] Continuing the procedure 600 of Fig. In step 606, the planner 128 can determine the total GPUs allocated to other nodes 108 that have workloads 130 assigned to the licensee associated with workload 130. For example, since procedure 600 attempts to determine whether the licensee associated with workload 130 can use workload 130 in a manner consistent with a license 136 held by the licensee, step 606 can determine the total GPUs allocated to other nodes 108 that have workloads 130 assigned to the licensee associated with workload 130.

[0106] In step 608, Scheduler 128 can calculate a suggested total number of allocated GPUs. This suggested total number of allocated GPUs can be the sum of the number determined in step 604 and the number determined in step 606.

[0107] In step 610, scheduler 128 can determine whether the license capacity has been exceeded. Specifically, based on the selected candidate node 108 and the proposed total number of allocated GPUs determined in step 608, scheduler 128 can determine whether the GPU license capacity for the licensee associated with workload 130 is exceeded.

[0108] If, in step 610, planner 128 determines that the license capacity is not exceeded, it can select candidate node 108 for approval to process workload 130 in step 612. If, in step 610, planner 128 determines that the license capacity has been exceeded, it can determine in step 614 whether there are any additional candidate nodes 108. If, in step 614, planner 128 determines that there are additional candidate nodes 108, then procedure 600 can return to step 602 to select a new candidate node 108. Conversely, if planner 128 determines in step 614 that there are no additional candidate nodes 108, procedure 600 can proceed to step 616. In step 616, planner 128 can determine that workload 130 should be rejected.

[0109] Although the procedure 600 in Fig. 6, which is described in relation to a specific resource type, namely GPUs, it should be understood that the procedure 600 can be repeated for any number of types of computing resources 110 and / or other license categories that may affect a license 136 for the licensee associated with the workload 130.

[0110] In the Fig. Sections 7 and 8 present example scenarios for the allocation of computer resources and related example considerations for licensing according to certain implementations. This disclosure includes these specific, possibly simplified examples only to facilitate understanding of certain implementations of this disclosure. These examples do not limit the scope of this disclosure.

[0111] Fig. Figure 7 illustrates an example scenario for the allocation of computing resources and related example licensing considerations according to specific implementations. The in Fig. The example scenario shown in Figure 7 is referred to as Example 1 and represents an example configuration in which GPU partitioning is permitted.

[0112] In Example 1, a computing system contains three GPU-enabled compute nodes, and each of the three GPU-enabled compute nodes has one pGPU. The computing system is configured with the following GPU partition capacity per node: the single pGPU of Node 1 is divided into seven GPU partitions, the single pGPU of Node 2 is divided into four GPU partitions, and the single pGPU of Node 3 is divided into four GPU partitions. The partition size for this arrangement is also considered small. For the purposes of these examples, it is assumed that the partition sizes can be small, medium, large, or whole (whole meaning the entire pGPU is not divided into smaller partitions). To continue with Example 1: The licensee has a total of 2 pGPU licenses.

[0113] The current state of the computer system includes certain allocated workloads that consume a portion of the licensee's GPU capacity. For example, Node 1 has GPU workloads consuming 4 GPUs, which is 0.57 of the pGPUs for Node 1. This is because Node 1 has one pGPU that is divided into seven GPU partitions, and four divided by seven equals 0.57. Another example: Node 2 has GPU workloads consuming 2 GPUs, which is 0.5 of the pGPUs for Node 2. This is because Node 2 has one pGPU that is divided into four GPU partitions, and two divided by four equals 0.5. Another example: Node 3 has GPU workloads consuming 1 GPU, which is 0.25 of the pGPUs for Node 3. This is because Node3 has a pGPU that has been split into four GPU partitions, and one divided by four equals 0.25.

[0114] Continuing from Example 1, the licensee can start a new workload that requests three GPUs. In this example, only two of the three compute nodes have enough available GPUs to accommodate the three GPUs requested by the new workload: Node1 and Node3. This is because two of the four GPUs (GPU partitions) on Node2 have already been allocated (leaving only two GPU partitions available on Node2). As described above, the licensee only has two pGPU licenses. Therefore, depending on which compute node (between Node1 and Node3) the scheduler selects, the licensee might not have enough licenses to start the new workload. For example, Node3 might be selected because only one of its four GPU partitions has been allocated; however, using the three available GPU partitions on Node3 would cause the licensee to exceed its licensed capacity of two pGPUs.Specifically, using the three available GPU partitions of Node3 would bring the pGPU usage for Node3 to 1. Adding the pGPU usage of all three compute nodes would result in a total pGPU usage of 2.07, which exceeds the licensee's licensed capacity of 2, meaning the requested workload would be denied in this scenario.

[0115] To illustrate this, the following calculations can be performed. First, the total number of allocated pGPUs on the selected compute node (Node3 in this example) can be determined. In this example, the calculation is 0.25 (i.e., the number of GPU partitions already allocated relative to the total number of GPU partitions for this compute node, Node3) plus 0.75 (i.e., the number of GPUs requested relative to the total number of GPU partitions for this compute node, Node3), which equals 1 pGPU (the single pGPU of Node3). Using the formula (Total allocated pGPUs + Total requested pGPUs) to determine the total pGPUs required, the total requirement is 2.07 pGPUs, which exceeds the licensee's licensed capacity of 2 pGPUs.

[0116] Performing similar calculations with Node1 as the selected compute node, the three requested GPUs would correspond to 0.43 of Node1's pGPUs (three of Node1's seven GPU partitions (3 / 7 = 0.43)). Adding the 0.43 pGPUs for the requested workload to the 0.57 pGPUs already allocated by Node1 results in 1 pGPU. Adding the total pGPUs allocated to the other nodes to the 1 pGPU for Node1 yields 1.75 (1 (for the selected Node1, adjusted for the requested 3 pGPUs) + 0.5 (for Node2) + 0.25 (for Node3), totaling 1.75). This total (1.75) is less than the licensee's two licensed pGPUs, so the workload can be scheduled using three loGPUs from Node1.

[0117] Fig. Section 8 illustrates example scenarios for the allocation of computing resources and associated example licenses according to specific implementations. The in Fig. The eight example scenarios shown are referred to as Example 2 and include Examples 2a and 2b. Example 2 shows example configurations in which GPU partitioning is not permitted.

[0118] In Example 2 (both Example 2a and Example 2b), a computing system comprises three GPU-enabled compute nodes, and each of the three GPU-enabled compute nodes comprises 4 pGPUs. The computing system is configured so that the partition size is whole, meaning that the pGPUs of each compute node are not partitioned into GPUs and are allocated as a single pGPU. In Example 2 (both Example 2a and Example 2b, see below), the licensee has a total of 8 pGPU licenses.

[0119] In Example 2a, the current state of the computing system includes certain allocated workloads that consume a portion of the licensee's GPU capacity. For example, Node1 has GPU workloads consuming 2 of the 4 pGPUs for Node1, Node2 has GPU workloads consuming 2 of the 4 pGPUs, and Node3 has GPU workloads consuming 1 of the 4 pGPUs.

[0120] Since it is not possible to request GPU partitions under the system in Example 2 (e.g., because the partition size is full), this request applies to 3 pGPUs. In this example, only one of the three compute nodes has enough available pGPUs to accommodate the requested 3 GPUs for the new workload, namely Node 3, because 2 of the 4 pGPUs from Node 1 and 2 of the 4 pGPUs from Node 2 have already been allocated (leaving only 2 pGPUs available at each of Node 1 and 2). As described above, the licensee has eight pGPU licenses. Therefore, if we take Node 3 as a candidate for the three requested pGPUs and add the three requested pGPUs to the 1 pGPU from Node 3, Node 3 would be allocated 4 pGPUs. By adding the pGPU usage of all three compute nodes, the total pGPU usage would amount to 8 pGPU, which is equal to (or less than) the licensee's licensed capacity of 8 pGPU.The requested workload would be permissible in this scenario.

[0121] To illustrate this, the following calculations can be performed. First, the total number of pGPUs allocated to the selected compute node (Node3 in this example) can be determined. In this example, the calculation is 1 pGPU (i.e., the number of pGPUs already allocated, 1 pGPU) plus 3 pGPU (i.e., the number of pGPUs requested), which equals 4 pGPUs. Using the formula (total number of allocated pGPUs + total number of requested pGPUs) to determine the total pGPU requirement, the total pGPU requirement would be 8, which is less than or equal to the licensee's licensed capacity of 8 pGPUs, meaning that the requested workload would be permissible in this scenario.

[0122] In Example 2b, the current state of the computer system includes certain allocated workloads that consume a portion of the licensee's GPU capacity. For example, Node 1 has GPU workloads that consume 3 of the 4 pGPUs for Node 1, and Node 2 has GPU workloads that consume 2 of the 4 pGPUs. However, Node 3 has no GPU workloads that consume the 4 pGPUs of Node 3.

[0123] Continuing with Example 2b: The licensee can start a new workload that requests four GPUs. Since it's not possible to request GPU partitions under the system in Example 2 (e.g., because the partition size is full), this request applies to 4 pGPUs. In this example, only one of the three compute nodes has enough available pGPUs to accommodate the requested 4 GPUs of the new workload: Node3. This is because 3 of the 4 pGPUs from Node1 and 2 of the 4 pGPUs from Node2 have already been allocated (leaving only 1 pGPU available for Node1 and only 2 pGPUs available for Node2). As described above, the licensee has eight pGPU licenses. Therefore, if we take Node3 as a candidate for the four requested pGPUs and add the four requested pGPUs to the 0 pGPUs already allocated to Node3, Node3 would be allocated 4 pGPUs.If you add up the pGPU usage of all three compute nodes, the total pGPU usage would be 9 pGPU, which exceeds the licensee's licensed capacity of 8 pGPU, meaning that the requested workload would be rejected in this scenario.

[0124] To illustrate this, the following calculations can be performed. First, the total number of pGPUs allocated to the selected compute node (Node3 in this example) can be determined. In this example, the calculation is 0 pGPU (i.e., the number of pGPUs already allocated) plus 4 pGPU (i.e., the number of pGPUs requested), which equals 4 pGPUs. Using the formula (total number of allocated pGPUs + total number of requested pGPUs) to determine the total pGPU requirement, the total pGPU requirement would be 9, which exceeds the licensee's licensed capacity of 8 pGPUs. This means that the requested workload would be rejected in this scenario.

[0125] Fig. Figure 9 shows a block diagram of an example computer 900 according to certain implementations. As described above, implementations of this disclosure can be performed using computing devices. For example, all or some of the implementations described in the Fig. The components or procedures shown in Figures 1-8 (e.g., System 100, Computing Cluster 102, Manager Node 104, Computing Node 108 and Procedures 300, 400, 500, 600 and 700) can be implemented at least partially with one or more computer devices such as the Computer Device 900.

[0126] The computer device 900 can include one or more computer processors 902, non-persistent memory 904 (e.g., volatile memory such as RAM, cache memory, etc.), persistent memory 906 (e.g., a hard disk, an optical drive such as a CD drive or DVD drive, flash memory, etc.), a communication interface 912 (e.g., a Bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), input devices 910, output devices 908, and numerous other elements and functions. Each of these components is described below.

[0127] In certain embodiments, the computer processor(s) 902 may be an integrated circuit for processing instructions. The computer processor(s) may, for example, be one or more cores or microcores of a processor. The processor 902 may be a general-purpose processor configured to execute program code contained in the software running on the computer device 900. The processor 902 may be a special-purpose processor in which specific instructions are integrated into the processor design. Although in Fig. Where only one processor 902 is shown, the computer device 900 can contain any number of processors.

[0128] The computer device 900 may also include one or more input devices 910, such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, motion sensor, or other type of input device. The input devices 910 enable a user to interact with the computer 900. In certain embodiments, the computer device 900 may include one or more output devices 908, such as a screen (e.g., a liquid crystal display (LCD), plasma display, touchscreen, cathode ray tube (CRT) monitor, projector, or other display device), a printer, external storage, or other output device. One or more of the output devices may be identical to or different from the input device(s).The input / output device(s) can be connected locally or remotely to the computer processor(s) 902, the non-persistent memory 904, and the persistent memory 906. There are many different types of computer equipment, and the input / output device(s) mentioned above can take other forms. In some cases, multimodal systems can allow a user to provide several types of input / output to communicate with the computer equipment 900.

[0129] In addition, the 912 communication interface can facilitate the connection of the 900 computer device to a network (e.g., a LAN, WAN, such as the Internet, a mobile network, or any other type of network) and / or to another device, such as another computer device.The 912 communication interface can perform or facilitate the reception and / or transmission of wired or wireless communications using wired and / or wireless transmit / receive devices, including those providing an audio connector, microphone connector, USB (Universal Serial Bus) connector, Apple® Lightning® connector, Ethernet connector, fiber optic connector, proprietary wired connector, Bluetooth® wireless signal transmission, Bluetooth® Low Energy (BLE) wireless signal transmission, IBEACONO wireless signal transmission, RFID wireless signal transmission, near field communication (NFC) wireless, Dedicated Short Range Communication (DSRC) wireless signal transmission, or an 802.11 Wi-Fi radio signal transmission, WLAN signal transmission, Visible Light Communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), IR communication radio signal transmission, Public Switched Telephone Network (PSTN) signal transmission, Integrated Services Digital Network (ISDN) signal transmission, 3G / 4G / 5G / LTE cellular data network radio signal transmission, Ad-hoc network signal transmission, Radio wave signal transmission, Microwave signal transmission, Infrared signal transmission, Visible light signal transmission, Ultraviolet light signal transmission, Radio signal transmission along the electromagnetic spectrum or a combination thereof.

[0130] The 912 communication interface can also include one or more GNSS (Global Navigation Satellite System) receivers or transceivers, which are used to determine the location of the 900 computer device based on the reception of one or more signals from one or more satellites connected to one or more GNSS systems. GNSS systems include, among others, the US Global Positioning System (GPS), the Russian Global Navigation Satellite System (GLONASS), the Chinese BeiDou Navigation Satellite System (BDS), and the European Galileo GNSS. There is no restriction on operation on a particular hardware configuration, and therefore the basic functions described here can easily be replaced by improved hardware or firmware configurations as they are developed.

[0131] The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or transmitting instructions and / or data. A computer-readable medium can be a non-transient medium capable of storing data and which does not contain carrier waves and / or transitory electronic signals that propagate wirelessly or via wired connections. Examples of non-transient media include, but are not limited to, magnetic disks or tapes, optical storage media such as CDs or DVDs, flash memory, and storage devices.A computer-readable medium can store code and / or machine-executable instructions that may represent a procedure, function, subroutine, program, routine, module, software package, class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., can be passed, relayed, or transmitted in any manner, such as by sharing memory, passing messages, passing tokens, transmitting over a network, or similar means.

[0132] All or some of the components of the Computer Device 900 may be implemented in circuits. For example, the components may contain electronic circuits or other electronic hardware and / or be implemented using electronic circuits that may contain one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs), digital signal processors (DSPs), CPUs, and / or other suitable electronic circuits) and / or be implemented using computer software, firmware, or any combination thereof to perform the various operations described. In some aspects, the computer-readable storage devices, media, and memory may contain a wired or wireless signal containing a bitstream and the like.However, non-transient computer-readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and signals as such.

[0133] Certain implementations of this disclosure may offer some, none, or all of the following technical benefits. In certain implementations, disclosure can enable more efficient resource utilization. For example, by tying licenses to actual workload usage rather than total infrastructure capacity, organizations can optimize their license purchases and potentially reduce costs. This approach can allow customers to pay for the resources they actively use and reduce or eliminate payments for unused or overhead capacity.

[0134] Certain implementations can offer customers greater flexibility. For example, the system can allow workloads to be queued when license capacity is reached, instead of rejecting them outright. This enables companies to better manage peak usage while avoiding license oversubscription.

[0135] Certain implementations can offer more granular control over licensing. For example, some implementations allow different categories of workloads or resources to be licensed separately and / or differently. This capability could enable tailored licensing models that are better aligned with an organization's specific usage patterns and objectives.

[0136] Certain implementations can provide real-time insights into license usage. By dynamically tracking resource consumption across different workloads, organizations can gain deeper insights into their licensing goals and usage patterns. This information can help them make more informed decisions about license acquisition and resource allocation.

[0137] Certain implementations can offer advantages in multi-cloud or hybrid cloud environments. For example, by using a custom scheduler that can be integrated with container orchestration platforms like Kubernetes, the system could be able to enforce consistent licensing policies across different cloud environments.

[0138] In certain implementations, this disclosure can enable more precise license enforcement for specialized resources. For example, some implementations offer the ability to manage GPU usage in fractions, allowing for more accurate licensing of GPU resources. This can be particularly valuable for artificial intelligence and machine learning workloads where GPU usage can vary significantly.

[0139] Certain implementations can offer advantages to software vendors. By providing more accurate usage data and more dynamically enforcing licenses, vendors could, for example, offer more flexible licensing models. This could potentially open up new market opportunities or pricing strategies.

[0140] It goes without saying that the systems and methods described in this disclosure may be combined in any suitable way.

[0141] Although certain operations are described or illustrated in this revelation in a particular order, the operations may occur in any suitable sequence. Furthermore, this revelation assumes that all suitable operations may be repeated one or more times in any order. Even if certain operations are described or depicted in this revelation as occurring sequentially, all suitable operations may, if appropriate, occur substantially at the same time. Any suitable operation or sequence of operations described or illustrated herein may be interrupted, suspended, or otherwise controlled by another process, such as an operating system or kernel, where appropriate.The actions can be performed in an operating system environment or as standalone routines that consume all or a substantial part of the system processing.

[0142] Although this disclosure has been described with reference to illustrative implementations, this description should not be interpreted in a restrictive sense. Various modifications and combinations of the illustrative implementations, as well as other implementations of the disclosure, will be apparent to those skilled in the art from the description. It is therefore intended that the appended claims encompass all such modifications or implementations.

Claims

[1] A computer device comprising the following: one or more processors; and one or more non-transitory, computer-readable storage media that store a program for execution by one or more processors, wherein the program comprises instructions for: Receiving a request to schedule an initial computer workload; Determine a resource type and a requested resource quantity for the initial computer workload in accordance with the requirement; Obtaining the full licensed capacity for the resource type; Obtain current resource usage information about existing computer workloads for the resource type; Determine whether scheduling the initial computer workload would result in total resource utilization exceeding the total licensed capacity; and at least on the basis of the finding that the total resource usage would not exceed the total licensed capacity, release the first computer workload for scheduling; or at least on the basis of the finding that the total resource usage would exceed the total licensed capacity, the first computer workload should be queued for later scheduling. [2] Computer device according to claim 1, wherein the programming further comprises instructions for determining a first category for the first computer workload, wherein the first workload category is one of several categories, wherein the total licensed capacity and the current resource usage are determined specifically for the first category. [3] Computer device according to claim 2, wherein the first category corresponds to the resource type determined according to the requirement. [4] Computer device according to claim 3, wherein the resource type comprises one or more of the following elements: a central processing unit (pCPU); a virtual CPU (vCPU) a physical graphics processing unit (pGPU); a logical graphics processing unit (IoGPU); or a lot of storage space. [5] Computer device according to claim 2, wherein the first workload category corresponds to a specific computer framework from a plurality of possible computer frameworks. [6] Computer device according to claim 5, wherein a second workload category corresponds to the resource type determined according to the requirement, wherein the total licensed capacity for the resource type is specific to the resource type of the determined computer framework. [7] Computer device according to claim 1, wherein: for GPU resources: the total licensed capacity is based on a number of licensed physical GPUs; the current resource usage is based on partitioned GPU usage across workloads; and The instructions for determining whether scheduling the initial computer workload would result in total resource usage exceeding the total licensed capacity include instructions for converting the partitioned GPU usage into an equivalent number of physical GPUs. [8] Computer device according to claim 1, further comprising instructions to determine, prior to obtaining the total licensed capacity for the resource type and obtaining the current resource usage via existing computer workloads for the resource type, that one or more pre-check criteria are met, wherein the pre-check criteria include validating that an active license exists for the resource type associated with the first requirement. [9] Computer device according to claim 1, wherein the requirement to schedule the first computer workload comprises a requirement to schedule the computer workload to be executed using one or more resources of a computer cluster implemented in a cloud computing environment, wherein the cloud computing environment comprises a container orchestration platform and at least one part of the one or more resources is of the resource type. [10] Computer device according to claim 1, wherein: Before receiving a request to schedule an initial computer workload, the first computer workload is selected from a queue of pending workloads; and The instructions for queuing the first computer workload, at least on the basis of the finding that total resource usage would exceed total licensed capacity, include instructions to return the first computer workload to the queue for pending workloads for later scheduling. [11] A computer-implemented method comprising the following: Receiving an initial request to schedule an initial computer workload by a computer device; Determining a resource type and a requested resource quantity for the first computer workload by the computer device and in accordance with the first request; Determining the total licensed capacity for the resource type by the computer device; Obtaining current resource usage for the resource type across existing computer workloads by the computer device; Approval of the first computer workload for scheduling by the computer device, based at least on the finding that scheduling the first computer workload would not result in the total resource utilization exceeding the total licensed capacity. [12] Computer-implemented method according to claim 11, further comprising: Receiving a second request to schedule a second computer workload by the computer device; Determining a resource type and a requested resource quantity for the second computer workload by the computer device and in accordance with the second requirement; Obtained, through the computer device, a total licensed capacity for the resource type for the second computer workload; Obtaining current resource utilization across existing computer workloads for the resource type for the second computer workload by the computer device; and Queuing the second computer workload for later scheduling, at least on the basis of the finding that the total resource usage for the second computer workload would exceed the total licensed capacity for that resource type for the second computer workload. [13] Computer-implemented method according to claim 11, further comprising determining a first category for the first computer workload, wherein the first category is one of several categories and the total licensed capacity and current resource usage are determined specifically for the first category. [14] Computer-implemented method according to claim 13, wherein the first category corresponds to the resource type determined according to the requirement. [15] Computer-implemented method according to claim 14, wherein the resource type comprises one or more of the following elements: a central processing unit (pCPU); a virtual CPU (vCPU) a graphics processing unit (pGPU); a virtual graphics processing unit (IoGPU); or a lot of storage space. [16] Computer-implemented method according to claim 13, wherein the first category corresponds to a specific computer framework from a plurality of possible computer frameworks. [17] Computer-implemented method according to claim 11, wherein: for GPU resources: the total licensed capacity is based on a number of licensed physical GPUs; the current resource usage is based on partitioned GPU usage across workloads; and Determining whether scheduling the initial computing workload would result in total resource usage exceeding the total licensed capacity involves converting the partitioned GPU usage into an equivalent number of physical GPUs. [18] Computer-implemented method according to claim 11, further comprising instructions to determine, prior to obtaining the total licensed capacity for the resource type and obtaining the current resource usage via existing computer workloads for the resource type, that one or more pre-verification criteria are met, wherein the pre-verification criteria include validating that an active license exists for the resource type associated with the first computer workload request. [19] Computer-implemented method according to claim 11, wherein: Before receiving a request to schedule an initial computer workload, the first computer workload is selected from a queue of pending workloads; and where queuing the first computer workload for later scheduling, at least on the basis of the finding that total resource usage would exceed total licensed capacity, includes instructions to return the first computer workload to the queue for pending workloads. [20] One or more non-transitory, computer-readable storage media that store a program for execution by one or more processors, the program comprising instructions for: Receiving a request to schedule an initial computer workload; Determine a resource type and a requested resource quantity for the initial computer workload in accordance with the requirement; Determine the total licensed capacity for the resource type; Obtain current resource usage information about existing computer workloads for the resource type; Determine whether scheduling the initial computer workload would result in total resource utilization exceeding the total licensed capacity; and at least on the basis of the finding that total resource usage would not exceed the total licensed capacity, release the first computer workload for scheduling; or at least on the basis of the finding that the total resource usage would exceed the total licensed capacity, queue the first computer workload for later scheduling.

Images