Process choreographer scenarios for clustering

The main advantages of using WebSphere clusters and Network Deployment (ND) to create and administer process choreographer instances are:

Configuration options

You can configure process choreographer in many different ways, so cluster configurations are usually very complex. Some of the main options to consider before you start creating application servers are outlined in the following descriptions:

Number of nodes in the WebSphere cell
One or more. All nodes are administered from a single deployment manager.
Number of nodes in each WebSphere cluster
One or more. Horizontal WebSphere clustering can increase service availability and increase the total workload capacity.
Number of application servers in each node
One or more. Vertical WebSphere clustering can increase resource utilization.
Database host
  • Remote, on a dedicated machine
  • Local to one of the application servers in the cluster
To share workloads, all business process containers in the same WebSphere cluster must use the same database. Hosting the database on a dedicated machine, preferably one with a hot standby, is recommended.
Application messaging queues
  • Local queues
  • Remote queues
Connection (WebSphere MQ queue managers)
  • One central (remote) queue manager hosting the queues for the application servers within one cluster.
  • One local queue manager per application server.
  • Two local queue managers per node, and WebSphere MQ clustering used to balance workload across several application servers.

    Workload balancing between different process choreographer instances requires that the queue managers used by the business process container of each application server are members of the same WebSphere MQ cluster.

Database system
You can use any of the supported databases except Cloudscape.
Hot standby machines
You have the following options for hot standby machines:
  • None
  • For the database
  • For a central queue manager

Cluster types: This topic refers to two different types of cluster. A WebSphere cluster groups application servers together to share workload and increase service availability. A WebSphere MQ cluster, previously known as an MQSeries cluster, groups together WebSphere MQ queue managers and can be used to achieve intraprocess workload balancing.

High availability

To achieve high availability of process choreographer services, consider the following:

Vertical clustering to maximize resource utilization

To improve performance, you might have to create multiple application server instances on the same node so that process choreographer can use the available system resources.

Workload balancing

If you want different instances of process choreographer to share the same workloads, they must:

Process choreographer database

Hosting the database on a dedicated machine, preferably one with a hot standby is recommended. The database can be on a machine that is outside the WebSphere cell, however the deployment manager must have access to it.

When planning the database, consider the following points:

WebSphere MQ

Process choreographer uses MQ queues for receiving requests and sending replies. Therefore each application server that hosts process choreographer requires one of the following options:

Process choreographer also supports embedded messaging. However, embedded messaging is not recommended for complex configurations because it does not support WebSphere MQ clustering.

In a WebSphere cluster environment, the use of embedded WebSphere MQ is also not recommended. This is because WebSphere MQ does not support a high-availability, hot-standby solution, such as HCAMP on AIX.

Central queue manager

By using a central queue manager for all queues, administration becomes easier. One queue manager is used by all cloned business process containers. However, using a central queue manager creates a single point of failure that needs to be hosted on a high availability system.

The following figure shows all the application servers in a WebSphere cluster using a single central queue manager on another machine.

This figure shows all the application servers in the WebSphere cluster using a single central queue manager on another machine.

Local queue manager without WebSphere MQ clustering

This is the standard, stand-alone process choreographer configuration. Each business process container has one local queue manager. This approach does not offer intraprocess workload sharing.

WebSphere MQ clustering

This complex technique supports intraprocess workload sharing for process choreographer services in a WebSphere cluster. The business processes in the cluster must all run on UNIX only, or Windows machines only; a combination of UNIX and Windows machines does not work.

Each application server requires two local queue managers, one for putting and one for getting messages. All the queue managers become members of the same WebSphere MQ cluster. On Windows systems, all the queue managers must use the same binding protocol. On UNIX systems, the put and get queue managers must use different protocols. For example, you can modify the queue connection factories so that all the put queue managers use the binding protocol (interprocess communications) and all the get queue managers use the default, client (TCP/IP) protocol.

Each business process container in the WebSphere cluster must be customized to reflect its own queue managers.

It is recommended that more than one queue manager in the WebSphere MQ cluster is made a cluster repository.

The following figure shows how the queue managers used by the application servers are grouped together in a WebSphere MQ cluster. The WebSphere MQ cluster (of queue managers) is parallel to the WebSphere cluster of application servers. Requests are shared across the get queues in the cluster.

This figure illustrates how the queue managers used by the application servers are grouped together in a WebSphere MQ cluster that parallels the WebSphere cluster of application servers. Requests are shared across the get queues in the cluster.

How the WebSphere cluster is created

Several different sequences are available for you to follow when creating a cluster for process choreographer. The following sequence is recommended:

  1. Install the prerequisites on each machine:
    • WebSphere MQ.
    • Database server, database client, or a type-4 Java database connectivity (JDBC) driver.
  2. On the first node in the cell, define the application servers.
  3. Create the required clones of the application server.
  4. Use the Install wizard on the deployment manager machine to install the business process container on any one of the application servers in the cluster. The business process container is simultaneously installed on all the other application servers in the cluster.
  5. If your WebSphere MQ configuration is a WebSphere MQ cluster of local queue managers you must modify the connection factories. Because each queue manager has a different name, you must modify the connection factories in each of the cloned application servers to reflect its unique differences from the cluster-wide, standard process choreographer Install wizard configuration.



Searchable topic ID:   c7dist
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/workflow/concepts/c7dist.html

Library | Support | Terms of Use | Feedback