Availability in the Deployment Architecture

The deployment architecture that is represented in Figure 2–2 uses several strategies to meet the availability requirements
of the reference configuration. Availability requirements fall into the two
categories that are discussed in the following sections:

Service Availability

Service availability means that a service is available,
even when a service provider fails. Service availability is generally achieved
using multiple identically configured service instances (redundancy). Redundancy
eliminates single points of failure (assuming that simultaneous failure of
all instances is extremely unlikely). If one instance providing a service
fails, another instance is available to take over. This mechanism is known
as service failover.

Service failover is supported in the reference configuration through
two mechanisms:

Load balancing. Load balancing uses redundant
hardware and software components to distribute requests for a service among
multiple component instances that provide the service. This redundancy provides
greater capacity than would be possible with a single instance. This redundancy
also means that if any one instance of a components fails, other instances
are available to assume a heavier load. Depending on the latent capacity that
is built into the deployment, a failure might not result in significant degradation
of performance. Load balancing is used in all of the service modules in the
reference configuration.

Directory Server multimaster replication.
The preferred solution for Directory Server, this mechanism provides data
that is crucial to the operation of the entire deployment. Multimaster replication
is specifically designed to synchronize data between the two (or more) Directory
Server instances shown in the deployment architecture. Multimaster replication
is the simplest directory service failover implementation and is suitable
for all but the highest-end deployments that need to support millions of users.

Session State Availability

Session state availability means that data associated
with a user session is not lost during a service failover. When a service
failover occurs, the session state data that is stored by the failed instance
is made available to the failover instance. This mechanism is known as session failover. The result is that the service failover is transparent
to the user: the user will not be required to log in again or to restart a
business operation.

Session failover is supported in the reference configuration through
two mechanisms:

Access Manager session failover. Access
Manager session information is created when a user is authenticated and stored
in a replicated database. This database is shared by Access Manager instances
and accessed through Message Queue. If an Access Manager instance fails, the
load balancer routes all user requests to a failover instance (service failover).
The failover instance retrieves session information from the shared database
and maintains the session.

Portlet session failover. The JSR 168
portlet specification requires portlets to map state information to an HTTP
session. If a web container supports highly available HTTP sessions, and if
a Portal Server instance fails, the HTTP session state can be recovered by
the failover instance. In the reference configuration, Portal Server is deployed
in an Application Server cluster, in which High Availability Session Store
(HADB) is used to store and replicate portlet session state. The failover
instance retrieves session information from HADB and maintains the session.

When a user is successfully authenticated with Access Manager,
the browser is redirected to a Portal Server instance. A portal desktop session
is created on this instance and is mapped to the user's Access Manager session.
This portal desktop session is used to track Portal Server specific information
such as the user's merged display profile and provider properties. If a Portal
Server instance fails, the desktop session is automatically re-created by
using the user's display profile and attributes that are stored in the Access
Manager's user session. However, provider properties that are stored in local
memory are lost.