The Redis session cache is most commonly used in a scenario where client requests are
directed by a load balancing mechanism to two or more replicated WebSEAL servers.
The replicated servers are identical. They contain replica copies of the WebSEAL
protected object space, junction database, and (optionally) dynurl database.
The client is not aware of the replicated front-end server configuration. The load
balancing mechanism is the single point of contact for the requested resource. The load balancer
connects the client with an available server.Figure 1. Failover for replicated WebSEAL servers
If the server where the client is connected suddenly becomes unavailable, the load
balancer redirects the request to one of the other replicated servers. This action causes the loss
of the original session-to-credential mapping. The client is new to this substitute server and is
normally forced to login again.
The purpose of the Redis session cache is to prevent forced login when
the WebSEAL server that has the original session with the client suddenly becomes unavailable. The
Redis session cache enables the client to connect to another WebSEAL
server, and create an authenticated session containing the same user
session data and user credentials.
Note: Whenever possible, configure load balancers to maintain session affinity. Session
affinity provides improved performance, improved user experience, and makes WebSEAL configuration
simpler.
