How to achieve continuous availability in the WebSphere Process Server V7

Brief introduction

As organizations begin to understand how best to leverage processes to help run and improve their business, business process management applications are becoming increasingly mission-critical. This means that the availability requirements of these applications often reach 24/7. BPM also encourages continuous process improvement, which means that changes to the application will be done more quickly in a variety of different forms. A number of mechanisms and techniques are needed to minimize downtime and to achieve continuous availability. These technologies need to be as automated as possible in order to improve consistency and speed and reduce fingerprint checks or human errors.

This article provides background knowledge, insights, and practical techniques for implementing continuous availability in the WebSphere Process Server V7.0.

First, let's review the topology of the WebSphere Process Server. This article will focus on the specific considerations for preparing and setting the application phase of the proposed methodology in this article. Because many different types of artifacts are involved in the IBM BPM solution running on the WebSphere Process Server, you need to use different techniques to achieve the desired results. You also need to perform some restrictions and special settings at the solution and application levels. Each scenario provides a detailed explanation, including the steps involved in performing these scenarios. This article will focus on the implementation of the scenarios and the basic techniques of the application, and use this as a benchmark to explore the changes associated with Store-and-forward and alternate topology configurations. This article also enumerates more insights into the scenarios that are executed and some of the effects. Finally, you will summarize how to apply a similar approach to the product fix package.

Before you try any of the procedures listed here in a production environment, it is strongly recommended that you test them thoroughly first. In addition to the topology structure, applications must be created in ways that help achieve continuous availability. This article provides some specific information, but assumes that the application handles interface changes appropriately, tables and other resource requirements that are required in the database. To put it another way, realize that some application changes can compromise compatibility and lead to downtime. The focus of this article is on compatible changes. For example, instead of deleting or changing an action, we perform an add operation. Application-specific databases do not launch changes. Operations such as delete operations and database changes are not covered in this article.

Background of the Process Server topology

Figure 1 shows a typical possible form of a WebSphere Process Server configuration. For simplicity's sake, this article assumes a single cell topology similar to this one. We cannot introduce each configuration scenario, but we want to provide some common practices that can be applied to most configurations.

Figure 1. A two-node and 4-cluster-clustered topology containing IBM HTTP Server

All WebSphere Process Server topologies take advantage of 4 key Features: Application deployment Objectives, messaging infrastructure, support infrastructure, and WEB infrastructure. A cluster is a group of servers that perform one or more of the 4 functions. You can have one cluster perform all 4 key functions. However, if these features are dispersed across multiple clusters to improve recovery, there is a chance for higher continuous availability.

In the topology shown in Figure 1, each of the 4 features has a dedicated cluster. The application deployment target cluster (Apptarget) consists of servers that have your application installed. These applications may include business processes, services, human tasks, and mediations. The remote messaging cluster (messaging) supports the requirements of your application for asynchronous messages and internal Process Server components. Support for the functionality provided by the infrastructure cluster (SUPPORT) complements the deployment objectives, as a stand-alone cluster that isolates and relieves certain workloads from the deployment target. Finally, the Web Component cluster (WEBAPP) hosts web-based client applications such as Business space, Business Process choreographer Tools, and REST API services.

This topology contains one deployment Manager and 2 Process Server nodes. The responsibility of the Deployment Manager is to manage the unit and provide an interface to configure the various components in the unit. The Deployment Manager is also responsible for installing and updating applications, so it is critical for us to achieve continuous availability.

One node hosts one or more application servers, in which each node hosts one member of each cluster. Each node is managed remotely by the deployment Manager through the node agent. The Deployment Manager communicates with the node agent of a node, which in turn communicates with the application server for that node.

In the WebSphere Process Server, the application is installed through the Deployment Manager using the integrated Solutions Console or the Wsadmin command-line scripting tool. When an application is installed or updated, the artifacts of the new application are first stored in the cell master repository. The deployment Manager then passes the artifacts of the new application to the node agent for each node. Subsequently, each node agent updates the application on the application server for that node.

IBM HTTP Server is typically used to handle HTTP traffic in the IBM BPM environment. IBM HTTP Server supports the routing of traffic to the application server using a file named Plugin-cfg.xml. A client connects to an HTTP server and is processed according to the load per application server configuration, which routes the client's request to the unit's application server. When we discuss updating an asynchronous application, we will cover the IBM HTTP Server configuration in more detail.

In the basic overview of the WebSphere process Server topology, we outline the knowledge needed to understand and successfully use the process described later.

Topology roles in continuous availability scenarios

The key to implementing continuous availability in WebSphere Process Server is to minimize downtime during application updates. Our goal is to keep the client from experiencing any downtime while updating the application, and it's best to be aware of no change at all. For some types of applications, this is simple and requires no special preparation. For most process Server applications, however, an update of 0 downtime requires careful planning and a special process that involves routing incoming application traffic between nodes. We'll explain this process in detail later, but we'll start with an overview of process Server topologies that make this goal possible.

One prerequisite for continuous availability is that we achieve what we call "high availability." For continuous availability, it is recommended to use a topology similar to Figure 1: A topology consisting of 2 nodes and 4 clusters, each of which has one node per cluster. At a minimum, you must have an application target cluster that is separate from the message cluster. This ensures that the messaging engine can independently failover with the application target server. You must also have at least two separate nodes to host the application target and the members of the message cluster. This allows you to stop the server on one node and update one application while having the other node handle all application traffic. These recommendations not only provide the foundation for continuous availability, but also lay a solid foundation for high availability.