Version 6.0.1 and later WebSphere

 

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

 

Install multiple clusters in a single cell

This topic describes how to federate a new, independent profile into a cell where a cluster already exists, ensure that the resulting portal is still functional, build a cluster from this new profile, and use WebSphere Application Server administration to determine what applications are shared between clusters.

For these steps, Cluster A will be used to describe the existing cluster. Portal B will be used to describe the new server profile that will serve as the basis for the new cluster definition, Cluster B.

  1. Cluster A must be upgraded to the current version, since the new cluster to be defined, Cluster B, will be at the same version level. All clusters must be at the same maintenance level. Also, presuming the current version includes the latest WebSphere Application Server service update requirements, these updates must also be applied to the Deployment Manager node (for example, updating from WebSphere Application Server Version 6.0.2.9 to Version 6.0.2.15).

    Cluster A is probably using several cell-scoped resources, such as datasource definitions for database access. These can remain cell-scoped as the resources for Portal B, and eventually Cluster B will be cluster-scoped as appropriate and thus will override the cell-scoped resources. However, you may use the following configuration tasks native to Version 6.0.1 to reconfigure cell-scoped resources to be cluster-scoped, to ensure visibility of these resources remain cluster-specific.

    Run the following remove and create configuration tasks on the Primary Node in Cluster A:

    • Windows:

      • Remove: WPSconfig.bat action-remove-all-jdbc-providers -Dwps.current.jdbc.scope=Cell

      • Create: WPSconfig.bat action-create-all-jdbc-providers –Dwps.current.jdbc.scope=Cluster

    • Linux:

      • Remove: WPSconfig.sh action-remove-all-jdbc-providers –Dwps.current.jdbc.scope=Cell

      • Create: WPSconfig.sh action-create-all-jdbc-providers –Dwps.current.jdbc.scope=Cluster

    • i5/OS:

      • Remove: WPSconfig.sh action-remove-all-jdbc-providers –Dwps.current.jdbc.scope=Cell

      • Create: WPSconfig.sh action-create-all-jdbc-providers –Dwps.current.jdbc.scope=Cluster

  2. Install Portal B as a standalone portal profile. See the topic Installing WebSphere Portal Express on an unmanaged node (primary) for details. This step should include configuring security to match the target cell’s configuration, setting up the desired database configuration, and setting up the initial portal site configuration (pages and portlets).

  3. Update Portal B to the current version, in order to get the configuration support necessary to inventory and remap common applications in the cell.

  4. Cell-scoped resources will become cluster-scoped as a result of creating the cluster.

  5. After validating the functionality and content of Portal B, use the action-mapped-app-list-create configuration task to build an inventory of enterprise applications and portlets that Portal B uses.

    • Windows and Linux:

      Run the following command from the portal_server_root/config directory:

      • Windows:

        WPSconfig.bat action-mapped-app-list-create

      • Linux:

        WPSconfig.sh action-mapped-app-list-create

    • i5/OS:

      Run the following command from the portal_server_root_user/config directory: WPSconfig.sh action-mapped-app-list-create

  6. Ensure that Portal B is designated as the primary node, which is a term to indicate that this profile will be used as a basis for a cluster definition.

    1. Modify the following file for your operating system:

    2. Set the property value PrimaryNode=true.

  7. Federate Portal B into the cell using the addNode command. Be sure to specify the -includeapps option on the command, to indicate that all applications in this new node (used by Portal B) will also be federated into the cell. For details on using the command and that option refer to addNode command. The addNode command will report the progress of the federation process. As the applications defined in the node in which Portal B is configured are being added in the cell, the addNode command will report if any of these applications already exist in the cell, and if so, the duplicates are dropped. After federation completes, applications that already existed in the cell are no longer mapped to Portal B, with the result that Portal B is incomplete, and most likely non-functional. These missing applications must now be restored.

  8. Use the action-map-apps-to-server task to iterate through the application inventory collected in a previous step and determine which applications are no longer mapped to Portal B.

    • Windows and Linux:

      Run the following command from the portal_server_root/config directory:

      • Windows:

        WPSconfig.bat action-map-apps-to-server

      • Linux:

        WPSconfig.sh action-map-apps-to-server

    • i5/OS:

      Run the following command from the portal_server_root_user/config directory: WPSconfig.sh action-map-apps-to-server

    This configuration task restores the mapping using the application profiles already in the cell.

    These existing application profiles must be at the required service level and must be compatible with Portal B.

  9. Update the deployment manager configuration for the new WebSphere Portal Express.

    The post-portal-node-federation-configuration task requires complete and accurate database information in the wpconfig_dbdomain.properties file. Before running the task, ensure that the database properties are correct and that password values are specified.

    1. Run the post-portal-node-federation-configuration task.

    2. After the post-portal-node-federation-configuration task is complete, wait at least 30 minutes and then restart the node agent on the WebSphere Portal Express node.

      After this task is complete, the Node Agent runs a background thread to expand all the EAR files of the updated applications into their target directory. Attempting to restart the node agent while this EAR expansion is in process can result in conflicts which will cause an application to be unusable. Although the time to complete EAR expansion is environment-dependent, for a typical environment wait 30 minutes after the post-portal-node-federation-configuration task has completed before restarting the node agent to allow sufficient time for EAR expansion to complete.

      1. Open the administrative console, and click System Administration > Node Agents.

      2. Select the check box beside the node agent that you want to restart, and click Restart.

    3. Restart the deployment manager.

      1. Stop the deployment manager.

      2. Start the deployment manager.

        • Windows and Linux:

          startManager command

        • i5/OS:

          startManager -profileName dmgr_profile

          where -profileName is the profile of the application server process in a multi-profile installation. The -profileName option is not required when running in a single profile environment. The default for this option is the default profile.

  10. Verify that Portal B is functionally intact by spot checking pages and portlets that you deployed into Portal B before it was federated. Any discrepancies or errors should be corrected now before continuing.

  11. Define a cluster using Portal B is the basis. Refer to the topic Creating the cluster for details.

  12. If additional nodes need to be added to the cell to support additional cluster members for Cluster B, they should be installed identically to this primary node (step 2 and step 3 above), then federated as secondary nodes, then have additional cluster members defined on these nodes. Refer to the topic Installing WebSphere Portal Express on an unmanaged node (secondary) for details.
Setup of Cluster B is complete. Cluster B is now an independent portal cluster from Cluster A, which means that Cluster B can have its own configuration, set of end-user portlets, and target community. Any applications that are common between Cluster A and Cluster B are most likely infrastructure or related to administration, and special care needs to be taken to preserve their commonality between clusters and correct maintenance levels. See the topic Installing updates for multiple clusters for more details.

 

Parent topic:

Version 6.0.1 and later Setting up multiple clusters

 

Previous topic

Version 6.0.1 and later Database sharing between clusters

 

Next topic

Version 6.0.1 and later Application sharing between clusters