![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Before you start
This tutorial discusses the concepts of using IBM® WebSphere Extended Deployment (hereafter called WebSphere XD) as a quality of service extender in an enterprise's Web infrastructure. It shows a hands-on example on how to set up a WebSphere XD multi-cell routing scenario. The information in this tutorial is mainly based on WebSphere XD 6.0.2 on top of WebSphere Application Server ND 6.0.2.
This tutorial is intended for IT architects, who are familiar with WebSphere Application Server and would like to know how to improve WebSphere's infrastructure. It is for practitioners who need to configure the WebSphere XD multi-cell routing scenario.
Today, customers demand extraordinary availability of a company's Web infrastructure. Many business critical applications are hosted that require special attention, such as the Web-based stock trading application of a bank, or an insurance company's claims handling application. This enforces the need for a flexible, secure, and highly scalable infrastructure to achieve the quality of service desired by today's customers.
Generally, companies have structured (or even physically divided) their environments into different tiers. In today's architecture, you most likely see a middleware driven approach. This approach lets companies have a central tier where all their Web traffic flows in and is processed, and where other enterprise information systems are integrated through a various set of protocols. They often have tiers such as a demilitarized zone (also known as DMZ), a client tier (considered as a zone where external clients reside), and an enterprise information tier (host systems, databases, and so forth).
However, this tutorial focuses on the middleware tier. Having a more detailed look at this tier, you can see that the IBM WebSphere Application Server (hereafter called Application Server) stack resides here. The middle tier is further structured in different logical domains called "cells". As with the previously introduced multi-tier approach, there are several good reasons (technical and organizational) for dividing a company's, or even a corporate group's, WebSphere infrastructure in cells:
- In the case of 24/7 scenarios, the WebSphere infrastructure is structured into different manageable parts to achieve the highest possible availability.
- Considering disaster recovery, it is a best practice to split two geographically separated data centers also into two logical domains.
- From an operations point of view, it is a good idea to separate subsidiary companies within a corporate group.
At the edge of the middleware tier (an edge is considered as a point where transition from one tier to another takes place), there are most likely found other components, such as proxy servers. For example, the IBM HTTP Server, with its included Web server plugin, acts as a proxy. They are responsible for caching content, protecting the application servers from too much workload balancing. That is why these components are considered as quality of service (hereafter called QoS) drivers that help customers meet these high availability requirements for their Web applications. In some cases, a component with limited QoS features, such as a proxying Web server, might be sufficient. However, under many other circumstances, companies need an advanced set of QoS capabilities.
At this point, WebSphere XD comes into play as a quality of service extender. In this role, WebSphere XD introduces many new features summarized under the term "dynamic operations". One of these is the "on demand router" (ODR), which acts as an intelligent proxy that helps to achieve performance goals.
To give you an idea of this capability, let's assume that a company has three applications for its customers: stock trading, account management, and financial advice. Let's further assume that the stock trading application is the most important one; its users need the best performance. The rest of the applications is not that important. WebSphere XD lets you define specific performance goals for each of these applications (which adhere to your formally defined service level agreements), and tries to achieve these goals by content based routing, request flow priorization, and requeueing of user requests.
This tutorial helps you learn about the advanced QoS capabilities of WebSphere XD in a multi-tiered and multi-cell WebSphere infrastructure. The tutorial has two parts:
- The first part provides overview information about multi-cell routing, dynamic operations, and core core group bridge services.
- The second part provides step-by-step instructions to setup the core group bridge configuration between two WebSphere XD cells.
For more information about WebSphere XD, see WebSphere XD 6.1 Operations Optimization documentation.
The following section discusses the role of WebSphere XD in a multi-cell environment from a technical point of view. The multi-cell routing scenario is described from a high-level perspective.
Figure 1 is based on a real life customer environment.
Figure 1. WebSphere XD multi-cell scenario
The WebSphere XD use case mainly consists of three tiers which are named client tier, DMZ tier, and middleware tier. All end users, who use the infrastructure, are seen as part of the client tier (at this point we make no difference between intranet and internet applications). Their only way to access the company's Web infrastructure and its business applications is through security proxy (for example, WebSEAL that is part of IBM Tivoli® Access Manager), which is responsible for authenticating users and for controlling access to the backend ODR cell (Cell A). If this extra security is not needed, it is possible to put a normal proxy server in the DMZ. It is important not to place any WebSphere XD components in the DMZ. Though the documentation states that this is possible, we strongly discourage you to do this because WebSphere XD components are not yet hardened enough. Finally, the scenario defines a middleware tier where all of the company's WebSphere Application Servers and all WebSphere XD components reside.
As mentioned earlier, WebSphere XD acts as an edge of the tier, and therefore, has an important role in the scenario. Since the WebSphere XD cell is considered as the only entrance point (this is achieved by an appropriate firewall and security proxy configuration) to the variety of business applications installed in the other WebSphere XD cells, all Web traffic will flow through the on demand routers. Therefore, the whole stack of WebSphere XD's QoS capabilities is used. To set up the routing to your other WebSphere cells, you have to configure the "multi-cell routing". This enables your ODRs to receive routing information (service policies, work classes, and so on) and enables the automatic routing to foreign cells. To establish this cross cell communication, WebSphere's core group bridge service is used.
WebSphere XD dynamic operations overview
In the previous section, a real life scenario for multi-cell routing with WebSphere XD is described from a high-level point of view. This section covers the WebSphere XD configuration of the scenario in more detail.
The core component for the multi-cell routing scenario is the ODR, which is considered as an intelligent router. It is based on the WebSphere proxy server and controls HTTP/HTTPS traffic. In our scenario, the ODR is responsible for all Web traffic that is going to business applications in the other WebSphere cells. In addition of being a proxy, the ODR has special advanced capabilities of intelligent request routing:
- Request classification - The ODR classifies incoming requests according to existing routing policies, such as URLs that start with "/StockTradingApplication". This divides Web traffic into different categories, whereas each of these categories maps to a specific application in your environment. This is why this feature is considered the basis for the following ones.
- Flow control and queuing - Besides the request classification, the ODR is responsible for controlling the flow of requests, which allows it to change the request flow based on defined metrics.
- Prioritization - In contrast to changing the order of incoming requests (which is described by flow control), prioritization enables the ODR to apply a certain logic or ruleset on the request flow. For example, it can say that Request A is more important to achieve the overall business goals than Request B. Request A is routed first, even if Request B arrived earlier.
- Dynamic workload management - WebSphere Application Server has the option to define weights for backend application clusters, which lets you decide how much traffic (for example, 50/50 or 20/20/60) hits each cluster member. Such a decision is usually made according to the hardware equipment of each cluster members' underlying hardware box. However, the ODR continuously fetches health information from all the servers or cluster members it routes to, and finally assigns these weights dynamically. Because of that, the ODR enforces a better utilization of your hardware resources and protects your server from too much of a workload.
- Dynamic application placement - If you have a typical WebSphere environment, you think of clusters with a static number of WebSphere Application Servers belonging to it. But, what if X servers are not sufficient under certain load conditions? To tackle this limitation, WebSphere XD provides dynamic clusters. In comparison with "normal" WebSphere clusters that are static (you define the number of members and weights manually), dynamic clusters have the characteristic of a dynamic number of members. The number depends on the inflowing workload and the information of the ODR in front of the WebSphere cell. The ODR recognizes situations where the number of server instances has to be increased, and finally does this by contributing the information to its target WebSphere XD cells.
As mentioned earlier, the ODR needs metrics that define the goals it can achieve. The starting point for this is the service policy, which is similar to a service level agreement. Each policy sets performance goals (for example, average response time < 2 sec.) to meet certain business requirements. For example, one may define three service policies to establish different QoS standards: gold standard (avg. response time < 1 second), silver standard (avg. response time < 2 seconds) and bronze standard (avg. response time < 3 seconds). In summary, the service policies, together with the request classification, provide the basis for the ODR's routing decisions.
To establish the required mapping to the service policies, WebSphere XD
lets you define work classes for each WebSphere application. This
configuration option helps the ODR classify the request according to a
defined pattern (in the case of HTTP requests, a common pattern is
/myStockTradingApplication/*), and is
intended to group requests that require the same QoS. Finally, a work
class is tied to a specific service policy by an intermediary
component called transaction class.
To put everything together, Figure 2 gives a simplified overview on how the service policies and work classes are used by the ODR and how the routing is done.
Figure 2. ODR routing overview
After the request flow hits the ODR, it gets classified according to the defined work classes. In a multi-cell routing scenario, this configuration is shared even across WebSphere cell boundaries. The requests are buffered in different internal queues. In the next step, the router correlates the queued requests to the available service policies, and possibly changes the request flow to meet the performance goals. After the prioritization has taken place, the ODR dynamically routes the requests to the available target application servers. Note that Figure 2 shows the simplest case with equal weight for each server.
Core group bridge service overview
As discussed in the previous sections, the ODR needs different pieces of configuration (such as service policies and work classes) to fulfill its role as an intelligent router. The WebSphere XD configuration is usually made via the WebSphere Admin Console, and therefore stored in the cell's configuration repository. WebSphere XD has a dynamic configuration service called the bulletin board, which enables the cell-wide distribution of the configuration items. Under the hood, the WebSphere Distribution and Consistency Service (hereafter called DCS) is used for the underlying communication. You can imagine DCS as a mechanism to share information among components with a given QoS.
In our multi-cell routing scenario, things get more complicated since the routing information has to be shared across cell boundaries (and moreover, has to be published in a foreign bulletin board). As shown in the Real life scenario section, it is a best practice in an enterprise-wide environment to create a separate cell for the ODRs. Because of that, you need to establish a link between your cells, which makes it possible to share the configuration items between them. This link is created by using a core group bridge, which enables WebSphere cells to communicate with each other.
To understand the concept of a core group bridge, the term "core group" needs to be clarified. A core group is defined as a physical grouping of Java™ Virtual Machine (hereafter called JVM) processes in a WebSphere cell. By definition, such a core group is also considered as a high availability domain for specific services. By default, there exists one group per cell called DefaultCoreGroup, where all clusters, servers, node agents, and the deployment manager are members of that group. A core group bridge makes the JVM processes of different cells talk to each other and to share their configuration.
Figure 3 gives an overview of how the core group bridge configuration might look like when connecting two cells. Note that the diagram shows the setup from Cell A's point of view.
Figure 3. Core group bridge configuration example
Establishing a core group connection
For each core group bridge scenario, an access point group needs to be configured in each cell. This is a collection of core groups that communicate with each other. By default, there exists an access point group called DefaultAccessPointGroup that is also used in the following sections to setup the bridge. An access point group's purpose is to define the interfaces a cell exposes to others (called access points), and to define the foreign cells' interfaces (called peer access points). Therefore, the access point group configuration is considered the basis for core group bridging. In the example described in Real life scenario, we have one access point and two peer access points from the ODR cell's point of view.
As mentioned earlier, access points belong to a cell's access point group and define which interfaces are going to be exposed to other cells. More precisely, these interfaces are called bridge interfaces. The configuration of such an interface consists of a specific core group member. The hostname and port are acquired dynamically by WebSphere XD. Because of high availability (remember that a core group is considered as a high availability domain), a minimum of two bridge interfaces have to be defined per access point. Altogether, these are the entry points from a foreign cell's point of view.
In addition to the interfaces a cell exposes, the remote endpoints which belong to an access point group have to be specified. That is why a peer cell is represented by a peer access point, which defines the endpoints a foreign cell exposes. These are named peer ports and consist of a hostname plus a port pair. As with bridge interfaces, you must define a minimum of two peer ports (per peer access point) due to high availability reasons.
In the next section, you'll set up the multi-cell routing scenario.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular tutorial tags |
My tutorial tagsSkip to tags list
Popular tutorial tags |
My tutorial tags
