The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter includes the following sections:
Power capping is not supported for rack servers.
If the CIMC is reset, the power monitoring functions of Cisco UCS become briefly unavailable for as long as it takes for the CIMC to reboot. While this usually only takes 20 seconds, there is a possibility that the peak power cap could be exceeded during that time. To avoid exceeding the configured power cap in a very low power-capped environment, consider staggering the rebooting or activation of CIMCs.
Configuring the Power Policy
The power policy is a global policy that specifies the redundancy for power supplies in all chassis in the Cisco UCS instance. This policy is also known as the PSU policy.
For more information about power supply redundancy, see Cisco UCS 5108 Server Chassis Hardware Installation Guide.
The following example configures the power policy to use grid redundancy and commits the transaction:
UCS-A# scope org / UCS-A /org # scope psu-policy UCS-A /org/psu-policy # set redundancy grid UCS-A /org/psu-policy* # commit-buffer UCS-A /org/psu-policy #
Configuring the Global Cap Policy
The global cap policy is a global policy that specifies whether policy-driven chassis group power capping or manual blade-level power capping will be applied to all servers in a chassis.
Any change to the manual blade-level power cap configuration will result in the loss of any groups or configuration options set for policy-driven chassis group power capping.
UCS-A# scope power-cap-mgmt UCS-A /power-cap-mgmt # set cap-policy manual-blade-level-cap UCS-A /power-cap-mgmt* # commit-buffer UCS-A /power-cap-mgmt #
Configuring Policy-Driven Chassis Group Power Capping
When policy-driven power chassis group power capping is selected in the global cap policy, Cisco UCS can maintain the oversubscription of servers without risking costly power failures. This is achieved through a two-tier process. At the chassis level, Cisco UCS divides the amount of power available between members of the power group. At the blade level, the amount of power allotted to a chassis is divided between blades based on priority.
Each time a service profile is associated or disassociated, UCS Manager recalculates the power allotment for each blade server within the chassis. If necessary, power from lower-priority service profiles is redistributed to higher-priority service profiles.
UCS power groups cap power in less than one second in order to safely protect data center circuit breakers. A blade must stay at its cap for 20 seconds before the chassis power distribution is optimized. This is intentionally carried out over a slower timescale to prevent reacting to transient spikes in demand.
Note |
The system reserves enough power to boot a server in each slot, even if that slot is empty. This reserved power cannot be leveraged by servers requiring more power. Blades that fail to comply with the power cap are penalized or shut down. |
A power group is a set of chassis that all draw power from the same power distribution unit (PDU). In Cisco UCS Manager, you can create power groups that include one or more chassis and then set a peak power cap in AC watts for that power grouping.
The peak power cap is a static value that represents the maximum power available to all blade servers within a given power group. If you add or remove a blade from a power group, but do not manually modify the peak power value, the power group adjusts the peak power cap to accommodate the basic power-on requirements of all blades within that power group.
A minimum of 3788 AC watts should be set for each chassis. This converts to 3400 watts of DC power, which is the minimum amount of power required to power a fully-populated chassis.
If insufficient power is available, Cisco UCS Manager raises an alert.
Note |
Creating a power group is not the same as creating a server pool. However, you can populate a server pool with members of the same power group by creating a power qualifier and adding it to server pool policy. |
Make sure the global power allocation policy is set to Policy Driven Chassis Group Cap.
The following example creates a power group called powergroup1, specifies the maximum peak power for the power group (10000 watts), adds chassis 1 to the group, and commits the transaction:
UCS-A# scope power-cap-mgmt UCS-A /power-cap-mgmt # create power-group powergroup1 UCS-A /power-cap-mgmt/power-group* # set peak 10000 UCS-A /power-cap-mgmt/power-group* # create chassis 1 UCS-A /power-cap-mgmt/power-group/chassis* # commit-buffer UCS-A /power-cap-mgmt/power-group/chassis #
The following example deletes a power group called powergroup1 and commits the transaction:
UCS-A# scope power-cap-mgmt UCS-A /power-cap-mgmt # delete power-group powergroup1 UCS-A /power-cap-mgmt* # commit-buffer UCS-A /power-cap-mgmt #
Cisco UCS uses the priority set in the power control policy, along with the blade type and configuration, to calculate the initial power allocation for each blade within a chassis. During normal operation, the active blades within a chassis can borrow power from idle blades within the same chassis. If all blades are active and reach the power cap, service profiles with higher priority power control policies take precedence over service profiles with lower priority power control policies.
Priority is ranked on a scale of 1-10, where 1 indicates the highest priority and 10 indicates lowest priority. The default priority is 5.
For mission-critical application a special priority called no-cap is also available. Setting the priority to no-cap prevents Cisco UCS from leveraging unused power from that particular blade server. The server is allocated the maximum amount of power that that blade can reach.
Note |
You must include this policy in a service profile and that service profile must be associated with a server for it to take effect. |
The following example creates a power control policy called powerpolicy15, sets the priority at level 2, and commits the transaction:
UCS-A# scope org / UCS-A /org # create power-control-policy powerpolicy15 UCS-A /org/power-control policy* # set priority 2 UCS-A /org/power-control policy* # commit-buffer UCS-A /org/power-control policy #
Include the power control policy in a service profile.
The following example deletes a power control policy called powerpolicy15 and commits the transaction:
UCS-A# scope org / UCS-A /org # delete power-control-policy powerpolicy15 UCS-A /org* # commit-buffer UCS-A /org #
Configuring Manual Blade-Level Power Capping
When manual blade-level power capping is configured in the global cap policy, you can set a power cap for each blade server in a Cisco UCS instance.
The following configuration options are available:
You can specify the maximum amount of power that the server can consume at one time. This maximum can be any amount between 0 watts and 1100 watts.
No power usage limitations are imposed upon the server. The server can use as much power as it requires.
If the server encounters a spike in power usage that meets or exceeds the maximum configured for the server, Cisco UCS Manager does not disconnect or shut down the server. Instead, Cisco UCS Manager reduces the power that is made available to the server. This reduction can slow down the server, including a reduction in CPU speed.
Make sure the global power allocation policy is set to Manual Blade Level Cap.
The following example limits the power usage for a server to 1000 watts and commits the transaction:
UCS-A# scope server 2/4 UCS-A /chassis/server # set power-budget committed 1000 UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server # show power-budget Power Budget: Committed (W): 1100 Oper Committed (W): Disabled UCS-A /chassis/server #
The following example shows the server power usage:
UCS-A# scope server 2/4 UCS-A /chassis/server # show stats mb-power-stats Mb Power Stats: Time Collected: 2010-04-15T21:18:04.992 Monitored Object: sys/chassis-1/blade-2/board Suspect: No Consumed Power (W): 118.285194 Input Voltage (V): 11.948000 Input Current (A): 9.900000 Thresholded: Input Voltage Min UCS-A /chassis/server #