Backup clusters
Backup clusters mirror the primary server clusters. Mirrored cluster support is for Enterprise JavaBeans (EJB) requests only.
Overview and prerequisites
When all the members of a cluster are no longer available to service EJB requests, any 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 of cluster members in the primary cluster are not available.
The fail back is automatic. You do not have to initiate fail back to the primary cluster after restarting the servers in the primary cluster. The backup cluster stops servicing requests as soon as the primary cluster becomes available.
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 use the same cluster name, install the same applications, use the same application names, and define the same resources in the backup cluster as in the primary cluster.
The primary cluster and the backup cluster must reside in separate cells because a cluster must have a unique name within a cell.
For successful fail back, the primary cluster must be defined as the backup for the backup cluster. Both the primary and backup clusters must have a backup cluster configured, and each cluster must specify the opposite cluster as its backup cluster.
Because the primary and backup clusters reside in different cells, with the current version of WebSphere Application Server, the clusters also reside in different core groups. You must configure the core group bridge service to allow communication between core groups. The core group bridge service eliminates the requirement of a running deployment manager and a node agent for the backup cluster support. In the previous release, if the deployment manager stopped, new requests could not be forwarded to the backup cluster after the primary cluster failed. In WAS V6, any core group bridge server that is configured in the primary cluster's cell can provide information about the backup cluster. The backup cluster support fails only if all of the core group bridge servers in a cell are not running.
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, WebSphere Application Server Enterprise or WebSphere Business Integration Server Foundation V5.0.2 or later or WAS Network Deployment V6. However, if you are using a V5.x cluster to back up a cluster that is on the current release, you do not have the additional functionality from the core group bridge service. All the deployment managers must be functional for backup cluster support.
Configuration
Mirrored cluster support is not configured by default. To use the mirrored cluster support, specify backup clusters in your configuration. 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, specify a name and a domain bootstrap address. The bootstrap host is the host that contains the deployment manager in which the backup cluster is configured. The bootstrap port is the bootstrap port for this deployment manager.
The primary cluster and the backup cluster must reside in separate cells. To place mirrored clusters in separate cells, configure the appropriate backup cluster domain bootstrap address. The backup cluster bootstrap host and port determine which cell contains the backup cluster.
One 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.
To configure a backup cluster using the administrative console, 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. 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.
Because the primary and backup clusters reside in different cells, with the current version of WebSphere Application Server, the clusters also reside in different core groups. You must configure the core group bridge service to allow communication between core groups. Use an access point group to join the two core groups. In the deployment manager for the primary cell, configure an access point group that has the core group access point for the backup cell as a peer access point. In the deployment manager for the backup cell, create an access point group that has the same name as the access point group you created in the primary cell. Add a peer access point that refers to the core group access point in the primary cell. See Configuring communication between core groups that are in different cells for more information. If you are configuring a V5.x cluster to back up a cluster that is on the current release, you do not have to configure the core group bridge service because the V5.x cluster does not belong to a core group. The backup cluster still functions using only the domain bootstrap address.
If you are configuring a backup cluster using the ExtendedCluster MBean, one can change the runtime configuration only. The MBean change does not affect the static configuration. Use the setBackup operation on the ExtendedCluster MBean to change the run-time configuration. For example, 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"});In this sample, ac is the AdminClient, and extendedCluster is the ExtendedClusterObjectName for the primary cluster.
Fail back support scenarios
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 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 about the backup cluster only. Because the client knows about the backup cluster only, 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.
Related Tasks
Creating backup clusters