Sun Convergence 1.0 Cluster Deployment

This article describes how to deploy and configure Sun Convergence on a Sun Java System Application Server 9.1 U1 cluster. The clustering feature provided by Application Server enables you to create highly available and scalable deployment architectures.

This article assumes that you have working knowledge the following:

• Installing and configuring Convergence. The Communications Suite 6 Installation Guide provides information on how to install and configure Convergence.
• Setting up clusters using Sun Java System Application Server 9.1 U1. To know more about clustering in Application Server, see:
  • Sun Java System Application Server 9.1 High Availability AdministrationGuide
  • Clustering in GlassFish Version 2

Pre-requisites and Deployment Example Architecture

The hardware and software requirements for configuring Convergence in an Application Server cluster is the same as with a default Convergence deployment. However, additionally you will need to install Sun Java System Web Server 7.0. The role of Web Server in this deployment example is that of a load balancer.

The following is the deployment architecture:

In the above deployment architecture, Machine A and Machine B are part of the cluster. Machine A has Domain Administration Server (DAS) and node agent configured. Machine B is configured with Node Agent. The cluster uses HADB for storing session specific information.

Machine C is an instance of Web Server 7.0, on which a load balancer plug-in is configured using the Machine A and Machine B information. The load balancer plug-in is available as part of the Application Server installer.

The load balancer routes all incoming requests to the backend cluster instances.

Setting up the Cluster

Follow these steps to set up the cluster:

1. Start Domain Administration Server on Machine A
2. Start Node Agents on Machine A and B
3. Create a cluster using the asadmin command-line utility.
4. Create the application server instances using the asadmin command.
5. Create HADB database for the cluster.

For more information on working with clusters, see Working with Clusters.

Deploying Convergence on the Application Server Cluster

Deploying Convergence on a cluster is different from deploying Convergence on a single instance of Application Server. After installing Convergence, you must execute the init-config command to configure Convergence. During configuration, you must supply details at appropriate stages in the configuration wizard. These steps are documented in the Convergence 1.0 Initial Configuration document. The following sections provide information on the details you must provide in a clustered setup.

Panel 2: Select the directory to store configuration and data files.

Select the directory where you want to store the configuration and data files. The default data and configuration directory is located here: /var/opt/sun/comms/iwc.

Note The data and configuration information must be available on the same path on all the instances in the cluster. If any changes are made to one instance in a cluster, the same has to be replicated in the other instances. You can use the iwcadmin command to do this.

You can also have the configuration and data directories on a networked mounted file system that is accessible to all instances of the cluster. This is currently not supported due to a requirement of unique Instant Messaging Component JID in the Instant Messaging geteway configuration (httpbind.conf). See Known Issues.

Panel 5: Application Server 9.1 Update 1 Configuration Details

In this panel, you must enter the Server Target Name as the name of the cluster. Since this is a cluster setup, you must enter the cluster name.

Panel 6: Application Server: Administration Instance Details

In this panel you must select the "Secure Administration Instance" check box. Due to a known issue in Application Server, this check box must be selected in order for the Convergence configuration tool to deploy Convergence on the cluster. see Known Issues.

Note You must restart the cluster after deploying Convergence on the cluster, see Working with Clusters.

Set the Session Passivation parameter to true

In a default Convergence deployment, the user sessions are not passivated. That is, the session information is not persisted in a store. The base.passivatesession configuration parameter that controls session passivation is set to false by default. In a clustered environment, this parameter should be set to true so that the user sessions are maintained. Use the following command to enable session passivation:

iwcadmin -w password -o base.passivatesesison -v true

Note You must restart the cluster if you change the configuration settings using the iwcadmin command.

Client Files

When Convergence is installed, the static files are copied in the application server's docroot directory. This directory contains all the JavaScript, HTML, CSS files that display the user interface. In a clustered environment, you must copy the iwc_static folder on all instances of the cluster. You must configure the load balancer to set the target context root for each cluster instance. Here is a snippet of the load balancer's configuration file:

<web-module context-root="/iwc" disable-timeout-in-minutes="30" enabled="true"/>
<web-module context-root="/iwc_static" disable-timeout-in-minutes="30" enabled="true"/>

Known Issues

This section describes the known issues, limitations, and suggested workarounds when Convergence is deployed in a clustered environment.

Deploying Convergence on the Cluster in a non-secure mode

If Convergence is deployed in a cluster in a non-secure mode, the application server fails to deploy Convergence. This is a known issue with Application Server.

Workaround: Deploy Convergence in a secure mode. To do this, you must enable the "Secure Administration Server Instance" check box as described in the section Panel 6: Application Server: Administration Instance Details.

Instant Messaging Component JID

Convergence communicates with Instant Messaging Server using the IM HTTP Gateway. The IM HTTP Gateway is a part of Convergence and all instant messaging requests are routed through the gateway. Every Gateway is associated with a unique identifier, known as component JID. The instance messaging client gateway connects to the Instant Messaging server using this component JID. When configuring Convergence on a clustered environment, the Instant Messenger component JID values on the cluster instances should be unique. This is because the Instant Messaging server can only serve one unique component JID request at a time. If your cluster instances connect to the Instant Messaging server using the same component JID, the Instant Messaging server will be unable to serve the requests and the connection to the instant messaging client is lost.

Workaround: When configuring the instances of a cluster, you must provide separate component JIDs for each cluster instance. For more information on how to work with Instant Messaging HTTP Bind Gateways, see Chapter 10 Using the Instant Messaging XMPP/HTTP Gateway in Sun Java System Instant Messaging 7.2 Administration Guide.