Guidelines for setting up a cluster

When you set up a WebSphere® Portal cluster, you must consider any planning that is required for the WebSphere Application Server nodes. If you are not familiar with WebSphere Application Server clustering, find resources here to help you get started.

Prerequisites

In WebSphere Application Server, a cluster is composed of multiple identical copies of an application server. A cluster member is a single application server in the cluster. WebSphere Portal is installed as an enterprise application server within the WebSphere Application Server infrastructure. All of the clustering features available within the WebSphere Application Server infrastructure are also available and apply to WebSphere Portal. Thus, a WebSphere Portal cluster is a collection of multiple WebSphere Portal servers that are identically configured.

For more information, select the appropriate IBM® WebSphere Application Server Network Deployment version at http://www.ibm.com/software/webservers/appserv/was/library/.

Guidelines for implementing cluster environments

Implement cluster environments according to the following guidelines:
  • The WebSphere Portal databases must be transferred to a supported external database, for example: DB2®, Oracle, or SQL Server .
  • You can use several approaches to configure an external web server in a clustered environment. The instructions for installing a WebSphere Portal follow WebSphere Application Server, which involves the plug-ins installation wizard to install the binary plug-in module after the cell is set up. For a complete description of the procedure for configuring an external web server in a clustered environment, refer to the following information:
  • The deployment manager node must be installed separately before the cells and clusters can be configured.
  • WebSphere Application Server provides database session persistence and memory-to-memory replication as techniques for HTTP session failover in a clustered environment. Review the following information to determine whether you want to use one of these techniques in your cluster:
    Warning: The memory-to-memory session application can lead to low memory conditions if failures cause replication to fail. This condition can occur because the local and backup sessions are stored in the JVM memory. Therefore, failures with replicating the session data can prevent freeing the memory that is allocated for the backup session.
  • You can create a dynamic cluster to run WebSphere Portal.
  • The WasRemoteHostName and WasSoapPort properties, which are in the wkplc.properties file, must always be accurate because many ConfigEngine scripts depend on them. If you are in a stand-alone environment, these parameters point to the host name and soap port for the WebSphere_Portal application server. If you are in a clustered environment, these parameters point to the Deployment manager host name and soap port. Modify these properties when instructed to during the installation instructions.
  • If you add a node to a cell or change a node's configuration after it is federated to the deployment manager, synchronize the node's configuration.
  • If you are planning to configure an external security manager for authentication or authorization, install and configure the WebSphere Portal cluster first. Verify that the cluster is working properly before you configure the external security manager.
  • IBM i: Set up a recycling procedure WebSphere Portal database with the following command; this procedure automatically removes the unused journal files: 
    CHGJRN JRN(Your DB2 DB Name/QSQJRN) DLTRCV(*YES)

    Where Your DB2 DB Name is the value of the release.DbName property, which is in the wkplc_dbdomain.properties file.