 | Level: Intermediate Wilfred Jamison, Ph.D. (wjamison@us.ibm.com), Software Engineer, IBM
Ann Black-Ziegelbein (annblack@us.ibm.com)IBM
22 Feb 2005 In this article, Part 6 in the series about designing and implementing an on demand solution, discover IBM® On Demand Operating Environment capabilities for monitoring and improving performance of business processes. Get detailed information about the features of IBM WebSphere® Extended Deployment 5.1 and find out how it can help you optimize usage of your IT resources. And learn how WebSphere Extended Deployment 5.1 can prioritize and load balance requests intelligently, allowing you to use it to achieve high-performance, on demand business processes.
Introduction
Previous articles in this series feature several facets of on demand computing, including:
- Integration of disparate applications using the Enterprise Service Bus (ESB)
- Development of business processes using Business Process Execution Language (BPEL)
- Optimization of business operations with provisioning of resources
- Communication of business-related events from BPEL applications through the Common Event Infrastructure (CEI)
In previous articles in this series, you learn about application development and
integration, business resilience, and performance monitoring. In this article, you get a different approach to optimizing on demand business process
performance using WebSphere Extended Deployment 5.1.
We focus on basic concepts and capabilities of the product and show you how
to incorporate WebSphere Extended Deployment 5.1 into the odFinance solution architecture. The odFinance application suite consists of the personal loan, customer enrollment, portfolio management, and online trading. We also highlight the on demand operations of WebSphere Extended Deployment.
Simplify management with WebSphere Extended Deployment
WebSphere Extended Deployment 5.1 builds upon WebSphere Application Server Network Deployment (Version 5.1.1) capabilities, offering enterprise-class qualities of service that help simplify management of complex environments while optimizing existing resources. WebSphere Extended Deployment consists of three key areas that work together to deliver an automated, high-performance, goals-driven environment:
- On demand operations
- The WebSphere environment becomes a virtual pool of resources that can be shared among multiple applications. These applications are associated with service-level goals and importance levels that can align with business goals. The goals, in turn, are used to dynamically adjust the resource provided to each application, allowing them to scale during unpredictable increases in demand. The result is better utilization of existing resources and reduced total cost of ownership.
- Extended manageability
- These capabilities simplify the management of the WebSphere Extended Deployment environment, allowing more time for employees to focus on the
business and less on managing infrastructure. WebSphere Extended Deployment provides new operations management views in the WebSphere administrative console for displaying the performance of the environment according to service-level goals. WebSphere Extended Deployment can monitor the health of the environment according to configurable health policies detailed to a customer's environment. When unhealthy situations are detected, alerts can be dispatched to notify administrators before a problem causes outages in the environment.
- High-performance computing
- Encompasses a programming model and runtime components that can offer near-linear scalability for high-end transaction processing. Provides high-availability services that help make WebSphere Extended Deployment autonomic managers highly available, enhancing the qualities of service for your business applications.
 |
Create on demand solutions with WebSphere Extended Deployment 5.1
This section defines on demand concepts and illustrates them by showing how we configured our odFinance applications.
In typical WebSphere Application Server environments, individual clusters of servers can host a common set of one or more applications, as shown in Figure 1.
Each cluster must be set up to handle worst-case scenarios for potential load, to ensure that when peak load occurs, enough
resources are available to the cluster to meet the demand. This planning requirement, however, can cause the cluster's resources to be under utilized. If more load comes into the cluster than what is expected, the cluster can become resource constrained and cause all requests to slow down (or potentially fail), including the ones with the most stringent response-time requirements.
Figure 1. Common network deployment configuration
The on demand solution provided by WebSphere Extended Deployment is two-fold. First, it provides a mechanism that routes and prioritizes application requests according to their assigned service policies (see Assign service-level goals and importance). Second, it provides a virtualized environment where resources can be combined into a common pool that applications can share. When applications that have varying workloads share this common pool, better utilization can be achieved. In some cases, the shared pool is even capable of supporting more applications than the resources individually assigned could provide, as shown in Figure 2.
Figure 2. WebSphere Extended Deployment configuration
Virtualize the WebSphere Extended Deployment environment with node groups and dynamic clusters
Unlike standard clusters, WebSphere Extended Deployment clusters can dynamically change in size, and hence, are called dynamic clusters. An autonomic manager called the Application Placement Controller (APC) decides when to start new dynamic cluster members and where to place the members. To decide how many members should be started, APC takes into account the cluster's load, and the nodes' CPU capacities and memory sizes. The APC also determines the optimal location for a new cluster member. And the APC can stop cluster members that are underutilized to make room for a member of a different dynamic cluster whose load has increased. In WebSphere Extended Deployment, administrators can control the set of resources (nodes) that a dynamic cluster can use to place its members.
For example, a given dynamic cluster should only place member instances on a subset of the nodes in the cell because the application running in that cluster requires access to a network resource accessible only from that set of nodes. We introduce a new configuration concept we call node groups to allow administrators to confine dynamic clusters to a subset of nodes. With WebSphere Extended Deployment, administrators can divide the nodes in their cell into node groups and create dynamic clusters to be hosted on the node groups. The APC interprets node groups as a resource pool that can be shared by all the dynamic clusters assigned to that node group. Currently, with WebSphere Extended Deployment, each node can only belong to one node group at a time. Applications are mapped to this node group (resource pool) by creating a dynamic cluster to be hosted on the node group and installing the application onto the dynamic cluster (similar to installing an application to a standard WebSphere cluster).
On demand router
The on demand router (ODR) is an intelligent proxy server for a given WebSphere Extended Deployment cell. It receives all incoming HTTP and HTTPS traffic to
the WebSphere Extended Deployment cell and routes it accordingly to an appropriate back-end application server. In addition to its basic proxy capabilities, the ODR provides the following core functions:
- Automatically discovers the cell configuration reacting to cluster members' start or stop events
- Classifies incoming requests based on a defined or default service policy
- Continuously monitors the request performance for each class of
traffic and produces statistics that the WebSphere Extended Deployment console displays
- Estimates the CPU capacity of each node in the cell and the CPU demand for each class of request
- Prioritizes the incoming requests according to their response time goals and business importance
See Classifying incoming requests to service policies using ODR for a more detailed discussion.
Use WebSphere Extended Deployment topology for odFinance
This section describes how to configure and set up
odFinance using WebSphere Extended Deployment 5.1. We cover the topology, nodes, node group, and dynamic clusters, followed by the applications we installed in the Extended Deployment cell.
Unfortunately, WebSphere Extended Deployment 5.1 has no support yet for BPEL processes running on WebSphere Business Integration Server Foundation, so it was not possible to federate WebSphere Business Integration Server Foundation servers with WebSphere Extended Deployment features. However, these four BPEL applications call several Web services using SOAP/HTTP:
- Customer Relationship Management services (CRM)
- Credit Check service (CC)
- Stock Quote services (SQ)
- Market Analysis services (MA)
Because these Web services are going to be called as heavily as the BPEL processes, it makes sense to deploy them in a WebSphere Extended Deployment cell. The topology is shown in Figure 3.
Meanwhile, the four odFinance applications are installed in a WebSphere Business Integration Server Foundation server. Alternatively, we could have also federated them in a WebSphere Application Server Network Deployment cluster or
installed each application on separate WebSphere Business Integration Server Foundation servers. Figure 3 also shows the front end, which is a set of portlets that call the odFinance applications using SOAP/HTTP.
Figure 3. Top-level topology of odFinance configuration
From the figure, we created one node group containing four WebSphere Application Server Base 5.1.1.1 servers. The odFinance applications send SOAP requests over HTTP to the ODR. We named our node group odFinanceNodeGroup, as shown in Figure 4, where the administration console shows the four servers. Using this node group, we created four dynamic clusters: MarketAnalysis, StockQuote, CreditCheck, and CRM. We used this naming convention to reflect in which dynamic cluster each Web service is going to be deployed.
Figure 4. Node group and dynamic clusters for odFinance
We define a dynamic cluster by navigating through Servers > Dynamic Clusters > New in the Administration console.
Figure 5 shows a top-level snapshot of the CRM dynamic cluster definition. We set the minimum number of instances to three because
CRM is the most common service called by the four odFinance applications; the other clusters are set to a minimum of two.
Meanwhile, the maximum number is set to unbounded in all clusters and the operation mode is set to automatic.
Figure 5. Dynamic cluster definition
Application servers and installed applications
The creation of dynamic clusters results in the creation of application servers in each node of the odFinanceNodeGroup -- one application server per dynamic cluster.
Since we created four dynamic clusters on a node group of four nodes, 16 application servers are created, as shown in Figure 6.
The naming convention used by WebSphere Extended Deployment 5.1 for an application server is <Dynamic Cluster Name>_<node name>.
Figure 6. Application servers created in the cell
We deployed all four services into the cell, with one application per dynamic cluster. We used our naming convention to determine
in which cluster to deploy an application. For instance, CRMService is deployed on the CRM cluster, and so on. Figure 7 shows the list of all installed applications in our WebSphere Extended Deployment cell. The four Web services are CRMService, CreditCheckService, MarketAnalysisService,
and StockQuoteService. They are only partially started because not all of the application servers in their respective dynamic clusters are started.
Figure 7. Installed enterprise applications
Assign service levels and importance to applications
Applications are assigned service-level goals and importance by using service policies.
Service policies are made up of three main parts: a goal, an importance, and a mapped workload.
The service policy goal can be one of three types:
- Average response time
- Specifies the average response time in which all the mapped workload should respond by
(for example, 800 milliseconds). It's a good goal type to use when all the workloads have similar response times.
- Percentile response time
- Configured by providing a percentile and a response time. Good for workloads that have some outlying response times that could skew the average response time. Specifies the percentage of requests that must respond within a certain response time threshold (for example, 80% at 800 ms).
- Discretionary
- Treat the work as best effort. This is meant for work that is of low priority and lowest importance.
Discretionary goal types do not have an associated goal value.
When setting the goal value for the average response time and percentile response time, the goal should be the maximum acceptable response time amount for this particular class of service and not how fast the workload should respond. Performance-based service policy goals are not intended to take the place of performance tuning and testing of the application.
The importance level of the service policy can be one of seven levels: Highest, Very High, High, Medium, Low, Very Low, and Lowest.
Importance is used in times of resource contention when trade-offs between levels of service must be made. The discretionary goal automatically has the lowest level of importance.
Transaction classes and service policies
The workload that is mapped to a service policy is defined as a transaction class. Each service policy can have one or more transaction classes
and can be moved from service policy to service policy as long as they
only belong to a single service policy at any one point in time. The transaction class is a mapping of Uniform Resource Identifier (URI) patterns from a particular Java™ Platform, Enterprise Edition (J2EE) application and module pair.
A transaction class can consist of URI patterns from multiple J2EE applications or module pairs. An application can have URI patterns split among multiple transaction
classes -- and therefore service policies -- as long as the URI pattern only belongs to one transaction class at a time.
For example, assume that the StockQuote service has URI patterns of /stockquote/quote/* and /stockquote/trade/*. We can assign /stockquote/quote/* to a transaction class
named StockQuote_QuoteWorkload that is mapped to a service policy of medium importance named Bronze, while we have the URI pattern /stockquote/trade/*
assigned to a transaction class named StockQuote_PlatinumWorkload mapped to a service policy of higher importance named Platinum.
By having the workload defined in a separate configuration construct (the transaction class) instead of defining it directly to the service policy,
we allow for finer-grained monitoring of the service policy. We also gain the capability to introduce scripts into the environment to move transaction classes
among service policies, depending on the scheduling scheme. All requests are considered to have a default service policy until they are mapped to a specific configured service policy.
The default service policy has a goal type of discretionary and is treated as best effort.
Back to the odFinance applications: We defined four service policies that are platinum, gold, silver, and bronze, as shown in Figure 8. All of them use average response time as the criterion. The importance of each policy is correlated with the goal.
Figure 8. Service policies defined for odFinance
A service policy can be applied to any transaction from any deployed application. A transaction is defined in terms of a URI. To specify the service policy of a transaction, you include that transaction in the transaction class of the
target service policy, as follows:
- Navigate to Operational Policies > Service Policies.
- Click the target service policy (for example, Platinum Service).
- Under Transaction Classes, click New.
- Provide a name for this transaction class and a description. Click Next.
- Under Define Transaction Class Memberships, choose the enterprise application, such as CRM.
- Select Module (for example, CRMWebService.war).
- From the left panel, choose all the URIs you want to be assigned with this service policy. Click Add, and they should all move to the right panel, as shown in Figure 9.
- Click Next, and then Finish.
Figure 9. Creating a transaction class for a service policy
Classify incoming requests to service policies using ODR
The on demand router is the key element in WebSphere Extended Deployment that implements the on demand operations. This section provides details about how it works. The on demand operations architecture is shown in Figure 10. As requests enter the ODR, they become classified by matching the incoming URI to a URI pattern defined in the transaction class. The most exact match maps the request to a transaction class. For example, two unique URI patterns map to two different transaction classes: /StockQuote/trade/* maps to transaction class StockQuote_Workload, and /StockQuote/trade/sell* maps to transaction class StockQuote_SellWorkload. Assume that the ODR also received a request for the URI of /StockQuote/trade/sell.jsp. The URI /StockQuote/trade/sell.jsp matches both URI patterns defined in StockQuote_Workload and StockQuote_SellWorkload transaction classes. However, it will be mapped to StockQuote_SellWorkload since it is a more exact match of its URI pattern.
Where two transaction classes are misconfigured to have the exact same URI pattern, the first most exact match will map the request. Since the transaction class can only be associated with one service policy at a time, a service policy can be obtained and thus, the request can be classified. If no transaction class contains a URI pattern that reveals a match, the request will be mapped to the default transaction class and the default service class.
Figure 10. On demand operations architecture
Dispatching classified requests
Once classified, the request is placed in a queue based on its classified service policy. The queues are dynamically created as new service policy classifications are discovered. These queues are managed by an autonomic manager called the Application Request Flow Manager (ARFM). The ARFM has two components: a gateway and a controller. The gateway acts on each request and queues and dispatches requests. The gateway keeps track of the number of outstanding requests that each cluster executes at any given time, enforcing a maximum number of outstanding requests for each cluster. By controlling and limiting the maximum number of requests concurrently executing on each cluster, the gateway prevents the nodes from being overloaded. When traffic is light, few requests execute concurrently on each cluster and the gateway dispatches arriving requests without queuing. When the traffic load increases, the number of concurrently executing requests running on each cluster reaches the maximum and requests begin to queue in the gateway. In this case, when a new request arrives, it is added to the queue corresponding to the request service class. When a previously dispatched request completes its execution, the gateway selects a new request from the queue and dispatches the request for execution. The gateway uses a weighted round-robin discipline to select requests from queues.
The ARFM controller computes the weights and the maximum concurrency limit used by the gateway. The controller continuously monitors the requests response and execution times on the servers. It also monitors the request intensities and other resource metrics such as CPU utilizations. The controller uses the monitoring data to tune the parameters of a queuing model, and it computes the optimum gateway settings to achieve the performance goals given the current system load and observed behavior. The controller runs periodically (by default every 60 seconds). Gateway queues have a configurable maximum depth and once the queue reaches the maximum limit, the requests will be turned away.
Dynamic workload management for dispatched requests
The ARFM monitors the outstanding concurrent requests and limits the number of concurrently dispatched requests to only what the available application servers are capable of processing. This prevents the back end from inadvertently being overloaded. Once the request is dispatched from the ARFM, it is routed to an appropriate application server.
We use the Work Load Manager (WLM) component in the ODR to decide which cluster member should receive a given request. The WLM is a load balancer that maintains a table of active server instances and dispatches to these instances by a weighted round-robin algorithm. The servers are given weights of 0 to 20. A weight of 0 means no traffic will be routed to the server. The requests are balanced across the application's servers in proportion to the weights of the servers. For example, server A has a weight of 20 and server B has a weight of 10. Twenty requests will be dispatched to server A and 10 to server B every 30 seconds. We use an autonomic manager called Dynamic Workload Manager (DWLM) to compute the weights associated with these back-end application servers. DWLM runs periodically and uses past observation of the execution time behavior of requests on each server to compute the server weights. DWLM continuously updates server weights to equalize the service times of the request across all the application servers in the same cluster.
|
Summary
In this article, you learned about the features and capabilities of WebSphere Extended Deployment Version 5.1. This technology can extend an existing WebSphere Application Server cluster to one that is capable of delivering high-performance, on demand computing.
With its on demand operations, WebSphere Extended Deployment can prioritize and load-balance requests more intelligently. As a result, you get improved transaction performance and optimized resource utilization. It also allows you to define service policies to establish performance expectations of specific transactions.
Stay tuned
The next article in this series highlights the extended manageability feature of WebSphere Extended Deployment 5.1, which
includes performance and health monitoring, visualization, notification, and more.
Resources
About the authors | 
| | Dr. Jamison currently works on incubation projects for the IBM On Demand Development and Strategy team. He is an expert of Performance Analysis/Engineering for J2EE applications and has numerous publications and
presentations on the subject matter. He is currently working on Business Process Management for On Demand Systems. You can reach him at wjamison@us.ibm.com. |
| 
| | Ann Black-Ziegelbein is a member of the WebSphere Technology Institute at IBM. She leads the design and implementation of Operations Management for WebSphere Extended Deployment. Ann recently published the book IBM WebSphere Application Server for Distributed Platforms and z/OS: An Administrator's Guide. Contact Ann at annblack@us.ibm.com. |
Rate this page
| |
