Limitations for setting up a cluster

• Install HCL WebSphere Portal as a stand-alone node before creating a cluster. We cannot install HCL WebSphere Portal into a managed node.

• Except for the initial setup of the cluster, HCL WebSphere Portal is not supported on a managed node that is not part of a cluster. A cluster can be created which contains only one HCL WebSphere Portal server, enabling a single HCL WebSphere Portal server to be operational in a managed cell.

• We cannot use the Derby database. The HCL WebSphere Portal databases must be transferred to a supported external database, for example: DB2, Oracle, or SQL Server .

• In a clustered environment, it is not possible to change settings through the Global Settings portlet or the XML configuration interface. These changes must be made by modifying the respective properties in the WebSphere Integrated Solutions Console.

• To support search, install and configure a remote search service on an application server node that is not part of the cluster.

• Administrative actions for HCL WebSphere Portal are immediately visible for the user who completes them. However, another user can be assured of seeing the changes only if the user logs out of HCL WebSphere Portal and then logs back in. This limitation applies to both cluster and non-cluster environments.

• When creating a cluster or a cluster member, do not use spaces in the cluster name or the cluster member name.

• For the deployment manager and each HCL WebSphere Portal node to be in the cluster, verify that each system clock is set to within 5 minutes of the others or the addNode command fails.

Restriction: The serverName is hardcoded to HCL WebSphere Portal. The serverName cannot be changed in a stand-alone environment. If we do change it, the ConfigEngine scripts do not work. For a clustered environment, see Virtual Member Manager integration for options on replacing the HCL WebSphere Portal JVM.

Parent topic: Cluster considerations