Guidelines for setting up a cluster | HCL Digital Experience

When you set up an HCL 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. HCL 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 HCL Portal. Thus, an HCL Portal cluster is a collection of multiple HCL Portal servers that are identically configured.

z/OS only note: The server short name must be unique within a cell. If you are planning to build a horizontal cluster, make sure to define a unique short name for all the nodes in the cell.

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 HCL 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 HCL 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.
  • z/OS® only: HCL Digital Experience provides the choice to install into a stand-alone profile or into the managed profile of an existing cell. An HCL Portal cluster can be formed from nodes that were installed into a stand-alone profile. This profile is installed into a managed profile or installed into a combination of stand-alone and managed profiles.
  • You can create a dynamic cluster to run HCL Digital Experience.
  • 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 HCL Digital Experience 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 HCL Portal cluster first. Verify that the cluster is working properly before you configure the external security manager.
  • IBM® i: Set up a recycling procedure HCL 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.