DB2 10 for Linux on System z Using z/VM v6.2, Single System Image Clusters and Live Guest Relocation

70 DB2 10 for Linux on System z Using z/VM v6.2, SSI Clusters and LGR

7.1 Processor sharing

In a clustered environment where DB2 guests are being relocated, using ncapped shared

virtual processors is a useful technique for dynamically, triangularly, and automatically

managing idle processor capacity to accommodate unpredictable workloads.

Usually CP assigns each virtual machine with at least one virtual processor. CP then

allocates processor time to a virtual machine based on its SHARE setting, and by default

assigns each virtual machine the same share of processor time.

A general guideline is to define as many virtual processors as needed (maximum processor

resources required), but do not exceed the number of real processors assigned to this LPAR.

Extra virtual processors just add to the overhead and potentially increase the software

multiprocessing factors. For example, if the LPAR has four IFLs, then do not allocate five

virtual processors to a single Linux guest machine. If a situation occurs where the Linux guest

uses 100% of the processors, that will adversely affect the entire LPAR.

However, in an LPAR with four IFLs, you can assign three virtual processors to one Linux

guest and two virtual processors to a second Linux guest, as well as another two virtual

processors to a third Linux guest. All requests for processor cycles will be managed by z/VM

according to the relative priorities of the Linux guests. A processor configuration best practice

is to maintain the ratio of four active virtual processors to one logical processor allocated to

the LPAR.

But if the guest system operates at greater than 90% utilization for sustained periods, then we

can dedicate a processor for the guest. The system operator can then use the DEDICATE

command to dedicate virtual processors to real processors.

7.2 Dynamic processor allocation - share settings

During a DB2 guest relocation, it is suggested to recalculate the z/VM share setting in the

target z/VM cluster before the actual guest relocation. Share setting allows you to control the

priority that system resources are assigned to a Linux guest. These resources can include

processors, real storage, and I/O capability. An absolute or a relative share can be specified.

Special care needs to be taken when virtual guests are with a relative share, where they

receive access to system resources that are in proportion with respect to other virtual

machines with relative shares.

7.2.1 Share setting scenario

As an example, consider that we have two z/VM clusters (ITSOSS1 and ITSOSS2) with two

allocated processors. In ITSOSS1 we have two DB2 Linux guests (ITSOLNX1 and

Note: System operators need to dedicate the processor to a virtual machine only if they

are sure that a virtual machine can make full use of the processor.

Important: When a virtual machine is relocated, its current share settings may or may not

be appropriate on the destination system. Some thought should be given to what this

user's share should be on the new system, and the settings changed using the SET

SHARE command if necessary.