Of course, the network guys will start to bombard you with "why"? I have answered the same question many times and I think it will be good to blog it here, so that I can re-use it for our next project.
Assume we have the following setup.
A very typical setup for Production - 2 OpenAM servers fronted by a hardware load-balancer; in the backend, we have a pair of Java Message Queue servers which are configured to form a MQ Cluster for the OpenAM to communicate to.
Let's zoom into OpenAM first.
OpenAM currently leverages the Core Token Services (CTS) to store the session information for its
authenticated users. These sessions can remain in memory or can be persisted in the
Session store. In OpenAM version prior to 10.1, the Session store refers to the MQ Cluster. (Let's ignore OpenAM 10.1 and above for this discussion)
Now, technically, because of the above architecture, OpenAM continues to function even if the load balancer is not configured with session stickiness. How?
I'll use the following diagram to illustrate how.
(1) : User tries to access OpenAM. The load-balancer redirects him to OpenAM 1.
(2) : User will be prompted to authenticate. OpenAM 1 creates a session and stores it in CTS
(3) : User tries to access OpenAM again within the same browser session. The load-balancer redirects him to OpenAM 2 instead, since session stickiness is not configured.
(4) : OpenAM 2 cannot find the user session. It will perform a "cross-talk" to the original OpenAM instance to see if the latest session information is available.
(5) : User session found in OpenAM 1!
(6) : The user will not be prompted to authenticate again.
So, it works! However, there is this penalty in (5) where the "cross-talk" takes place. The rationale of having the load balancer configured with session stickiness is to avoid this extra traffic.
And imagine there are millions of requests per hour, this extra traffic can be very taxing to the OpenAM instances. Instead of serving users with authentication and authorization, extra load is taken up for the "cross-talk" activities. This is not ideal!
.
Now, technically, because of the above architecture, OpenAM continues to function even if the load balancer is not configured with session stickiness. How?
I'll use the following diagram to illustrate how.
(1) : User tries to access OpenAM. The load-balancer redirects him to OpenAM 1.
(2) : User will be prompted to authenticate. OpenAM 1 creates a session and stores it in CTS
(3) : User tries to access OpenAM again within the same browser session. The load-balancer redirects him to OpenAM 2 instead, since session stickiness is not configured.
(4) : OpenAM 2 cannot find the user session. It will perform a "cross-talk" to the original OpenAM instance to see if the latest session information is available.
(5) : User session found in OpenAM 1!
(6) : The user will not be prompted to authenticate again.
So, it works! However, there is this penalty in (5) where the "cross-talk" takes place. The rationale of having the load balancer configured with session stickiness is to avoid this extra traffic.
And imagine there are millions of requests per hour, this extra traffic can be very taxing to the OpenAM instances. Instead of serving users with authentication and authorization, extra load is taken up for the "cross-talk" activities. This is not ideal!
.
Do we need to install the message queue as part of Session Failover component. Say if I have OpenAM node 1 and Node 2 with no session failover installed.
ReplyDeleteIf a session is created on node 1 and and we try to authenticate on Node 2.. Will node 1 communicate to node 2 using this cross talk mechanism on its own.. or do we need to install something separate?