Failover in a cluster

The following have failover capabilities in a clustered environment:

If we configure a secondary master and the primary master fails, the distributed session cache and the internal runtime database failover to the secondary master. When the primary master is restored, reconciliation occurs and the primary master resumes control of these services. For the distributed session cache, a full copy of all sessions is restored.

We can also configure tertiary and quaternary masters for distributed session cache failover. If the primary and secondary masters are both unavailable, the distributed session cache fails over to the tertiary master. If the tertiary master is also unavailable, the distributed session cache fails over to the quaternary master. The distributed session cache forms a chain of session replication from the primary to the quaternary master. If any node in the chain fails, it can request a full copy of all sessions from either partner in the chain when it recovers. There is no disk caching of sessions, so a full copy is required. There is no failover between the master servers for the configuration and geolocation databases. If the primary master fails, the other nodes have a local read-only copy of the information they can use in the interim. However, no configuration or geolocation updates are possible until the primary master is back online or a new primary master is designated.

For WebSEAL to fail over, set the following parameter in the [junction] stanza of the WebSEAL configuration file:

Parent topic: High availability of cluster services