KR20110128825A - Energy-aware server management - Google Patents

Abstract

The described implementation relates to energy-aware server management. One implementation involves an adaptive control unit configured to maintain a predetermined level of response time for a server farm while managing energy usage in the server farm by transitioning individual servers between active and inactive states.

Description

Energy-Aware Server Management {ENERGY-AWARE SERVER MANAGEMENT}

The described embodiment relates to energy-aware server management. More specifically, this patent application relates to tools for providing energy-awareness and dispatching for request / response services.

Data centers often include a large number of computers (ie servers). Many of these servers are temporarily underutilized or even unused, but are kept to handle surges in requests reaching the data center. For example, consider a Christmas rush on an online shopping site or a late afternoon congestion on a commuter traffic information site. Servers currently used in data centers consume large amounts of energy when they are idle (for some servers, idle is 70% of full energy use). Turning off these servers can save energy, but can also adversely affect the response time of Web services if customer surges are reached and not enough servers are turned on. The concept can manage the data center in a manner that considers the energy use of the data center while satisfying the requested service response time.

The described embodiment relates to energy-aware server management. More specifically, this patent application relates to tools for providing energy-awareness and dispatching for request / response services.

In one embodiment, an adaptive control unit configured to manage energy usage in a server farm by transitioning individual servers between active and inactive states while maintaining response times for the server farm at a predefined level. For example, the pre-assessment level may be defined in a service level agreement (SLA).

In another implementation, the tool predicts future workload for a set of computers. Individual computers have at least two energy states, such as on / active, sleep and off. The tool creates energy-aware server management policies for predicted future workloads and adjusts the energy state of individual computers based on the energy-aware server management policies.

The term " tool " means, for example, an apparatus (s), system (s), computer readable medium (eg, one having executable instructions) as permitted by the above context and throughout a document. Computer-readable media), component (s), module (s), and / or methods. In various examples, the tool may be implemented in hardware, software, firmware or a combination thereof. The examples listed above are intended to provide a quick reference to aid the reader and are not intended to define the scope of the concepts described herein.

The accompanying drawings show implementation of the concepts conveyed in this application. The features of the illustrated implementation can be better understood by reference to the following description in conjunction with the accompanying drawings. Like reference symbols in the various drawings are used to refer to like elements as much as possible. In addition, the leftmost digit in each reference number indicates the figure in which the reference number first appears and the related discussion.
1 shows an example of a method for implementing an energy-aware server management concept in accordance with some implementations of the present concepts.
2 illustrates an example of a system for achieving energy-aware server management in accordance with some implementations of the invention.
3 illustrates an example of components for achieving energy-aware server management in accordance with some implementations of the present concepts.
4-5 illustrate a flow diagram associated with an energy-aware server management method in accordance with some implementations of the present concepts.

The present application relates to energy-aware server management. Briefly, this patent describes a concept for operating a set of computers, such as server farms, at expected performance levels while reducing energy consumption.

The concept may employ a multi-state server in a server farm that responds to user-requests or "requests." Overall, a request can be thought of as a "workload" of a server farm. The multi-state server may have an active state (s) in which the request can be processed and an inactive state in which the request is not processed. Some multi-state computers can have multiple inactive states. For example, sleep, hibernate and / or off may be examples of inactive states. Inactive servers use substantially less energy than active servers. However, there may be a latency period of, for example, several seconds to a few minutes involved in transitioning from the inactive-state server to the active state. This latency period can create unwanted processing delay (s) before additional servers are available (ie, active) to process the request.

Thus, energy-aware server management may consider or balance some parameters such as latency and performance criteria to reduce energy usage while responding to requests in a timely manner.

1 provides an illustrative example of some of the concepts in the form of method 100. In this case, the future workload for a computer set, such as a server computer, is predicted or estimated at 102. The forecast may be related to a relatively short time period, such as a few seconds to several minutes. In this particular case, an individual computer can have two or more energy states. For example, a computer can have an active state (ie, on) and one or more inactive states (ie, among many, off, sleep, and hibernate).

Detailed examples of workload prediction methods are described below under the heading "Workload Prediction Examples". Briefly, in some examples, job prediction is a parameter considered in the workload prediction processor, among other things, relative long-term modeling, relative short-term history, current trends and / or external knowledge (eg, , Business projects, and scheduled events).

Long-term modeling can observe workload trends over multiple years such as time of day, day of the week, time of year, and election. For example, as a worker arrives at work and starts the day, he performs various personal and / or work related requests, so there may be a continuous workload request between 8:00 and 9:00 each morning of the week.

Short history is related to the level of user request for the last few seconds or minutes. For example, mentioning a website in a famous TV show can attract a hit to that website for the next few minutes. An indication of the upward trend of recent seconds or minutes may be useful for predicting future requests for the next few seconds or minutes.

This trend may be related to user requests received during the workload prediction process. For example, the present trend can be derived from the shape of the graph of requests over the time available recently. The graph can be stable or vary in time series distribution (eg linear, exponential).

External information can be thought of as information not obtained from current or past requests. Instead, external information may be associated with an upcoming event that may not appear in, for example, historical data. For example, external information may convey that the Olympics are approaching and that an unusually high number of requests may be experienced as the user attempts to download video from the event during the Olympics.

Alternatively or in addition to the number of requests, external information may be related to the request size. For example, continuing with the example above, the size of each request is larger than usual because the external information can increase in the number of requests during the Olympics and the requests tend to be related to downloading data intensive videos. Can indicate that it can.

The above description provides a non-limiting example of workload prediction. Other examples can predict the request size. The estimated request size can be used for workload prediction. In summary, there are many ways of predicting future workloads. The predicted future workload can then be used in the systems / methods described below, among others.

The energy-aware server management policy may be determined for the estimated workload at 104. In brief, the energy-aware server management policy may include capacity provisioning. In some implementations, dose provision can be considered proactive (ie, proactive dose provision) in that the workload can be made in an online, real-time manner as the workload changes. Proactive capacity provision can be considered proactive because it can be done proactively to mask the time it took for the server to transition between different power states. This can be contrasted with reactive determinations where decisions and any response actions are made "after" the event occurred.

In other words, computer sets have the capacity to handle a given workload in their current state. If the capacity of the computers is different from the capacity to handle the expected workload in their current state, capacity provisioning may be employed to adjust the state of some of the computers to organize future capacity with the predicted workload.

Energy-aware server management policies include changing (ie, transitioning from an active state to an inactive state or vice versa) of one or more of the computers. Energy-aware server management policies are based on the expected service life of individual computers involved in the energy use of the computer set, timeliness expectations for responses to user requests, confidence in predictions / estimates, and / or transitions. Many factors can be balanced, including, but not limited to, impacts. These factors are described in more detail below under the heading "Examples of dose provision".

The energy status of an individual computer may be adjusted based on the energy-aware server management policy at 106. For example, some computers may transition from active to inactive to conserve energy. The energy-aware server management policy may specify how a request should be allocated among active computers.

Another aspect of the energy-aware server management policy may specify which state a particular computer should be in. This can be done to improve the reliability of the computer. For example, some types of computers can suffer long term consequences if they transition too much between active and inactive states. Thus, the energy-aware server management policy may indicate that an individual server should not transition more than a given number of times in a given time period, such as one day. The system can keep track of how many cycles "Machine A" has gone through and choose to transition another machine if Machine A has gone too far. Various aspects of the energy-aware server management policy will be discussed in more detail below under the heading “state transition example” in connection with FIG. 2.

Example of system configuration

2 illustrates only one example of a system 200 in which the energy-aware server management described above may be implemented. In this case, the system 200 includes a load dispatcher 202, an adaptive control unit 204 and four servers 206 (1), 206 (2), 206 (3), and 206 (n). Includes a set of The load dispatcher 202, the applicable control unit 204 and the servers 206 (1), 206 (2), 206 (3), and 206 (n) may be co-located and / or distributed with each other in various implementations. Can be.

A user, indicated generally at 210, may make requests 212 (1)-212 (n) received by the load dispatcher 202. The load dispatcher issues individual requests 212 (1) -212 (n) as indicated in 214 (1) -214 (n), in accordance with the energy-aware server management policy 216 and the list of active machines 218. Send to individual servers 206 (1) -206 (n). The energy-aware server management policy 216 and the active machine list 218 are generated by the adaptive control unit 204 and sent to the load dispatcher 202.

The active machine list 218 reflects the energy management control decisions 220 communicated by the adaptive control unit 204 to the servers 206 (1)-206 (n). An energy management control decision can be thought of as a control that implements an energy-aware server management policy at the server level by controlling the state of individual servers 206 (1) -206 (n). Adaptive control unit 204 generates energy-aware server management policy 216 and active machine list 218 based on various input parameters. In this case, the input parameters include, but are not limited to, performance counter 222, request information 224, energy usage 226, and / or input request workload (not specifically shown).

The performance counter 222 may be sent from the servers 206 (1) -206 (n) to the adaptive control unit 204. Performance counters may indicate the capacity at which individual servers and / or the overall set of servers are operating.

Request information 224, such as response time, may be obtained from the load dispatcher 202. The request information may be specified in several ways, among other things, such as request rate (ie, request per unit time), request size, and / or request response time.

Energy usage 226 can be obtained from a variety of sources, one simple source being an energy consumption meter from a power source (not shown) to servers 206 (1) -206 (n). Although not specifically shown, other implementations may provide energy usage for individual servers, alone or in combination with overall energy usage. The adaptive control unit may receive information about sources not specifically shown. For example, the adaptive control unit can obtain the performance information defined in the SLA. This performance information can be used in the formation of energy-aware server management policy 216. In addition, the adaptive control unit can send only a specific portion of the energy-aware server management policy 216 to the load dispatcher 202. For example, the energy-aware server management policy may include dispatch logic that is sent to the load dispatcher to define how the request is sent to the server.

In some cases, the load dispatcher 202 can function as a load balancer, sending requests 212 (1) -212 (n) to the active server 206 (1) -206 (n). It can distribute uniformly. In other cases, with respect to active servers, the load sender can strategically distribute requests to a subset of active servers at a relatively high frequency to keep these servers at a specific capacity, for example 70% of the total capacity. Any request for a subset of this server to exceed a certain capacity may be sent to a second subset of active servers. Such a configuration may allow the second subset to operate in a preliminary role while keeping many of the active servers operating at a specific or desired capacity, thereby increasing energy efficiency. In one aspect, this second subset of active servers can be thought of as a hedge against unexpected workload spikes.

Further, based on the information obtained from the adaptive control unit 204 (ie, the energy-aware server management policy 216 and / or the active machine list 218), the load dispatcher 202 transitions to an inactive state and You can redistribute the load from any server.

In summary, in some implementations, the load dispatcher 202 may distribute the request only between active servers and may redistribute the request from a server that is transitioning to an inactive state.

In the illustrated configuration of the system 200, the adaptive control unit 204 can predict future workloads (ie, future requests). The adaptive control unit can form an energy-aware server management policy to handle future workloads in an energy efficient manner. The adaptive control unit may take into account a number of parameters in forming the energy-aware server management policy. These parameters may include, but are not limited to, request information 224, energy usage 226, and / or performance counters 222.

In summary, the adaptive control unit 204 may control the state of the servers 206 (1) -206 (n) in accordance with the energy-aware server management policy via the energy management control decision 220. In the configuration shown, the adaptive control unit can function in a relatively simple closed loop control scenario where the system function can be controlled via an output generated based on the received input.

The adaptive control unit, to name a few, operates by receiving input data relating to system performance, such as server CPU usage, request response time, and energy consumption. The input data may be considered to reflect the predicted future workload in order to determine how to handle the predicted future workload. For example, the number of servers in each energy state (ie, active, inactive (sleep, hibernate, off, etc.)) can be adjusted to balance capacity with anticipated workload and thereby conserve energy. In other words, the adaptive control unit can provide an energy state between servers 206 (1)-206 (n) to handle the predicted workload in an energy efficient manner.

In some cases, servers 206 (1) -206 (n) may employ a processor designed for non-server related use. For example, the concept may allow processors designed for use in netbooks and other mobile applications to be advantageously applied to server scenarios. For example, an Intel brand of Atom processor may be used in some of the configurations. Atom processors are relatively energy efficient in the active state and have an inactive sleep state that provides about 90% energy savings over the active state.

Inactive states generally provide different latency times for transitioning to the active state. For example, a true "off" state can provide more than 99% power savings over an active state. However, substantial energy savings come at the expense of relatively long transition latency. For example, the transition latency from the off inactive state to the active state can be several minutes. In contrast, a “sleep” inactive state can provide energy savings of, for example, 90% but transition latency can provide, for example, 10-20 seconds. A potential drawback of this long transition is that if the workload prediction actually underestimates the future workload, the off-in server will not help for a relatively long time.

Inactive state of "hibernation" can provide energy savings and transition latency between sleep and off inactive states. For example, hibernation can provide 95% energy savings and a 30 second latency transition compared to the active state. Note that in some features, hibernation is characterized by a deep level of sleep. With regard to Intel's Atom processor mentioned above, the active state energy consumption is 28-34 watts, but it consumes 3-4 watts in the sleep state and 1-2 watts in the hibernation state, both of which are at least idle for the idle processor. Provide at least 1/10 energy savings in energy consumption. The inactive state example described above is provided for the purpose of discussion. It should be understood that the concept is not associated with a particular set of inactive states that can be provided to a particular server computer. In other words, the energy saving function can be applied to any system, device and / or device that can be powered down and / or powered off.

Computers with multiple inactive states tend to be available in some product lines, such as notebook computers. Product lines that provide multiple inactive states tend to be designed for freestanding applications, such as personal use, rather than coordinated applications such as server farms. One reason for these characteristics in organized applications is the complexity / difficulty of controlling various computers in a high performance and energy efficient manner.

The complexity of balancing performance and energy efficiency also occurs in single use scenarios. For example, a notebook computer simply shuts down in an inactive state when the time expires (ie no user input is received for a predetermined period of time). This timeout method does not attempt to predict future use in any way and to satisfy the future use in an energy conscious way or to operate the computer in a high performance way for the user. Therefore, when a user returns to a computer that has transitioned to such an inactive state, the user must provide some input and wait while the computer transitions back to the active state.

Energy-aware server management policy 216 may allow the energy efficiency potential of a multi-state computer to be realized in a collective setup such as a server farm. Briefly, energy-aware server management can determine when individual servers 206 (1) -206 (n) will transition between inactive and active states to service current and anticipated future workloads.

3 shows an example of a logic module of the adaptive control unit 204 to achieve energy-aware server management. In this case, the logic module appears as workload prediction module 304, strategy or policy module 306, and state adjustment module 308.

The workload prediction module 304 can determine the current workload and predict the future workload. In one aspect, the workload may be thought of as the number of requests multiplied by the number of requests per unit time. In operating scenarios where a relatively large number of requests are involved, the average request size can be calculated with a fairly high degree of accuracy. In these cases, the workload may simply be calculated as the number of requests per hour times the average request size. The workload prediction module can use various techniques to predict future workloads, some of which have been introduced above and some discussed in more detail below. Briefly, in the system of FIG. 2, workload prediction module 340 may use request information 224 as input data for predicting future workload. In other cases, the workload prediction module may receive and use external information. In some implementations, the workload prediction module can collect, model, and store long-term historical trends for use in estimating or predicting future workloads.

The policy module 306 may form an energy-aware server management policy to satisfy the workload predictions supplied by the workload prediction module 304. For example, the policy module may calculate the current capacity as the number of active servers and the number of requests that can be handled by individual active servers in unit time. The policy module can calculate the appropriate capacity for the anticipated workload. In summary, energy-aware server management policies may include providing capacity to handle predicted workloads.

The policy module 306 may form an energy-aware server management policy to reconfigure the server to the appropriate capacity for the workload expected from the current configuration. For example, consider a hypothetical scenario involving a server farm of 10 servers, where each active server can handle 10 requests per second. The current workload is 67 requests per second being handled by seven active servers (the other three are inactive). Workload prediction indicates that the workload will be 38 requests per second at a future time t + Δt. In this case, the policy module may form an energy-aware server management policy that reduces the number of active servers.

The policy module 306 may include a number of factors in cost benefit analysis when forming an energy-aware server management policy. For example, the policy module can consider how many individual servers are activated and deactivated to optimize server life. The lifetime of a server tends to be inversely proportional to the number of transitions between active and inactive energy states. Another factor may be an SLA that defines a level of performance for the system 200. Another factor that can be considered is the level of confidence in the workload prediction. For example, in the case of high confidence, the policy module can conclude that four active servers will be sufficient for the predicted workload and may include deactivating three more servers for a total of six inactive servers. . If the level of confidence is low, the policy module can form an energy-aware server management policy that maintains four active servers.

In some implementations, the policy module 306 can employ a performance learning model that can include other parameters or metrics such as CPU, memory, disks, networks, etc. in forming the energy aware server management policy. . Also, for the convenience of explanation, the above discussion treated all servers equally. However, the policy module may form an energy-aware server management device 216 that recognizes and / or handles differences or heterogeneity between servers. The difference may be inherent in the server and / or external. For example, energy-aware server management policies may reflect that individual servers have transition times between different capacities, different power footprints, and different energy states. Similarly, servers can be affected by external factors such as temperature hotspots, maintenance tasks.

The energy-aware server management policy may specify which inactive state an individual server should transition to. For example, sleep inactivity provides a faster transition to the active state, so energy-aware server management devices require that other servers provide more energy savings while other servers provide more energy savings. It can indicate that it can transition to.

The energy-aware server management device may use additional factors to determine server transitions. For example, for maintenance / maintenance tasks such as software upgrades, the active server can transition off, while other servers in the inactive state can transition to active so that system capacity is not affected.

State provision module 308 may cause a state change to an individual server to occur in accordance with the energy-aware server management policy provided by policy module 306. Also, to avoid the load sender 202 (FIG. 2) sending a request to an inactive server, the state coordination module may communicate which server is active to the load sender.

Workload prediction example

In one implementation, workload prediction may be made using weighted linear regression. In this case, weighted linear regression can be thought of as a form of regression analysis in which observations are represented using mathematical functions of one or more independent variables. For example, the observation may be a dependent variable, such as a request per second. An example of an independent variable may be an input such as time. For weighted linear regression, the function can be represented as a linear combination of regression coefficients. The goal of weighted linear regression may be to reduce (and potentially minimize) the weighted sum of squares between the observed value and the value predicted by the function. Weights are used to assign different importance values to different observations. In summary, this particular workload prediction method combines regression analysis with historical trends, long-term models, external knowledge, etc. to predict future workloads.

Capacity provision example

In some specific examples, capacity provision may be made using machine learning in a performance learning model. In one such case, capacity provision employs a quartile regression machine learning method where the quantile of the conditional distribution of response times is expressed as a function of the input workload (requests per second) and the number of active servers.

This quartile regression takes into account the fact that when server usage is low, the response time increases almost linearly and increases rapidly (eg, potentially exponentially) as the input workload approaches the server's processing capacity. . In other words, the capacity provision method can learn the response time of the system in an off-line manner by changing the input workload parameter and the number of active servers. Then, for an estimate of a given SLA requirement and forecast workload, calculate the number of servers needed to satisfy the workload within a particular SLA.

State transition example

4 provides a flow diagram of a method 400 for achieving a state transition in accordance with energy-aware server management. The method 400 begins at block 402. At block 404, the method cleans up the server (ie, a server in a server farm or another group of servers). Block 404 may clean up the server according to one or more parameters. For example, servers can be organized according to their energy state (ie, active or inactive). Inactive servers can also be organized into ranked groups that reflect their relative energy savings. For example, an active server is listed before a sleep inactive server, after which the inactive server is hibernated and finally the inactive server is off.

Block 406 cleans up the energy state. In one case, the energy state can be organized based on the transition latency between inactive and active states. Alternatively or additionally, energy states can be sorted or ranked based on their energy use or footprint. So for example, an energy state may be listed from maximum energy consumption (ie, active) to minimum energy consumption (ie, off).

Block 408 calculates the difference or Δ between the predicted server demand (ie, the workload) at future time t _f and the capacity available at time t _f . Techniques for predicting workload are described above. In summary, block 408 serves to identify at what future time the available server capacity is just right, too high or too low.

If the difference in block 408 is equal to zero (ie, the predicted workload is equal to future capacity), the method proceeds to block 410. Since no capacity adjustment is needed, block 410 stops the process to control the server at the current time. After some incremental time, such as 30 seconds, the method returns to the start 402 and the method is repeated.

If there is a difference in block 408 (ie, the difference is not zero), the method proceeds to block 412.

Block 412 recognizes the set of servers (from the entire server introduced at block 404) that are transitioning in the intermediate period between the current time t and the future time t _f . In other words, block 412 identifies servers that are transitioning between states and / or are already scheduled to do so. If the difference in block 408 is positive (i.e.? 0; 0), the method proceeds to block 414; otherwise, if the difference is negative (i.e.? Lt; 0), the method proceeds to block 416 do.

At block 414, the method increases server capacity for time t _f by identifying inactive servers to transition to an active state. The status of individual servers is listed at block 404 above. Inactive servers considered for identification do not belong to the set recognized at 412. In other words, the identified server is an inactive server that is transitioning, transitioning or unscheduled in an intermediate period.

Various other parameters can be used to select the identified server. For example, transition latency can be considered. For example, future time t _f If is 30 seconds later, the method may consider the transition latency as a consideration for the server to transition. For example, if the sleep-to-active transition latency is 20 seconds and the off-to-active transition latency is 1 minute, then the method may indicate that the transition is a future time t _f. (I.e. 30 seconds), the server can be selected from the sleep state to terminate.

The method may take into account the number of times an individual server has transitioned in a given time period. For example, if one of the sleep state servers has already transitioned by the threshold number of times, the method may choose to transition another sleep state server that is below the threshold. Other parameters can also be used in the identification process in cost benefit analysis. For example, cost may include, among other things, the risk of increased response time and reduced server life due to frequent state transitions. The gain may be, among other things, reduced energy utilization.

Block 416 deals with a scenario where the server capacity at future time t _f is greater than the expected workload. Block 416 reduces server capacity for time t _f by ranking the individual active servers to transition to inactive. The active server under consideration does not include the servers identified in set {ts} in block 412 that may already be transitioning. The active server can be selected based on one or more parameters that can be considered using cost benefit analysis. Examples of parameters are described above with respect to block 414. Briefly, if a given server has already transitioned by a threshold number of times, the cost-benefit analysis may be weighted for transitioning that server again. Instead, another server can be chosen to transition.

Other parameters that can be considered are related to hedging for insufficient capacity. For example, suppose the server transition takes 20 seconds in each method, and the process cannot stop once started. Therefore, it takes 40 seconds to reactivate the active server (let's say server 1) once the transition has started (ie 20 seconds from active to inactive and an additional 20 seconds from inactive to active). For the purposes of discussion, suppose t _f is 30 seconds in the future. If another inactive server (let's say server 2) is now available to transition to active state, the risk associated with transitioning to server 1 is that the server 10 can be activated in a timely manner as long as time t _f is at least 20 seconds ahead. It is relatively low for seconds. So, for example, if a decision is made to deactivate server 1 and an underestimation associated with time t _f is detected after 8 seconds, server 2 can be activated in a timely manner to cover additional capacity requests (ie, 8 A second plus 20 second transition leaves server 2 active at 28 seconds or 2 seconds before capacity may be inadequate). Therefore, the availability of server 2 can be tilted toward deactivating server 1 for cost-benefit analysis.

Another similar parameter relates to the ability of server 1 itself to cover any underestimation. For example, continuing the above example, assume that for a 40-second active-to-active transition, Server 1 takes 20 seconds to transition in each direction. Consider the first scenario where the future time t _f is 30 seconds later. In this case, if an underestimate is detected, Server 1 will not be available to cover additional demand at future time t _f . In such a scenario, this parameter may be weighted in a direction that does not transition server 1. Consider another scenario where future time t _f is 60 seconds later. In this case, if an underestimate is detected, server 1 may be deactivated and reactivated before time t _f (ie within 40 seconds). In this scenario, this parameter can be weighted in the direction of deactivating the server. Those skilled in the art will appreciate that cost-benefit analysis may consider many parameters to provide the expected service level while conserving energy.

As with block 410, after a predetermined incremental time, such as 30 seconds, the method returns to start 402 and the method can be repeated.

Algorithm 1 shows a specific state transition method that employs cost-benefit analysis to generate part of an energy-aware server management policy.

Algorithm 1

Step 0. Clean up servers in the order that active servers come before inactive servers-called SSequence.

The energy states are arranged in ascending order of their transition from the energy state to the active state-called ESequence.

Arrange the energy states in ascending order of energy footprints-PSequence.

Step 1. Calculate the difference between the predicted server demand (let's say P server) and the number of servers available at a predetermined future timestep (let's say F server).

(The number of servers available in a predetermined future time-step depends on the number of servers currently active, the number of servers currently transitioning and the number of servers to transition before a predetermined time step.)

Step 2. If the difference is zero, stop (difference = D = P-F).

Step 3. Take the first T servers in SSequence and transfer them to an active state (unless already active or transitioning to active), T = MINIMUM (P, F). For each i on T servers, NoChangeUntilTime [i]: = set to a predetermined future time step.

Step 4.If D is the amount (ie, add capacity),

then

Take the next D servers from the SSequence (for step 3) in ascending order of ESequence

For each such server (let's say s)

       NoChangeUntilTime [s]: = set to a predetermined future time step

if (future timestep-current time> transition-from-that-energy-state-to-active) (i.e., time still remains)

Schedule the transition from the future time (future time step-current time) to that server's active state

else

Now schedule the transition to the active state of that server's

end if

end for

else

If D is negative (i.e. low capacity)

then

Take the next D servers active (for step 3) from SSequence and for each of those servers (called j) NoTransitionUntilTime [j] <= current time

Step 4A. For each energy state in PSeqeuce

if (future time step-current time> = transition-from-that-energy-state-to-active) + transition-from-active-to-that to energy state -energy-state))

Now schedule D to go to that energy state; stop

else if (future time step-current time> = transition from that energy state to active)

AND (there are D servers in that energy state)

then

Now schedule D to go to that energy state; stop

else

Now schedule (D-number of servers in that energy state) to go to that energy state

D = D-the number of servers in that energy state

GO TO STEP 4.A (and consider the next energy state in that order)

end if

end for

end if

end if

In summary, the capacity provisioning method takes a proactive approach to transitioning servers to different energy states, masking the latency of these transitions and delaying transitions to satisfy load demands while reducing energy usage.

Secondly, the implementation applies the transition while considering additional factors such as history of transitions per server, hot spots, maintenance operations, failures, and the like. For example, to balance the number of transitions across nodes, some active servers may be placed in a low energy state and vice versa.

Method example

5 shows a flowchart of a method or technique 500 consistent with at least some implementations of the present concepts. The order in which the method 500 is described is not intended to be interpreted as a limitation, and any number of the described blocks may be combined in any order to implement the method or other methods. In addition, the method may be implemented in any suitable hardware, software, firmware or combination thereof, whereby the extension device may implement the method. In one case, the method may be stored as a set of instructions in a computer readable storage medium in a manner such that execution by the computing device causes the computing device to perform the method.

At block 502, the method predicts the number of future requests to the server pool including individual servers configured with an active state and at least two different inactive states.

At block 504, the method models the response time for future requests as a function of the number of future requests and the number of active servers.

At block 506, the method calculates the number of servers to operate in each active state and each inactive state to satisfy the response time.

At block 508, the method causes the individual server to transition between states to satisfy the calculated number.

The method described above can reduce energy usage by the server while satisfying the user's expectations (ie, satisfying the conditions of the SLA, etc.).

conclusion

Although techniques, methods, devices, systems, etc. related to energy-aware server management are described in language specific to structural features and / or methodological acts, the claims defined in the appended claims should be limited to the specific features or acts described. It should be understood that it is not. Rather, the specific features and acts are disclosed as example forms of implementing the claimed methods, apparatus, systems, and the like.

Claims (14)

Predicting a future workload for a set of computers, wherein each computer has at least two energy states;
Forming 104 an energy-aware server management policy for the predicted future workload;
Adjusting 106 an energy state of an individual computer based on the energy-aware server management policy.
Method 100.
The method of claim 1,
The estimating includes estimating the future workload as the product of the number of requests predicted for a given future time period and the average amount of data per request in the past time period.
Way.
The method of claim 1,
The forming step includes solving a function comprising a service level agreement with the future workload.
Way.
The method of claim 1,
The forming step takes into account potential negative life expectancy ramifications for the individual computer involved in the state transition.
Way.
The method of claim 1,
The forming step takes into account the transition time for transitioning an inactive computer to an active state in a scenario where the predicted future workload is less than the actual future workload.
Way.
The method of claim 1,
The adjusting further includes transmitting a signal identifying the adjusted state of the individual computer.
Way.
The method of claim 1,
The adjusting step takes into account the transition time between the individual energy states
Way.
The method of claim 1,
The adjusting may take into account the uncertainty associated with the predicted future workload.
Way.
The method of claim 1,
The adjusting step leaves the buffer of the underutilized computer as a hedge to maintain response time for future requests.
Way.

An adaptive control unit 204 configured to maintain a response time for the server farm at a predetermined level while managing energy usage in the server farm by transitioning individual servers between active and inactive states;
System 200.
The method of claim 10,
The adaptive control unit includes a workload prediction module configured to predict a future workload of the server farm.
system.
The method of claim 11,
The adaptive control unit includes a policy module configured to manage the predicted workload in a manner that handles energy usage by transitioning individual servers between active and inactive states while meeting performance criteria associated with the predicted workload.
system.

The method of claim 10,
The adaptive control unit includes a state adjustment module configured to adjust a state of an individual server according to an energy-aware server management policy.
system.
The method of claim 10,
And further comprising a load dispatcher for assigning a workload to the individual active server based on the instructions from the adaptive control unit.
system.

Images