82 IBM Enterprise Workload Manager
4.2 Setup function of the Control Center
This section describes how to set up the domain policy that defines the performance goals for
the workload running in your management domain. Work running in a multi-tiered
heterogeneous environment can be categorized into
transactions and processes. For both
transaction- and process-oriented work, EWLM provides reporting based on performance
goals defined in a service policy, which is similar to a service level agreement. Before going
into the details of how to set up your policies, let’s get familiar with some terminology first.
You are already familiar with the concept of a
management domain, a heterogeneous
environment comprised of a collection of managed servers and a domain manager. In this
environment, the
domain manager is the central point of control for a domain.
A management domain defines the environment in which a service policy runs. Only one
service policy is active in a management domain at any given time and this policy applies to
all managed servers in the domain. If no user-defined service policy has been activated, the
domain runs with a Default service policy.
Domain policy
You can think of a domain policy as a contract which prescribes how EWLM should treat
“work” within a management domain. This treatment may include how the work should be
classified, prioritized, managed, reported, and so forth.
A domain policy is a collection of service policies, applications, transaction classes, service
classes, and optionally platforms and process classes for an EWLM management domain.
The structural view of the components is shown in Figure 4-3. In the following sections we
look at each component in turn and describe the relation of these components to each other.
Figure 4-3 Structural view of domain policy
Service policy
A service policy describes the business performance objective and the business importance
of work running in a heterogeneous installation. It describes the business view of workloads
and ties it to the reporting and implicit management of the workloads. It does not contain any
explicit linkage to server topology or middleware. You can have several service policies that
Chapter 4. Administering EWLM 83
identify different performance objectives intended for different times. For example, you might
have one service policy for weekday processing and another one for month-end processing.
Similar to a service level agreement contract, a service policy is defined by a name and
consists of service classes, transaction classes, process classes, and optionally, defined
workload.
While you can define multiple service policies depending on your installation objectives,
service classes typically are the same for multiple policies. They usually differ in their goal
settings only. However, in many cases a single service policy is sufficient.
Generally, all transactions running in the management domain will be assigned to a service
class, whether a default service class for an application environment or an EWLM service
class. There is only one set of transaction classes and process classes in a Domain Policy.
You can assign these transaction classes and process classes to the multiple service policies
within the Domain Policy.
As shown in Figure 4-4, you can have multiple service policies defined in the domain policy,
representing different objectives for your enterprise. In this illustration, both service policies
(weekend and week day) share the same service classes (Web banking and Stock sales); the
only difference is that the performance goal for the service classes is slightly different to
represent the different performance objective.
Figure 4-4 Service policy
84 IBM Enterprise Workload Manager
Service class
A service class is a central concept to EWLM and represents a group of work that has similar
performance goals or business requirements. You must define a specific goal as well as an
importance factor. A service class contains only one goal and one importance factor. The
supported performance goals are the following:
? Percentile Response Time: What percentile of work requests should complete in a
specified amount of time. The specified value is given as a percentage. The time value
can be in hours, minutes, seconds, and microseconds.
? Average Response Time: The average amount of time in which work in the service class
should complete. It is specified in hours, minutes, seconds, or microseconds.
? Velocity: Defines how fast work should run relative to other work requests when ready,
without being delayed for CPU, storage, and I/O. Velocity goals are intended for work for
which response time goals are not appropriate. In particular, this is the case for all kinds of
processes which are not instrumented, such as server processes, daemons, or long
running batch-like work. The following are some velocity type values:
–Fastest
–Fast
– Moderate
–Slow
–Slowest
? Discretionary: Low priority work for which you do not have any particular performance goal
or importance. EWLM processes discretionary work using resources not required to meet
the goals of other service classes. It is used for workloads whose completion time is
unimportant.
In addition, you must also specify how important it is to your business that the assigned goal
is met through the
Importance factor. Importance plays a role only when a service class is not
achieving its goal. For instance, resources may be taken away from a less important service
Tip: While it should not be a performance issue, we recommend that you limit the number
of service classes to reflect real differences in performance objectives. This will be good
positioning for later, when EWLM introduces the management functions. It is hard to be
precise at this point in time, but we suggest that a good rule of thumb is to limit your service
classes to around 30 for ARM transactional work. If you have hundreds of service classes
in mind, you might be trying to micro-manage the environment.
The number of transaction and process classes should be limited to what is meaningful
and manageable from a reporting perspective. The number of service classes should be
limited to the classes of work that have distinguishably different performance objectives. If
considering usage of more than 100 transaction, process, or service classes, start
monitoring memory and processor usage on the domain manager as the configuration
approaches 100 managed servers.
Regarding transaction classes, what it important from a performance point of view is the
number of transaction classes active on each server. If there are lots of transaction classes
in the policy, but only a few are active on each server, there should not be much of a
performance impact. On the other hand, if there are lots of transaction classes with every
transaction class active on every server there might be a performance impact.
Start with simple policy and grow as required.
Chapter 4. Administering EWLM 85
class in order for a more important service class to achieve its goal. You can specify five
levels of importance settings:
– Highest
–High
–Medium
–Low
–Lowest
Workload
An optional feature of the EWLM Control Center is workload. It is used to group a set of
service classes that you want to put together for reporting purposes.
Before continuing with further descriptions, let’s consider Figure 4-5, which shows an
example of how all these pieces are related to each other.
Figure 4-5 Relationship between the main elements and the domain policy
Given the illustrated business objective, how do we associate an individual transaction with
the correct business goal (service class)? Classification describes how work is assigned to
service classes. You have one set of classification definitions for a management domain.
Classification consists of transaction classes and process classes. Transaction classes are
grouped according to the application, while process classes are grouped by the platform.
Transaction class
Transaction classes
are used to group transactions which have the same goal or which are
reported together and are mapped to service classes. The classification of transactions into a
transaction class is done through the use of rules. Complex rule sets can be built, consisting
of multiple nested rules, in order to accurately classify transactions. The classification rules
are specific to each application environment.
An application must be ARM-instrumented in order for it to be monitored by EWLM as an
application. It is the starting point for classification of transactions into transaction classes.
For example, WebSphere Application Server, HTTP Server, and DB2 are examples of
applications which are ARM-instrumented. In future releases of EWLM there will be many
more applications that are ARM-enabled. For the first release of EWLM all applications which
Domain Policy
Service Class:
Trade
Service Class:
Reporting
Service Class:
Portfolio
Service Class:
Financial
Workload
A
Workload
C
Workload
B
90% in 2 sec
Imp: High
90% in 4 sec
Imp: High
Velocity: Slow
Imp: Low
Velocity: Slow
Imp: Low
same as weekday
same as weekday
Velocity: Fast
Imp: High
Velocity: Fast
Imp: High
Service Policy
Weekday
Service Policy
EndOfMonth
86 IBM Enterprise Workload Manager
are not ARM-instrumented can still be monitored – but as process classes rather than
transaction classes.
You can use transaction classes to not only define which work should be assigned to a
service class, but also to define which work within a service class you would like to
specifically monitor. Transactions that are not classified to a transaction class are then
assigned to the default transaction class and service class. A one-to-one mapping of
transaction classes to service classes is possible, as is mapping multiple transaction classes
to one service class.
Process class
A process class is similar to a transaction class and defines a group of system processes
intended for reporting and management according to a service class. A process class
monitors work requests that a system initiates, whereas a transaction class monitors work
requests that users initiate from an application. Non-ARM instrumented transactional and
application servers have to be monitored as process classes.
You can map several process classes to the same service class. The classification of
processes into a process class is done through the use of rules. These classification rules are
specific to each platform. You cannot map a process and a transaction class to the same
service class. The mapping is mutually exclusive, which means you either map a process
class
or a transaction class to a service class.
Rules
Rules
provide a way to identify and to classify the transaction or process classes to which
work belongs. They consist of a filter type, a filter value, and an operation to apply to the filter
type-value pair to determine if there is a match.
The key is to configure the filtering granular enough to reflect the business goals in the
classification of the transactions. This involves defining the filters at a granular enough level
within both the transaction classes and process classes. The level of filtering depends on your
environment. Table 4-2 gives a summary of the filter types you can use to classify process
workloads for all supported operating systems of your managed servers. Following that is a
list of the filter types you can use to classify transaction workloads.
Table 4-2 Process filters
Note: Non-ARM instrumented transactional and application servers have to be monitored
as part of a process class.
Filter Name AIX Windows OS400 Solaris
EWLM: ClusterName Yes Yes Yes Yes
EWLM: Hostname Yes Yes Yes Yes
EWLM: Management Domain Name Yes Yes Yes Yes
EWLM: OS Level Yes Yes Yes Yes
EWLM: OS Platform Yes Yes Yes Yes
EWLM: System Name Yes Yes Yes Yes
Executable Path Yes Yes No Yes
Username Yes Yes No Yes
Groupname Yes No No Yes
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.