HP ML150 HP Power Capping and Dynamic Power Capping for ProLiant servers techn - Page 24

Subtleties of power capping - ilo part number

Page 24 highlights

Subtleties of power capping Avoiding power capping conflicts within groups IPM is a powerful tool for setting and managing power caps across defined groups of servers, including SIM collections. It is important to remember, however, that except for Enclosure Dynamic Power Capping, power caps are ultimately set at the individual server level. A group power cap set through IPM is simply apportioned as individual power caps to all of the servers in the group. Power capping is also completely non-hierarchical. A power cap set using IPM has no precedence over a power cap set using the iLO interface. Each server simply conforms to the last power cap that it received, regardless of the method by which it was set. For example, consider a server that is a member of two distinct SIM collections. If a group power cap is applied to each of these collections, servers that are in both collections will have individual power caps that reflect the later collection to have a power cap applied. Similarly, if the iLO interface is used to set a power cap on an individual server, it will replace the previous power cap for that server, even if it was part of a group with its power cap set through Insight Power Manager. Since Insight Manager sees a group power cap as a simple aggregation of individual power caps, changing the power cap of an individual server will eventually be reflected in the number displayed for a group power cap in Insight Power Manager. A similar situation can occur when setting enclosure dynamic power caps for groups of enclosures using IPM. Once a group power cap has been apportioned to the individual enclosures, those individual enclosure caps can be overwritten by setting a new cap on a single enclosure through its Onboard Administrator. This potential overlap in setting power caps is important to take into account when planning and implementing an overall power capping/capacity management strategy. Conflicts can best be avoided by choosing a single consistent method for setting power caps. For example, a system administrator could define a set of non-overlapping SIM collections used specifically for power and cooling management. Powering-up groups of servers when using Dynamic Power Capping HP Dynamic Power Capping is a powerful tool for controlling the steady-state power consumption of servers in real time. However, it does not control the power consumption of servers at start-up. If a group of servers on the same PDU are powered up simultaneously, there will be a window during start-up before Dynamic Power Capping is online when the servers determine their maximum power consumption and will draw close to their maximum power at roughly the same time. If this peak is too large, it may cause problems. To prevent this from occurring, it is important to manually power on these server groups in a staggered manner. In the case of auto power-up situations, this staggered power-up can be achieved by enabling the servers' Power On Delay and setting it to ―Random up to 120 seconds.‖ This is accomplished through the iLO interface or through the enclosure OA for BladeSystem servers. Setting low or unattainable power caps on servers In theory, a power cap can be set to any value that is above the minimum power consumption for a given server or a group of servers. However, setting power cap values close to the minimum power consumption is not good practice since maintaining a power cap at or near this level prevents the server from accomplishing meaningful work. Additionally, a server's minimum power consumption level may rise over time due to a number of causes, including increases in fan activity as data center temperatures rise or the hot-add of disk drives to the server. This can result in a situation where a power cap becomes unachievable since it has become lower than the minimum power consumption 24

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26

24
Subtleties of power capping
Avoiding power capping conflicts within groups
IPM is a powerful tool for setting and managing power caps across defined groups of servers,
including SIM collections. It is important to remember, however, that except for Enclosure Dynamic
Power Capping, power caps are ultimately set at the individual server level. A group power cap set
through IPM is simply apportioned as individual power caps to all of the servers in the group.
Power capping is also completely non-hierarchical. A power cap set using IPM has no precedence
over a power cap set using the iLO interface. Each server simply conforms to the last power cap that
it received, regardless of the method by which it was set.
For example, consider a server that is a member of two distinct SIM collections. If a group power cap
is applied to each of these collections, servers that are in both collections will have individual power
caps that reflect the later collection to have a power cap applied. Similarly, if the iLO interface is used
to set a power cap on an individual server, it will replace the previous power cap for that server, even
if it was part of a group with its power cap set through Insight Power Manager. Since Insight
Manager sees a group power cap as a simple aggregation of individual power caps, changing the
power cap of an individual server will eventually be reflected in the number displayed for a group
power cap in Insight Power Manager.
A similar situation can occur when setting enclosure dynamic power caps for groups of enclosures
using IPM. Once a group power cap has been apportioned to the individual enclosures, those
individual enclosure caps can be overwritten by setting a new cap on a single enclosure through its
Onboard Administrator.
This potential overlap in setting power caps is important to take into account when planning and
implementing an overall power capping/capacity management strategy. Conflicts can best be
avoided by choosing a single consistent method for setting power caps. For example, a system
administrator could define a set of non-overlapping SIM collections used specifically for power and
cooling management.
Powering-up groups of servers when using Dynamic Power Capping
HP Dynamic Power Capping is a powerful tool for controlling the steady-state power consumption of
servers in real time. However, it does not control the power consumption of servers at start-up. If a
group of servers on the same PDU are powered up simultaneously, there will be a window during
start-up before Dynamic Power Capping is online when the servers determine their maximum power
consumption and will draw close to their maximum power at roughly the same time. If this peak is too
large, it may cause problems. To prevent this from occurring, it is important to manually power on
these server groups in a staggered manner. In the case of auto power-up situations, this staggered
power-up can be achieved by enabling the server
s’
Power On Delay and setting it to
Random up to
120 seconds.
This is accomplished through the iLO interface or through the enclosure OA for
BladeSystem servers.
Setting low or unattainable power caps on servers
In theory, a power cap can be set to any value that is above the minimum power consumption for a
given server or a group of servers. However, setting power cap values close to the minimum power
consumption is not good practice since maintaining a power cap at or near this level prevents the
server from accomplishing meaningful work. Additionally, a server’s minimum power consumption
level may rise over time due to a number of causes, including increases in fan activity as data center
temperatures rise or the hot-add of disk drives to the server. This can result in a situation where a
power cap becomes unachievable since it has become lower than the minimum power consumption