Perficient

Digg This!

Page 2 of 3   « previous page   next page »

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:

WPS_HOME\config\WPSconfig.bat

  database-transfer-export

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:

WPS_HOME\config\WPSconfig.bat
  database-transfer-import

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

Voila, database export/import complete.

Security
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:

WPS_HOME\config\WPSconfig.bat 

  enable-security-ldap 

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.

WPS_HOME\config\WPSConfig.

  bat activate-portlets –

  DPortalAdminPwd=password

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:

WPS_HOME\config\WPSconfig.bat 

  secure-portal-ldap

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.

Page 2 of 3   « previous page   next page »