IBM BPM, V8.0.1, All platforms > Tuning > Advanced tuning

Clustered topology tuning: Apply a data-driven scaling methodology

In general, there are two primary reasons to consider when evaluating moving to a clustered topology from a single-server configuration: scalability or load balancing to improve overall performance and throughput, and high availability or failover to prevent loss of service due to hardware or software failures.

Although not mutually exclusive, there are considerations applicable to each. This information, however, focuses is on the performance-related aspects of clustering, and not on the high availability aspects.

Ideally, it is possible to scale up a topology arbitrarily to match the required load. The WebSphere Application Server Network Deployment (ND) infrastructure provides this capability. However, effective scaling still requires that standard performance monitoring and bottleneck analysis techniques be used.

The following considerations apply. It is assumed that additional cluster members imply additional server hardware.

• If you are deploying more than one cluster member (JVM) on a single physical system, it is important to monitor not just the resource utilization (CPU, disk, network) of the system as a whole, but also the utilization by each cluster member. This allows the detection of a system bottleneck due to a particular cluster member.
• If all members of a cluster have bottlenecks, scaling can be achieved by adding one or more members to the cluster, backed by appropriate physical hardware. On WebSphere Application Server for z/OS , scaling can also be achieved by allowing more servants to run within the server (cluster member).

• If a singleton server or cluster member is the bottleneck, there are some additional considerations:

  • A messaging engine in a cluster with "One of N" policy (to preserve event ordering) can become the bottleneck. Scaling options include:
    • Hosting the active cluster member on a more powerful hardware server, or removing extraneous load from the existing server.

    • If the Message Engine (ME) cluster is servicing multiple buses, and messaging traffic is spread across these buses, consider breaking up further to a separate ME cluster per bus.

    • If a particular bus is a bottleneck, consider whether destinations on that bus can tolerate out-of-order events, in which case the cluster policy can be changed to allow workload balancing with partitioned destinations.
    • For WebSphere Application Server for z/OS, horizontal scaling in a cluster can also be achieved by adding servants to a server instead of adding cluster members. Adding servants can simplify system management tasks. See the Redbooks publication titled z/OS: WebSphere Business Process Management V7 Production Topologies at: http://www.redbooks.ibm.com/redpieces/abstracts/sg247831.html.

  • A database server can become the bottleneck. Approaches to consider are:

    • If the database server is hosting multiple databases that are active (for example, the BPEDB and the MEDB), consider hosting each database on a separate server.

    • If a single database is driving load, consider a more powerful database server.
    • Make use of DB2 database partitioning and clustering.

Advanced tuning