Page 2 of 4   « previous page   next page »

Installation of Portal
Our plan is to install Portal first on WAS1, do some basic configuration then install what's called a "secondary" Portal on WAS2. Prior to installing Portal anywhere, however, we must ensure that the WAS1 and WAS2 nodes have any and all patches/efixes required by the release of Portal that we're installing. In our example, we're going to install version 5.1 of Portal.

At this point you go ahead and install Portal on WAS1. This is a custom install. You'll be choosing the Application Server that's already installed on this node and federated into the cell. The installer will recognize that this is a federated node and will prompt you to select whether this is a primary or secondary node. Since this is the first install, you must select primary node. The installer will interface with the Deployment Manager controlling this node and install the appropriate files.

1. Execute the installer on WAS1
2. Agree to the terms. Click Next. (See Figure 4.)
3. Select Custom, click Next. (See Figure 5.)
4. Select the instance that you want to use from the list. If the installation program doesn't detect an instance of WebSphere Application Server but you know that it's on the machine, you can enter the directory path to the WebSphere Application Server. Click Next. (See Figure 6.)
5. Select Primary and click Next. (See Figure 7.)
6. Specify the directory where you want to install WebSphere Portal. Click Next. (See Figure 8.)
7. Verify the components to be installed and click Next.
8. When the installation is finished, the installation program displays a confirmation panel listing the components that have been installed.
9. Click Finish.

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're 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\wp-config.properties file is then edited to reflect the necessary database settings for the remote database instance. The data is then 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 Portal and that the user directory will be a remote IBM Directory Server (LDAP). We're also assuming here that LDAP is set up properly with the necessary Portal users.

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 security for the Portal and put the details in the Portal's configuration now stored in the remote data-base. It will also enable Global Security for the Deployment Manager and both federated nodes WAS1 and WAS2. By re-starting the nodeagents on both WAS1 and WAS2, the DM and the Portal AppServer on WAS1 will put our security policy into effect.

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

This must be done only on the primary node (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 to use. The "active" status is a state 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 imploded you'd lose all of your Portals in one shot. Horizontal clustering is really where it's at when it comes to high availability. So read on!

Page 2 of 4   « previous page   next page »