Considering Assumptions and Dependencies

As you plan your deployment, consider the following assumptions to determine if your environment is appropriate for using system failover and session failover.

Assumptions

• Redundant OpenSSO Enterprise servers and Policy Agents are installed for basic load-balancing. Additionally, you must manually configure each instance for system failover and session failover.

• All OpenSSO Enterprise servers must share the same configuration data. This can be achieved by setting up configuration data replication among multiple instances of OpenDS, or by configuring each OpenSSO Enterprise server to point to the same instance of Sun Directory Server.

• You can configure system failover at either the OpenSSO Enterprise Policy Agent or at the OpenSSO Enterprise Client SDK.

• When configuring session failover, you must deploy Java Message Queue and the Berkeley Database on a machine other than the one hosting the OpenSSO Enterprise servers. You can configure a single Message Queue with a single Berkeley Database, or you can configure multiple instance of both.

Using Java Message Queue Broker and Berkeley Database for Session Failover

If you configure a single instance of Java Message Queue Broker and as single instance of Berkeley Database to provide session failover for your deployment, no session data replication is possible. If either Message Queue Broker or Berkeley Database fails, then all the stored user sessions are lost. The OpenSSO Enterprise server would operate as if session failover was not configured.

A good practice is to use two instances of Message Queue Broker configured with two instances of Berkeley Database. User sessions are replicated among the Berkeley Database instances. This dual-host configuration is for failover purposes and not for load sharing. Adding more Message Queue Broker instances and Berkeley Database instances does not increase processing capacity. Adding more instances actually reduces the overall session failover processing capacity due to the extra data replication overhead.

• The Java Message Queue Broker and Berkeley Database pair should be configured in an active-standby mode so that at any given time only one of the pair is up and running.

• The Java Message Queue Broker and Berkeley Database pair on the backup host is be used only for failover purposes.

• When the primary Java Message Queue Broker and Berkeley Database pair fail, other pair on the backup host can be started to provide uninterrupted session service.