LABOR RESOURCE ALLOCATION USING A MACHINE LEARNING MODEL

Abstract

In some examples, a system receives a request from a requester to execute an initial workload in a virtual computing environment and determines the requester type, which is one of a variety of different requester types. The system receives metrics related to resource utilization in the virtual computing environment and, using a machine learning model, determines a resource allocation to the initial workload based on the requester type and the metrics. The machine learning model adjusts the resource allocation for the initial workload based on further collected metrics related to resource utilization by the workload and on recognized requester behavior while the initial workload is running in the virtual computing environment.

Description

background

[0001] A computer system can contain a virtual computing environment in which virtual computing units, such as containers or virtual machines (VMs), can run. These virtual computing units can be used to execute workloads initiated by requesters. Brief description of the drawings

[0002] Some embodiments of the present disclosure are described with reference to the following figures. Fig. Figure 1 is a block diagram of an arrangement that includes a proactive workload management engine and other components, according to some examples. Fig. Figure 2 is a flowchart of a proactive workload management process, based on some examples. Fig. Figure 3 is a block diagram of a storage medium that stores machine-readable instructions according to some examples. Fig. Figure 4 is a block diagram of a system according to some examples. Fig. Figure 5 is a flowchart of a procedure according to some examples.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated to make the example shown clearer. Furthermore, the drawings contain examples and / or embodiments that correspond to the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. Detailed description

[0004] A virtual computing environment can support scalability and flexibility by adjusting the number of virtual compute units running to meet the demands of the requesters. A requester can initiate a workload to be executed by virtual compute units. However, managing workloads in a virtual computing environment presents several challenges. Virtual compute units used to execute workloads can compete for computer system resources. Insufficient resource allocation for a workload can negatively impact its performance. For example, it may take a long time to complete, or the workload may restart unexpectedly.Furthermore, a lack of timely insight into workload resource consumption can prevent an organization from understanding why workload performance is suffering and from determining what measures to take to improve workload performance.

[0005] Some example approaches employ reactive resource scaling for workloads, where administrators or other users can monitor workload operations in a virtual machine environment using monitoring tools and manually or programmatically adjust resource allocations to meet targets such as Quality of Service (QoS) objectives. However, such reactive scaling approaches can lead to suboptimal resource allocation for workloads, including over- or under-provisioning. Over-provisioning resources to workloads results in inefficient resource allocation, driving up costs, while under-provisioning leads to workload performance issues.Furthermore, manually adjusting resource allocations is labor-intensive and can be slow, resulting in less flexibility in managing workloads in a virtual computing environment.

[0006] In accordance with some implementations of this disclosure, proactive workload management systems or techniques are capable of making predictive adjustments to resources allocated to workloads in a virtual computing environment based on monitored metrics, requester types, and requester behaviors. Adjusting resources may involve one or a combination of the following: adjusting how many virtual compute units are used to run a workload; adjusting on which physical compute nodes of a computer system the virtual compute units run; selecting the types of physical resources used by the virtual compute units; or any other adjustment that changes the quantity or type of resources used by a workload.A “resource” can therefore refer to a virtual computing unit or a physical resource.

[0007] In some examples, a workload management system determines the type of requester that has requested the execution of a workload, receives metrics relating to resource utilization in the virtual computing environment, uses a machine learning model to determine a resource allocation for the workload based on the determined requester type and the metrics, and dynamically adjusts the resource allocation for the workload using the machine learning model based on further collected metrics relating to resource utilization by the workload and on captured requester behavior while the workload is running in the virtual computing environment. It should be noted that multiple machine learning models can be used, for example, one machine learning model per requester or group of requesters.

[0008] The workload management system is able to predict periods of increased or decreased workload using a machine learning model that is continuously (or iteratively) refined, allowing proactive adjustments to resource allocations to meet demands and avoid over-provisioning of resources, thus reducing costs and increasing efficiency.

[0009] The following discussion refers to examples where the requester of a workload is a user. Other examples may apply techniques or mechanisms according to some implementations of this disclosure to other types of requesters, including programs or machines. The following discussion also refers to the use of containers to execute workloads. Other examples may use other types of virtual computing units, such as VMs, to execute workloads in a virtual computing environment.

[0010] Fig. Figure 1 is a block diagram of a sample arrangement containing a proactive workload management engine (102) that can manage user-requested workloads running in containers on physical compute nodes. In the example of Fig. In example 1, container 104A runs on a physical compute node 106A, and container 104B runs on a physical compute node 106B. In other examples, a physical compute node may contain a different number of containers than in this example. Fig. 1 shown. Although Fig. While example 1 shows an example with two physical compute nodes, other examples may use a different number (one or more) of physical compute nodes.

[0011] In some examples, the physical compute nodes 106A and 106B are part of a compute cluster 108, which refers to a group of physical compute nodes (or worker machines). An example of a compute cluster 108 is a Kubernetes cluster running containerized applications (i.e., applications running in appropriate containers). In Kubernetes, containers are contained within pods, with a pod containing a specific number of containers. Although Kubernetes is referenced, containers in other examples may refer to other technologies.

[0012] The proactive workload management engine 102 receives a workload request 110 to initiate a workload using containers in the compute cluster 108. The workload request 110 can be initiated by a user and by an electronic device (e.g., 112 in Fig. 1) of the user.

[0013] The proactive workload management engine 102 also receives metrics 114 from a monitoring system 116. The monitoring system 116 can contain sensors in the compute cluster 108 that are capable of collecting metrics associated with operations of the compute cluster 108 while workloads from containers are running on the respective physical compute nodes 106A and 106B. A sensor can refer to a hardware sensor or a sensor implemented with machine-readable instructions.

[0014] Furthermore, a user management engine 118 can be used to define user profiles 120 for different users, who are then able to submit workload requests to the proactive workload management engine 102. The user management system 118 can also define groups, where a group represents a set of user profiles. The user management system 118 can provide group information 122 that defines the groups. As explained below, a specific user can be assigned to a group based on their user profile.

[0015] The proactive workload management engine 102 includes machine learning models 124, each of which can be used to determine resource allocation for a given workload. In some examples, custom machine learning models can be assigned to different users (or other types of requesters) or different groups of users (or groups of other types of requesters). The following discussion refers to the "machine learning model 124" in the singular. However, it should be noted that different machine learning models 124 can be used for workloads with different requesters or groups of requesters.

[0016] Furthermore, the machine learning model 124 can continuously adjust resource allocation in response to changing conditions during workload execution. The machine learning model 124 can initially be trained using a training dataset. Additionally, the machine learning model 124 can be updated based on learning through monitoring workload executions in compute cluster 108. It should be noted that resource allocation can still be based on a user-assigned resource quota and the available resources in compute cluster 108.

[0017] Examples of machine learning models that can be used include any or a combination of the following: classification models such as multi-label random forests or cost-sensitive decision trees, tabular transformation models, or other types of machine learning models. Machine learning model 124 can be trained using training data obtained by collecting metrics and usage data from existing deployments of compute clusters running workloads in various usage scenarios. Machine learning model 124 can be fine-tuned using continuously collected metrics and usage data from compute cluster 108 while running production workloads. Training a random forest model, for example, might involve adjusting the model's hyperparameters using a training dataset.Another example is training a cost-sensitive decision tree, where the decision tree grows based on a training data set.

[0018] The proactive workload management engine 102 can deliver a resource allocation output 126 to a scheduler 128. In some examples, the machine learning model 124 can generate output containing labels or parameters relating to various resources, and the proactive workload management engine 102 can use this output labels or parameters to generate a representation of the resource allocation, which is delivered to the scheduler 128 as resource allocation output 126. The resource allocation output 126 contains information that specifies a resource allocation for a workload generated using the machine learning model 124.Examples of resources that can be allocated include any or a combination of the following: a set of containers to use for the workload (or a number of pods to use), on which physical compute nodes the containers should run, types of physical resources to use for running the workload, or other types of resources.

[0019] Scheduler 128 schedules workloads using the resources specified by resource allocation output 126. For example, based on resource allocation output 126, scheduler 128 can schedule the execution of a workload using the specified number of containers (or pods), on one or more specified physical compute nodes, and using specific types of physical resources. In examples where compute cluster 108 is a Kubernetes cluster, scheduler 128 can be a Kubernetes scheduler. Other examples may use different types of schedulers.

[0020] As in Fig. As shown in Figure 1, the physical compute node 106A comprises physical resources 130A, including an accelerator 132A (e.g., a graphics processing unit (GPU), a data processing unit (DPU), a tensor processing unit (TPU), an application-specific integrated circuit, or another type of specialized processor), a central processing unit (CPU) 134A, a memory 136A, an input / output (I / O) device 138A, and other types of resources. Similarly, the physical compute node 106B comprises physical resources 130B, including an accelerator 132B, a CPU 134B, a memory 136B, an I / O device 138B, and other resources. Examples of I / O devices can be any or a combination of the following components: a network interface controller, disk-based storage, a graphics controller, or any other type of device capable of performing I / O operations.A CPU is used to execute primary machine-readable instructions, such as an operating system (OS), system firmware, and application programs. An accelerator is a specialized processor that can offer higher performance and energy efficiency than a CPU for certain types of operations, such as those related to artificial intelligence or other operations involving intensive mathematical operations. The output of resource allocation 126 can indicate the use of one or more of the aforementioned physical resources.

[0021] The proactive workload management engine 102 can also display a workload management user interface (UI) 150 on a display device 152 of the electronic device 112. The workload management UI 150 provides various insights into the workloads in the compute cluster 108. Examples of information that can be displayed in the workload management interface 150 include resource utilization information 154, which indicates the resource usage by a workload; objectives 156 that have been set for the workload; scaling actions 158 (including scaling actions that have been performed on the workload and / or upcoming scaling actions for the workload, where a "scaling action" may refer to an adjustment of a resource allocation); and group assignment information 160 (which relates to the assignment of a user profile to a group).The information displayed in the user interface 150 for workload management improves the user's understanding of the configuration and performance of the compute cluster and helps with troubleshooting when problems occur in the compute cluster 108.

[0022] In some examples, the proactive workload management engine 102 can provide real-time insights into workload performance and system optimization. These insights are delivered in "real time" as various pieces of information generated or considered by the proactive workload management engine 102 are displayed in the workload management user interface 150 as the information is being generated or used. A user can customize the visualization of the information displayed in the workload management UI 150, including selecting the display format (e.g., graphical format, text format, etc.), the numerical ranges to use, and the granularity of the displayed information, including a specific time range, the amount of information displayed per workload, per user or application, and so on.

[0023] The following are examples of metrics 114 that are collected by the monitoring system 116. Metrics 114 can include information about resource utilization, such as the use of a CPU, GPU, memory, and I / O device. Metrics 114 can also include information about resource requests, identifying specific resources requested by a workload. Metrics 114 can also include resource limits that restrict the use of certain resources. Furthermore, metrics 114 can include performance metrics related to workload performance, such as the time it takes to complete workloads, any workload restarts, whether workloads meet performance targets like QoS goals, and other performance metrics.

[0024] The metrics 114 enable the proactive workload management engine 102 to determine in the compute cluster 108 any or a combination of the following: the compute load of workloads, bottlenecks in workloads, over- or under-allocation of resources, compute requirements of workloads, memory requirements of workloads, I / O requirements of workloads, or other resource-related problems or information relating to the performance of workloads and the resources used by the workloads.

[0025] In some examples, the metrics collected by the monitoring system 116 may also include information that links the use of specific resources to particular users, applications, or individual workloads. In this way, the proactive workload management engine 102 can present granular information (e.g., in the workload management user interface 150) about resource consumption patterns of users, applications, or workloads. Other metrics 114 may include timestamps that represent user login times, times when resources were used, or other time-related information. The metrics 114 may also include historical usage information that shows how users, applications, or workloads have used resources in the past. Such historical usage information can be used by the machine learning model 124 to make future predictions about resource usage.

[0026] Additional metrics 114 can include geographic locations where workloads are run, as well as types of workloads (e.g., compute-intensive workloads that intensively utilize processing resources, memory-intensive workloads that have a large number of memory accesses, or I / O-intensive workloads that perform a large number of network communications or accesses to disk-based storage devices).

[0027] The proactive workload management engine can also receive resource utilization targets. These targets can be set by one or more administrative entities, such as human administrators, administrative programs, or administrative machines. A "target" can refer to a threshold that defines an upper or lower limit for resource utilization. Additionally or alternatively, a "target" can refer to a goal related to resource utilization. The target can be expressed as a range of resource utilization that the proactive workload management engine should allocate to a workload during workload execution. More generally, a "target" can refer to a target for a metric (or a collection of metrics).The objectives in section 162 can be granular objectives that can be configured for different types of users, different geographical regions, different organizations, different tenants, etc.

[0028] The goals (162) can be used by the machine learning model (124) to generate scaling measures for adjusting resource allocations. Resource allocation can be adjusted to achieve resource utilization that meets one or more of the goals (162). For example, a resource utilization cap can prevent individual workloads from monopolizing resources and negatively impacting other workloads. Furthermore, by comparing actual resource utilization with the goals (162), the proactive workload management engine (102) can identify containers that are provisioned too much (resource waste) or too little (potential performance issues).

[0029] As mentioned above, the workload management UI 150 presented by the proactive workload management engine 102 contains the targets 156, which can contain the targets 162 received by the proactive workload management engine 102. The display of the targets 162 in the workload management interface 150 allows a user (e.g., an administrator) to monitor resource utilization thresholds that can affect workload performance.

[0030] Furthermore, the resource usage information provided by the proactive workload management engine can assist in creating user profiles. For example, an administrator can use the user management engine to modify a specific user's profile based on the resource usage information. Changing a specific user's profile can affect which of several groups that specific user is assigned to.

[0031] The administrator can also adjust one or more targets 162 based on recommendations from the proactive workload management engine 102. Adjusting a target 162 can lead to cost savings if the resource allocations align with the adjusted target 162 while still meeting the performance requirements of a workload. For example, the proactive workload management engine 102 might determine that a particular user's workloads are consistently consuming more or fewer resources than originally allocated using the machine learning model 124. In this case, the proactive workload management engine 102 (via the workload management user interface 150) can recommend increasing or decreasing one or more targets 162, thus allocating more or fewer resources to the user's workloads.Another example is that the proactive workload management engine 102 can detect, based on workload performance metrics, that workloads are not meeting performance targets. In such cases, the proactive workload management engine 102 (via the workload management user interface 150) can recommend increasing one or more targets 162 so that more resources can be allocated to achieve the performance targets.

[0032] Fig. Figure 2 is a flowchart of a process 200 of the proactive workload management engine 102 according to some examples. Fig. Figure 2 shows one sequence of tasks. In other examples, the tasks may be performed in a different order, some tasks may be omitted, and others may be added.

[0033] The proactive workload management engine 102 receives (at 202) the user profiles 120, the group information 122, the metrics 114 collected by the monitoring system 116, and the targets 162.

[0034] The proactive workload management engine 102 can (at 204) assign user profiles to the respective groups defined by the group information 122. A group comprises a collection of user profiles that are similar to one another. The group to which a particular user profile belongs provides an indication of the user's type. For example, a first group corresponds to power users who initiate workloads with high resource consumption. A second group corresponds to regular users who initiate workloads with average or typical resource consumption. A third group corresponds to occasional users who only rarely initiate workloads on the compute cluster 108. Although examples of groups are given above, other examples may include other types of groups that denote other types of users. The assignment of user profiles to groups is discussed further below.

[0035] The proactive workload management engine 102 receives (at 206) a workload request (e.g., 110 in Fig. 1) by User A to initiate a workload in Compute Cluster 108. User A is associated with a user profile 120 (referred to as "User A's Profile"), which may (at 204) have been assigned to a specific group. If it is not already assigned to a group, the proactive workload management engine 102 can assign User A's Profile to a selected group of the groups represented by the group information 122.

[0036] The proactive workload management engine 102 determines (at 208) a user type for user A based on the group to which user A's profile is assigned. Based on various inputs, including the determined user type of user A, the metrics 114, and the goals 162, the machine learning model 124 of the proactive workload management engine 102 can generate an initial resource allocation for the workload (at 210). For each group, the machine learning model 124 can identify typical resource usage patterns and performance levels and base the initial resource allocation on such typical resource usage patterns and performance levels.

[0037] The resources allocated during the initial resource allocation can include any or a combination of the following: a number of containers (from the containers in physical compute nodes 106A to 106B) to be used for the workload (or a number of pods to be used), the physical compute nodes 106A to 106B on which the containers will run, types of physical resources (e.g., GPU versus CPU, higher-speed CPU versus lower-speed CPU, etc.) to be used for running the workload, or other types of resources.

[0038] In addition to the inputs mentioned above, the machine learning model 124 can also consider other inputs, including any or a combination of the time of the requested workload, the number of currently running or requested workloads, the geographic region where the workload is to be executed, or other information. For example, if the workload is to be executed during peak usage times (e.g., during a company's business hours) in a specific geographic region, this would affect resource allocation for the workload, as the machine learning model 124 must consider competing resource requests from other workloads.

[0039] When creating resource allocations, the machine learning model 124 can predict or forecast the upcoming resource requirements of workloads and proactively trigger scaling measures to prevent bottlenecks before they impact performance. The machine learning model 124 learns continuously and is able to dynamically refine its logic based on evolving patterns. Based on refinements of the machine learning model 124, the workload performance, and the prevailing conditions of the compute cluster 108, the machine learning model 124 can adjust the resource allocation for the workload (at 212). For example, the machine learning model 124 can decrease or increase the number of containers (or pods) allocated to the workload, switch from using CPUs to using GPUs (or vice versa), change a memory allocation, and so on.

[0040] The proactive workload management engine 102 can implement damping to prevent rapid adjustments to resource allocations. For example, damping can result in a gradual increase and / or decrease in resource allocations to avoid over- or under-provisioning of resources for a workload.

[0041] Resource allocation adjustments can also be based on monitored user A behavior. User A might be expected to request workloads of one or more specific workload types, such as workloads related to AI system development or scientific research. The group to which User A is assigned might indicate that users belonging to that group are expected to submit workloads of one or more specific workload types. If the machine learning model 124 determines that the workloads requested by User A belong to a second type, different from the one or more specific workload types, the machine learning model 124 can take corrective action, for example, by reducing the resource allocation for the workloads requested by User A.

[0042] More generally, if the machine learning model 124 detects (at 212) that a user A's behavior deviates from expected behavior, the machine learning model 124 can adjust the resource allocation to the user A's workload (at 210).

[0043] Other examples of workloads that may be requested by various users include processing and analyzing streaming data, predictive data analytics to generate recommendations, diagnostic workloads using machine learning techniques, generative AI workloads such as large language model (LLM) workloads (e.g., workloads where queries are submitted to chatbots that generate responses to the queries), data backup workloads, or other types of workloads. Some workloads may perform repetitive mathematical calculations, such as AI or machine learning. In this case, accelerators (e.g., 132A, 132B in Fig. 1) are selected for running these workloads to improve performance. Other workloads may involve running large programs, which depend on the selection of CPUs (e.g., 134A, 134B in Fig. 1) can benefit from the execution of such workloads. Different workloads can be requested by different types of users, e.g., individual users (e.g., data scientists, data analysts, system administrators, etc.), users involved in automated tasks (e.g., in a factory), product engineers, finance staff, executives, and so on.

[0044] The following is an example of how a user profile is associated with a group of user profiles. It assumes there are N (N ≥ 2) groups of user profiles that can be defined by an administrator or other entity. A user profile comprises a collection (e.g., a vector) of attributes (a multidimensional data point), where the attributes (dimensions) can represent resource usage patterns and performance levels related to a user's workloads. For example, the vector of attributes that makes up the user profile can include any one or a combination of the following: an attribute representing CPU usage, an attribute representing GPU usage, an attribute representing memory usage, an attribute representing I / O usage, attributes representing performance metrics, or other attributes.In further examples, the vector of attributes that make up the user profile may also contain one or more pieces of information relating to a role of the user (e.g., which department of an organization the user belongs to, whether the user is a guest or an employee or another role), one or more allowed types of resources that the user is allowed to use, or user authorization information (e.g., specifying a user's authorization or security level).

[0045] The proactive workload management engine 102 can determine which of the N groups a user profile should be assigned to based on similarities between the user profile and the corresponding N groups. These similarities can be represented by distances in the vector space between the user profile and the corresponding N groups. Each group of profiles has a center point in the vector space, which is calculated based on the user profiles represented by that group.

[0046] A maximum distance D can be achieved. eps can be defined. For a given user profile, the proactive workload management engine 102 calculates a distance (in vector space) of the given user profile to the center corresponding to each of the N groups. If the distance of the given user profile to the center of a particular group of user profiles is less than or equal to the maximum distance D epsIf this is the case, the given user profile will be assigned to the specific group of user profiles.

[0047] If the given user profile is outside the maximum distance D epsIf a given user profile is an outlier in all N groups, the proactive workload management engine 102 can either (1) create a new group of user profiles if a sufficient number of outliers have been detected by the proactive workload management engine 102, or (2) assign the given user profile to the nearest group of user profiles. If option (2) is chosen, the proactive workload management engine 102 can recalculate the center of the group of user profiles to which the given user profile is assigned. For example, if the given user profile is assigned to group X, which contains a set of existing user profiles, then the recalculation of the center of group X is based on the set of existing user profiles plus the newly assigned given user profile.

[0048] As mentioned above, the assignment of a user profile to a group of user profiles determines a type of user associated with that profile, which the machine learning model 124 uses to create an initial resource allocation for the user's workload. In some cases, the group assignment information 160 displayed in the workload management user interface 150 can provide information about a group to which a user is assigned, as well as the distance of the user's profile from different groups, allowing an administrator to understand the user's proximity to the groups.

[0049] The use of the Proactive Workload Management Engine 102 enables the automated allocation of resources to workloads that meet workload performance goals while simultaneously increasing efficiency and reducing costs. The Proactive Workload Management Engine 102 can detect deviations in user behavior from expected behavior and adjust resource allocation to the user's workload accordingly. The Proactive Workload Management Engine 102 can manage a large number of users and automatically assign them to appropriate groups, which can then be used to determine resource allocations. Targets (thresholds) can be considered by the Proactive Workload Management Engine 102 when creating scaling measures.The targets can also be dynamically adjusted to changing conditions to improve the resource allocations provided by the proactive workload management engine 102.

[0050] Fig. Figure 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 that stores machine-readable instructions which, when executed, cause a workload management system to perform various tasks.

[0051] The machine-readable instructions contain 302 instructions for receiving workload requests, in order to receive a request from a requester to execute an initial workload in a virtual computing environment. The requester can be a user or another type of entity, such as a program or a machine. The virtual computing environment can include, for example, containers or VMs.

[0052] The machine-readable instructions contain instructions for determining the requester type (304) to identify a requester type, where the identified type is one from a variety of different requester types. The determination of the requester type can be based on the assignment of a requester profile to a group of requirement profiles.

[0053] The machine-readable instructions contain instructions for receiving metrics 306, in order to receive metrics relating to resource usage in the virtual data processing environment. The metrics can be received, for example, from the monitoring system 116. Fig. 1 will be received.

[0054] The machine-readable instructions contain instructions for determining the initial resource allocation (308) to determine a resource allocation for the first workload using a machine learning model, based on the specified requester type and metrics. The resource allocation may include a set of virtual compute units to be used for the first workload, which physical compute nodes the virtual compute units should execute, what types of physical resources to use for executing the first workload, or other types of resources.

[0055] The machine-readable instructions contain instructions for adjusting resource allocation 310 to adjust the resource allocation for the first workload using the machine learning model based on further collected metrics relating to resource usage by the first workload and on the basis of captured requester behavior while the first workload is running in the virtual computing environment.

[0056] It should be noted that other workloads (e.g., subsequent or previous workloads) of the requester or other requesters can be handled in a similar manner. Different machine learning models can be used for other requesters.

[0057] In some examples, the machine-readable instructions can determine whether the detected behavior of the requester indicates that the requester has a workload that differs from the expected workload of the requester.

[0058] In some examples, the machine-readable instructions can modify the resource allocation for the first workload if it is detected that the requester is deploying workloads that differ from the expected workloads. The change in resource allocation can involve modifying the resource allocation itself or denying or blocking further use of resources.

[0059] In some examples, the machine learning model can adjust the resource allocation to the first workload by sending information to a workload scheduler specifying a resource allocation that the scheduler uses when allocating resources to the first workload. An example of a workload scheduler is Scheduler 128. Fig. 1.

[0060] In some examples, the resource allocation for the first workload includes the allocation of virtual computing units in the virtual computing environment to execute the first workload.

[0061] In some examples, the allocation of resources to the first workload involves a selection of physical compute nodes of a computer system on which the virtual compute units will run.

[0062] In some examples, the allocation of resources to the first workload involves selecting one resource type from a variety of resource types, where the selected resource type specifies a type of physical resource for use by the first workload.

[0063] In some examples, the machine learning model can also determine the resource allocation for the first workload based on one or more of the following attributes: a time at which the first workload is to be executed, a set of workloads running in the virtual computing environment, a geographic region in which the first workload is to be executed, or a historical usage of resources by workloads.

[0064] In some examples, the machine learning model can predict an upcoming resource demand from workloads in the virtual computing environment and further adjust the resource allocation for the first workload based on the predicted upcoming resource demand.

[0065] In some examples, the machine learning model can further adjust resource allocation for the initial workload based on a target for a metric of metrics. The target can be one of the targets 162 from Fig. 1. Act.

[0066] In some examples, the machine-readable instructions can dynamically adjust the target for the metric based on detected requester behavior.

[0067] In some examples, the machine-readable instructions can determine the type of requester based on a requester profile, where the profile contains attributes that represent a resource usage pattern and performance levels of the requester.

[0068] In some examples, the profile also contains one or more pieces of information relating to a role of the requester, one or more permissible types of resources for the requester, and requester approval information.

[0069] In some examples, the machine-readable instructions can contain representations of groups of profiles (e.g., part of the group information 122 of Fig. 1) and determine the type of requester based on the assignment of the requester's profile to a selected group of profiles from the groups of profiles.

[0070] In some examples, the assignment of the requester's profile to the selected group of profiles is based on the distances of the requester's profile to the groups of profiles.

[0071] In some examples, the machine-readable instructions can generate a visualization of resource usage metrics by the first workload, with the visualization further including information about an upcoming adjustment of the resource allocation for the first workload.

[0072] Fig. Figure 4 is a block diagram of a System 400 according to some examples. The System 400 can be implemented with one or more computers.

[0073] The System 400 includes one or more hardware processors (402). A hardware processor can be a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry.

[0074] The System 400 also includes a storage medium 404 on which machine-readable instructions are stored. These instructions can be executed on the hardware processor 402 to perform various tasks. The machine-readable instructions on the storage medium 404 include instructions 406 for receiving requests, enabling the system to receive a request from a requester to execute a workload in a virtual computing environment.

[0075] The machine-readable instructions in storage medium 404 contain instructions for determining the requester type 408, in order to determine a requester type based on a relationship of a requester profile to groups of profiles, where the determined type is one from a multitude of different requester types. The machine-readable instructions can associate the profile with a group of profiles based on determining a distance of the profile to the group of profiles in a vector space.

[0076] The machine-readable instructions in storage medium 404 contain instructions for receiving metrics 410 to receive metrics relating to resource usage in the virtual computer environment.

[0077] The machine-readable instructions in storage medium 404 contain instructions for adapting the resource allocation 412 to determine, using a machine learning model, a resource allocation for the workload based on the specified type of requester and metrics, wherein the resource allocation includes a set of virtual computing units to be used to perform the workload and a type of physical resource to be used.

[0078] Fig. Figure 5 is a flowchart of a Process 500, such as that used by the proactive workload management engine 102. Fig. 1. Process 500 involves receiving (at 502) a request from a requester to execute a workload in a virtual computing environment.

[0079] Procedure 500 involves determining (in 504) the assignment of a requester's profile to a selected group from a multitude of groups of requirement profiles. The assignment may include determining the distances between the profile and the respective groups within the multitude of requirement profile groups.

[0080] Process 500 involves receiving (at 506) metrics relating to resource utilization in the virtual computing environment from a monitoring system. These metrics can originate from sensors or be linked to operations performed by a computing cluster (e.g., 108 in). Fig. 1) collect while workloads are distributed across virtual compute units on corresponding physical compute nodes (e.g., 106A and 106B in Fig. 1) be carried out.

[0081] Process 500 involves determining (at 508) an initial resource allocation for the workload using a machine learning model based on the specified type of requester and metrics, where the resource allocation includes a set of virtual compute units to be used to execute the workload, one or more physical compute nodes on which the set of virtual compute units will run, and a type of physical resource to be used.

[0082] Process 500 involves creating (at 510) a customized resource allocation for the workload using the machine learning model based on further collected metrics relating to resource utilization by the workload and on the basis of recognized requester behavior while the workload is running in the virtual computing environment.

[0083] As used here, an “engine” can refer to one or more hardware processing circuits, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry. Alternatively, an “engine” can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) that can be executed on the one or more hardware processing circuits.

[0084] Although Fig. 1. Where the proactive workload management engine 102, the user management engine 118, the monitoring system 116 and the scheduler 128 are shown as separate components, in other examples two or more of the aforementioned components can be integrated into one component.

[0085] A storage medium (e.g., 300 in Fig. 3 or Fig. 404 in Fig.4) may include any or a combination of the following: a semiconductor storage device such as dynamic or static random-access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; a magnetic disk such as a hard disk, floppy disk, and removable disk; another magnetic medium, including tape; an optical medium such as a compact disc (CD) or digital video disc (DVD); or another type of storage device. It should be noted that the instructions described above may be provided on a single computer- or machine-readable storage medium or, alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system, possibly with multiple nodes.Such a computer-readable or machine-readable storage medium or media are considered part of an article (or manufactured item). An article or manufactured item may refer to any single manufactured component or to multiple components. The storage medium or media may be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded for execution over a network.

[0086] In this disclosure, the use of the term "a," "an," or "the" includes the plural forms unless the context clearly indicates otherwise. Similarly, the terms "includes," "including," "comprises," "have," or "have," when used in this disclosure, specify the presence of the elements indicated but do not exclude the presence or addition of other elements.

[0087] The foregoing description includes numerous details to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and deviations from the details described above. It is intended that the accompanying claims cover such modifications and variations.

Claims

[1] A non-transitory, machine-readable storage medium that stores instructions which, when executed, cause a workload management system to: to receive a request from a requester to execute an initial workload in a virtual environment; to determine a type of requester, where the determined type is one from a variety of different requester types in a computer environment; To receive metrics relating to resource usage in the virtual computer environment; to determine, using a machine learning model, an allocation of resources to the initial workload based on the specific type of requester and metrics; and using the machine learning model, to adjust the resource allocation to the first workload based on further collected metrics relating to resource utilization by the first workload and based on determined requester behavior while the first workload is running in the virtual computing environment. [2] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: to determine whether the identified behavior of the requester indicates that the requester is involved in workloads that differ from the requester's expected workloads. [3] Non-transitory, machine-readable storage medium according to claim 2, wherein the instructions, upon execution, cause the workload management system to: Based on the finding that the requester is involved in workloads that differ from the expected workloads, the resource allocation for the first workload should be changed. [4] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: to adapt the resource allocation to the first workload using the machine learning model by sending information specifying a resource allocation that is used by a workload planner when providing the resource allocation to the first workload, from the machine learning model to the workload planner. [5] Non-transitory, machine-readable storage medium according to claim 1, wherein the resource allocation to the first workload comprises an allocation of virtual computing units in the virtual computer environment for the execution of the first workload. [6] Non-transitory, machine-readable storage medium according to claim 5, wherein the resource allocation to the first workload comprises a selection of physical compute nodes of a computer system on which the virtual compute units are executed. [7] Non-transitory, machine-readable storage medium according to claim 1, wherein the resource allocation to the first workload comprises selecting a resource type from a plurality of resource types, wherein the selected resource type specifies a type of physical resource for use by the first workload. [8] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: using the machine learning model to determine the resource allocation for the first workload based on one or more of the following attributes: a time at which the first workload is to be executed, a set of workloads running in the virtual computing environment, a geographic region in which the first workload is to be executed, or a historical usage of resources by workloads. [9] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: using the machine learning model to predict an upcoming resource requirement due to workloads in the virtual computing environment, to further adjust the resource allocation for the initial workload using the machine learning model, based on the predicted future resource requirements. [10] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: using the machine learning model to further adjust the resource allocation for the initial workload based on a target for one of the metrics. [11] Non-transitory, machine-readable storage medium according to claim 10, wherein the instructions, upon execution, cause the workload management system to: to dynamically adjust the target for the metric based on an identified behavior of the requester. [12] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: to determine the type of requester based on a requester profile, where the profile includes attributes that represent a resource usage pattern and performance levels of the requester. [13] Non-transitory, machine-readable storage medium according to claim 12, wherein the profile further comprises one or more pieces of information relating to a role of the requester, one or more permitted types of resources for the requester and authorization information of the requester. [14] Non-transitory, machine-readable storage medium according to claim 12, wherein the instructions, upon execution, cause the workload management system to: To obtain representations of profile groups; and to determine the type of requester based on an assignment of the requester's profile to a selected profile group from the profile groups. [15] Non-transitory, machine-readable storage medium according to claim 14, wherein the assignment of the requester's profile to the selected profile group is based on distances between the requester's profile and the profile groups. [16] Non-transitory, machine-readable storage medium according to claim 1, wherein the instructions, upon execution, cause the workload management system to: to generate a visualization of metrics of resource utilization by the workload, the visualization further including information about an upcoming adjustment of resource allocation for the workload. [17] A system that includes the following: a processor; and a non-transitory storage medium that contains instructions that can be executed on the processor to: to receive a request from a requester to execute a workload in a virtual computer environment; to determine a type of requester based on a relationship between a requester's profile and profile groups, where the determined type is one from a variety of different requester types; Receive metrics regarding resource usage in the virtual computer environment; and to determine a resource allocation for the workload using a machine learning model based on the specified type of requester and metrics, wherein the resource allocation includes a set of virtual computing units to be used to execute the workload and a type of physical resource to be used. [18] System according to claim 17, wherein the instructions are executable on the processor to: using the machine learning model to adjust resource allocation to the workload based on further collected metrics relating to resource utilization by the workload and based on determined requester behavior while the workload is running in the virtual computing environment. [19] A procedure that includes the following: Receiving a request from a requester to execute a workload in a virtual computing environment by a system that includes a hardware processor; Determining by the system an assignment of a requester profile to a selected group from a large number of groups of requester profiles; Receiving metrics relating to resource usage in the virtual computer environment by the system from a monitoring system; Determine, using a machine learning model running in the system, an initial resource allocation to the workload based on the specified type of requester and metrics, wherein the resource allocation includes a set of virtual computing units to be used to execute the workload, one or more physical computing nodes on which the set of virtual computing units is to run, and a type of physical resource to be used; and Using the machine learning model, generate a customized resource allocation for the workload based on additional collected metrics relating to resource utilization by the workload and on the basis of determined requester behavior while the workload is running in the virtual computing environment. [20] The method of claim 19, comprising: Generate, using the machine learning model, the adapted resource allocation for the workload based on a target for a metric of metrics; and Dynamically adjusting the target for the metric based on identified requester behavior.

Images