Page 3 of 4   « previous page   next page »

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 are ready to add a second Portal on WAS2.

As noted earlier, we'll be installing a secondary node on WAS2. This will install the requisite Portal files but leave out the default portlets since we'll be using the ones already installed on 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 performing WebSphere Portal configuration. Click Next.

Once installation is complete, we have to 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 many 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 this time without affecting WebSphere Global Security definitions on the Deployment Manager. Restart the Portal on WAS2 for the security settings to take effect.

We must also tell our new Portal node to talk to the same configuration database that's being used by the Portal on WAS1. To do this, we need to edit the wpconfig.properties file on WAS2. We want the database-related parameters to match what we configured on WAS1. Refer to the InfoCenter for the list of relevant parameters for this step.

Once the database parameters are configured in the wpconfig.properties file, put them into effect by executing:

WPS_HOME\config\WPSconfig.bat connect-database

This command will hook us up so that both Portals are reading the same configuration information.

Now we have two Portals installed, both secured using LDAP, both using the same remote data base to store config data, and both ready to be clustered.

Cluster Time
The Portal cluster is defined by using the Deployment Manager Admin Console. Log into the console and navigate to the Servers -> Clusters section of the navigation tree.

1.  Click New
a.  Define the cluster name
b.  Check the box Prefer local enabled
c.  Check the box Create Replication Domain for this cluster
d.  Check the box for "Select an existing server to add to this cluster" and then choose server WebSphere_Portal on node WAS1 from the list
e.  Check the box Create Replication Entry in this Server
f.  Click Next

2.  Create the second cluster member
a.  Define the name of cluster member (make sure it's different from the name of cluster member 1 above)
b.  Select the node WAS2
c.  Uncheck the box Generate Unique HTTP Ports
d.  Check the box Create Replication Entry in this Server
e.  Click Apply and then click Next to view the summary.

3.  To create the new cluster, click Finish

4.  Save the changes

The cluster is created! See, the actual cluster creation itself is very brief. So easy!

When we create the second cluster member above, the Deployment Manager is actually copying portlets and other configuration files from WAS1 to WAS2. It's synchronizing the nodes so they both contain the same application information. This is why we didn't have to install portlets during the Portal install on WAS2.

You may be asking yourself what the replication entries are that we're creating in this step. One of the chief benefits that the Network Deployment topology gives us is the ability to have our cluster members on WAS1 and WAS2 share information between them. This includes session information as well as dynacache information. With this step, all members in the defined Replication Domain that have Replication Entries will be able to share this valuable information.

If you're load balancing these Portals, having the user session shared between all the cluster members would be part of the high-availability configuration. If one Portal goes down, the other still has your session data active in memory. Excellent!

Tidy Up
But of course it couldn't be THAT simple. There are a few additional tasks left to perform to ensure the smooth operation of our cluster.

First, to be able to deploy portlets properly, we have to edit a file located on each of our Portal servers. This file is called DeploymentService.properties and it's located in WPS_HOME\shared\app\config\services.

Open this file up and set the wps.appserver.name property to the name of the cluster you defined in step 1a above. Save and close this file. We're done with it.

Next, we have to update the wpconfig.properties file on each Portal node with the correct cluster member information. The server name is no longer what it was when we installed Portal. Each cluster member has a specific name that we have to refer to it by. So open up the wpconfig.properties file and edit the ServerName property. Set this to match the cluster member name used in the Deployment Manager. To determine the cluster member name, click Servers > Cluster Topology in the Deployment Manager Admin Console and expand the cluster to view the cluster members.

Page 3 of 4   « previous page   next page »