HCL WebSphere Portal roadmap: Multiple clusters

HCL WebSphere Portal roadmap: Multiple clusters

Add an HCL WebSphere Portal cluster to an existing cluster.
To manage appservers and clusters within a single administrative domain or cell, or to manage multiple portals within the same managed cell, we can add a cluster to an existing cluster.

Read Plan for multiple clusters.
Configure the web server plug-in after transfering the database.

Topology example
This topology depicts two portal clusters that share a cell. One deployment manager manages the cell. Each cluster has an individual database for the JCR and Release portal database domains. The clusters share a common database server that has the Community, Customization, LikeMinds, and Feedback portal database domains. The clusters also share an LDAP server and a remote search server. There is a search collection for each cluster, but the collections are co-located on a single server. The release and JCR databases are separate. A network load balance directs incoming traffic between the two web servers. Each cluster has a web server. However, a single on-demand router might be used instead.
Maintenance and application updates, including updates to portlet preferences, are applied separately to each cluster.

Prepare

Gather information and software before installing HCL WebSphere Portal.

Check product system requirements.
Log in to HCL Software Support and get the software.

Prerequisites

We can use existing prerequisite software installations. Verify that your existing version is supported. If it is not, upgrade to the appropriate version. Otherwise, install a web server, database server, and user registry server. Typically the database and user registry servers are already installed and configured. However, there might be specific configuration steps that are required to integrate them with the portal server. Visit Install and prepare the prerequisite software for more topic information.

Install a web server.
Prepare a database server.

Prepare a user registry.

Install the HCL WebSphere Portal

Install HCL WebSphere Portal involves preparing the operating system, installing or upgrading the installation manager, and running the installation program. Visit Install the HCL WebSphere Portal software for more topic information.

Apply the latest cumulative fix

Portal maintenance is delivered through individual fixes (Fixes) and Combined Cumulative Fixes (CFs), which is recommended to the environment.
Roadmap: applying maintenance

Create cluster A

Create the first cluster, including the database transfer, augmenting the Deployment Manager, creating a cluster node, enabling security, and creating additional horizontal cluster nodes. These instructions are for a horizontal cluster only. For information on setting up a vertical cluster, see Set up a Cluster.
Log in to HCL WebSphere Portal to verify that we have a working portal:
http://hostname.example.com:10039/wps/portal

10039 is the default transport port that is created by DX Application Server.

To get the latest updates for the wizard, apply the most recent Combined Cumulative Fix.
Access the Configuration Wizard
http://your_server:10200/hcl/wizard

If you experience difficulties accessing the wizard, try a different browser.
Log in to the wizard with the cw_profile admin ID.
Select Set Up a Cluster > Database Transfer.
The Database Transfer configuration option in the Configuration Wizard:

Assigns users and permissions
Creates databases
Obtains support for database collation
Transfers the database

Provide information about the environment.
Record the database settings to use with create Portal B. If cluster A exists, upgrade it to match Portal B.
Important: Maintain the same number of data sources with identical names to the Cluster A data sources. Then, the data source bindings in the applications can be resolved on every cluster. If you share databases across the clusters, this statement refers to both the shared and non-shared domains. All domains must use the same names. For example, if Cluster A uses relDS comDS custDS jcrDS fbkDS lmDS, then Cluster B must also use six data sources with the same names. Cluster B cannot be configured to use a single data source. An enterprise application that is shared between cluster contains only a single binding to a single data source name. An application cannot contain a binding to multiple data source names. If the data source names are the same and the user ID and password are the same, then the extra aliases are not required. The binding in the application resolves to the data source for both clusters because the name is the same and the user ID and password is the same.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.
Select Set Up a Cluster > Create a Deployment Manager.
Provide information about the environment.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Optional: If we changed the context root during the installation or configuration of HCL WebSphere Portal, then complete the optional next step from the Configuration Wizard to update parameters with the new context path after after completing Create a Deployment Manager configuration option.
Log in to HCL WebSphere Portal to verify that we have a working portal server.
Select Set Up a Cluster > Create a Cluster.
Provide information about the environment.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.
Set Up a Cluster > Enable Federated Security.

Note: If you set Use Administrator IDs stored in the LDAP user registry to yes, the WebSphere Application Server and HCL WebSphere Portal user IDs and passwords are changed to the LDAP user ID and password. If we do not want to change both user IDs and passwords to match the LDAP user ID and password, set this value to no. After we configure the LDAP user registry, we can manually change the user IDs and passwords.
Provide information about the environment.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.
Install HCL WebSphere Portal on the additional node.
Tip: For additional nodes, we only need to install the HCL WebSphere Portal product binary files. Therefore, on the Features screen of the IBM Installation Manager, ensure that Portal Server Profile is not selected.
Optional: To shorten the site URL for search engine optimization benefits, we can modify your context root and remove navigational state information from your URL using the Modify Site URLs for SEO configuration option.
Set Up a Cluster > Create an Additional Cluster Node.
Note: If we are setting up a vertical cluster, manual instructions are available for dynamic and static cluster configurations.
Provide information about the environment.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.

Configure portal B

Install HCL WebSphere Portal. Then, use the Configuration Wizard to deploy a stand-alone portal.
Log in to HCL WebSphere Portal to verify that we have a working portal:
http://hostname.example.com:10039/wps/portal

Access the Configuration Wizard:
http://your_server:10200/hcl/wizard

For HCL DX v8.5 or 9 software level prior to CF18, the wizard address will be:
http://your_server:10200/ibm/wizard

After installing CF18, the configuration wizard will automatically be adjusted to http://your_server:10200/hcl/wizard.
Log in to the Configuration Wizard with the administrative ID for the configuration wizard profile, cw_profile.
Note: If the language is not currently supported for the user interface, we might see the English version. For details on supported languages and the language codes for all of the HCL WebSphere Portal user interfaces, see Supported languages.
Select Set Up a Stand-alone Server > Database Transfer.
Provide information about the environment.
Important: Maintain the same number of data sources with identical names to the Cluster A data sources. Therefore, the data source bindings in the applications can be resolved on every cluster. If you share databases across the clusters, this statement refers to both the shared and non-shared domains. All domains must use the same names.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.
Select Set Up a Stand-alone Server > Enable Federated Security.
Note: If you set Use Administrator IDs stored in the LDAP user registry to yes, the WebSphere Application Server and HCL WebSphere Portal user IDs and passwords are changed to the LDAP user ID and password. If we do not want to change both user IDs and passwords to match the LDAP user ID and password, set this value to no. After we configure the LDAP user registry, we can manually change the user IDs and passwords.
Provide information about the environment.
Save the configuration settings.

Choose one of the following options:

Click Download Files to run the steps remotely.
Click Run All Steps to run the steps locally.

Log in to HCL WebSphere Portal to verify that we have a working portal server.

Configure the multiple cluster

After you create cluster A and portal B, run the various tasks to create the multiple cluster.

Optional: Complete the following steps on the primary node of Cluster A:
Use the same database user ID and password for each identically named domain or data source. It allows the existing JAAS Authentication Aliases to be functional. If a unique database user ID and password are required, more manual configuration is required to create and map JAAS Authentication Aliases for each data source.

Open a command prompt.
Change to the wp_profile_root/ConfigEngine.
Create the JAAS Authentication Aliases:

./ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr -DWasPassword=dmgr_password

Where authDomainList is set to a list of domains that use unique database user ID and passwords. The domain properties are set correctly in the wkplc_dbdomain.properties file, including user ID and password.

Optional: If necessary, upgrade Portal B to the current fix pack.
Complete the following steps to create an inventory list of Portal B enterprise applications and portlets:

Open a command prompt on Portal B.
Change to the wp_profile_root/ConfigEngine.
Create the list:

./ConfigEngine.sh mapped-app-list-create -DWasPassword=password

Federate Portal B:
cd wp_profile_root/bin
./addNode.sh dmgr_hostname dmgr_port -includeapps -username was_admin_user -password was_admin_password

...where...

dmgr_hostname is the TCP/IP host name of the Deployment Manager server
dmgr_port is the SOAP port number of the Deployment Manager server
was_admin_user and was_admin_password are the user ID and password for the Deployment Manager administrator

If the WebSphere Application Server administrator user ID and password are different from the Deployment Manager values, add the following parameters to the addNode task:

-localusername local_was_admin_user
-localpassword local_was_admin_password

Tip: Read addNode command for information about the addNode command and other optional parameters.Warning: If the addNode task fails for any reason, complete the following steps before you rerun the task:

Remove the node if the AddNode task succeeded in creating the node.

If the items exist, log on to the deployment manager and complete the following steps:

Remove the HCL WebSphere Portal server definition.
Remove the HCL WebSphere Portal JDBC Provider.

Stop the HCL WebSphere Portal server on the primary node of Cluster B and ensure that the following parameters are set correctly in the wkplc.properties file:
Note: We can add these parameters (particularly passwords) directly to any task. However, we might want to temporarily add them to the properties file. We can then remove them when we are finished to keep the environment secure.

Set WasSoapPort to the port used to connect remotely to the deployment manager.
Set WasRemoteHostName to the full host name of the server used to remotely connect to the deployment manager.
Verify that WasUserid is set to the Deployment Manager administrator user ID.
Verify that WasPassword is set to the Deployment Manager administrator password.
Verify that PortalAdminPwd is set to the HCL WebSphere Portal administrator password.
Verify that ClusterName is set.
Verify that PrimaryNode is set to true.

Determine which applications from the inventory list are no longer mapped to Portal B. The task uses the application profiles in the cell to restore the mappings. Wait 30 minutes after we run this task to allow all EAR files to expand before you proceed to the next step.

AIX Linux : ./ConfigEngine.sh map-apps-to-server -DWasPassword=password
Windows : ConfigEngine.bat map-apps-to-server -DWasPassword=password

Ensure that all database parameters are correctly set, including passwords, in the wkplc_comp.properties and wkplc_dbtype.properties files on Portal B.
Run the following task on Portal B:

AIX Linux : ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=password
Windows : ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=password

The HCL WebSphere Portal node is federated. It uses the Deployment Manager cell and its user registry. If the administrative user ID and group name are different between HCL WebSphere Portal and Deployment Manager, choose one of the following options:

Add the existing administrative user ID and group to the Deployment Manager security configuration
Complete the following steps to change the values in the HCL WebSphere Portal configuration to match the Deployment Manager values:

Start the HCL WebSphere Portal server.
Verify that the required HCL WebSphere Portal administrative user ID and group ID are defined in the Deployment Manager user registry that provides security.
Run the following task:

AIX Linux : ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
Windows : ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
Where:

WasPassword is set to the administrative password for the Deployment Manager cell
newAdminId is set to the fully qualified distinguished name (DN) of the HCL WebSphere Portal administrative user ID in the cell
newAdminGroupId is set to the fully qualified DN of the group for the HCL WebSphere Portal administrative user ID in the cell
Important: If the value for newAdminGroupId contains a space; for example, Software Group, open the wkplc.properties file. Add the values for newAdminId, newAdminPw, and newAdminGroupId. Save changes and then run the wp-change-portal-admin-user task.

After the task completes, stop the HCL WebSphere Portal server.

Complete the following steps from the WebSphere Integrated Solutions Console on Portal B:

Log on to WebSphere Integrated Solutions Console.
Click System Administration > Node Agents.
Check the box next to the required node agent and then click Restart.

Stop and restart the deployment manager.

Stop and restart the HCL WebSphere Portal server on Portal B.
Restart the HCL WebSphere Portal server on Cluster A. Verify that Cluster A is functionally intact; check pages and portlets. Verify that Portal B is functionally intact; check the pages and portlets that we deployed into Portal B before it was federated. Any discrepancies or errors must be corrected before you continue.
Note: If Portal B has an administrative ID other than wpsadmin, the server is not functional. It is functional after the cluster is complete and the administrative ID is configured to match the security settings.
Choose one of the following options to define a cluster with Portal B as the basis:

To define a static cluster:

Run the following task:

AIX Linux : ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password
Windows : ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=dmgr_password

Configure the cluster to use an external web server to take advantage of features such as workload management. Go to Configure a web server and an application server on separate machines (remote) for information.
Note: Start with the step about starting the plug-ins installation wizard.

To define a dynamic cluster:

Log on to the deployment manager WebSphere Integrated Solutions Console.
Complete the following steps to create a node group:

Click System administration > Node groups.
Click New.
Type the node group Name.
Type any information about the node group in the Description text box.
Click OK.
Click the Save link to save changes to the master configuration.

Add members to the node group:

Click System administration > >Node groups.
Click the name of the node group that we want to add members to.
Click Node group members under Additional Properties.
Click Add.
Select the primary node and then click Add.
Click the Save link to save changes to the master configuration.

Complete the following steps to create a dynamic cluster in the node group:

Click Servers > Clusters > Dynamic clusters.
Click New.
Select WebSphere Application Server from the Server Type menu and then click Next.
Select Automatically define cluster members with rules.
Type the cluster name in the Dynamic cluster name text box. Then, click Next. Type the same value that you provided for the ClusterName parameter in the wkplc.properties file of your primary node.
Remove all default membership policies and then click Subexpression builder.
Enter the following information in the Subexpression builder window:

Select and from the Logical operator menu.
Select Nodegroup from the Select operand menu.
Select Equals (=) from the Operator menu.
Type the node group name that you created in the previous step in the Value text box.
Click Generate subexpression.
Click Append.

Click Preview membership to verify that all nodes included in the node group display and then click Next.
Click Create the cluster member using an existing server as a template and then select the primary node HCL WebSphere Portal server.
Click Next.
Specify the dynamic cluster properties for the minimum and maximum number of server instances.
Review the summary page to verify your actions and then click Finish.
Create the dynamic cluster:

AIX Linux : ./ConfigEngine.sh cluster-node-config-dynamic-cluster-setup -DWasPassword=dmgr_password
Windows : ConfigEngine.bat cluster-node-config-dynamic-cluster-setup -DWasPassword=dmgr_password

Access the Web Content Manager content through an external web server:

Log on to the deployment manager WebSphere Integrated Solutions Console.
Select Environment > WebSphere Variables.
From the Scope menu, select the Node=nodename, Server=servername option to narrow the scope of the listed variables. Node=nodename is the node that contains the HCL WebSphere Portal application server.
Update the WCM_HOST variable with the fully qualified host name used to access the HCL WebSphere Portal server through the web server or On Demand Router.
Update the WCM_PORT variable with the port number used to access the HCL WebSphere Portal server through the web server or On Demand Router.
Update the WCM_HOST and WCM_PORT variable for each additional HCL WebSphere Portal application server that exists in the cluster.
Synchronize the node with the deployment manager.
Save changes and then restart the deployment manager, the node agents, and the HCL WebSphere Portal servers.

Install any additional nodes for Cluster B. Then, federate them as secondary nodes and define them as cluster members on these nodes. We can add more nodes to a static or dynamic cluster. We can also add more vertical cluster members to an existing node in a static or dynamic cluster to provide vertical scaling.
Restart the HCL WebSphere Portal server on Cluster A and Cluster B.
After you set up your multiple clusters, complete the extra tasks to ensure a balanced workload and failover support.

Update the web server configuration to enable user requests to be routed to the new cluster. Refer to the web server documentation for information about using a web server with multiple clusters in a cell.
Update the database configuration to share database domains between clusters.

If you entered passwords in any of the properties files when we created the cluster, remove them for security purposes.
Deployment of Cluster B is complete. It is now an independent cluster from Cluster A, which means that Cluster B can have its own configuration, set of user portlets, and target community. Any applications that are common between Cluster A and Cluster B are most likely infrastructure or related to administration. Special care must be taken to preserve their commonality between clusters and correct maintenance levels.

Configure the web server
Move the web server plug-in from the WebSphere Application Server to the web server.

Tune the servers in the environment

Tune the servers is important to the performance of the portal environment. HCL WebSphere Portal is not tuned for a production environment after installation and deployment. The database needs tuning for improved performance. We can organize the database now or soon after finishing the configuration. You need to tune and maintain the database on a regular basis.

Run the performance tuning tool to complete an initial tuning of your servers.
Check the tuning guide for more instructions. Use the tuning guide for the previous product version when the tuning guide for the current release is unavailable.

Configure a remote search service

Configure the remote search service to offload and balance system load.

Use the IBM Installation Manager to install the remote search service using the IBM Installation Manager.

If we use single-sign on, prepare the security for the remote search service.
Configure the security between portal and the remote search server.
Set the search user ID.

Configure the remote search service.

Configure the seedlist servlet.

Parent topic: HCL WebSphere Portal Roadmaps for advanced configurations