Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, hyper filter, Timothée Bensimon

Related Topics: WebSphere

IBM WebSphere software products: Article

Your Guide to Portal Clustering in WebSphere Portal Server 5.1

WebSphere Portal Server 5.1

Remote Database
For the Portal on the federated node WAS1 to share its configuration information with any additional Portal nodes we choose to install, we must transfer its configuration to an external datastore such as a remote DB2 or Oracle database.
For the sake of this exercise, we’ll assume that you’ve configured a remote DB2 database, as defined in the Portal Infocenter, to accept the Portal configuration data. We’ll also assume that you’ve followed the appropriate steps in the Infocenter to transfer the Portal configuration data to that remote database.

This is a fairly straightforward step and is the same whether you are clustering Portal or not. It involves exporting the Portal configuration data from the bundled Cloudscape database running locally on WAS1:
The WPS_HOME\config\wpconfig.properties file is then edited to reflect the necessary database settings for the remote database instance. Then the data is loaded to this remote database by invoking:


The wpconfig.properties file is read and the data is written out to the remote database server.

Voila, database export/import complete.

The configuration steps for enabling Portal security and WebSphere Global Security are largely the same whether you’re talking about a cluster or a standalone environment. However, there are some key differences. For this example, we’ll assume that you’ve chosen to enable security for the Portal and that the user directory will be a remote IBM Directory Server (LDAP). We’ll also assume that LDAP is set up properly with the necessary users for the Portal.

First, edit the wpconfig.properties file on WAS1 as detailed in the Infocenter. Then execute:
This will set up the security for the Portal and put the details in the Portal’s configuration now stored in the remote database. It will also enable Global Security for the Deployment Manager and both federated nodes WAS1 and WAS2. A restart of the nodeagents on both WAS1 and WAS2, the DM, and the Portal AppServer on WAS1 will put the security policy into effect.

Portlet Install & Activation
During the installation process, the default portlets will be installed via the Deployment Manager as if they were any other WAR files. However, portlets are special forms of Web applications that require an additional step called activation. This step will tell the portal configuration that the portlet is available for general use. Since this isn’t a normal step for installing a Web application, the Deployment Manager is unable to activate the portlets during the install process. We must do that manually via the command line.

This must be done on the primary node only (WAS1):
WPS_HOME\config\WPSConfig.bat  portlets –DPortalAdminPwd=password
Of course, because security is enabled, we must provide the Portal Admin password when invoking these commands.
  bat activate-portlets –
You’ll see the called ANT tasks activating each of the default portlets (including the all-important admin portlets) and indicating whether or not they’re ready for use. The “active” status is a state that’s defined in the Portal repository currently stored locally on WAS1.

Without this step, you won’t see any portlets on the Portal home page and won’t be able to administer the Portal.

Ensuring that the Portal continues to function after this step is crucial. You can do this simply by logging into the Portal running on WAS1. If you can log in without errors and browse the Portal, then you’re good to go to the next section.

Technically you could stop at this point, skip the next section, and go straight to creating the cluster itself. This would end up giving you a vertical cluster of multiple Portals installed on WAS1. This would be a perfectly fine Portal cluster, but in the event that the WAS1 server itself imploded, you would lose all your Portals in one shot. Horizontal clustering is really where it’s at when it comes to high availability. So read on!

The Second Node
We should now be able to coast the rest of the way toward our cluster. By this point, the heavy lifting has been done and we’re ready to add in the second Portal to WAS2.
As noted earlier, we’ll be installing a secondary node on WAS2. This will install the requisite Portal files but will leave out the default portlets since we’ll be using the ones already installed in the Cell (the ones derived from WAS1).
  1. Execute the installer on WAS2.
  2. When prompted, select Custom.
  3. When prompted, select Secondary node.
  4. The installation program will detect that WebSphere Application Server security is enabled and give you the option of continuing the installation without configuring the WebSphere Portal. Click Next.

Installing the secondary node bypasses the portlets installation since it will be using the ones that were installed on WAS1.

Once the installation is complete, we must tell this Portal node that security is enabled by editing the WPS_HOME\config\wpconfig.properties file on WAS2. We want the security-related parameters to match what we configured on WAS1. Refer to the InfoCenter for the list of relevant parameters for this step (there are a lot of them).

Once we’re certain that we have the correct values for security, we want to execute the following task on WAS2:
This command will secure the newly installed Portal with the same values used for WAS1 but without affecting the WebSphere Global Security definitions on the Deployment Manager. Restart the Portal on WAS2 for the security settings to take effect.

More Stories By Chris Lockhart

Chris Lockhart is a senior technical resource at Perficient, a firm recognized for its expertise around IBM technologies. Chris has worked with IBM's WebSphere, Tivoli and Lotus Software platforms for more than 6 years. For more information, please visit www.perficient.com

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.