Managing Power in Cisco UCS\n
Download this chapter
Managing Power in Cisco UCS\nManaging Power in Cisco UCS\n
 Feedback

Managing Power in Cisco UCS

This chapter includes the following sections:

Power Management in Cisco UCS

You can manage power through Cisco UCS Manager by configuring any of the following features:

  • Power supply redundancy for all chassis in a Cisco UCS instance

  • Policy-driven chassis-level power capping

  • Manual blade-level power capping

Rack Server Power Management

Power capping is not supported for rack servers.

Configuring the Power Policy

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.

Configuring the Power Policy

Procedure
 Command or ActionPurpose
Step 1UCS-A# scope org org-name  

Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

 
Step 2UCS-A /org # scope psu-policy  

Enters PSU policy mode.

 
Step 3UCS-A /org/psu-policy # set redundancy {grid | n-plus-1 | non-redund}  

Specifies one of the following redundancy types:


  • grid —Provides power redundancy when two power sources are used to power the chassis. If one power source fails, the surviving power supplies on the other power circuit continue to provide power to the chassis.

  • n-plus-1 —Balances the power load for the chassis across the number of power supplies needed to satisfy non-redundancy plus one additional power supply for redundancy. If any additional power supplies are installed, they are recognized and powered off.

  • non-redund —Balances the power load for the chassis evenly across all installed power supplies.

For more information about power redundancy, see the Cisco UCS 5108 Server Chassis Installation Guide.

 
Step 4UCS-A /org/psu-policy # commit-buffer  

Commits the transaction to the system configuration.

 

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

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.

We recommend that you use the default power capping method: policy-driven chassis group power capping.
Important:

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.

Configuring the Global Cap Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-A# scope power-cap-mgmt  

Enters power cap management mode.

 
Step 2 UCS-A /power-cap-mgmt # set cap-policy {manual-blade-level-cap | policy-driven-chassis-group-cap}  

Sets the global cap policy to the specified power cap management mode.

By default, the global cap policy is set to policy driven chassis group cap.

 
Step 3 UCS-A /power-cap-mgmt # commit-buffer  

Commits the transaction to the system configuration.

 
The following example sets the global cap policy to manual blade power cap and commits the transaction:
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

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.

Power Groups

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.

Instituting power capping at the chassis level requires the following:

  • IOM, CIMC, and BIOS version 1.4 or higher

  • 2 PSUs

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.

Once a chassis is added to a power group, every service profile associated with that chassis also becomes part of that power group. Similarly, if you add a new blade to a chassis, that blade inherently becomes part of the chassis' power group.

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.

Creating a Power Group

Before You Begin

Make sure the global power allocation policy is set to Policy Driven Chassis Group Cap.


Procedure
 Command or ActionPurpose
Step 1 UCS-A# scope power-cap-mgmt  

Enters power cap management mode.

 
Step 2 UCS-A /power-cap-mgmt # create power-group power-group-name  

Creates a power group and enters power group mode.

 
Step 3 UCS-A /power-cap-mgmt/power-group # set peak {peak-num | disabled | uninitialized}  

Specifies the maximum peak power (in watts) available to the power group.

 
Step 4 UCS-A /power-cap-mgmt/power-group # create chassis chassis-id  

Adds the specified chassis to the power group and enters power group chassis mode.

 
Step 5 UCS-A /power-cap-mgmt/power-group/chassis # commit-buffer  

Commits the transaction to the system configuration.

 

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 #

Deleting a Power Group

Procedure
 Command or ActionPurpose
Step 1 UCS-A# scope power-cap-mgmt  

Enters power cap management mode.

 
Step 2 UCS-A /power-cap-mgmt # delete power-group power-group-name  

Deletes the specified power group.

 
Step 3 UCS-A /power-cap-mgmt/power-group/chassis # commit-buffer  

Commits the transaction to the system configuration.

 

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 #

Power Control Policy

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.

Creating a Power Control Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-A# scope org org-name  

Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.

 
Step 2 UCS-A /org # create power-control-policy power-control-pol-name  

Creates a power control policy and enters power control policy mode.

 
Step 3 UCS-A /org/power-control-policy # set priority {priority-num | no-cap}  

Specifies the priority for the power control policy.

 
Step 4 UCS-A /org/power-control-policy # commit-buffer  

Commits the transaction to the system configuration.

 

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 #
What to Do Next

Include the power control policy in a service profile.

Deleting a Power Control Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-A# scope org org-name  

Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.

 
Step 2 UCS-A /org # delete power-control-policy power-control-pol-name  

Deletes the specified power control policy.

 
Step 3 UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

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

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:

Enabled

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.

Disabled

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.

Setting the Blade-Level Power Cap for a Server

Before You Begin

Make sure the global power allocation policy is set to Manual Blade Level Cap.


Procedure
 Command or ActionPurpose
Step 1UCS-A# scope server chassis-id / server-id  

Enters chassis server mode for the specified server.

 
Step 2UCS-A /chassis/server # set power-budget committed {disabled | watts}  

Commits the server to one of the following power usage levels:


  • disabled —Does not impose any power usage limitations on the server.

  • watts —Allows you to specify the upper level for power usage by the server. If you choose this setting, enter the maximum number of watts that the server can use. The range is 0 to 10000000 watts.

 
Step 3UCS-A /chassis/server # commit-buffer  

Commits the transaction to the system configuration.

 
Step 4UCS-A /chassis/server # show power-budget  

(Optional) Displays the power usage level setting.

 

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 #

Viewing the Blade-Level Power Cap

Procedure
 Command or ActionPurpose
Step 1UCS-A# scope server chassis-id / server-id  

Enters chassis server mode for the specified server.

 
Step 2UCS-A /chassis/server # show stats mb-power-stats  

Displays the power usage statistics collected for the 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 #