U.S. patent application number 12/254698 was filed with the patent office on 2009-07-16 for adaptive dynamic buffering system for power management in server clusters.
This patent application is currently assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to Hoi Y. Chan, Jeffrey O. Kephart, David W. Levine.
Application Number | 20090183016 12/254698 |
Document ID | / |
Family ID | 39855711 |
Filed Date | 2009-07-16 |
United States Patent
Application |
20090183016 |
Kind Code |
A1 |
Chan; Hoi Y. ; et
al. |
July 16, 2009 |
ADAPTIVE DYNAMIC BUFFERING SYSTEM FOR POWER MANAGEMENT IN SERVER
CLUSTERS
Abstract
A system, method and computer program product for managing power
consumption in a system comprising at least two computing devices.
The at least two computing devices are organized as part of active
computing device group or a ready computing device group, the ready
computing devices configured into various modes of readiness
including a standby mode, a hibernating mode, and a power-off mode.
A control device receives obtained sensed parameters indicative of
the processing load at the group of active computing devices and
determines a "Readiness" index value representing a state of system
readiness which is a function of a transition time parameter
representing a time for moving one or more computing devices from
the second group of ready computing devices to the first group of
active devices in response to a service level violation. To achieve
maximum power saving and yet meet various performance targets, the
ready computing devices are dynamically allocated from amongst
three states: standby, hibernating or power-off, based on the
current readiness index value.
Inventors: |
Chan; Hoi Y.; (New Canaan,
CT) ; Kephart; Jeffrey O.; (Cortlandt Manor, NY)
; Levine; David W.; (New York, NY) |
Correspondence
Address: |
SCULLY, SCOTT, MURPHY & PRESSER, P.C.
400 GARDEN CITY PLAZA, SUITE 300
GARDEN CITY
NY
11530
US
|
Assignee: |
INTERNATIONAL BUSINESS MACHINES
CORPORATION
Armonk
NY
|
Family ID: |
39855711 |
Appl. No.: |
12/254698 |
Filed: |
October 20, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12013952 |
Jan 14, 2008 |
7441135 |
|
|
12254698 |
|
|
|
|
Current U.S.
Class: |
713/323 ;
713/300; 713/320; 713/340 |
Current CPC
Class: |
G06F 1/3287 20130101;
G06F 1/3203 20130101; G06F 1/3246 20130101; Y02D 10/171 20180101;
Y02D 10/00 20180101 |
Class at
Publication: |
713/323 ;
713/320; 713/300; 713/340 |
International
Class: |
G06F 1/32 20060101
G06F001/32; G06F 11/30 20060101 G06F011/30; G06F 1/26 20060101
G06F001/26 |
Claims
1. A computer program product for managing power consumption in a
system comprising at least two computing devices including a first
group of active computing devices each adapted for processing a
computational workload, the computer program comprising a computer
readable medium having computer usable program code embodied
therewith, the computer usable program code comprising: computer
usable code configured to sense a state of processing operations at
said active computing devices, computer usable code configured to
receive, at said control device, a signal requesting that
additional computing devices from a second group of inactive
computing devices be added to the first group of active computing
devices, or that computing devices from the first group of active
computing devices be placed in the second group of inactive
computing devices according to said state of processing operations;
computer usable code configured to determine a system transition
time TT value for moving one or more computing devices from the
second group of ready computing devices to said first group of
active devices, and comparing said TT value against a minimum
value, M_min, representing a minimum acceptable delay time for
switching a standby computing device from said second group of
ready computing devices to said first group of active computing
devices and, against a maximum value, M_max, representing a maximum
delay interval when all computing devices are in a powered off
state; said computer usable code configured to enable the control
device to further dynamically generate a readiness index parameter
RI.sub.t at a current time indicating a state of system readiness
where RI.sub.t is a real number from 0 to 1, where 0 represents
minimum readiness and 1 represents maximum readiness, said RI.sub.t
calculated according to one of:
RI.sub.t=RI.sub.t-1+(TT-M_min)/M_max, when increasing system
readiness according to a predetermined system response time policy,
or, RI.sub.t=RI.sub.t-1-(TT-M_min)/M_max, when decreasing system
readiness according to a predetermined system response time policy,
and, where RI.sub.t-1 is a RI value prior to said current time;
and, computer usable code configured to dynamically allocate one or
more computing devices in said second group of ready computing
devices in various stages of stand-by, hibernating and power-off
readiness according to a value of said readiness index parameter,
wherein if RI=0, all N ready computing devices in the second group
are in powered-off state where N=number of total ready computing
devices in the second group; and, if RI=1, all N ready computing
devices in the second group are in one of: standby state or
hibernating state; wherein, a time it takes to bringing a computing
device from said second group of ready computing device to an
active readiness state in said first group is minimized, while
maximizing energy savings in said system.
2. The computer program product for managing power consumption as
claimed in claim 1, wherein said dynamically allocating includes:
providing a number N*(1-RI) of powered off computing devices in
said second group; providing a number N*RI/2 of standby computing
devices in said second group; and, providing a number N*RI/2 of
hibernating computing devices in said second group.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of U.S. Ser. No.
12/013,952, filed Jan. 14, 2008, the entire contents of which are
incorporated herein by reference.
BACKGROUND
[0002] 1. Field of the Invention
[0003] The invention relates generally to power management
techniques for computing systems, generally, and more particularly,
the invention relates to effective and efficient and, a dynamic
server buffering system for optimizing power consumption in servers
while adhering to specified Service Level Agreements (SLAs).
[0004] 2. Description of the Related Art
[0005] The cost of data center server power consumption and the
cooling systems to dissipate the generated heat are major expenses
in modern data centers where thousands of servers are densely
packed in relatively small racks. To maintain effective operation
and sustain profitability, it becomes necessary to have power
management systems to optimize the power usage with respect to
customer requirements. In other words, these power management
systems must be able to use minimum power possible and yet be able
to satisfy all customer requirements. It is well established that a
typical server consumes a relatively high amount of power even it
is idle, due to chip leakage current and other supporting
components such as disk drive and network gears. Turning system off
and direct all traffic to a subset of available servers during
non-peak hours is a common approach to save power during periods of
low traffic. Current technologies for server shutdown are mainly
based on actions of system administrators, by manual operation
or/and based on some simple policies. Based on their experiences
and workload history, the system operators may shut down systems
for an extended period of time. In doing so, these system operators
must consider the possibility of sudden increased traffic load and
in most cases, usually over-provision to account for the worst case
situations in order to maintain customer satisfaction. The amount
of effort for the system administrators, and the priority of data
center to satisfy customer requirement over the cost of power
consumption negate the effective use and benefit of these power
management systems.
[0006] New power management strategies which turn on and off
servers based on real time or near real time workload has been
investigated. It is obvious that there is a finite cost of shutting
down a system and turning it back on. The amount of time to power
down/up and restore active applications means lost time for real
work and usually maximum power is used to power on/off a server,
not to mention the frequent repeated power on/off cycle increases
the wear-and-tear of these servers, resulting in higher failure
rate. Due to the time lapsed in restoring a server from shut-down
state to fully available for use, usually from 1 to 5 minutes,
depending on system applications and configurations, power on a
shut-down server may not react fast enough to the sudden increased
traffic demand, resulting in frequent violation of customer SLAs.
In addition, no customer or data center manager want to see their
servers spend most of its productive time in repeat turn on/off.
All these potential problems prevent this power management
strategies from being widely used.
[0007] It would be highly desirable to provide an autonomic,
adaptive and dynamic server buffering system for server power
on/off to optimize power consumption, and at the same time,
guarantees customer satisfaction by satisfying customer SLAs.
SUMMARY
[0008] The present invention addresses the needs described above by
providing a dynamic buffering system is a buffer tool which
includes a set of servers as a workload buffer in various stages of
readiness to absorb sudden increased of traffic without frequent
power on/off of servers.
[0009] In accordance with one embodiment, a server in the buffer
may have one of the following stages: 1) full standby mode, which
is ready to accept workload instantaneously, but remains idle as
long as all main servers can serve the current workload without
customer violation; 2) hibernate mode, which allows various
components of the servers in this mode to be in minimum consumption
power mode, but it may take a short amount of time, in the order of
10 to 30 seconds, to restore to standby mode; 3) fully shut down
mode.
[0010] The servers in this 3.sup.rd mode in the buffering tool is
completely shut down which allows maximum power saving. The number
of servers in the pool, as well as the number of servers in various
stages of readiness are determined automatically and dynamically by
user policies, or by user-determined pluggable predictive machine
learning algorithms as response to real time workload
conditions.
[0011] The invention particularly addresses a need by providing a
system, method and computer program product for managing power
consumption in a system comprising at least two computing devices,
the method comprising:
[0012] providing one or more computing devices in a first group of
active computing devices each adapted for processing a
computational workload, and,
[0013] sensing a state of processing operations at the active
computing devices,
[0014] receiving, at a control device, a signal requesting that
additional computing devices from a second group of inactive
computing devices be added to the first group of active computing
devices, or that computing devices from the first group of active
computing devices be placed in the second group of inactive
computing devices according to the state of processing
operations;
[0015] determining, by the control device, a system transition time
TT value for moving one or more computing devices from the second
group of ready computing devices to the first group of active
devices, and comparing the TT value against a minimum value, M_min,
representing a minimum acceptable delay time for switching a
standby computing device from the second group of ready computing
devices to the first group of active computing devices and, against
a maximum value, M_max, representing a maximum delay interval when
all computing devices are in a powered off state;
[0016] the control device further dynamically generating a
readiness index parameter RI.sub.t at a current time indicating a
state of system readiness where RI.sub.t is a real number from 0 to
1, where 0 represents minimum readiness and 1 represents maximum
readiness, the RI.sub.t calculated according to one of:
[0017] RI.sub.t=RI.sub.t-1/(TT-M_min)/M_max, when increasing system
readiness according to a predetermined system response time policy,
or,
[0018] RI.sub.t=RI.sub.t-1-(TT-M_min )/M_max, when decreasing
system readiness according to a predetermined system response time
policy, and, where RI.sub.t-1 is a RI value prior to the current
time; and,
[0019] dynamically allocating, by the control device, one or more
computing devices in the second group of ready computing devices in
various stages of stand-by, hibernating and power-off readiness
according to a value of the readiness index parameter, wherein
[0020] if RI=0, all N ready computing devices in the second group
are in powered-off state where N=number of total ready computing
devices in the second group; and,
[0021] if RI=1, all N ready computing devices in the second group
are in one of: standby state or hibernating state;
[0022] wherein, a time it takes to bringing a computing device from
the second group of ready computing device to an active readiness
state in the first group is minimized, while maximizing energy
savings in the system.
[0023] In one dynamic allocation scheme, the method for managing
power consumption includes:
[0024] providing a number N*(1-RI) of powered off computing devices
in the second group;
[0025] providing a number N*RI/2 of standby computing devices in
the second group; and,
[0026] providing a number N*RI/2 of hibernating computing devices
in the second group.
BRIEF DESCRIPTION OF THE DRAWINGS
[0027] The objects, features and advantages of the invention are
understood within the context of the Description of the Preferred
Embodiment, as set forth below. The Description of the Preferred
Embodiment is understood within the context of the accompanying
drawings, which form a material part of this disclosure,
wherein:
[0028] FIG. 1 shows a system diagram depicting the environment in
which the present invention is employed;
[0029] FIG. 2 shows an example server allocation manager GUI 200
according to one embodiment of the invention;
[0030] FIG. 3 is an example user interface depicting the Automatic
Mode 202 of the Server Allocation Manager;
[0031] FIG. 4 is an example user interface depicting the Manual
Mode 204 of the Server Allocation Manager;
[0032] FIG. 5 is an example user interface depicting the
User-Assisted Automatic Mode 204 of the Server Allocation Manager;
and,
[0033] FIG. 6 is an example user interface depicting the Full
PowerMode 208 of the Server Allocation Manager.
DESCRIPTION OF THE PREFERRED EMBODIMENT
[0034] FIG. 1 illustrates an environment 10 in which the power
management system and method of the invention may be employed. As
shown in FIG. 1, the system includes: an on-Demand Router 20 that
receives http requests from clients (not shown); two (2) server
buffers including: an Active buffer 40 and a Ready buffer 60; an
Allocation Manager 100; and, performance metric sensors 80. The
On-Demand router 20 particularly receives incoming client requests
and assigns the requests to one or more of the server devices in
the active server buffer (alternately referred to as buffer active
buffer pool. The Active Servers Buffer 40 includes computing
devices, e.g., servers or server clusters 24 in various power
states that are ready to accept workload. The Ready Servers Buffer
60 also includes servers or server clusters 28 in various power
saving states such as standby, hibernating and complete powered off
states. Allocation Manager 100 is a computing device for
controlling the power settings of each of the servers in the Active
Servers Buffer, the deployment of servers from the Ready Servers
Buffer to the Active Servers Buffer (or removal of servers from the
Active Servers Buffer and place them back in the Ready Servers
Buffer), and the allocation of servers in each of the readiness
states (e.g., Standby, Hibernating and Complete Powered Off) in the
Ready Servers Buffer. The Allocation Manager 100 makes its
allocation decision based on inputs feedback from the Performance
Metric Sensors 80. In operation, Performance Metric Sensors 80
collect system performance data from each of the servers/server
clusters from the Active Servers Buffer and forward the sensor data
to the Allocation Manager 100 where methods and functions execute
for analysis and control purposes. That is, the Allocation Manager
100 may be part of a computing device including a memory having a
computer readable instructions, data structures, program modules,
and application interfaces forming the analysis and control
component. Performance Metric Sensors, which may comprise software
agents or applications that run on the system to collect data,
collect system performance data including, but not limited to:
Response Time, Queue Length (i.e., the number of unprocessed client
requests waiting to be serviced), memory usage, down time etc. It
should be understood that there may be other sensors that are
unique to a specific application. For example, in a web application
serving customer requests, the common sensor is a response time
sensor. The collected sensor data is forwarded to the Allocation
Manager for analysis. At the Allocation Manager, for instance,
sensor readings regarding a performance criteria, e.g., request
buffer queue length, may be compared with a minimum value and a
maximum value, with the Allocation Manager performing steps in
accordance with the reading.
[0035] FIG. 2 shows an example graphical user interface (GUI) 200
operable and associated with the Allocation manager computing
device 100 that enables users to select various modes of operation.
FIG. 2 depicts the GUI 200 having at least four (4) basic user
selections representing modes of operation that are available for
system control via the Allocation Manager 100. These modes of
operation include: 1) Automatic Control 202 enabling execution of
computer readable instructions, data structures, program modules,
and application interfaces for providing full automatic control of
server allocation based on built-in/user defined power management
policy; 2) Manual Control 204 enabling execution of computer
readable instructions, data structures, program modules, and
application interfaces for enabling user selection of the relative
allocation of servers among the buffers; 3) User Assisted Automatic
Control 206 enabling execution of computer readable instructions,
data structures, program modules, and application interfaces for
enabling automatic control mode with user confirmation; and, 4)
Full Power 208 a mode of operation where all servers are active
with full available power.
[0036] Additionally shown in FIG. 2 is an interface display portion
212 providing an instantaneous readout of system performance
parameter data such as Response Time (e.g., in milliseconds), Queue
Length, power usage (e.g., in Watts) as a function of time, and
send them to the Allocation Manager for analysis/monitoring of the
Active Server Buffers.
[0037] FIG. 3 depicts the GUI 202 presented via the Allocation
manager interface display upon selection of the automatic mode of
operation via the Allocation Manager 100. In the fully automatic
mode, the system automatically selects the best allocation policy
for buffering periodically. However, administrator may override at
any time. In this Server Allocation Automatic mode of operation
202, the GUI enables user to select the main parameters to be used
by the Allocation Manager to automatically manage the distribution
of servers in the active/ready buffers based on the monitored
performance. For example: a control button 222 enables user
selection of the control parameters such as system response time; a
slide bar control 224 enables user control of the amount of power
savings with performance as a tradeoff; a window 226 shows the
projected Service Level Agreement (SLA) performance target
violation (e.g., in units of time) with the selected parameters.
Selection of the Advanced policy control 228 allows a user to
select user defined or other plugged-in power management policies
for execution by the allocation manager.
[0038] As referred to herein the SLA pertains to a contract between
service providers and clients. The parameters which determine if
the SLA is complied depend on the agreement between the service
provider and the clients. Usually, the major parameter used is
response time--the amount of time it takes to receive a response
from the service provider after a service request is made (e.g.
HTTP call, request a URL etc.). The criteria which determine SLA
violation is a parameter agreed upon by the service provider and
the client. For example, the response time must not exceed 25% of
the agreed value more than 10 times in 5 minutes. This criteria is
used in the algorithm as an input parameters.
[0039] FIG. 4 is an example user interface depicting the Manual
Mode 204 of the Server Allocation Manager. FIG. 4 particularly
depicts the GUI 204 presented via the Allocation manager interface
display upon selection of the manual mode of operation via the
Allocation Manager 100. In this Manual mode, users are enabled to
assign servers from one buffer to another, for example, by dragging
and dropping a selected server (as represented by its server name
or ID or icon 244) between a first listing 241 provided for the
Active buffer to a second listing 243 provided for the Ready
buffers including separate locations from which hibernating,
stand-by and powered off servers may be selected from or moved to.
In this manner, the users are enabled to adjust the power state of
each server via respective power state control selections 242,
confirm or cancel the automatic server allocation decision made by
the Allocation Manager. As shown in FIG. 4, although not shown, it
is understood that in the fully manual mode, the user selects and
allocates a pool of n (n=0,1,2, . . . , Smax) servers as a server
pool. The number of servers in various stage of readiness is
completely set by user policies. The policy will remain in effect
until the user cancels or selects another buffer policy. In
addition, in this manual operation mode, a user can select all
servers to be active in accepting workload (no buffer and
shutdown), e.g., no server in server pool (n=0). This enables
administrators to use full processing power when needed. For
example, an administrator may allocate fifteen 15 servers in the
server buffer pool in a 30 server environment. Fifteen (15) servers
are active servers, 3 server may be in immediate standby mode, 3
may be in hibernate mode and 9 are in fully power mode. As the
workload increases, servers in standby mode will be used first to
add to the active server list, the standby servers are then
replaced by a equivalent number of hibernate servers which in
turned are replaced by full shut down server (power up server).
This process continues until all server in power off stage are
depleted. In case of decreasing worldoad, this process reverses.
This multiple step stages process provide buffering to enable
minimum violation of SLA policy as well as optimizing power
consumption.
[0040] FIG. 5 is an example user interface depicting the
User-Assisted Automatic Mode 206 of the Server Allocation Manager.
In the User Assisted Automatic Mode, a user is enabled to via user
selectable buttons or icons 245 confirm, modify or cancel the
server allocation decision made by the Allocation Manager. More
particularly, in user assisted automatic mode, a user selects an
initial policy to determine the number of servers in each readiness
mode, the system will continuously evaluate current worldoad
condition together with historical information to select the best
policy to optimize power while meeting customer requirement by
selecting an optimized allocation of active, standby, hybernate or
power-down servers. It is understood that a user can select any
policy as the user sees fit, it is not limited to a pre-defined
policy. In one embodiment, the system operates in a fully automated
mode (automatic control mode); a user assisted mode is possible
which is like the fully automatic control mode but with user
verification and confirmation. It is further understood that any
change of policy over the initial user selected one must be
approved by the administrator. An administrator can override,
change or accept the generated policy.
[0041] FIG. 6 is an example user interface depicting the Full
PowerMode 208 of the Server Allocation Manager In the Full Power
Mode, the power of each server is set to the maximum available
power and deploys all servers to the Active Servers Buffer.
[0042] In sum, thus, FIGS. 2-4 represent a management system
including a graphical user interface (GUI) which enables user to
select one of the operating modes: 1) a manual configuration in
both active and inactive groups of servers which enables users to
set the configuration of the system according his/her current
needs; 2) a semi-automatic mode in both active and inactive groups
of servers which enables users to examine the said algorithm
generated power managed configuration before execution of the
configuration; and, 3) fill automatic mode which allows the said
algorithm generated configuration to be executed without any
intervention from the users.
[0043] Referring back to FIG. 1, the performance metric sensors as
described herein, provide for real-time monitoring of various
systems and run time parameters. That is, the mechanism to
automatically select the right mix of servers in various stages of
readiness in the Ready server buffer pool depends upon the
following monitored parameters including, but not limited to:
current workload (which may be determined by a workload sensor that
measures the intensity of incoming traffic, e.g., worldoad is
arriving at 300 client requests per second); customer SLAs
(application priority) which may be fixed parameters, usually
defined by a set of parameters (e.g., response time) and are
usually stored in memory or a database for reference; current
response time (which may be determined by a time sensor that
measures the amount of time it takes for the client to receive
service response after a request is issued from the most recent
request); number of available servers in various stages of
readiness, user priority and, environment temperature, etc. (which
data is kept in the Allocation Manager and is dynamically updated
to reflect the current allocation). Via the user interface provided
with the Allocation Manager, a user can assign weight to each of
the parameters to emphasize their relative importance. Furthermore,
the system dashboard provided in FIG. 2 enables an administrator to
project system performance for a specific allocation of servers (as
guidance for policy authoring). For example, if maximum power
saving is selected (e.g., 40%), the system may recommend 15 servers
out of 30 servers to be put in a server pool where 10 servers will
be in shutdown state, 2 in standby and 3 in hibernate mode. The
administrator however, must accept SLA violation probability of 10
to 20%. In the other extreme, if maximum SLA compliance is
selected, a power savings of 10% is achievable given the
probability of SLA violation is below 5%.
[0044] This power management system further includes a control
mechanism which enables user to select one of the following
operation modes: a) fully manual; b) user assisted automatic; and
c) full automatic mode. An additional full-powered mode is
additionally available.
[0045] In all operation modes, the power management system
continuously records SLA performance/violation data, server
performance statistics, server allocation as well as worldoad
condition as data to enable various machine learning or prediction
algorithm to continuously enhance its accuracy. For example, one
such algorithm implemented is the use of a utility function with
positive re-enforcement mechanism to enable maximum accuracy. For
example, increased accuracy =positive reward, and decreased
accuracy=negative reward. This utility function will eventually
converge to an optimal performance with minimum energy
consumption.
[0046] In the Active Servers Buffer where all the servers are
available for work, the power consumption state on each of the
servers can be modified from full available power to minimum power
by setting the power state of the processors (FIG. 4). This example
algorithm may make use of the system response time and SLA as the
factors in the analysis, however it is understood that the same
basic procedure can be applied to multiple parameters. A pseudocode
description of an example method that may be implemented by the
allocation manager is as follows:
TABLE-US-00001 For each server and application running in the
Active Servers Buffer If SLA target - current response time moving
average > delta { if server power state != minimum power state
set power state to the next lower state else if number of server
running application > 1 move server to Ready Buffer } else If
SLA target - current response time moving average < 0 { if
server power state != maximum power state set power state to the
next higher state else move a standby server from Ready Servers
Buffer to Active Servers Buffer } End
[0047] In the foregoing pseudocode description, "Moving average" is
defined as the average of data points in the specified time
elapsed. It is called moving average because it keeps changing as
time moves forward (for example, 5 minutes moving average of
temperature at 3:30 pm is the average of all temperature data taken
between 3:25 pm and 3:30 pm). Delta is a parameter determined by
the SLA. For example, such parameter can be defined as: the
response time must not exceed 25% of the agreed value more than 10
times in 5 minutes.
[0048] As mentioned, the response time parameter may be the sole
parameter to determine SLA violation and the optimal mix of servers
in various power states. However, it is understood mat other
parameters such as workload, queue length, etc. can be included in
the algorithm. Thus, alternatively, a weighted average approach may
be used such that:
P.sub.1*W.sub.1+P.sub.2*W.sub.2+P.sub.3*W.sub.3 . . .
P.sub.N*W.sub.N
where P.sub.1, P.sub.2, . . . , P.sub.N are parameters used and
[0049] W.sub.1, W.sub.2, . . . , W.sub.N are relative weights
assigned to each of the parameters with W.sub.1+W.sub.2 . . .
+W.sub.N=1. [0050] Then the foregoing pseudocode description
(algorithm) may be generalized as: [0051] Aggregate SLA parameters
Target--current weighted aggregate parameters moving
average>delta [0052] It is additionally understood that if only
response time is used, then W.sub.1=1, W.sub.2, W.sub.3 . . .
W.sub.N=0, the algorithm is defaulted to: [0053] SLA target
response time--current response time moving average>delta [0054]
as mentioned hereinabove.
[0055] In the Ready Servers Buffer, servers are distributed in each
of the different readiness states. For purposes of illustration,
there are three readiness states: standby state, hibernating state,
and powered off state representing maximum to minimum readiness.
For example, it takes typically a few minutes to power up a server
from a powered off state, and approximately 10 to 30 seconds from
hibernating state to a standby state. Maximum power saving can be
achieved if all the servers are in the complete powered off state,
but it takes a few minutes to bring a powered off server to the
standby state if there is an abrupt increase of workload, the few
minutes delay will result in serious violation of performance
target. To achieve maximum power saving and yet meet various
performance targets, an index is determined referred to as a
"Readiness Index" (RI, a real number from 0 to 1, where 0
represents minimum readiness and 1 represents maximum readiness).
This index is initially set to a value by the user or, may be at a
default of 1. As the system is used, this index will change
according to the sensor data feedback mechanism described herein.
One non-limiting example that may be implemented by the allocation
manager for allocating servers in the Ready Servers Buffer
according to the RI is provided in the pseudocode description as
follows:
TABLE-US-00002 If RI = 0, all servers in the Ready Servers Buffer
are in powered off state If RI = 1, all servers in the Ready
Servers Buffer are in the standby state/hibernating state N =
number of total servers in the Ready Servers Buffer N_off = Number
of powered off servers = N * ( 1 - RI ) N_standby = Number of
standby servers = N * RI / 2 N_hibernating = Number of hibernating
servers = N * RI / 2
[0056] The Readiness Index, RI, comprises a real number from 0 to
1, where 0 represents minimum readiness and I represents maximum
readiness. This index is initially set to a value by the user or at
a default of 1. In operation, this RI index will change according
to the feedback mechanism. From the Performance Metric, i.e., a
single parameter such as the response or transition time which is a
measure of the time it takes to recover from response time
violation to being in compliance with the SLA, a parameter referred
to as "Transition Time Interval" (TT), is defined as the time it
takes for the Allocation Manager to remedy a current SLA violation
alert by moving servers from the Ready Servers Buffer to the Active
Servers. In one example programming aspect that may be implemented
by the allocation manager, TT is kept to a minimum.
[0057] Thus, letting
TABLE-US-00003 M_min = time to move a standby server from Ready
Servers Buffer to Active Servers Buffer or minimum acceptable
delay; and, M_max = maximum delay interval (with all servers in
powered off state )
[0058] The following is an example pseudocode depiction of a method
employed for automatically configuring ready server buffer
readiness index:
TABLE-US-00004 If TT > M_max TT = M_Max If TT - M_min > 0 {
// increase readiness RT = RI + ( TT - M_min ) / M_max If RI>1
RI = 1; } Else { // decrease readiness RI = RI - ( TT - M_min ) /
M_max if RI < 0 RI = 0 }
[0059] More particularly, M_min and M_max are set as defined above,
RI is default to 1 or, an operator can select an initial value
between 0 and 1, with 1 being the maximum readiness and 0 for
minimum readiness, TT is set as described hereinabove.
[0060] The present invention has been described with reference to
flow diagrams and/or block diagrams or recitations of methods,
apparatus (systems) and computer program products according to
embodiments of the invention. It will be understood that each flow
and/or block of the flow diagrams and/or block diagrams, and
combinations of flows and/or blocks in the flow diagrams and/or
block diagrams, can be implemented by computer program
instructions. These computer program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, embedded processor or other programmable data processing
apparatus to produce a machine, such that the instructions, which
execute via the processor of the computer or other programmable
data processing apparatus, create means for implementing the
functions specified in the flow diagram flow or flows and/or block
diagram block or blocks.
[0061] These computer program instructions may also be stored in a
computer-readable memory that can direct a computer or other
programmable data processing apparatus to function in a particular
manner, such that the instructions stored in the computer-readable
memory produce an article of manufacture including instruction
means which implement the function specified in the flow diagram
flow or flows and/or block diagram block or blocks.
[0062] The computer program instructions may also be loaded onto a
computer-readable or other programmable data processing apparatus
to cause a series of operational steps to be performed on the
computer or other programmable apparatus to produce a computer
implemented process such that the instructions which execute on the
computer or other programmable apparatus provide steps for
implementing the functions specified in the flow diagram flow or
flows and/or block diagram block or blocks.
[0063] While the invention has been particularly shown and
described with respect to illustrative and preformed embodiments
thereof, it will be understood by those skilled in the art that the
foregoing and other changes in form and details may be made therein
without departing from the spirit and scope of the invention which
should be limited only by the scope of the appended claims.
* * * * *