WebSphere

 

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

 

Manage the cluster

This section provides information on how to manage the different instances of each part of your cluster, including portlets, themes and skins, WAS, scripting, SSO, WMM, and security.

 

1: Managing portlets

Because all WebSphere Portal Express servers in the cluster share the same database, any WebSphere Portal Express node can be used to manage portlets. Cluster nodes do not need to be stopped when managing portlets.

1.1: Deploying portlets (installing or updating)

When you deploy a portlet, WebSphere Portal Express stores the portlet configuration data in the WebSphere Portal Express database and then forwards the portlet application's Web module and associated configuration to the deployment manager. The deployment manager is responsible for pushing the Web module to each node in the cluster.

The deployed portlets must be activated before they can be used, which cannot be accomplished until the deployment manager has synchronized the associated Web modules to each node in the cluster. Auto-synchronization of the Web modules to each node in the cluster might not happen immediately, or at all, depending on how the administrator has auto-synchronization configured in the deployment manager. For this reason, WebSphere Portal Express cannot guarantee that the portlet has been successfully synchronized to each node in the cluster and thus cannot automatically activate the portlet during deployment.

To deploy and activate portlets in your cluster, perform the following steps from any WebSphere Portal Express node in the cell:

  1. Deploy your portlets using either the WebSphere Portal Express Administration page or the XML configuration interface utility (xmlaccess command).

  2. Activate the deployed portlets in the cluster by running the command below. In addition to activating the portlets, this step causes the deployment manager to synchronize the changes across the cluster members.

    • Windows and Linux:

      Run the following command from the portal_server_root/config directory:

      • Windows:

        WPSconfig.bat activate-portlets

      • Linux:

        ./WPSconfig.sh activate-portlets

    • i5/OS:

      Run the following command from the portal_server_root/config directory: 

      WPSconfig.sh -profileName profile_root activate-portlets
      where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal Express is installed; for example, wp_profile.

    If you run the activate-portlets task while you are logged in to WebSphere Portal Express, log out and log back in before you can see the updated status for the portlets.

1.2: Providing portlets as WSRP services

By providing a portlet as WSRP service, a Producer makes the deployed portlet available remotely to Consumers. The WebSphere Portal Express database stores information about whether a portlet deployed in the cluster is provided as a WSRP service. Because the WebSphere Portal Express database is shared between the nodes in a cluster, all nodes are updated when providing a portlet as a WSRP service.

The URLs of the Producer services definitions in the Web Services Description Language (WSDL) document always automatically point to the Web server performing load balancing in the cluster. This ensures that all requests of Consumers invoking WSRP services of the Producer will be correctly load balanced.

The Producers URLs are generated by first checking the settings of the WSRP SOAP ports, as described in the WSRP documentation provided on the WebSphere Portal Express documentation page: http://www.ibm.com/websphere/portal/library. If the SOAP port values are not set, the values of the host.name and host.port properties in ConfigService are used. These values typically point to the load balancing traffic dispatcher. If no values are specified for either the SOAP ports or in ConfigService, the host name and port of the request used to reference the Producer WSDL document is used.

1.3: Uninstalling portlets

Uninstalling portlets in cluster environment is the same as in a stand-alone environment. Because uninstalling the portlet removes the portlet configuration from WebSphere Portal Express databases and all cluster members share the same database, the uninstalled portlet will be unavailable to all other members automatically.

 

2: Managing themes and skins

Theme and skin JSPs are managed as part of the main WebSphere Portal Express enterprise application and are thus part of the WebSphere Portal Express EAR file. When customized themes and skins are deployed into the cluster, they must be updated in the cluster's master configuration, which is managed by the deployment manager. See Deploying customized themes and skins for complete instructions.

 

3: Installing additional WebSphere Application Server features

In some situations you might need to install additional WebSphere Application Server features on the nodes in your cluster. For example, this could be necessary if a portlet requires a WebSphere Application Server feature not currently installed on the nodes. When installing additional features in a clustered environment, install the features on every node in the cluster. Also, the WebSphere Application Server Network Deployment node cannot have fewer features than the nodes that it manages. Consequently, if you install a new feature on the managed nodes, review the features on the WebSphere Application Server Network Deployment node to determine whether also install the feature on the WebSphere Application Server Network Deployment node.

For example, if you select the full installation option for WebSphere Portal Express, the WebSphere Application Server will not have the extended messaging feature installed by default. If any of your portlets use the extended messaging feature, you will have to install this new feature on all nodes before you are able to deploy these portlets.

To verify whether the feature is installed on the node, you can do one of the following:

 

4: Managing WebSphere Application Server replication

Replication is a service provided by WebSphere Application Server that transfers data, objects, or events among application servers. Data replication can be used to make data for session manager, dynamic cache, and stateful session beans available across many application servers in a cluster.

 

Managing WebSphere Application Server dynamic caching

Data replication service (DRS) is the internal WebSphere Application Server component that replicates data among application servers. There are several types of data replication, and WebSphere Portal Express can make use of data replication for dynamic caching and for memory-to-memory replication of session data.

Enabling data replication for dynamic caching in a cluster environment is absolutely necessary to maintain data integrity between multiple WebSphere Portal Express nodes in the cluster. Replication also helps improve performance by generating data once and then replicating it to other servers in the cluster. For information on configuring the settings for dynamic cache replication, refer to the WebSphere Application Server information center:

 

Managing WebSphere Application Server distributed sessions

WebSphere Portal Express can make use of the WebSphere Application Server capabilities to support HTTP session failover, which enables one node in a cluster to be able to access information from the existing HTTP session in case of a failure in the cluster node originally handling that session. This capability to have session information accessible to other application servers is referred to as distributed sessions. WebSphere Application Server provides two techniques that can be used for distributed sessions, either of which can be used in a WebSphere Portal Express cluster: memory-to-memory session replication and database persistent sessions. For further information on distributed session support, refer to the WebSphere Application Server information center:

Distributed session support is not enabled by default, so you will have to determine whether to provide this capability in your cluster, and, if so, which of the two techniques you will use. For details on these two techniques, refer to the WebSphere Application Server information center.

Memory-to-memory session replication

Database session persistence

 

5: Working with the Portal Scripting Interface in a cluster

 

Prerequisite

Before you can use the Portal Scripting Interface in a clustered environment, manually copy the wp.wire.jar file supplied with WebSphere Portal Express to the WebSphere Application Server Network Deployment machine:

  1. Verify whether the wp.wire.jar file is present in the app_server_root/lib directory on the deployment manager machine.

  2. If the file is not present, copy the file from the app_server_root/lib directory on any WebSphere Portal Express node to the app_server_root/lib directory on the deployment manager machine.

  3. Restart the deployment manager.

 

Running the scripting client in a cluster

To start the Portal Scripting Client in a clustered environment, the scripting client must connect to the SOAP port of the WebSphere Application Server Network Deployment machine, as in the following examples.

When WebSphere Application Server security is disabled:

When WebSphere Application Server security is enabled:

 

where:

For more information about the Portal Scripting Client, go to the Portal Scripting Interface section.

 

6: Changing single sign-on (SSO) settings in a cluster

If you have configured the nodes in your cluster to use single sign-on (SSO), you can change the SSO settings for the cluster by completing the following steps:

  1. In the deployment manager administrative console, click Security > Global security.

  2. Expand Authentication mechanisms, and click LTPA > Single signon (SSO).

  3. Update your SSO settings, and click OK.

  4. Ensure that Synchronize changes with Nodes is selected, and click Save to update the deployment manager configuration.

  5. Restart all servers in the cell, including the node agents and the deployment manager.

 

7: Using custom user registry security with a WebSphere Application Server node

If you are using a custom user registry for security with a WebSphere Portal Express cluster, complete the following steps to ensure that your security configuration is set up properly:

  1. Ensure that you have copied the WMM binary files from one of the WebSphere Portal Express nodes in the cluster to the deployment manager machine. Instructions for doing this are provided in Configuring security.

  2. Because all nodes being managed by a deployment manager must have the same security settings, perform additional configuration for any nodes in the cell that are running WebSphere Application Server without WebSphere Portal Express, so that they are also using the custom user registry for security.

    1. Copy the wasextarchive.jar file created as part of the previous step to the installation root directory of the WebSphere Application Server node.

    2. Stop WebSphere Application Server.

    3. Unjar the contents of the wasextarchive.jar file in the WebSphere Application Server installation directory.

    4. Verify that the WMM binary files (wmm*.jar) are in the app_server_root/lib directory.

    5. Restart WebSphere Application Server.

 

8: Manually editing Member Manager files on a federated node

If WebSphere Portal Express is installed on a federated node and you want to manually edit the Member Manager configuration, first check out the Member Manager files from the deployment manager configuration repository, according to the following instructions:

  1. On the primary node of the WebSphere Portal Express cluster, check out the files:

    • Windows and Linux:

      Run the following command from the portal_server_root/config directory:

      • Windows:

        WPSconfig.bat check-out-wmm-cfg-files-from-dmgr

      • Linux:

        ./WPSconfig.sh check-out-wmm-cfg-files-from-dmgr

    • i5/OS:

      Run the following command from the UserData directory path portal_server_root/config: 

      WPSconfig.sh -profileName profile_root check-out-wmm-cfg-files-from-dmgr
      where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal Express is installed; for example, wp_profile.

  2. Make any changes to the Member Manager files. The files can be edited in the portal_server_root/wmm directory on the WebSphere Portal Express node.

  3. If the wmm.xml file references any files that are not in the following list, ensure that you copy the referenced files manually to the deployment manager machine and each node in the cluster.

    • wmm.xml

    • wmmAttributes.dtd

    • wmmAttributes.xml

    • wmmAttributesDescription.xml

    • wmmAttributesMap.dtd

    • wmmDBAttributes.xml

    • wmmDBAttributesDescription.xml

    • wmmLAAttributes.xml

    • wmmLDAPAttributes.xml

    • wmmLDAPServerAttributes.xml

    • wmmur.xml

    • wmmWASAdmin.xml

  4. When you have completed your changes, check the files back in:

    • Windows and Linux:

      Run the following command from the portal_server_root/config directory:

      • Windows:

        WPSconfig.bat check-in-wmm-cfg-files-to-dmgr

      • Linux:

        ./WPSconfig.sh check-in-wmm-cfg-files-to-dmgr

    • i5/OS:

      Run the following command from the UserData directory path portal_server_root/config: 

      WPSconfig.sh -profileName profile_root check-in-wmm-cfg-files-to-dmgr
      where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal Express is installed; for example, wp_profile.

  5. The Member Manager changes will be replicated to the other cluster nodes the next time the cluster is synchronized.

 

Parent topic:

Clustering and WebSphere Portal Express