Patent Application
20110154353
“Cloud Computing” has become a very visible technology in recent years. Amazon, Google, and many other companies have established various types of clouds in order to provide users with a highly scalable computing infrastructure. These clouds, frequently implemented using very large collections of servers or “server farms,” service a variety of needs ranging from large scale data storage to execution of virtual machines. One issue faced by providers of a public cloud infrastructure, or by any operator of a large, shared computer infrastructure, is how to efficiently utilize and distribute the workload across the available system resources. Most computer systems will have peak load times, while at other times valuable resources may go unused. Examples of such resources include, but are not limited to:
CPU (e.g., FLOPS or MWIPS1, or as indicated in VMware tools, MHz)
Volatile memory (e.g., RAM)
Storage (e.g., hard-disk space)
Network bandwidth
Power consumption
Database utilization
Many large systems execute workload scheduler software to better utilize the available system resources. As computer systems have continued to provide increasingly larger processing capacities, however, the numbers of tasks scheduled for execution have also continued to increase. A large mainframe computer or server farm, for example, may have hundreds or even thousands of tasks scheduled for execution at any given point in time. With so many tasks to contend with and a finite set of resources, scheduling tasks such that all the operational constraints are met can be daunting. When such constraints cannot all be met, the workload scheduler software must choose which task requests to attempt to satisfy, deferring or even declining those task requests which cannot be met in the requested time frame. The ability of a workload scheduler to make appropriate choices among the many possible schedules depends upon the scheduler's access to relevant information about each task's scheduling requirements, including whether and how the task may be rescheduled. When resources become overcommitted, resource scheduling problems can be overshadowed by the related but different problem of optimally choosing, from among competing tasks, those task scheduling requests that will actually be fulfilled and those that will not.
Existing workload schedulers may thus not be able to adequately distribute the load at peak times of system resource utilization (wherein there may be conflicting user priorities) and troughs in utilization (wherein capacity may exceed demand). Further, existing methods of workload scheduling optimization tend to focus on the identification of processing bottlenecks and manual task ordering without taking into account which task schedules may provide greater overall value or utility. Thus, existing workload schedulers may also not adequately address situations where resources become overcommitted.
The present disclosure describes systems and methods that utilize user-provided resource and scheduling task metadata to automatically vary the pricing of tasks submitted to a computer system. The variations in price operate to create a demand-driven schedule optimization of the computer system's workload. The disclosed systems and methods determine an optimal scheduling of each task, as well as an estimated pricing of the computer time charged for executing each task. As users schedule jobs for execution, resources already allocated to scheduled tasks and measured performance data for the system are aggregated by a workload scheduler to produce a measure of the current and projected utilization of the system's resources over time. The aggregated information is used by the workload scheduler to vary the price charged to users that submit new tasks for execution. A calculated price is presented to a user, allowing the user to submit the job as originally scheduled or vary the scheduling options so as to lower the cost of executing the task. Such pricing variations are designed to discourage system users from scheduling tasks during periods of high projected utilization of the system and encourage the scheduling of tasks during periods of low projected utilization. Users will naturally schedule their work during times that will be the most cost-effective for them. The users thus produce a market/demand-driven scheduling optimization that distributes the demand for the limited shared resources of the computer system over time.
In at least some embodiments, the pricing variations are further designed to encourage users to allow a degree of flexibility in scheduling their tasks by permitting the workload scheduler to vary the scheduled start, execution and end times of their tasks as needed to better utilize the system's resources. In such embodiments, the system has added flexibility to keep prices down by leveling peak utilization spikes through the dynamic re-scheduling of workloads within their user-specified time-boundaries. Various analysis techniques may be applied to the reservation schedule so as to present the lowest (and hence, most competitive) possible price for every new workload scheduling request.
The present disclosure describes systems and methods that implement a demand-driven workload scheduling optimization of shared resources used to execute tasks submitted to a computer system. These methods further implement scheduling tasks designed to optimize prices offered for new workloads in a resource-constrained environment. This optimization results in the demand-optimized use of the resources of the computer system. The scheduled tasks may include, for example, any of a variety of software programs that execute individually, separately and/or in conjunction with each other, and may be submitted as executable images, as command language scripts and/or as job control images that control the execution of one or more software programs.
In the interest of clarity, not all features of an actual implementation are described in the present disclosure. It will of course be appreciated that in the development of any such actual implementation (as in any development project), numerous decisions must be made to achieve the developers' specific goals (e.g., compliance with system- and business-related constraints), and that these goals will vary from one implementation to another. It will further be appreciated that such development effort might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. Moreover, the language used in the present disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in this disclosure to “one embodiment” or to “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
Mainframe 110 shows an example of how each mainframe of
Continuing to refer to the example system of
Scheduler module 200 interacts with users of the system via a user interface presented at a user workstation (e.g., a graphical user interface via user stations 116 and 118) to accept new task requests from the user. Users provide scheduler module 200 with scheduling and resource requirements for their respective tasks, which scheduler module 200 combines with the scheduling and resource requirements of previously scheduled jobs and with current resource utilization data stored on non-volatile storage device 134 to determine a price for running a user's task. Tasks may be scheduled by the user for immediate execution or for execution starting at a later time. After calculating the price, scheduler module 200 presents the price to the user and can optionally present alternative scheduling and resource alternatives that may lower the cost to the user. The user may accept the price of the task as scheduled, reject the price without submitting the task for execution, or change the scheduling and resource requirements and submit the changes for a new price computation.
If the user accepts an offered price for a task, databases stored on non-volatile storage device 134 and used to track scheduled tasks are updated, and the user's task is submitted by scheduler module 200 for execution via one of job queues 136. After the task has executed, additional surcharges and/or discounts can be applied by scheduler module 200 to the user's final cost based upon actual measured resource utilization. By providing a dynamic pricing structure that is based upon current and projected resource utilization of a system, pricing can be used as an incentive to steer users of the system away from peak utilization times of the system and towards low utilization times. For example, pricing may be used to steer users away from executing tasks immediately and towards scheduling their tasks for delayed execution at a later time. A user's task may cost less if scheduled for delayed execution later in the evening (when resources are used less and cost less) rather than immediately in the middle of the work day (when utilization and prices are higher). Additional discounts may be offered to further encourage users to schedule their tasks well in advance (e.g., scheduling a task on Friday to execute over an upcoming weekend during late evening hours rather than scheduling a task for immediate execution first thing on Monday morning). Pricing may also be used to incentivize users to avoid fixed scheduling and resource requests, instead allowing the system to schedule their tasks within a window of time using varying ranges of resource (e.g., a larger time window that allows execution on a slower processor if a faster processor is not available). Pricing may further be used to encourage users to allow their tasks to be started, paused and resumed again one or more times within an overall time window larger than the total time required for the task. Such flexibility enables the system to shift lower priority tasks as needed to accommodate tasks with less flexible scheduling and resource requirements.
User portal module 202 interacts with the user to provide data to, and receive data from, a user operating a user station (e.g., via a graphical user interface presented at user station 118 of
If the user accepts the price (block 308), workload scheduler module 204 schedules and queues the task for execution on one of queues 136, updates task metadata 212 with data for the newly scheduled task, and updates resource allocations 210 to reflect the resources allocated to the task (block 310), completing method 300 (block 314). If the user rejects the price (block 308) and opts to modify the task scheduling and/or resources used (block 312), method 300 is repeated (blocks 302-308). If the user rejects the price (block 308) and opts to abort the task request altogether without modifying the request (block 312), method 300 completes (block 314).
As previously described, the pricing determined by pricing estimator module 206 is designed to discourage scheduling of tasks and corresponding resources during periods of high or peak use, and to encourage task/resource scheduling during periods of low usage. One example of how this may be achieved is to make the price of system resources inversely proportional to the amount of remaining resources. For example, in at least some embodiments, the combined memory and processor resources of a machine (e.g., the RAM and CPU of virtual machine 130a of
U=A/log(XTotal−XAllocated) (1)
wherein for XTotal not equal to XAllocated,
A is a price factor,
XTotal is the total available resource capacity,
XAllocated is the resource capacity already allocated, and
U is the resulting minimal lease unit price for the given resource usage.
If XTotal is equal to XAllocated, there is no need to calculate U, as the resource has been fully allocated and is thus unavailable and the request as scheduled would be rejected. This can occur if the user does not allow sufficient flexibility in task scheduling or resources required.
It should be noted that the single combined RAM/CPU resource of the above example was presented for simplicity. Those of ordinary skill in the art will recognize that a wide variety of computer system resources may be priced and allocated to tasks fractionally, individually or in combination. Examples of such resources include, but are not limited to, processing bandwidth, volatile memory (e.g., RAM), non-volatile memory (e.g., disk space), network bandwidth, database utilization, instances of a software application and ports used to access a software application. All such pricing and allocation of resources, fractions of resources and combinations of resources are contemplated by the present disclosure.
In at least some embodiments, a user's flexibility in scheduling may be factored into equation (1) to encourage such flexibility. For example, a user may be presented with two options:
For small numbers of tasks, this optimization may be achieved using exhaustive enumeration of all possible schedules, but for larger numbers of tasks more sophisticated statistical methods may be used (e.g., a Monte Carlo method such as simulated annealing). Other examples of methods suitable for determining an optimal task schedule may include any of a number of deterministic methods (e.g., interval optimization and branch and bound methods), stochastic methods (e.g., basin hopping, stochastic tunneling, parallel tempering and continuation methods) and metaheuristic methods (evolutionary algorithms, swarm-based optimizations, memetic algorithms, reactive search optimizations, differential evolution methods and graduated optimizations). Various other optimization methods may become apparent to those of ordinary skill in the art, and all such methods are contemplated by the present disclosure.
Referring now to
Programmable control device 510 may be included in a computer system and be programmed to perform methods in accordance with this disclosure (e.g., method 300 illustrated in
In addition, acts in accordance with the methods of
Storage devices, sometimes called “memory medium,” “computer-usable medium” or “computer-readable storage medium,” are suitable for tangibly embodying program instructions and may include, but are not limited to: magnetic disks (fixed, floppy, and removable) and tape; optical media such as CD-ROMs and digital video disks (“DVDs”); and semiconductor memory devices such as Electrically Programmable Read-Only Memory (“EPROM”), Electrically Erasable Programmable Read-Only Memory (“EEPROM”), Programmable Gate Arrays and flash devices.
Various embodiments further include receiving or storing instructions and/or data implemented in accordance with the foregoing description upon a carrier medium. Suitable carrier media include a memory medium as described above, as well as signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network 102 and/or a wireless link.
As evident from the examples presented, at least some of the functionality described herein (e.g., scheduler module 200 of
The above discussion is meant to illustrate the principles of at least some example embodiments of the claimed subject matter. Various features are occasionally grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments of the claimed subject matter require more features than are expressly recited in each claim.
Various changes in the details of the illustrated operational methods are possible without departing from the scope of the claims that follow. For instance, illustrative flow chart steps or process steps of
Other variations and modifications will become apparent to those of ordinary skill in the art once the above disclosure is fully appreciated. For example, although events and metric data are described as originating, at least in part, from computers such as PCs, mainframes and workstations, other devices or components may also source metric data and/or trigger events. Examples of such devices may include network switches, network routers, disk drives, raid controllers, printers, modems, uninterruptable power supplies and datacenter environmental sensing and control devices. Also, although a mainframe computer system was described in the examples presented, the systems and methods disclosed are not limited to mainframe computer systems. Many other types of computer systems and topologies may be equally suitable for implementing the systems, such as any of a variety of distributed computer systems interconnected by one or more communication networks (e.g., Amazon's EC2 cloud topology). All such computer systems and topologies are contemplated by the present disclosure. It is intended that the following claims be interpreted to include all such variations and modifications.
The present application claims priority to U.S. Provisional Patent Application No. 61/289,359 filed on Dec. 22, 2009 and entitled “System and Method for Market-Driven Workload Scheduling Optimization on Shared Computing Resources,” which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61289359 | Dec 2009 | US |
