Workload Charging By Soft-Capping To A Defined Capacity; Recommendations On Setting Up An Lpar Cluster - IBM Z9 Planning Manual

Processor resource/systems manager
Table of Contents

Advertisement

Workload Charging by Soft-Capping to a Defined Capacity

Workload charging introduces the capability to pay software license fees based on
the size of the LP the product is running in, rather than on the total capacity of the
CPC. The capability is enabled by the LPAR clustering technology of the System z9
servers together with the License Manager component of z/OS. Each LP is
assigned a defined capacity by the installation in terms of Millions of Service Units
(MSUs).
WLM helps ensure that the rolling 4-hour average CPU utilization for the LP does
not exceed this amount by tracking the CPU utilization for the logical partition. If the
4-hour average CPU consumption of the LP exceeds the defined capacity of the LP,
WLM dynamically activates LPAR capping (soft-capping). When the rolling 4-hour
average dips below the defined capacity, the soft-cap is removed.
WLM will not dynamically adjust the defined capacity for an LP. This is the
responsibility of the installation. If an LP consistently exceeds its defined capacity,
the license certificates and the defined capacity of the LP should be adjusted to
reduce the amount of time the LP is soft-capped. If you have a configuration where
the LP weights move significantly from one LP to another according to shift, then
you must license the products in each LP at the highest capacity that will be used
by that LP.

Recommendations on Setting Up an LPAR Cluster

v An LPAR cluster is a collection of two or more logical partitions, on a particular
v Identify logical partitions on the CPC that will be in the cluster (members of the
v IBM recommends allocation of shared CPs and enablement of WLM
v Establish an initial weight for each LP in the cluster. This will be the weight for
v Enable each LP in the cluster for WLM management.
v To enable DCM of managed channel paths for a logical partition, the name
v Calculation to estimate the number of cache structures that can be supported:
3-46
PR/SM Planning Guide
CPC, that are part of the same parallel sysplex. LPAR clusters do not span
CPCs as do parallel sysplexes. Though the member LPs of an LPAR cluster will
all be in the same parallel sysplex, all members of a parallel sysplex might not be
members of the same LPAR cluster. A given parallel sysplex can have member
LPs that belong to multiple LPAR clusters, each on a different CPC.
same parallel sysplex). A single CPC can have several LPAR clusters just as a
single CPC can have many LPs, each having membership in a different parallel
sysplex.
management for cluster members (see Note 1). The number of initially online
CPs should be maximized to provide optimum flexibility to WLM. The number of
reserved CPs defined should be the maximum allowed for an LP in your
configuration minus the number of initially online CPs. See "Number of Central
Processors" on page 3-28 for additional information on central processors.
the LP immediately after it is activated (see Note 2). Triple digit values should be
used, wherever possible, for initial weights because WLM reapportions weights
on a percentage basis. The total weight of the cluster will equal the sum of all the
initial weights of its member LPs. Leave the minimum and maximum weights
blank or make the range as wide as possible (optimally 1 to 999) to provide WLM
maximum flexibility as it distributes CPU resource among the cluster members.
specified on the IOCLUSTER keyword for managed channel paths in the IOCDS
must match the sysplex name of the software running in the logical partition. See
"Dynamically Managed CHPIDs" on page 2-27 for more information on the
IOCLUSTER keyword.

Advertisement

Table of Contents
loading

Table of Contents