IBM Enterprise Workload Manager Release 1

Chapter 4. Administering EWLM 89

Before building a domain policy, developing an accurate understanding of your workload is a

fundamental step. We highly recommend that you plan time to analyze your workload: this

helps ensure that the best filtering and classification can be applied and the work managed to

the utmost efficiency according to the business needs within your installation. The following is

a sample methodology you can follow to identify and classify your workload.

Assessment

Start the classification of your workload by identifying all the business functions within the

management domain. List them in business terms rather than technical ones. Interview your

business function analyst with the objective of building the list of your applications with their

business goals and their level of importance to your business. If you have a formal service

level agreement, that would be a good starting point. If not, the application administrators

should have an idea of what is “good,” what is “bad,” and the relative importance of the

business functions.

Once you build the business application list, the next step is to be able to identify each

application to EWLM so that the classification of work and consequently the assignment of

the performance goals can be performed. To complete this task, you will probably need to

interview the application developer or the application manager to understand how the

application flows and its starting point.

For transactions, you need to identify what the edge server is. The

edge server is the entry

point of the application into the management domain, meaning the first hop, where the

classification takes place. So, for example, the Trade application consists of a set of HTTP

requests that will arrive at the Web server: in this case the Web server represents the edge

server where the EWLM classification takes place. To be able to recognize these HTTP

requests as part of the Trade application, you need to provide some transactions filters that

EWLM will use to match the incoming requests. If a match occurs, then the HTTP request

belongs to the Trade application. So, once you identify your transactions through the filtering

mechanism, you can associate them to a service class that implicitly means a performance

goal. This goal should represent the business goal provided by your SLA.

Beside transactions, your application probably has some processes that require classification

to EWLM, for example, utilities. Processes are platform specific, so for each of them you need

to identify on which platform they run and how to classify them through the filtering provided

by the platform. Once you have this information, with the help of the system programmer, you

can assign a service class and the related performance goal to the process.

Now that you collected all the information about your applications, you are ready to define

your service policy. There are different ways to proceed. We recommend that you take

advantage of the sample policies EWLM provides. In the following sections, we describe the

Default policy and the Sample policy. We consider these policies a good starting point, and if

they do not differ a lot from your target environment, you might consider copying and adapting

one of these policies to your needs. This should limit the amount of effort required to build

your initial policy.

4.2.2 The Default and Sample policies

EWLM provides a Default domain policy that is deployed automatically until a user-defined

policy is deployed in the installation. Figure 4-7 shows the default setup when you complete

EWLM installation. When you are running under the default domain policy, it is important to

understand that all work is assigned to a discretionary goal. Once a domain policy is

deployed, the default domain policy cannot be activated again, but its components – like

transaction classes and so forth, are available to be included in new domain policies.