WebSphere Extended Deployment enhances service
policy and workload management for the Compute Grid by providing a rule-based
service policy methodology, a new completion time service policy goal
type, and the ability to mix grid jobs and OLTP workloads in the same
WebSphere application server. The features of the Operations Optimization
component apply to the management of the Compute Grid environment when the
two components, Compute Grid and Operations Optimization, are deployed
together. You must have the Operations Optimization component installed
to define service policies. See the Operations Optimization Information
Center for more information on dynamic operations.
Refer to the WebSphere Extended Deployment Operations Optimization
Information Center for more information on defining service policies.
Service policy classification in WebSphere Extended Deployment Compute Grid is controlled by a
set of rules defined to the job scheduler. These rules can be composed
of Boolean expressions and can include the following operand types:
- Submitter identity
- Submitter group
- Job name
- Job class
- Application name
- Application type
- Platform
- Time
See Job classification in Compute Grid
for details
on each of the previous operands.
Goals types
- Discretionary goals indicate work that does not have significant
value. As a result, work of this type can see a degradation in performance
when resources are constrained.
- Average response time goals are indicative of work with a higher
priority than discretionary. The average response time goal is assigned
a specific time goal on the following panels.
- Percentile response time goals are another measure for work with
a higher priority than discretionary. The percentile response goals
are defined with specific criteria on the following panel. The percentile
response time target is the percentage of requests whose response
time is T or less that should be P or more; a target has particular
values for T and P.
- Completion time goals specify the maximum
amount of time (minutes) that is acceptable for a job to complete
and still maintain the level of service that the service policy implies.
Queue time goals are deprecated in Version 6.1. Completion time is
queue time plus execution time of a grid job. Completion time combined
with the importance associated with service policies ensure
that important jobs are dispatched first. All jobs are dispatched
immediately if there is capacity. This completion time goal type is
used only when there are more jobs than what can be processed immediately.
The attempt is to get the job completed by completion time, and not
just get dispatched. The application placement controller (APC) assesses
the historical date for a job and dispatches the job based on that
data. For example, if completion time is set to 30 minutes, and from
historical date the APC knows that the job takes 30 minutes to complete,
then this job will be dispatched right away. The class of a job is
important when predicting the performance characteristics of batch
jobs. The APC design is such that the system assumes that a job in
class A will have (broadly) the same performance characteristics
as other jobs in class A.
Default classification rules and precedence
WebSphere
Extended Deployment V6.1 provides two default classification rules:
- A rule that assigns any job of type Java 2 Platform Enterprise
Edition (J2EE) to the transaction class defined by the named J2EE
application's default IIOP work class.
- A rule that assigns any job to the default transaction class,
DEFAULT_TC
Both default rules can be edited and deleted. The order
of the rules can be modified, and user-defined classification can
be added. The job scheduler evaluates the list of classification rules
in order and assigns the transaction class specified by the first
matching rule. Only one classification rule set per cell is supported
in WebSphere Extended Deployment Version 6.1. A default configurable
transaction class, named DEFAULT_TC by default, is associated with
this set. If none of the classifications rules match a job, then the
default transaction class is applied to that job. Graphical user interface
(GUI) support for choosing a transaction class from a drop-down list
while building a rule is only present in the presence of Operations
Optimization package. In a Compute Grid only environment there is
a text field where a transaction class name is specified.