WebSphere Portal cluster planning

 

+
Search Tips   |   Advanced Search

 

  1. Before you begin
  2. Supported configurations
  3. Guidelines for implementing cluster environments
  4. Limitations

 

Before you begin

In IBM 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.

Portal Server is a specialized instance of WebSphere Application Server.

With a stand-alone configuration

  • Each portal server acts independently of others.
  • Does not provide for common management or administration for multiple servers.
  • Failures results in service interruptions and loss of unsaved end user data.

Clustered configuration provides...

  • scalability
  • failover
  • performance

WebSphere Portal is installed as an enterprise application server within the WAS infrastructure. All of the clustering features available within the WAS infrastructure are also available and apply to WebSphere Portal. Thus, a WebSphere Portal cluster is simply a collection of multiple WebSphere Portal servers that are identically configured.

When planning for WebSphere Portal clusters, also take into account any cluster planning required for the WAS nodes.

Configured resources have scope

Cell

  • <config_root>/cells/<cell_name>/*.xml
  • Replicated and available to all nodes in the cell
  • Enterprise Applications (EARs) are cell-scoped
  • addNode does not merge cell settings. Must be re-created on new cell.

Node

  • <config_root>/cells/<cell_name>/nodes/<node_name>/*.xml
  • All servers on that node have access to this resource
  • Portal's shared libraries and JDBC resources are node scoped

Server

  • <config_root>/cells/<cell_name>/nodes/<node_name>/servers/<server_name>/*.xml
  • A resource is only accessible by that server

 

Supported configurations

Although WebSphere Portal provides business process integration support through IBM WebSphere Process Server (WPS), the use of these products in a managed cell or cluster is limited to certain configurations. Because a cluster must consist of identical copies of an application server, either every instance of WebSphere Portal must be installed with WPS or every instance of WebSphere Portal must be installed without WPS.

The installation program for WebSphere Portal installs WPS with a subset of components required by WebSphere Portal, including necessary service level updates. However, if you so choose, we can manually perform a full installation of WPS and use that installation to create the deployment manager profile and custom profile needed for the installation of WebSphere Portal. If you intend to follow this approach, ensure that the instance of WPS is at the correct service level.

Installation scenario Can resulting configuration be used in a managed cell or cluster? Details
Installation on an unmanaged node, including WPS. No Standalone portal server that includes support for business process integration. However, because WPS cannot be federated after installation, we cannot use this node in a managed cell or cluster.
Installation on an unmanaged node, not including WPS Yes Standalone portal server that does not include support for business process integration. However, we can federate this node to a deployment manager cell after installation.

To install WebSphere Portal without WPS, ensure that you select No when asked whether to install business process integration support during installation.

Installation on a managed node, including WPS. Yes Portal server node that includes support for business process integration and is managed by a deployment manager.

This is the only supported installation path if we need to have business process integration support available in a managed cell or cluster.

Installation on a managed node, not including WPS. Yes Portal server node that is managed by a deployment manager, but does not include support for business process integration.

This documentation does not include detailed instructions for this scenario.

 

Guidelines for implementing cluster environments

  1. There are several approaches we can use to configure an external Web server in a clustered environment. The instructions provided here for installing a WebSphere Portal follow the approach recommended by WAS, which involves using the Plug-ins installation wizard to install the binary plug-in module after the cell has been set up.

    Before using the configureweb_servername script during Web server configuration in a managed cell, change the timeout request period for the SOAP client on the deployment manager machine. The default, in seconds, is 180. Edit...

    was_profile_root/properties/soap.client.props

    ...and change the line to...

    com.ibm.SOAP.requestTimeout=6000

  2. Ensure that WAS and WebSphere Portal are installed properly on each node. Verify that all appropriate interim fixes are applied to each node.

  3. The deployment manager node must be installed separately before the cells and clusters can be configured.

  4. WAS provides database session persistence and memory-to-memory replication as techniques for HTTP session failover in a clustered environment.

  5. If you add a node to a cell or change a node's configuration after it has been federated to deployment manager, synchronize the node's configuration.

    System Administration | Nodes | Node | Full Resynchronize

    This helps ensure that there is no mismatch between node and cell configuration after the synchronization is complete.

  6. If you are planning to configure an external security manager to perform authentication or authorization for WebSphere Portal in a cluster environment, install and configure the WebSphere Portal cluster first. Verify that the WebSphere Portal cluster is working properly before proceeding with the configuration of any external security managers.

  7. i5/OS:

    Set up a recycling procedure Portal Database with the following command. This procedure automatically removes the unused journal files:

    CHGJRN JRN(QWPS60/QSQJRN) DLTRCV(*YES)

    QWPS60 is a default name of the WebSphere Portal database.

 

Limitations

The following limitations apply when implementing a WebSphere Portal cluster:

  1. You must install and configure WebSphere Portal separately on each node. In addition, there can only be one WebSphere Portal cluster per cell.

  2. Windows only: There is a known limitation with many Windows operating systems that limits path names to a maximum length of 259 characters. This can be a potential problem due to the depth of the WAS Network Deployment directory structure, particularly when deploying applications in a cluster. To avoid problems related to excessively long paths names, consider the following recommendations when installing WAS Network Deployment :

    • Use a short installation path. For example, use...

      C:\WebSphere

      ...instead of...

      C:\Program Files\IBM \WebSphere

    • Specify short cell and node names. For example, you might use sm01cell instead of stonemillNode01cell.

  3. Windows/UNIX only:

    Cloudscape, the default database installed with WebSphere Portal, cannot be operated remotely and therefore cannot be used in a cluster environment. When installing WebSphere Portal, you will first install to Cloudscape, then reconfigure WebSphere Portal to point to the common database used for the cluster.

  4. In a clustered environment, it is not possible to change portal settings through the Global Settings portlet or the XML configuration interface. These changes must be made by modifying the respective properties in the WAS administrative console.

  5. To support search in a clustered environment, install and configure search for remote search service on an application server node that is not part of the cluster.

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

  7. To enable security, stop all cluster members, and then run one of the following tasks...

    enable-security-ldap
    enable-security-wmmur-ldap
    enable-security-wmmur-db

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

  9. i5/OS limitations: The following configurations are not supported in an i5/OS environment:

    • WebSphere Portal installation on a federated node. If you are building a WebSphere Portal cluster in an i5/OS environment, federate each node after installing WebSphere Portal.

    • Installation in a mixed node environment.

 

Gotchas

  • Not reading the documentation. Planning, Pre-requisites

  • Not applying recommended WAS fixes. Refer to Hardware Software section. Fixes applicable to Dmgr and Node

  • Not following the steps in the order listed in the documentation. Most problems for cluster installation are caused by not following the steps.

  • Not taking time to understand concepts first. On the fly knowledge acquisition.

  • Not checking that WebSphere Portal is operational after each configuration step. Make assumption that it will work. Backups

 

Related information

 

Parent topic:

Clustering and WebSphere Portal