Version 5.0.2 of WebSphere Application Server introduces "mirrored cluster support," which provides backup clusters that mirror the primary server clusters. Mirrored cluster support is for EJB requests only.
Overview and prerequisites
When all members of a cluster are no longer available to service EJB requests, clients that must interact with one of the EJB application servers in the cluster do not function. Mirrored clusters enable an EJB cluster (primary cluster) to failover to another EJB cluster (backup cluster) when none of the EJB application servers in the primary cluster are able to service a request. The backup cluster allows the client to continue functioning when all cluster members of the primary cluster are not available.
If cluster members in the primary cluster subsequently become available, the mirrored cluster support attempts to fail back the requests to the primary cluster. This fail back is automatic, so you do not have to instruct the mirrored cluster support explicitly to allow fail back.
For the backup cluster to take over servicing requests successfully, the objects and resources available in the primary cluster must also be available in the backup cluster. You must install the same applications, use the same application names, and define the same resources in the backup cluster as in the primary cluster.
For successful fail back, the primary cluster must be defined as a backup for the backup cluster. In other words, both primary and backup clusters must have a backup configured, and each cluster's backup must point to the opposite cluster.
The primary and backup clusters must have the same cluster name and the same application names. Thus, the primary cluster and the backup cluster must reside in separate cells because a cluster must have a unique name within a cell.
The mirrored cluster failover support is not cell (domain) level failover or node agent failover. For the most part, the mirrored cluster support depends on a running deployment manager and node agents, and is limited to cluster failover only. For example, if the primary cluster's entire cell stops processing, a new client's requests to the primary cluster will fail and are not sent to the backup cluster. Information regarding the backup cluster cannot be retrieved from the primary cluster's cell because the primary cluster's cell is not processing. On the other hand, if the primary cluster's cell manager or node agents and application servers stop processing after the client has already been sending requests to the primary cluster, the client already knows about the backup cluster and is able to send the requests to the backup cluster.
For cluster failover and fail back to function as expected, all of the servers (deployment manager, node agents and application servers) for both the primary cluster and the backup cluster must be at a release and level that provides mirrored cluster support; that is, Version 5.0.2 or later.
Configuration
The mirrored cluster support defines a mirrored cluster as a backup cluster which is optional and which a user might or might not configure. Each cluster can have only one backup cluster, which must be configured before it is specified as a backup cluster.
To configure a backup cluster in a cluster, you must specify a name and an endpoint. The endpoint is called the "domain bootstrap address" and consists of a bootstrap host and port. The bootstrap host is the host that contains the deployment manager in which the backup cluster is configured. The bootstrap port is this same deployment manager's bootstrap port.
The primary cluster and the backup cluster must reside in separate cells. To place mirrored clusters in separate cells, configure the appropriate backup cluster endpoint. The backup cluster bootstrap host and port determine which cell contains the backup cluster.
You can configure a backup cluster using the administrative console or the ExtendedCluster MBean. To determine the value for the domain bootstrap address and configure a backup cluster using the console, see "Creating backup clusters."
As to configuring a backup cluster using the console, you use the Configuration tab on the Domain Bootstrap Address page to statically define the backup cluster; the static value is consumed each time the deployment manager starts. You use the Runtime tab on the Domain Bootstrap Address page to define the backup cluster during run time only; when the deployment manager stops, the run-time backup cluster information is discarded.
As to configuring a backup cluster using the ExtendedCluster MBean, you can change the run-time configuration only. The MBean change does not affect the static configuration. You can use the setBackup operation on the ExtendedCluster MBean to change the run-time configuration. For example, you can use the following Java code to set the primary cluster's backup cluster:
ac.invoke(extendedCluster, "setBackup", new Object[] { backupClusterName, backupBootstrapHost, backupBootstrapPort}, new String[] { "java.lang.String", "java.lang.String", "java.lang.Integer"});
Where ac is the AdminClient, and extendedCluster is the ExtendedClusterObjectName for the primary cluster.
Fail back support
There are two scenarios that affect the cluster fail back support.
In the first scenario, requests are made by the client to the primary cluster, which eventually stops accepting requests. The requests are then routed to the backup cluster. The client initially sent requests to the primary cluster and therefore has information or "knows about" the primary cluster. As a result, when the primary cluster is available again, the requests fail back to the primary cluster.
In the second scenario, the client does not start sending requests until after the primary cluster is down, and the requests go directly to the backup cluster. In this case, the client has information or "knows about" only the backup cluster. Since the client knows only about the backup cluster, when the primary cluster becomes available, the requests from this client continue to route to the backup cluster and do not fail back to the primary cluster when it becomes available. This scenario occurs when an object is created on the backup cluster. In this case, the backup cluster becomes the primary cluster for this object.
Both of these scenarios can occur within the same client at the same time, if the client is sending requests to existing objects and creating new objects after the primary cluster stops processing.