In this chapter, we provide some useful examples of HMC functionality, which ease the operations of virtualized SAP landscapes on PowerVM. If you are interested in further HMC capabilities, refer to:

The change from dedicated to shared resources is simple. It requires that you make a slight change in the existing profile and restart the LPAR. Prior to doing this, of course, you must have a policy for sharing the physical server (CEC = Central Electronic Complex) resources that supports the processing requirements of the combined load, according to the business need. This policy determines the relative weights, the guaranteed entitlements, and the virtual processor (VCPU) distribution.

Set VCPU requirements to a value that reflects the expected peak workload requirements. The entitlement depends on how much capacity you want to guarantee, how many partitions are set up, and how many physical processors are available in the shared processor pool. The weight determines your relative processing priorities: online over batch, production over non-production, and so on. Using the dynamic tools that we discuss in this chapter, you can also fine-tune this policy during the operation to address a different load. You can get an understanding of the LPAR requirements for each SAP system from the SAP Computer Center Management System (CCMS), Insight reports (9.6, “IBM Insight for SAP” on page 157), and other monitoring tools.

To change an LPAR from a dedicated to a SPLPAR, you must create a new profile or change the existing profile. In our example, we alter the existing profile, save it, and restart the partition:

The shown LPAR can later use up to one physical processor if enough resources in the shared pool are available with what corresponds to the setting in the dedicated setup before. In addition, we allow an increase to the amount of processor without a restart, for example when using scheduled DLPAR operations or adding new hardware (Maximum processing units and Maximum virtual processors). To later benefit from the implicit capping, which we introduce in 4.3, “Assigning implicit capping to LPARs” on page 33, we create it as uncapped, which is the recommended partition mode and type used for SAP environments with PowerVM.

The shared processor LPARs have two main flavors: those with strict resource definitions and those with flexible limits.

Strict resource definitions are achieved by defining the entitlement of the LPAR and capping the LPAR. The entitlement is the resource capacity that is guaranteed to the LPAR and is always available to it. Capping the LPAR restricts it from using any resources beyond this entitlement, and therefore the entitlement must be large enough to fulfill the processing requirements of the peak workload.

A shared LPAR that you define in this manner resembles a dedicated LPAR, with two exceptions: Other LPARs can use its resources when not used by their owner (more flexible than with dedicated shared partitions), and a fraction of processors can be assigned whereas Dedicated LPARS always require whole processors.

LPAR entitlements are in a sense reserved capacity: The sum of the entitlements of all of the SPLPARs sharing the pool cannot exceed the number of physical processors in the pool, which is the only way that the entitlements are guaranteed. Therefore, large LPAR entitlements limit the number of LPARs that can be active in the shared processor pool.

To achieve the best processor sharing, keep the entitlements small and the partitions uncapped. Uncapped partitions can utilize resources in the shared pool well beyond their guaranteed entitlement, which is the most common approach for combined SAP landscapes because the LPARs can adapt to the workload requirements, and the resource distribution can adapt to the various workload peaks in multiple LPARs. Of course this also leads to contention in the shared processor pool if workloads are heavily competing for resources. You have several options to enforce a priority policy and relative behavior of the LPARs, which are referred to as implicit capping. They provide a means to control the resource allocation, while still providing the flexibility and efficiency of resource sharing.

Most LPAR settings can be dynamically altered during runtime by DLPAR (dynamic LPAR) operations using the HMC. Using this functionality, you can manually change the behavior of the LPARs or schedule DLPAR operations using the HMC directly or by external tools.

The number of VCPUs that are available to a partition limits the number of whole physical processors that this LPAR can address, because one virtual processor represents at maximum one physical processor. The LPAR is therefore effectively capped at a maximum physical processor utilization that is equal to its number of configured VCPUs.

By reducing the LPAR weight, you do not actually cap the LPAR; instead, you reduce its ability to compete for additional resources above its actual entitlement. If there is no competition for these resources, the LPAR is only restricted by its number of configured VCPUs, which allows it to be both flexible and harmless to other workloads of higher priority (with greater weights).

The advantage of implicit capping versus explicit capping is:

Figure 4-4 on page 34 shows how to access the HMC panel to dynamically change the resources.

The HMC provides the possibility to schedule dynamic LPAR operations to add or remove processor and memory, and assign or unassign I/O devices at a defined period in time. You can use this scheduling to change the LPAR resource allocation, for example, to support an SAP mode change.

Earlier in this book, we discussed the advantages provided by the dynamic reconfiguration feature. In this example, we focus on dynamically changing resource allocation of the processor. To use this functionality for a specific LPAR:

This scheduling allows the LPARs to react on predictable load peaks. To give a small processor-based example, we look into a machine with an LPAR per time zone having predictable peaks during the day and low utilization during the night. Hence they have different load peaks moving from partition to partition. By changing the amount of virtual processors, we can ensure that batch processes during the night shift of an LPAR do not impact the performance of a partition running in day shift and better utilize the processor resources of the shared pool.

Multiple shared processor pools (MSPP) are useful in SAP landscapes in several ways, including the ability to segregate workloads and the ability to create subpools, which you can use to limit software license costs that are based on the number of available processors.

There are several IBM Redbooks publications available that describe in detail how you manage multiple shared processor pools. This section is an extract of the IBM Redpaper:

IBM System p Advanced POWER Virtualization (PowerVM) Best Practices, REDP-4194

Starting with the POWER6 technology-based systems, you can define multiple shared processor pools and assign the shared partitions to any of the MSPPs. Setting up this feature is rather simple because you only set the properties of a processor pool.

To set up a shared processor pool (SPP):

In a shared pool environment the Pool Utilization Authority (PUA) can be used to restrict the data, which can be monitored within an LPAR. This can be necessary for example in hosted environments, where customers should not be able to get information about the hosting system. On the other side monitoring of processor usage in SAP may require additional metrics from the processor pool. The table in 9.3, “Other monitoring tools” on page 117 shows which metrics are affected.

Unfortunately the HMC does not provide on any screen a setting explicitly named PUA or Pool Utilization Authority. Therefore we show in this short section how to change this setting.

Select in the HMC an LPAR and open the properties as in Figure 4-10:

On the Hardware Tab chose the page for Processors. PUA is enabled by setting the checkbox for "Allow performance information collection".

Starting with POWER7 technology-based systems and AIX 6.1 memory compression can be used and is named Active Memory Expansion (AME).

More details can be found in 8.5, “Active Memory Expansion for SAP systems” on page 84. AME can be enabled and configured on the HMC by setting the checkbox for Active Memory Expansion in the profile for an LPAR on the memory tab (see Figure 4-11 below):

On this tab you can set also the expansion factor. As you see in the example above the expansion factor of 1.5 leads to 6GB of expanded and 4GB of physical memory when the LPAR is started with this profile.

Switching AME On or Off requires a restart of the LPAR. On the other side the expansion factor can be modified without rebooting the LPAR by using DLPAR operations. On the HMC select in the LPAR list, Dynamic Logical Partinioning 'Memory' Add or Remove and change the value for the memory expansion factor (see Figure 4-12).

When AME is enabled, the operating system is switching off the support for 64K pages. If necessary you can turn on 64K memory pages again by changing the restricted vmo setting vmm_mpsize_support to 1. You can do this with the following command:

Simultaneous Multithreading (SMT) was introduced with POWER5 processors and started as two-way multithreading (SMT-2). With the POWER7 processor, four-way multithreading (SMT-4) was introduced. In addition to the POWER7 technology-based hardware, one of the following software levels is required as the minimum level to support SMT-4:

With operating system commands, you can switch Simultaneous Multithreading on or off, or you can select SMT-1 (= off), SMT-2, or SMT-4 directly. Changes to the SMT mode affect the whole partition. On AIX and Linux, changes to the SMT mode take effect immediately, on IBM i, the changes will take effect after an IPL of the partition. The following commands are used in the supported operating systems:

You can control the SMT mode with the smtctl command. To switch on SMT, execute the following command:

To switch off SMT, use the command:

In order to switch between the three SMT modes on a POWER7 technology-based machine, the command smtctl has been enhanced with another parameter to change the number of SMT threads. For example, in order to run the LPAR with four SMT threads you execute the following command:

You can control the SMT mode through system value QPRCMLTTSK. There are three possible values for that system value: Value 0 to turn SMT off, value 1 to turn SMT on to the highest available degree (SMT-2 on POWER6, SMT-4 on POWER7), and value 2 to let the operating system decide and dynamically change what level of SMT to use. Selecting SMT-2 explicitly on POWER7 technology-based systems is currently not supported on IBM i. To switch on SMT, enter the command:

To switch off SMT, enter the command:

You can control the SMT mode with the ppc64_cpu command with parameter --smt. You can select either on or off, or you can select the SMT mode directly. To switch on SMT, execute the command:

or:

To switch off SMT, execute the command:

or:

To select SMT-2 explicitly, execute the command:

To display the current SMT status, execute the command:

With the Hardware Management Console (HMC), you can define a compatibility mode in the LPAR profile. The compatibility mode allows LPAR migration between Power Servers running with different versions of POWER processors. Currently supported are the compatibility modes POWER6, POWER6+™, and POWER7. If you are running on POWER7 technology-based systems and switch the compatibility mode in the profile to POWER6 or POWER6+, you implicitly turn off the capability to run with four SMT threads. The following Figure 4-13 is showing where to change the compatibility mode in an LPAR profile on the HMC: