Browse Prior Art Database

A method for managing concurrent, overlapping system- and group-level power caps

IP.com Disclosure Number: IPCOM000198600D
Publication Date: 2010-Aug-10
Document File: 6 page(s) / 72K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for managing concurrent, overlapping system- and group-level power caps.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 6

Ȉ

Power-management applications like the IBM* Active Energy Manager (AEM) and the Hewlett Packard** (HP) Insight Power Manager (IPM) allow users to specify power caps on computer systems (e.g., rack-mount or blade servers). A power cap represents the maximum amount of power the system in question is allowed to consume. Having specified a cap for a given system, the firmware in that system will prevent the power consumed by that system from exceeding the cap value, using mechanisms like CPU or memory throttling to reduce power consumption when necessary.

    Power-management applications often allow a cap to be set not only on a system but on a group of systems, in which case the maximum power consumed by the group as a whole is limited to the specified value. A group cap can be useful when, for example, the group represents all the servers in a particular rack. Setting a cap for the group then has the effect of limiting the power consumed by the rack. Because many data centers specify a fixed power budget per rack, this is a valuable capability. Alternatively, a group might represent all the systems cooled by a given Computer Room Air Conditioner (CRAC) or group of CRACs. Because the power consumed by systems translates directly into heat, a limit on the power consumed by the group is dictated by the cooling capacity of the CRAC or CRACs in question. By allocating less power to a group, the user can not only save on energy costs, but can add more computing power to a data center that is constrained by the amount of power or cooling that is available to it.

    Group caps are enforced by allocating power to individual systems in the group to keep the aggregate power less than the group cap. This allocation may be a one-time, static allocation done at the time the group cap is established, or it may be updated dynamically over time in response to changing conditions (a technique often referred to as "power shifting"). Whether static or dynamic, the allocation of the group-level power limit to individual systems may be done in a naive manner, e.g., by simply dividing the overall limit by the number of systems and allocating the result to each system, or by more sophisticated methods that take into account the workloads on the individual systems. Regardless of the approach, the group-level cap is ultimately enforced by updating system-level caps on the individual systems in the group at discrete points in time.

    Though group capping is available today, existing implementations do not allow concurrent, overlapping system- and group-level power caps; i.e., given a system A, it is not possible to set a system-level cap for A and a separate group-level cap for a group of systems that includes A, nor is it possible to set separate caps for two different groups, each containing A. Some power-management applications (e.g., IPM and AEM) will, in fact, allow overlapping system- and group-level caps to be set, but the caps are not enforced concurrently...