Chapter 1. IBM Enterprise Workload Manager Overview 13
These EWLM goal definitions are server and application agnostic. This means that hardware
and application upgrades can occur without requiring changes to the goals defined.
To prepare for developing a Domain Policy, the administrator should:
? Create a list of the instrumented applications to be managed in the EWLM Management
Domain. See “EWLM supported platforms and applications” on page 16 to identify
whether your application is supported in this release.
? Create a list of all the transaction types to be managed for each business application.
Assign a business goal and importance for each type of transaction based on your existing
SLA.
? Create a list of operating system platforms to be managed.
? Create a list of various processes on each of the managed platforms that will be
processing the transactional or non-transactional work and assign business goals and
importance.
? Group the transactions and processes based on the business goals and importance. This
will be the basis for the service class.
1.2.5 Instrumentation
Instrumentation provides the data to create the topology of a transaction, that is, what server
instances or application instances a transaction flows through. In a typical Web transaction,
for example “Buy Books,” the transaction starts at a Web server (edge server), flows to an
application server, then to a database server. Without instrumentation, the transaction would
look like three separate processes with three separate response times rather than one
transaction. This is key to EWLM, providing end-to-end topology views and statistics for
business transactions.
In order for EWLM to report on these transactions and potentially manage the domain based
on these statistics, Application Response Measurement 4.0 (ARM) has been implemented for
application instrumentation. ARM is an Open Group standard composed of a set of APIs that
can be used to collect response time information for enterprise applications. Currently there
are three types of applications instrumented with ARM 4.0: WebSphere Application Server,
DB2 UDB, and Web servers. ARM 4.0 supported middleware includes the following:
? DB2 UDB V8.2
? WebSphere V5.1.1
? WebSphere Plug-ins delivered with 5.1.1
For the correct plug-in releases, refer to the Web Servers section of the table at:
www.ibm.com/software/webservers/appserv/doc/v51/prereqs/was_v511.htm
? Independent IHS/Apache Web server ARM plug-ins
– Configures into IHS 2.0.42
Placed into the http serve/modules directory (minimum release tested)
Note: Customer-developed applications can be instrumented so that EWLM can
manage them. This requires using ARM 4.0, which is described in the next section,
“Instrumentation.”
Note: For applications that are not instrumented, EWLM provides process-based
management instead of transaction-based management.
14 IBM Enterprise Workload Manager
– Available from the Apache Web site
? Independent IIS Web server ARM plug-in
– Configures into IIS 5.0 and later
– ARM 4.0 support ships with IBM Virtualization Engine Suite for Servers
Let’s look at how ARM, EWLM, and instrumented applications work together to provide
end-to-end response times and application/transaction topology using correlation. Figure 1-7
has three EWLM managed servers and a domain manager in a EWLM domain. When a user
request is initiated, the transaction flows through the Apache, WebSphere Application Server
and DB2 middleware. The ARM instrumentation in each application layer is shown as a
arm_start_tran() and arm_stop_tran().
Figure 1-7 Transaction Correlation using EWLM, ARM, and Middleware
The arm_start_tran() call at each middleware layer indicates to the EWLM ARM
implementation the start of a transaction (or sub-transaction) instance, and therefore that
EWLM needs to record the transaction start time for the middleware service. The
arm_start_tran() call specifies ARM properties (also called filters) for the transaction instance
that the EWLM ARM implementation compares against service policy information to classify
the transaction instance to a particular transaction class and, consequently, a particular
service class. The service class, in turn, associates the transaction instance with a business
goal and relative importance to other work occurring in the EWLM domain.
The arm_stop_tran() call at each middleware layer indicates to the EWLM ARM
implementation the completion of a transaction (or sub-transaction) instance, and therefore
that EWLM needs to compute the response time for the transaction instance. The
arm_stop_tran() call also specifies a transaction completion status, such as succeeded or
Apache
arm_start_tran()
arm_stop_tran()
…..
EWLM ARM
Impl
Policy
User Request
{ARM
Corr #1}
Websphere
arm_start_tran()
…..
DB2 UDB
arm_start_tran()
arm_stop_tran()
…..
EWLM
domain
manager
EWLM ARM
Impl
EWLM ARM
Impl
Apache
data
data
Websphere
data
DB2 UDB
correlated
{ARM
Corr #2}
arm_stop_tran()
Chapter 1. IBM Enterprise Workload Manager Overview 15
failed, that the EWLM ARM implementation will include in its transaction completion data
capture.
The EWLM ARM implementation interacts with the EWLM managed server logic (not
depicted separately in this figure) to capture and send in-progress and completed transaction
data to the EWLM domain manager.
In this particular scenario in Figure 1-7, work arrives at the Apache server with no input
correlator, formally referred to as a parent ARM correlator. When arm_start_tran() is called
from the Apache server, the EWLM ARM implementation notices that there is no parent ARM
correlator, and performs classification to determine which transaction and service classes to
associate with the transaction instance. The EWLM ARM implementation also constructs and
returns an arm_start_tran() output argument child correlator, formally referred to as a current
ARM correlator, which reflects two key pieces of information:
1. Description of the Apache server as the first middleware hop in this transaction instance
processing.
2. The arm_start_tran() processing transaction classification result.
It is important to note that the classification action that occurs for the Apache server
arm_start_tran() call happens because no parent ARM correlator was specified as an input
argument. A transaction instance being processed by a middleware hop is considered to be a
transaction edge whenever no parent ARM correlator is available, and therefore the
transaction is classified by EWLM ARM processing.
The Apache server inserts the current ARM correlator received from its arm_start_tran() call
into the HTTP request header, and eventually transfers control to the WebSphere Application
Server to proceed with transaction instance processing. When the WebSphere Application
Server is prepared to process this transaction instance, it extracts the Apache server’s current
ARM correlator from its input HTTP header and specifies that as the parent ARM correlator
input argument on its arm_start_tran() call. This time, the EWLM ARM implementation
ignores filters specified on the arm_start_tran() call because of the parent ARM correlator,
and instead constructs an output argument current ARM correlator reflecting the following:
1. Description of the WebSphere Application Server as the second middleware hop in this
transaction instance processing.
2. The same transaction classification result that was reflected in the parent ARM correlator,
which is the result achieved by the Apache server.
Sometime following its arm_start_tran() call, the WebSphere Application Server determines
that the transaction instance requires a database query, and performs a JDBC call to the DB2
Universal Database™ server to accomplish this. The WebSphere Application Server current
ARM correlator is included in the JDBC control transfer protocol, and when the DB2 server is
prepared to process the query it extracts this correlator from JDBC input data and specifies
that as the parent ARM correlator input argument on the DB2 arm_start_tran() call. Again, the
EWLM ARM implementation ignores filters specified on the arm_start_tran() call because of
the parent ARM correlator, and instead constructs an output argument current ARM
correlator reflecting the following:
1. Description of the DB2 server as the third middleware hop in this transaction instance
processing.
Note: A hop is when a work request flows from one application to another. Hop 0 is the
place where an application is first assigned a correlator for the work request. Hop 0 occurs
at what is referred to as the
transaction edge.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.