Self-optimizing functionality

AIX 5L Version 5.2 offers self-healing and self-optimizing functionality, such as dynamic CPU deallocation and reconfiguration. The system adapts automatically and dynamically to changes in the environment and reacts to disruptions appropriately.

DLPAR/DR

The concept of Dynamic Logical Partitioning (DLPAR) as a powerful new

functionality was introduced in AIX 5L Version 5.2. It provides flexibility in dealing with changing workload demands and enables the system administrator to add, move, and remove system resources like processors, memory, and I/O slots from one partition to another without the need to reboot the system or any partitions.

There are many benefits to using DLPAR. You can move processors from a test to a production partition in periods of peak demands or you can move memory to a partition that is doing excessive paging. Another possibility of using the DLPAR functionality is to move an infrequently used I/O device such as a CD-ROM between partitions. The concept of DLPAR is shown and explained in Figure 2-1. It emphasizes that all Dynamic Reconfiguration (DR) requests will be initiated from the Hardware Management Console (HMC).

Figure 2-1 Concept of Dynamic Logical Partitioning (DLPAR)

In this example, we want to move a processor from partition A to partition B. We choose, on the HMC, the Dynamic Logical Partitioning menu for partition A.

We then check the box Moving resource to a partition and define partition B as the destination partition. This is all the administrator has to do. The rest is done by the operating system itself automatically and works as follows.

The HMC informs partition A about the request to remove one processor from partition A. The resource will be freed by scheduling all processes to other CPUs and handed over to the hypervisor, which acts as a partition manager. Partition A informs the HMC about the successful resource reduction. It has now six processors left. Through a serial connection, the hypervisor gets reconfigured from the HMC. This means that the free processor will be configured in the partition definition of partition B. This LPAR is then informed by the HMC about the request to add a processor. Partition B configures the processor and reports back to the HMC that the addition of the resource has finished successfully. Processes running in partition B can now be scheduled to use this additional processor in addition to the CPU resources that existed before. This ensures a performance improvement in times of peak workload demands.

Depending on your partition profile and what the required, desired, and maximum values are for the partition in terms of CPUs, it is possible to move more than one resource at a time. This works similarly for adding, moving, and removing memory. For I/O adapters, the dynamic reconfiguration is not fully integrated in the dynamic reconfiguration framework. Before you can move I/O adapters, you have to manually deconfigure the I/O slot by first using AIX commands on that partition. For a detailed description, including screen shots, refer to the redbook AIX 5L Differences Guide Version 5.2 Edition, SG24-5765.

Most applications are not aware of the amount of resources on the system. They are called DLPAR-safe and are not affected by DLPAR operations. As expected, there are DLPAR-aware applications as well. Examples are databases, because they scale with the configuration, performance monitors, because they report resource statistics, and license manager. DLPAR-aware applications need to adjust to the use of the system resources. They need to handle changes in the system configuration.

The dynamic reconfiguration (DR) framework introduced in AIX 5L Version 5.2 is designed to be non-destructive, which ensures that at no stage of the dynamic reconfiguration process a failure of exchanging resources can cause harm to the operating system image. With DLPAR technology, there are additional features enabled, which include Dynamic Capacity Upgrade on Demand (DCUoD) and Dynamic CPU sparing.

Capacity Upgrade on Demand (CUoD)

The Capacity Upgrade on Demand feature offers a non-disruptive method of activating additional processors based on resource needs. This is built directly into certain models of IBM ^ pSeries, such as the pSeries 670 and 690.

Chapter 2. Enhancements in AIX 5L Version 5.2 17

To meet increasing workload demands, processors can be enabled dynamically. You can activate capacity in processor pairs only. It is a permanent activation and cannot be turned off. A keyed authentication based on CUoD Capacity Cards is necessary.

Static CUoD is available in SMP mode with AIX 5L Version 5.2. This requires a reboot of the system to change the number of licensed resources. Dynamic CUoD is available in LPAR mode, which does not require a reboot of the system or the affected partitions. DLPAR ensures that this operation is accomplished with no negative impact on the system. The main advantage of the CUoD feature is that customers can adjust easily to increasing workloads without requiring new servers.

Dynamic CPU Guard and CPU sparing

We differentiate between CPU Guard and CPU sparing. Both operations are considered to be DR operations. A processor reaching a pre-determined threshold is reported by Open Firmware. CPU Guard dynamically removes this failing processor. CPU sparing replaces the faulty processor dynamically. The spare processors are CUoD CPUs that are not licensed or activated with CUoD activation mode.

In conclusion, if you want to use Dynamic CPU sparing, you need to have an IBM

^ pSeries 690 or pSeries 670 in LPAR mode that has DLPAR-enabled firmware and is loaded with an appropriate CPU Capacity Card. The

replacement of CPUs is transparent to the user and the applications because no notification of reconfiguration will be sent to CPU Guard-aware or DR-aware applications. Using CPU sparing, you ensure performance and system availability for your pSeries server.