FIELD OF PRESENTLY DISCLOSED SUBJECT MATTER

The invention relates to data centers and in particular to a system and a method for minimizing costs associated with operation thereof.

BACKGROUND

Nowadays, a considerable portion of the operational costs of data centers are costs associated with power consumption. Power consumption depends, inter alia, on the loads on various components of the data center (components such as servers including CPUs, memories, etc.). As the loads on such components increase, so does the power consumption of the data center. In addition, as the loads increase, more heat is generated by such components. Such heat, in turn, needs to be removed, as it can deteriorate the performance of the data center in general and of its components in particular. In order to remove such heat, utilization of various cooling means (such as air conditioning, etc.) is required. The higher the heat, the more cooling is required, and thus, power consumption increases (as a result of operating the cooling means at higher loads). There is thus a need in the art for a new method and system for minimizing costs associated with operation of data centers.

Prior art references considered to be relevant as background to the presently disclosed subject matter are listed below. Acknowledgement of the references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter.

U.S. Patent Publication No. 2003/0193777 (Friedrich et al), published on

October 16, 2003 discloses an energy management system for one or more computer data centers, including a plurality of racks containing electronic packages. The electronic packages may be one or a combination of components such as, processors, micro-controllers, high-speed video cards, memories, semi- conductor devices, computers and the like. The energy management system includes a system controller for distributing workloads among the electronic packages. The system controller is also configured to manipulate cooling systems within the one or more data centers. SUMMARY

In accordance with an aspect of the presently disclosed subject matter, there is provided a method for optimizing resource consumption parameters associated with operation of one or more interconnected datacenters, each having one or more datacenter components, the method comprising:

receiving a plurality of jobs, each job associated with a Service Level Specification

(SLS);

receiving resource consumption parameters associated with consumption of one or more resources by the datacenter components;

providing a prediction of dynamic loads on the datacenter components; and determining, based at least on the resource consumption parameters and the prediction of dynamic loads an execution plan including an execution location and an execution time for the jobs while meeting at least (i) the respective SLSs associated therewith, and (ii) optimized resource consumption parameters associated with operation of the datacenters for executing the jobs.

In accordance with an embodiment of the presently disclosed subject matter, there is further provided a method wherein the optimized resource consumption parameters associated with operation of the datacenters are based on resource consumption parameters associated with operation of the datacenters components.

In accordance with an embodiment of the presently disclosed subject matter, there is further provided a method wherein the datacenter components include at least one server.

In accordance with an embodiment of the presently disclosed subject matter, there is further provided a method wherein the datacenter components further include at least one cooling means. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the resource consumption parameters associated with operation of the datacenter components of the datacenters for executing the jobs include resource consumption parameters associated with operating at least one server and at least one cooling means. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the resource consumption parameters are at least one of time-dependent resource consumption parameters and load-dependent resource consumption parameters.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the resource consumption parameters are resource consumption costs.

In accordance with an embodiment of the presently disclosed subject matter, there is further provided a method wherein the cooling means include at least one air conditioner. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the resource consumption parameters are at least one of time-dependent resource consumption parameters and load-dependent resource consumption parameters. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the load-dependent resource consumption parameters are statistically estimated utilizing at least one general resource consumption meter and data on the varying loads on the datacenter components. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the SLS includes at least one of: execution timeframe constraints, cost constraints, location constraints, resource consumption constraints. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method, further comprising operating a scheduler configured to trigger execution of the jobs according to the determined execution plan. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the execution plan further includes execution requirements to be met by the datacenter components for executing the jobs and wherein the method further comprises causing, in response to triggering execution of the jobs, assignment of datacenter components to execute the jobs.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method further comprising re-determining an execution plan, based also on the current loads on the datacenter components, in case the causing failed.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a method wherein the execution plan further defines datacenter components to execute the jobs. In accordance with an aspect of the presently disclosed subject matter, there is yet further provided a system for optimizing resource consumption parameters associated with operation of one or more interconnected datacenters, each having one or more datacenter components, the system comprising at least one processing resource configured to:

receive a plurality of jobs, each job associated with a Service Level Specification

(SLS);

receive resource consumption parameters associated with consumption of one or more resources by the datacenter components;

provide a prediction of dynamic loads on the datacenter components; and determine, based at least on the resource consumption parameters and the prediction of dynamic loads an execution plan including an execution location and an execution time for the jobs while meeting at least (i) the respective SLSs associated therewith, and (ii) optimized resource consumption parameters associated with operation of the datacenters for executing the jobs.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the optimized resource consumption parameters associated with operation of the datacenters are based on resource consumption parameters associated with operation of the datacenters components. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the datacenter components include at least one server.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the datacenter components further include at least one cooling means. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the resource consumption parameters associated with operation of the datacenter components of the datacenters for executing the jobs include resource consumption parameters associated with operating at least one server and at least one cooling means.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the resource consumption parameters are at least one of time-dependent resource consumption parameters and load-dependent resource consumption parameters.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the resource consumption parameters are resource consumption costs. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the cooling means include at least one air conditioner.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the resource consumption parameters are at least one of time-dependent resource consumption parameters and load-dependent resource consumption parameters. In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the load-dependent resource consumption parameters are statistically estimated utilizing at least one general resource consumption meter and data on the varying loads on the datacenter components.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the SLS includes at least one of: execution timeframe constraints, cost constraints, location constraints, resource consumption constraints.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the processing resource is further configured to operate a scheduler configured to trigger execution of the jobs according to the determined execution plan.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the execution plan further includes execution requirements to be met by the datacenter components for executing the jobs and wherein the processing resource is further configured to cause, in response to triggering execution of the jobs, assignment of datacenter components to execute the jobs.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the processing resource is further configured to re-determine an execution plan, based also on the current loads on the datacenter components, in case the cause failed.

In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system wherein the execution plan further defines datacenter components to execute the jobs.

In accordance with an aspect of the presently disclosed subject matter, there is yet further provided a computer program comprising computer program code means for performing the following steps when the program is run on a computer: receiving a plurality of jobs, each job associated with a Service Level Specification

(SLS);

receiving resource consumption parameters associated with consumption of one or more resources by the datacenter components;

providing a prediction of dynamic loads on the datacenter components; and determining, based at least on the resource consumption parameters and the prediction of dynamic loads an execution plan including an execution location and an execution time for the jobs while meeting at least (i) the respective SLSs associated therewith, and (ii) optimized resource consumption parameters associated with operation of the datacenters for executing the jobs.

BRIEF DESCRIPTION OF FIGURES

In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, the subject matter will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which:

Figure 1 schematically illustrates an exemplary environment in which a system for optimizing resource consumption parameters associated with operating one or more interconnected data centers operates, according to an exemplary embodiment of the presently disclosed subject matter;

Figure 2 is a block diagram schematically illustrating a simplified, exemplary system for optimizing resource consumption parameters associated with operating one or more interconnected data centers, according to the presently disclosed subject matter;

Figure 3 is a flowchart illustrating a sequence of operations carried out for creating a new job, according to certain examples of the presently disclosed subject matter;

Figure 4 is a flowchart illustrating a sequence of operations carried out for optimizing a jobs execution plan, according to certain examples of the presently disclosed subject matter; and

Figure 5 is a flowchart illustrating a sequence of operations carried out for executing a job, according to certain examples of the presently disclosed subject matter.

DETAILED DESCRIPTION

In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations. Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "receiving", "providing", "determining", "operating", "executing", "causing" or the like, include action and/or processes of a computer that manipulate and/or transform data into other data, said data represented as physical quantities, e.g. such as electronic quantities, and/or said data representing the physical objects. The term "computer" should be expansively construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, a personal computer, a server, a computing system, a communication device, a processor (e.g. digital signal processor (DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), any other electronic computing device, and or any combination thereof.

The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a computer readable storage medium.

As used herein, the phrase "for example," "such as", "for instance" and variants thereof describe non-limiting embodiments of the presently disclosed subject matter. Reference in the specification to "one case", "some cases", "other cases" or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the presently disclosed subject matter. Thus the appearance of the phrase "one case", "some cases", "other cases" or variants thereof does not necessarily refer to the same embodiment(s).

It is appreciated that certain features of the presently disclosed subject matter, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

In embodiments of the presently disclosed subject matter, fewer, more and/or different stages than those shown in Figs. 3-5 may be executed. In embodiments of the presently disclosed subject matter one or more stages illustrated in Fig. 3-5 may be executed in a different order and/or one or more groups of stages may be executed simultaneously. Figs. 1-2 illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in Fig.2 can be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein. The modules in Figs. 2 may be centralized in one location or dispersed over more than one location. In other embodiments of the presently disclosed subject matter, the system may comprise fewer, more, and/or different modules than those shown in Figs. 2.

Bearing this in mind, attention is drawn to Figure 1, which schematically illustrates an exemplary environment in which a system for optimizing resource consumption parameters associated with operating one or more interconnected data centers operates, according to an exemplary embodiment of the presently disclosed subject matter.

According to some examples of the presently disclosed subject matter, the environment can include one or more datacenters (e.g. datacenter 110-a, 110-b, 110-c, etc.). The datacenters can be interconnected by a network 120 (e.g. a general-purpose network). In some cases, the Network can be a public Wide Area Network (WAN) such as the Internet, a private WAN, a dark fiber, etc.

In some cases, when the environment includes two or more datacenters, one or more of the datacenters can be located in different geographical locations, and in some cases in different time zones. Thus, for example, datacenter 110-a can be located in California, whereas datacenter 110-b can be located in Switzerland and datacenter 110-c can be located in India. It is to be noted that any datacenter can be located anywhere and the above are mere examples.

Data centers or components thereof (servers 130 and/or cooling means 140, and/or any other resource consuming element relating to the datacenter) consume various resources (e.g. electricity, etc.). Such resource consumption can be associated with various parameters such as costs, e.g. in terms of money. The resource consumption parameters (e.g. costs) can vary according to the location (e.g. electricity can be cheaper in the United States than in Switzerland, etc.). In addition, in some cases, resource consumption parameters can vary according to the time of day. For example, electricity costs (which is an exemplary resource consumption parameter) can be generally lower at nighttime (e.g. between 20:00-6:00) than during daytime (e.g. between 6:00-20:00). Thus, in some cases, at a certain point in time, there can be a difference in resource consumption parameters between various locations.

Each datacenter can comprise one or more servers 130 (e.g. any type of computer including, inter alia, one or more processing resources such as one or more processing units, one or more memory resources such as a memory, and one or more network interfaces). According to some examples of the presently disclosed subject matter, the servers 130 can be interconnected by any type of network, such as a general -purpose network, a Storage Area Network (SAN), a Local Area Network (LAN) or any other type of network known in the art.

In addition, each datacenter can further comprise one or more cooling means 140 such as air-conditioners, etc. In some cases, the cooling means 140 can be associated with one or more computers (e.g. one of the servers 130, or any other computer) configured to manage, monitor and control the cooling means 140 operation, including the loads on the cooling means 140. In some cases, such computers can also interconnect to the datacenter network (to which, for example, the servers 130 are also connected).

According to some examples of the presently disclosed subject matter, each datacenter can further comprise one or more general resource consumption meters 150 (hereinafter: "general meters"). The one or more general resource consumption meters 150 can be used for measuring consumption of various resources, such as electricity, by the datacenter's components (e.g. its various resource consuming elements such as the servers 130, the cooling means 140, etc.).

According to some examples of the presently disclosed subject matter, utilization of the measurements obtained by the general resource consumption meters 150 along with data on the varying loads on the datacenter components (e.g. the servers 130 and/or the cooling means 140, and/or any other resource consuming element relating to the datacenter) over a certain time period (e.g. an hour, a day, a month, or any other period) can enable estimation (e.g. statistical estimation) of specific consumption parameters (e.g. consumption rates, etc.) of various resources (e.g. electricity) as a function of the loads on specific datacenter components. For that purpose, various types of load related parameters (such as, for example, CPU cycles, temperature, disk temperature, storage bandwidth consumption, air-conditioning engine Rounds-Per-Minute, air-conditioning set temperature, etc.) of the datacenter components can also be measured, for example using known methods and techniques. It can be appreciated that the estimation will be more accurate as the estimator is fed with more samples (usually, over a longer time period).

In some cases, in addition or as an alternative to the general resource consumption meters 150, all or part of the datacenter components that consume resources can be associated with their own resource consumption meters 160. Such resource consumption meters 160 can be utilized for measuring and/or sampling such data center components relevant resource consumption parameters (e.g. its relevant electricity consumption parameters such as consumption rates, etc., or any other parameter).

According to some examples of the presently disclosed subject matter, utilization of the measurements obtained by the resource consumption meters 160, along with data on the varying loads on the datacenter components that are associated with the resource consumption meters 160, can also enable calculation of the resource consumption parameters (e.g. consumption rates, etc.) as a function of the loads on the datacenter components. It is to be noted that in some cases such calculation (utilizing measurements obtained by the resource consumption meters 160) can be more accurate than the calculation that is based on general resource consumption meters 150.

Having described the exemplary environment in which a system for optimizing resource consumption parameters associated with operating one or more interconnected data centers operates, attention is drawn to Figure 2, schematically illustrating a system for optimizing resource consumption parameters associated with operating one or more interconnected data centers, according to the presently disclosed subject matter.

According to some examples of the presently disclosed subject matter, system 200 can be implemented on one of the servers 130 or distributed between several servers 130. Such servers 130 can comprise one or more processing resources 210. The one or more processing resources 210 can be a processing unit, a microprocessor, a microcontroller or any other computing device or module, including multiple and/or parallel and/or distributed processing units, which are adapted to independently or cooperatively process data for controlling and managing relevant system 200 resources and for enabling operations related to system 200 resources.

Such servers 130 can further comprise one or more network interfaces 220 (e.g. a network interface card, or any other suitable device) for enabling communication between various components of system 200, including, inter alia other servers 130 and/or other resources connected to any one of the interconnected datacenters 110 (e.g. datacenter 110- a, datacenter 110-b, datacenter 110-c, etc.).

According to some examples of the presently disclosed subject matter, such servers 130 can be associated with a data repository 230, configured to store various data, including inter alia data of various jobs (e.g. a task or a series of tasks that can be executed in batch mode) to be executed (e.g. backup jobs, business intelligence jobs, summarizing large quantities of data such as monthly or yearly summaries, etc.). In addition, data repository 230 can be configured to store user-defined requirements defining a service level specification (SLS) specifying various requirements that the one or more of the jobs are required to meet. The SLS can include information such as, for example, execution timeframe constraints (e.g. a time frame for executing the job, a start- time limit, an end- time limit, maximal execution time limit, etc.), location constraints defining locations in which the job can and/or cannot be executed (e.g. in case the job is not allowed to execute in one or more datacenter or in case the job is required to execute on a specific location, etc.), resource consumption constraints (e.g. resource consumption limits), etc.

Data repository 230 can be further configured to store data relating to the interconnected datacenters 110 (e.g. datacenter 110-a, datacenter 110-b, datacenter 110-c, etc.), such as their locations, their time zones, resource consumption parameters relating to consumption of various resources (e.g. electricity) that they utilize (including, when relevant, time and/or date dependant resource consumption parameters), etc.

Data repository 230 can be still further configured to store data relating to the data centers servers 130, cooling means 140 and other components of the datacenters 110. Such data can include their characteristics, such as manufacturer, size, computing power, capacity, various resources consumption rates, including, when relevant, load dependant resources consumption rates, etc.

Data repository 230 can be still further configured to store data relating to the dynamic behavior of one or more of the interconnected datacenters 110, and/or of one or more of the datacenters 110 components (such as the servers 130, the cooling means 140, etc.). Such data relating to the dynamic behavior can include, inter alia, data of the loads of the interconnected datacenters 110, and/or of one or more of the datacenters 110 components (such as the servers 130, the cooling means 140, etc.). As indicated above, such data can be measured for example using known methods and techniques. Utilization of such data can enable statistical estimation of predictions of dynamic loads on one or more of the datacenters 110, and/or one or more components thereof (e.g. servers 130, cooling means 140, or any other component).

In some cases, data repository 230 can be further configured to enable retrieval, update and deletion of the data stored therein. It is to be noted that in some cases, data repository 230 can be located locally on one of the servers 130. In some cases, data repository 230 can be distributed on several servers of a certain datacenter or on more than one datacenter. In some cases, data repository 230 can be located in any other suitable location. In some cases, additionally or alternatively, data repository 230 can be shared between multiple servers 130.

According to some examples of the presently disclosed subject matter, system 200 can further comprise one or more of the following modules: job creation module 240, job execution module 250, scheduling optimization module 260, scheduling module 270 and loads prediction module 280.

According to some examples of the presently disclosed subject matter, job creation module 240 can be configured to receive new jobs for execution. In some cases, job creation module 240 can be further configured to receive user-defined requirements defining a service level specification (SLS) specifying various requirements that the job is required to meet. In some cases, job creation module 240 can be further configured to trigger an execution plan optimization process. A more detailed description of the job creation module 240 is further provided herein, inter alia with reference to Figure 3.

According to some examples of the presently disclosed subject matter, execution plan optimization module 260 can be configured to calculate an optimized execution plan for executing one or more jobs, as further detailed herein, inter alia with reference to Figure 4.

In some cases, the optimized execution plan can be calculated while utilizing prediction of dynamic loads that can be calculated by loads prediction module 280, utilizing the data of the dynamic behavior of one or more of the interconnected datacenters 110, and/or of one or more of the datacenters 110 components, as indicated above.

In some cases, scheduling module 270 can be configured to act as a scheduler triggering execution of jobs in accordance with the calculated optimized execution plan, as further detailed, inter alia with reference to Figure 4.

According to some examples of the presently disclosed subject matter, job execution module 250 can be configured to execute one or more jobs, as further detailed herein, inter alia with respect to Figure 5.

Turning to Figure 3, there is shown a flowchart illustrating a sequence of operations carried out for creating a new job, according to certain examples of the presently disclosed subject matter.

According to some examples of the presently disclosed subject matter, process 300 begins by system 200, e.g. while utilizing job creation module 240, receiving a new job for execution (block 310). Such a new job can be provided by a user of the system 200 (e.g. a system administrator, or any other user), for example by utilizing a user interface. In some cases, such a new job can be created by the system 200 automatically, without human intervention.

The received job can be associated with an SLS specifying various requirements that the job is required to meet. As indicated above, the SLS can include information such as, for example, a time frame for executing the job (e.g. a start-time limit, an end-time limit, maximal execution time limit, etc.), locations in which the job can be executed (e.g. in case the job is not allowed to execute in one or more datacenters), resource consumption limits, etc.

Following receipt of the job, job creation module 240 can be configured to update data repository 230 with data about the received job and the SLS associated therewith.

According to some examples of the presently disclosed subject matter, following receipt of a new job, job creation module 240 can be configured to trigger a process of job execution plan optimization (block 320).

It is to be noted, with reference to Fig. 3, that some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to the system elements that realize them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Attention is now drawn to Figure 4 in which a flowchart illustrating a sequence of operations carried out for optimizing a jobs execution plan, according to certain examples of the presently disclosed subject matter, is shown. System 200 can be configured to operate the execution plan optimization module 260 in order to perform an execution plan optimization process 400. The execution plan optimization module 260 can be configured to receive various input data (e.g. by retrieving it from data repository 230), including: a. Data indicative of the datacenters 110 and/or their components (e.g. servers 130, cooling means 140, etc.) along with data indicative of the time and/or load dependant resource consumption parameters (e.g. consumed amounts, costs, rates) associated with operating the datacenters 110 and/or their components (e.g. servers 130, cooling means 140, etc.) (block 410);

b. Data indicative of the various jobs that are to be performed along with the SLSs associated with such jobs (block 420); and

c. Data indicative of predictions of dynamic loads on one or more of the datacenters 110, and/or one or more components thereof (e.g. servers 130, cooling means 140, or any other component), as calculated by loads prediction module 280 (block 430).

According to some examples of the presently disclosed subject matter, the execution plan optimization module 260 can be further configured to operate an optimizer in order to determine an execution plan that defines the execution location (in terms of which data center is to execute the job) and the execution time of the jobs while minimizing the costs associated with execution of the jobs and meeting the SLSs associated therewith (block 440).

In some cases, the execution plan optimization module 260 can be still further configured to calculate execution requirements for the jobs. Such execution requirements can define specific criterions that the datacenter components (e.g. servers 130), that are expected to execute the jobs, are required to meet. Such data can be utilized by job execution module 250 when executing a job, as further detailed herein, inter alia with reference to Figure 5. In some cases, the determined execution plan can define a more specific execution location, such as specific servers 130 in a specific datacenter 110 on which the job is to be executed.

It is to be noted that in some cases, the execution plan optimization module 260 can be configured to operate the optimizer in order to search for the optimal solution out of a set of calculated valid solutions (e.g. a solution that minimizes the costs associated with operating the one or more interconnected data centers 110 while meeting the SLSs associated with the jobs). In other cases, the execution plan optimization module 260 can be configured to operate the optimizer in order to return a valid solution (out of one or more valid solutions) that meets, for example, a pre-defined costs threshold, and while meeting the SLSs associated with the jobs. Optionally, the optimizer uses one or more optimization techniques. Optionally, the optimization techniques used by the optimizer can include any one of, or any combination of, linear programming, simulated annealing, genetic algorithms, or any other suitable optimization technique known in the art. Optionally, the optimization technique can utilize heuristics and/or approximations. Optionally, optimization decisions can be taken based on partial and/or not up-to-date information.

Attention is drawn now to a simplified example. Assume that there are three jobs that need to be executed: Job A, Job B and Job C, and that the jobs need to be executed in an environment that comprises two data centers: Datacenter A that is located in New- York, United States (hereinafter: "NY"), and Datacenter B that is located in Bern, Switzerland (hereinafter: "BERN"). Let's further assume that according to the jobs, SLSs Job A is required to execute within 6 hours, Job B is required to execute within 12 hours and Job C is required to execute within 18 hours. We may still further assume that the execution time of each job is about 10 hours.

Assume that at the point in time where the execution plan optimization module 260 determines an execution plan, the electricity costs (which are an exemplary resource consumption parameter) in NY are 50% higher than the electricity costs in BERN, and that the electricity costs gap is expected to remain similar for the next 12 hours, after which the electricity costs in BERN become 20% higher than the electricity costs in NY.

As indicated above, in some cases, execution plan optimization module 260 can be configured to determine an execution plan that optimizes the resource consumption parameter, as, for example, it minimizes the electricity (or optimizes any other resource parameters or combination of resource parameters pertaining to one or more resources) costs associated with executing the jobs.

If execution plan optimization module 260 determines an execution plan based on the time dependant resource consumption costs (which are an exemplary resource consumption parameter) while disregarding the loads influence on the resource consumption rates (and, subsequently on the resource consumption costs associated with operating Datacenters A and B), and assuming that there are enough resources in Datacenter B to execute all of the jobs (Job A, Job B and Job C), scheduling optimization module 260 can determine that all jobs are to be executed immediately in Datacenter B.

However, it can be appreciated that such determination will cause the loads on Datacenter B and on its components (e.g. servers 130, cooling means 140, or any other component) to be higher than the loads that can be expected if the jobs are not executed simultaneously at the same location (Datacenter B). Such increase in loads can cause a non-linear increase in power consumption, thus making such an alternative not optimal, as, for example, high power consumption can cause higher resource consumption costs (which are an exemplary resource consumption parameter) associated with operating Datacenters A and B in comparison to the resource consumption costs associated with distributing the execution between Datacenter A and Datacenter B.

Alternatively, execution plan optimization module 260 can determine an execution plan according to which Job A and Job B are executed immediately in Datacenter B and Job C is executed in Datacenter A after the electricity costs in BERN become 20% higher than the electricity costs in NY. In some cases, such an alternative can result in optimized resource consumption parameters (e.g. lower costs) associated with operating Datacenters A and B, in comparison to the previous scenario.

It is to be noted that the many other possible scenarios exist, depending, inter alia, on the time and load dependant resource consumption parameters (e.g. costs) of the various datacenters 110. The examples above are mere non-limiting examples for illustrative purposes only.

It can be appreciated that execution plan optimization module 260 can perform the optimization while taking into account all of the input data while calculating an execution plan, thereby addressing all, or part of the issues disclosed in the example above, as well as additional and/or alternative issues.

Returning to Figure 4, following calculation of an execution plan, execution plan optimization module 260 can be configured to check if any of the jobs cannot be executed while meeting the SLS associated therewith (block 450). If there are such jobs, execution plan optimization module 260 can be configured to notify a user (e.g. a system administrator or another entity, including a non-human entity) about the reason and/or provide such user with a recommendation for corrective actions to be taken in order to allow calculation of an execution plan (block 460). Such a corrective action can include adding one or more datacenters in one or more location, or adding one or more components to one or more datacenters (e.g. datacenter 110-a, 110-b, 110-c, etc.), or relaxing one or more SLS constraints, thereby enabling successful calculation of an execution plan. Optionally, the action can include adding relevant plug-ins to one or more servers 130. It is to be noted that the recommendations disclosed herein are mere examples, and other recommendations can be additionally or alternatively issued to the user.

If there are no such jobs, or following a notification/recommendation to the user, execution plan optimization module 260 can be configured to trigger a scheduling module 270 configured to trigger execution of jobs that can be executed, in accordance with the calculated optimized execution plan (block 470).

It is to be noted, with reference to Fig. 4, that some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to the system elements that realize them, this is by no means binding, and the blocks can be performed by elements other than those described herein. Figure 5 is a flowchart illustrating a sequence of operations carried out for executing a job, according to certain examples of the presently disclosed subject matter. According to some examples of the presently disclosed subject matter, scheduling module 270 can be configured to trigger execution of jobs in accordance with the calculated optimized execution plan. Once scheduling module 270 triggers execution of a job, system 200 can be configured to operate the job execution module 250 in order to perform a job execution process 500. In some cases, the job execution module 250 can be configured to determine runtime execution parameters for execution of a job (block 510).

Such runtime execution parameters can define, for example, assigning datacenter components (e.g. servers 130) to execute the job (e.g. determining what datacenter components, such as servers 130, will participate in the job execution, etc.) and/or determining each datacenter component part in the job execution and/or determining the maximal permitted loads on the various datacenter components that are to participate in the job execution, etc. In some cases, the runtime execution parameters are required to meet the execution requirements calculated for the job. As indicated above, such execution requirements can define specific criteria that the datacenter components (e.g. servers 130), that are expected to execute the jobs, are required to meet (e.g. having a certain capability, having a certain hardware component, having a certain software component, having a certain network connection, etc.).

In some cases, job execution module 250 can be further configured to check if valid runtime execution parameters were found (block 520). If not, job execution module 250 can be configured to reschedule the job for later execution if possible and/or notify a user (e.g. a system administrator or another entity, including a non-human entity) about the failure and/or provide such user with a recommendation for corrective actions to be taken in order to allow execution of the job (block 550).

It is to be noted that when rescheduling the job for later execution, job execution module 250 can, in some cases, be configured to trigger execution plan optimization module 260 to recalculate an execution plan for executing the failed job. In some cases, execution plan optimization module 260 can be configured to take into account also the current dynamic behavior (including, data indicative of loads) and/or the historic dynamic behavior data (stored for example on data repository 230) of one or more of the interconnected datacenters 110, and/or of one or more of the datacenters 110 components (such as the servers 130, the cooling means 140, etc.) while recalculating an execution plan for executing the failed job (in addition, or as an alternative to the data indicative of the predictions of dynamic loads of block 430).

If there are valid runtime execution parameters, job execution module 250 can be configured to attempt executing the job. In some cases, the job can be executed while dynamically manipulating (e.g. tuning, etc.) local parameters for optimizing the resource consumption parameters, thereby minimizing the execution costs associated with execution of the job while meeting the SLS associated therewith, for example by throttling (e.g. adjusting the clock frequency, reducing the processing speed, etc.) (block 530).

In some cases, job execution module 250 can be further configured to check if the execution was successful (block 540). If so - the process ends (block 560). If not - job execution module 250 can be configured to reschedule the job for later execution if possible (as detailed above) and/or notify a user (e.g. a system administrator or another entity, including a non-human entity) about the failure and/or provide such user with a recommendation for corrective actions to be taken in order to allow execution of the job (block 550).

As indicated above, in some cases, the determined execution plan can define a more specific execution location, such as specific servers 130 in a specific datacenter 110 on which the job is to be executed. In such cases, there may not be a need in determining runtime execution parameters indicating what datacenter components (e.g. servers 130) are to participate in the job execution, etc.

It is to be noted, with reference to Fig. 5, that some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.