Last, we must enable our Portals to accept the dynamic cache replication that we enabled when we created the cluster. In a normal Web application you wouldn't have to do this, but this isn't a normal Web application after all.

If this step is not completed, situations could occur in which users have different views or different access rights, depending which cluster member handles the user's request.

On WAS1, execute the following:

WPS_HOME\config\WPSconfig.bat action-set-dynacache
-DserverName=cluster_member -DReplicatorName=replicator_name

In this syntax, the value of cluster_member is the name of the cluster member to update, in this case the cluster member on WAS1. The value of replicator_name is the name of the cluster member with which to replicate, in this case the cluster member on WAS2.

Be sure to run the same command (but with the values reversed) on the WAS2 node.

After making the configuration changes detailed above, it would be a good idea to do a Full Synchronization of all the changes. This will instruct the Deployment Manager to copy any and all changes out to the two federated nodes via the nodeagents.

In the admin console, select System Administration > Nodes, select the two nodes from the list, and click Full Resynchronize. The admin console will display a message indicating that a request for full synchronization has occurred successfully. Be sure to check to the status messages in the Runtime Messages panel at the bottom of the screen to be sure that the request completed successfully.

We haven't really talked about a remote HTTP server to handle static content and the incumbent installation and configuration of the WebSphere Plugin, but that's really incidental to clustering Portal. Suffice it to say that the plug-in located on the remote Web servers will contain knowledge of the two Portal cluster members and will route traffic to them based on the policies set in the cluster administration area of the Admin Console.

HTTP Session Replication
When dealing with a cluster, once a user creates a session with a portal by logging in, the user is returned to that WebSphere Portal cluster member for the rest of his session. There's a portlet in the global settings section of the Portal Administration panel that will tell you which cluster member is handling the current session.

The cluster member currently handling the session is referred to as the session owner. If this cluster member were to fail, then the plug-in on the Web servers will route the next request to another cluster member. The new cluster member either retrieves the session from a server that has the backup copy of the session or it retrieves the session from its own backup copy table. The server now becomes the owner of the session and affinity is now maintained to this server.

Whenever a session is modified in any of the cluster members, that session data is replicated to each of the other members of that cluster. So in our example, WAS1 would replicate the session with WAS2. By default, in a cluster the sessions are replicated to each of the cluster members that are using same replicator domain (defined when the cluster was created).

However, because this gets defined during the creation of the cluster and not the cluster member (AppServer) itself, we must go back and tell the Web container on each cluster member's AppServer that it should use this replication domain to store session data.

To enable this "memory-to-memory" session replication:

a.  Click Application Servers > WebSphere_Portal > Web Container > Session Management
b.  Click Distributed Environment Settings under Additional Properties
c.  Select Memory to Memory Replication
d.  Click Apply
e.  Repeat these steps for each cluster member

Save the changes to the Deployment Manager master config and synchronize the changes. Restart the cluster members for replication to take effect. You're all set! No fear now of losing a session.

Clustered!
Now that you have a functioning cluster of Portal servers, you may be tempted to believe that nothing will ever go wrong and that your life as a portal admin is worry-free. You have every reason to believe this. Your Portal cluster is highly available, it is running on the industry's leading application server, it is extremely powerful and flexible, but there are some inherent frailties to be aware of. And we'll discuss them next month!

Hopefully you'll come back to hear about some practical techniques for managing real-world portal clusters. This is stuff that you probably won't find in the InfoCenter.

Speaking of the InfoCenter, there's good information regarding the establishment of a Portal cluster currently located at http://publib.boulder.ibm.com/pvc/wp/510/ ent/en/InfoCenter/wpf/clus_install.html.