The WebSphere Partitioning Facility

WebSphere Partitioning Facility lets you create and manage partitions in WebSphere XD.

In its simplest form, a partition is a list of labels that can be created by applications (or metadata found in declarations within applications) whenever they are required. For example, an application can render a set of abstract partition names to represent categories of items being bid upon during auctions:

  • sporting goods
  • automobiles
  • toys
  • antiques

The WebSphere Partitioning Facility is a programming framework and runtime environment that makes it possible for high transaction volume applications to scale linearly by adding hardware capacity.

To accomplish this, an application is partitioned across multiple servers in a cluster. Each partition is a uniquely addressable endpoint within the cluster, to which requests for certain EJBs or certain data are always routed.

Partitioning solves some of the traditional challenges of very large clustering, because it can reduce data contention and reduce the overhead of replicating shared data, like caches or state information.

The goal of partitioning is to provide the ability to control specific resources during cluster member execution.

Requests can be routed to a specific application server that has exclusive access to certain computing resources, such as a dedicated server process or database server. The requests can be a HTTP, EJB or database read or update, with the endpoint receiving the work being highly available. WebSphere Partitioning Facility offers functionality to route work to a particular cluster endpoint. This reduces overall system overhead while retaining high availability of each endpoint.

As a result, WebSphere Partitioning Facility is designed to make it easier to develop applications with the following characteristics:

  • Write-intensive applications that traditionally do not scale well because of contention
  • Applications that must process high-speed message feeds
  • Applications with a need for singletons that must be made highly available

Requests should be directed to an application server that has exclusive access to specific resources. The WebSphere Partitioning Facility framework provides tools and APIs for the management of these partitions, such as...

  • activation and deactivation
  • rebalancing of partitions
  • when a partition is loaded or unloaded
  • a partition is moved to a different application server

A partition can be activated on any cluster member in a cluster. The High Availability Manager (HAManager) guarantees there is a single instance of an active partition in the cluster at a given time within the cluster for cluster scoped partitions. The HAManager allows a partition to be moved from one member in the cluster to another. When moving a partition, the partition state will be deactivated on the original cluster member and activated on the new target cluster member.

Partitions are by default highly available. A partition can only be hosted on a single cluster member at a time. They are made highly available using the HAManager. If a cluster member fails as a result of a JVM shutdown or JVM failure, then the HAManager moves all partitions which were running on the failed cluster member to another surviving cluster member.

The HAManager monitors many cluster-wide resources. In general, this takes a certain amount of performance. If the cluster members are paging or otherwise engaged so that HAManager functionality cannot operate effectively, then HA-managed events will begin to occur to account for perceived cluster member anomalies.

For this reason, IBM recommends that you do not put the application servers under a large load in normal cases, in order to better handle spikes at times when challenges arise. In addition, reducing virtual memory paging as much as possible will result in a more reliable cluster operational environment.

The number of partitions in a specific solution should be managed carefully. When possible, having fewer partitions is generally simpler and more efficient. Each partition takes system resources to implement within the workload management function; requires additional administrator effort from a system management perspective; and produces a reduction in cluster performance when tracking, from a performance monitoring perspective.