Abstract:
A method comprises recognizing a need for an additional resource to be made available to a target computer workload. A determination is made whether said target workload is licensed for additional resource. If the determination is positive, the resource is transferred to the target workload. If the determination is negative, a license is transferred from a source workload, and then the resource is transferred to the target workload.

Description:
BACKGROUND OF THE INVENTION 
     Herein, related art may be discussed to put the invention in context. Related art labeled “prior art” is admitted prior art; related art not labeled “prior art” is not admitted prior art. 
     Servers, e.g., web servers, database servers, are computers that provide services to other computers. License fees for server software are often based on the hardware resources available to run the software. Thus, the fees for running software restricted to an 8-CPU partition of a 32-CPU server can be much less than software permitted to run on the full system. 
     Virtualization and other technologies provide for software-controlled reallocation of hardware resources to partitions. This means that restricting software to a partition does not restrict it to a fixed amount of resources. Accordingly, software licenses may have to provide for the maximum number of resources that can be allocated to a partition, which can lead to wasteful over-provisioning on the licensee&#39;s part. As is apparent from the detailed description below with reference to the following drawings, the present invention addresses the problem of license over-provisioning in servers that allow software-controlled reallocation of resources to partitions. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
       The following drawing is of an embodiment of the invention and not of the invention itself. 
         FIG. 1  is a schematic diagram of a server and associated method in accordance with an embodiment of the invention. 
         FIG. 2  is a more detailed flow chart of the method of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION 
     The present invention provides a server workload management function that iteratively allocates software license rights along with hardware resources to workloads in a manner analogous to the allocation of hardware resources to workloads. Within each iteration, a resource (hardware or software license right or a combination) is allocated to the highest priority workload as defined by the policies and taking into account resources assigned during previous iterations. The end result is that both hardware resources and software license rights are distributed optimally as defined by management policies. With such an enforcement mechanism in place, a licensor can securely offer more limited and, thus, more economical, licenses to customers, reducing the need for a customer to over-provision licenses. 
     A server AP 1  includes partitions P 1 -P 3 . Each partition has processor, memory, and input/output resources assigned to it. As shown in  FIG. 1 , processors (also known as “central processing units” (CPUs) C 01 -C 04  are assigned to partition P 1 , CPUs C 05 -C 08  are assigned to partition P 2 , and CPUs C 09 -C 12  are assigned to partition P 3 . 
     Partitions P 1 -P 3  are running respective workloads A 1 , A 2 , and B 1 . Each workload can include an operating system and one or more applications. Workloads A 1  and A 2  are two instances of the same application, e.g., the same database application, while workload B 1  is an instance of another application. For example, the database application of workload A 1  can be a database for one department of a company, while the database application of workload A 2  can be running a second database for a different department of the company. Workload B 1  can be a web server application. 
     The workload management function WMF is implemented by workload managers WL 1 -WL 3 , which are software agents running respectively in partitions P 1 -P 3 . Each workload manager WL 1 -WL 3  has access to a respective copy of workload management policies MP 1 -MP 3  and a respective copy of license data LD 1 -LD 3 . Collectively, workload managers WL 1 -WL 3  provide for automated reallocation of resources. The reallocations are made based on policies MP 1 -MP 3  and license data LD 1 -LD 3 . 
     More specifically, workload managers WL 1 -WL 3  collectively implement a method ME 1  flow-charted in  FIG. 1  and shown tangibly embodied in computer readable storage media  15 . At method segment M 1 , workload manager WL 1  recognizes a need for more hardware resources to be allocated to its respective workload A 1  running in partition P 1 . More specifically, workload manager WL 1  has detected that 90% of the available CPU resources for partition P 1  are being utilized. Policies MP 1  indicated that CPU resources should be added to a partition at this level of utilization to provide adequate headroom for a potential spike in demand. As indicated in the alternative representation of method ME 1  in  FIG. 2 , recognition of a need to reallocation can involve 1) a request from a workload manager for more resources, e.g., because of high utilization; 2) an offer by a workload manager to relinquish idle resources; 3) a scheduled reallocation (e.g., day versus night allocations); or 4) user initiated reallocations, as shown at method segment M 1 A. 
     Whether in response to a resource utilization problem or a scheduled event, a new allocation of resources to workloads is determined at method segment M 2 . Optimal resource allocation can be a complex problem. Method segment M 2  breaks the problem down into iterations in which a single resource or a bundle of resources is assigned to a workload based on priorities determined by management policies MP 1 -MP 3 . Policy considerations can include the importance of the workload, the expected utilization of the workload, and the resources already allocated to the workload in previous iterations. 
     As indicated in  FIG. 2 , planning a reallocation can involve assigning, at method segment M 2 A, a first minimum granularity resource unit to the highest priority workload as determined by management policies. Then, dependent resource allocations are made at method segment M 2 B. For example, if a partition runs two workloads, e.g., two virtual machines running on an OS, then a fraction of a CPU might be assigned to one of the workloads. However, the partition might have a minimum granularity of a whole CPU, so method segment M 2 A would involve assigning a fraction of a CPU to the workload and method segment M 2 B would involve assigning a whole CPU to the partition (if the resources previously assigned to that partition did not provide for the fraction). 
     Once the dependencies are assigned at method segment M 2 B, method ME 1  returns to method segment M 2 A to allocate the next resource unit. Each time a resource is allocated at method segment M 2 A, its dependencies are assigned at method segment M 2 B unless all dependent resource assignments have already been made. When all resources have been assigned, method ME 1  continues with method segment M 3 A. 
     In the case where the resource is a software license right, it can only be assigned to qualified workloads, e.g., one of perhaps plural instances of an operating system or application to which the right applies. For example, license data LD 1 -LD 3  may indicate that a database program is licensed for up to four instances and a total of eight CPUs. Server AP 1  can have two instances of the database, with one having a higher priority than the other. The first license right would be assigned to the higher priority instance. A later license right might be assigned to the same instance or to the lower priority instance (e.g., because the “needs” of the originally higher priority instance had been relatively satisfied). Hardware resources could then be assigned to workloads as license rights permit. 
     At method segment M 3 , the new allocation is implemented. Generally, reallocation can involve determining a license-compatible least-disruptive series of steps to implement the new allocation and then implementation of those steps. Method segment M 3  of  FIG. 1  can be broken down into method segments M 3 A-M 3 D as shown in  FIG. 2  to ensure that license terms are complied with during the actual reallocation. At method segment M 3 A, source hardware is deactivated. At method segment M 3 B, license rights are removed from source workloads. At method segment M 3 C, license rights are added to the target workload. At method segment M 3 D, the inactivated hardware resources are transferred to the target workload and reactivated. Of course, if the new allocation is the same as the old, no changes are required. 
     Once the reallocation is implemented, method ME 1  provides for enforcing licensing rights at method segment M 4 . If no workload has been assigned unlicensed resources, this enforcement is trivial. However there may be cases where a workload manager commands an operating system to limit access to hardware resources, as indicated at method segment  4 A in  FIG. 2 . For example, the operating system might be licensed to use five cores, but the cores come four to a processor, the lowest unit that can be assigned to a partition. In that case, two processors and eight cores may be assigned to a partition, while the workload manager limits the operating system to using five cores. 
     In the illustrated case, the licenses for the database applications running in partitions P 1  and P 2  each permit four CPUs, but can be pooled so that licensing restrictions are met as long as the total number of CPUs for both partitions is no more than eight. In that case, “one CPU” of the license for partition P 2  is transferred to partition P 1  at method segment M 4 . Finally, one CPU, e.g., CPU C 05  is transferred from partition P 2  to partition P 1 , relieving the high utilization level of P 1 . (This is the transfer indicated by the arrow from CPU C 05  to partition P 1  in  FIG. 1 .) Moving a CPU to a different partition can involve several steps, including allowing threads running on it to terminate, preventing new threads from starting on that CPU, and then transferring the CPU. 
     It should be noted that the policies can specify conditions under which additional hardware and software licenses can be purchased. For example, a server may have reserved processors that can be “instantly activated” under a pre-arranged fee provision. Likewise, a software license might have provisions for instant expansion under a pre-arranged fee provision. Thus, when conditions merit, the amount of resources and license rights to be allocated can be varied by the workload management function. 
     Herein, “software agents” are computer programs, and a computer “workload” is a program or set of programs. Herein, a “computer program” or more simply a “program” is an ordered set of instructions tangibly embodied in computer-readable storage media and interpretable and executable by a central processing unit. Herein, “program” does not encompass purely abstract ideas, natural phenomena, or laws of nature. A “program set” is a set of one or more programs. All programs described herein effect changes in state in computer-readable memory. 
     While the invention is illustrated for a system with three hard partitions, it is applicable to systems with different numbers of partitions, and for systems with virtual instead of hard partitions. In fact, the invention can be applied to un-partitioned systems provided a workload manager controls the allocations of resources to workloads. The policies can involve utilization levels, usage predictions, and business priorities, among other considerations. The policies can seek to evenly distribute workloads or concentrate them so that some resources can be powered down. The license terms can vary and provide various means for augmenting a license to permit a reallocation, including automatic payment for an additional resource. The resources can be CPUs, memory, I/O devices, and various combinations and types of those classes of computer components. Now that multi-core processors are becoming prevalent, licensing and resource transfers can be on a per-core rather than a per-CPU basis. Fractional resource transfers can also be implemented, e.g., by time-sharing a resource such as a CPU or core. These and other variations upon and modifications to the illustrated embodiment are provided for by the present invention, the scope of which is defined by the following claims.