Cisco UCS Manager CLI Configuration Guide, Release 2.0
Managing Power in Cisco UCS
Downloads: This chapterpdf (PDF - 511.0KB) The complete bookPDF (PDF - 7.82MB) | The complete bookePub (ePub - 1.25MB) | Feedback

Managing Power in Cisco UCS

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 domain
  • Policy-driven chassis-level power capping
  • Manual blade-level power capping

Rack Server Power Management

Power capping is not supported for rack servers.

Power Management Precautions

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

Power Policy

The power policy is a global policy that specifies the redundancy for power supplies in all chassis in the Cisco UCS domain. 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 Action Purpose
    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 # scope psu-policy  

    Enters PSU policy mode.

     
    Step 3 UCS-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 4 UCS-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 Action Purpose
      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 Action Purpose
        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 Action Purpose
          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 Action Purpose
            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 Action Purpose
              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 domain.

              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 Action Purpose
                Step 1 UCS-A# scope server chassis-id / server-id  

                Enters chassis server mode for the specified server.

                 
                Step 2 UCS-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 3 UCS-A /chassis/server # commit-buffer  

                Commits the transaction to the system configuration.

                 
                Step 4 UCS-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 Action Purpose
                  Step 1 UCS-A# scope server chassis-id / server-id  

                  Enters chassis server mode for the specified server.

                   
                  Step 2 UCS-A /chassis/server # show 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:
                      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 #