Super cluster solution, part 1th: Tips for Maximizing the application's scalability

Brief introduction

For most enterprise software topologies, application scalability is an important quality of service. To achieve scalability, enterprise-class Java™ee applications are typically deployed and executed in the IBM WebSphere application Server network deployment cluster. However, the actual size of the cluster is limited. What if the size of the cluster is not enough to handle the required application load?

This 2-part series describes a useful technique for maximizing application scalability in the WebSphere application Server, which we call the Super cluster. The first part of this series describes the "super cluster" techniques that will be applied to HTTP Plug-ins and WebSphere Proxy Server. Part 2nd will discuss the DMZ Secure Proxy Server for WebSphere application Server, IBM WebSphere Virtual Enterprise on Demand Router (ODR), and IBM We Bsphere EXtreme Scale.

Cluster

To achieve scalability, enterprise-class Java EE applications are typically deployed and executed in a cluster of WebSphere application Server Network Deployment (hereafter referred to as network deployment). The client requests routing across the cluster, so the workload is allocated between all application server processes.

Figure 1. Client requests distributed among cluster members

Affinity (Affinity)

If the application is designed in a stateless manner, the request is routed to any network Depoloyment cluster member that contains the deployed application (no request affinity). However, according to protocol and application programming, client requests can have a affinity with a particular network deployment cluster member. For example, an HTTP session might be created in a cluster member that handles the first request, so all subsequent requests for that client should be sent to the same cluster member. The affinity examples include the affinity of HTTP session and HTTP protocol, the affinity of SIP session and SIP protocol, the IIOP of transactional affinity, and so on. Most router components can maintain relative affinity when forwarding requests to cluster members (application servers).

Failover

In addition to scalability, deploying applications to network deployment clusters can provide high availability. If one of the cluster members fails, the router can pass the client request to an application on another cluster member. Using the session failover mechanism provides a transparent failover mechanism when an HTTP or SIP session occurs.

Management

Although it is theoretically possible to use a non-clustered network deployment instance to gain scalability in the aforementioned pattern, the use of the network deployment cluster provides a significant management advantage. Applications in the clustered network deployment instance are simplified for startup, stop, install, uninstall, or update compared to applications deployed in a network deployment instance. In fact, the management of an application deployed in a non-clustered network deployment instance is an error-prone process.

Cluster size limit

IBM WebSphere Application Server V6.0 introduces a component called the High Availability Manager (HAM). This component also provides a new configuration property called the core group. Although discussion of the high Availability manager and all related features is beyond the scope of this article, the core group building rules have an impact on the limits of cluster size, so you need to have a basic understanding of the core groups:

Core Group

The core group refers to a static high-availability domain that contains a tightly coupled set of WebSphere application Server processes. Each process in the WebSphere application Server cell is a member of the core group. The core group processes establish a network connection to each other and use these connections to monitor and determine whether a process is running, or fails. All members of the core group are connected to each other in a mesh topology, as shown in Figure 2.

Figure 2. WebSphere application Server process in the core group

Tight coupling between JVMS provides a low message latency (only one network jump between any members) and fast fault detection. However, the fully interconnected topological structure also restricts the scalability of the core group greatly. As a result, the core group cannot scale as much as the cell does, and the larger cell needs to be divided into multiple core groups. Depending on the communication requirements of a particular WebSphere application Server environment between core groups, the core group bridging services (core team bridge Service,cgbs) need to be connected together.

Figure 3. Multiple core groups in a large WebSphere cell

Core Group Building Rules

A well built core group should be created in accordance with the core group building rules, as described in the WebSphere application Server information Center (reference resources). One of the building rules shows that a WebSphere application Server cluster cannot exceed a core group. In other words, all members of the cluster must be members of the same core group. This rule means that the maximum size of the WebSphere application Server cluster is potentially limited by the maximum size of the core group.

Figure 4. The cluster must be a subset of the core group