Sun Java System Reference Configuration Series: Portal Service on Application Server Cluster

Previous: Chapter 5 Implementation Module 2: Access Manager With Session Failover on Application Server
Next: Setting Up an Application Server Cluster Node on ps1

Overview of the Portal Service Module

The portal service module of the reference configuration's deployment architecture illustrated in Figure 2–2consists of two instances of Sun Java System Portal Server running on two different computers. The module makes use of a hardware load balancer that is configured to provide service failover capability between the two Portal Server instances. All requests for portal services are addressed to the virtual service name and IP address of the load balancer. The load balancer directs each request to one of the two Portal Server instances.

This module implements portlet session failover. When a user logs in and is authenticated by the Access Manager service, the load balancer routes the portal request to one of the Portal Server instances, which builds and returns a Portal Desktop to the user. As the user accesses various portal channels and portlet applications from the desktop, the requests from the user are routed to the same Portal Server instance. Portlet session state is maintained by the web container supporting the Portal Server instance.

If the Portal Server instance fails, the system recovers as follows:

Service Failover. Subsequent requests are routed by the load balancer to the other Portal Server instance.
Portlet Session Failover. The new Portal Server instance rebuilds the Portal Desktop by using the Access Manager session state and retrieves portlet session state from a high availability database, thus making the service failover transparent to the user.

Portlet session failover depends upon high availability mechanisms provided by the web container. Hence, portlet session failover for the portal service module is achieved by using an Application Server cluster and its High Availability Session Store (HADB).

The architecture of the portal service module is shown in the following illustration.

Figure 6–1 Portal Service Module

Illustration of the portal service module as described
in the text.

The Portal Server instances run in a web container that is provided by Application Server. Each Portal Server instance runs in an Application Server instance on its respective computer. The instances are managed by Application Server node agents that are acting on behalf of the Domain Administration Server (DAS).

As shown in Figure 6–1, the Portal Server instances together constitute a single portal service, pstestPortal.

Also indicated in Figure 6–1 is that the Application Server instances are configured to operate within the context of an Application Server cluster. The cluster provides for high availability through an HADB cluster consisting of an HADB instance on ps1 and ps2.

The module also includes two components that are not replicated and therefore represent single points of failure:

Java DB. Java DB is the default relational database that is used to support Portal Server features such as the search engine, community membership, and portlet sample applications (wiki, survey, and filesharing). However, Java DB cannot be configured for high availability.

If support for communities is required in your deployment, you can switch to another relational database that can be configured for high availability. For example, instructions for configuring Portal Server to use Oracle RDBMS can be found at the Sun Developer Network web site (http://developers.sun.com/portalserver/reference/techart/databases.html).
Portal Server's Search engine. In most architectures, a single search instance is deployed on a dedicated node and is accessed by all Portal Server instances. However, for simplicity, the search instance is deployed in this module in a separate, non-clustered Application Server instance on ps1. It is not possible to have multiple instances of the search engine using the same database (not shown in Figure 6–1) and at the same time be accessible through a load balancer. As a result, if the search instance fails, the search channel and the subscriptions and collaboration services, which depend upon Java DB, will become inoperative.

The general approach to implementing this module is to first set up the Application Server cluster (plus an additional Application Server instance in which to deploy the search instance), and then to install, deploy, and configure the pstestPortal portal within the cluster. In setting up the cluster, the Java ES installer is run in Configure Now mode to install and configure Application Server, HADB, and Access Manager SDK. In setting up the pstestPortal portal, the Java ES installer is run in Configure Later mode to install Portal Server, Java DB, and Service Repository libraries. Following these procedures, load balancing is implemented to provide portal service failover. Then portlet session failover is set up.

This module can be scaled horizontally by adding an additional computer like ps2 and its respective components, and following the instructions in this chapter that apply to ps2.

Note –

The procedures in this chapter use the host names, domain name, and IP addresses shown in Figure 3–1 and Figure 6–1. However, you must map these host names, domain name, and IP addresses to equivalent names and addresses in your environment. For this reason, the procedures in this chapter show host names, domain name, and IP addresses as variables.