...
A Session Controller can operate either alone, or in a cluster of multiple Session Controllers, that synchronize sessions information with each other. If they are deployed in a cluster, as SC mirrors, each change in a session, such as session creation, logon, logoff or session removal are broadcasted to the other SC servers, so they all are instantly synchronized.
A number of Agents communicates communicate with one or more SC servers, and each SC server synchronizes changes with the other SC servers like this:
If the Agent 4 asks SC3 ot to create a new session, SC3 will tell SC1 and SC2 about the new session.
If Agent1 later logs a user in, the other SC servers will be informed about the changes in the session and update their internal tables, as ell well as send out commands to the Agents that have a copy of the session to tell them to remove that particular one from their caches.
...
Session Controllers are the most complex part of PortalProtect to cluster. Each individual Session Controller needs to know about all other session controllers, and all session controllers has to have to be connected to all other session controllers within a cluster.
...
It does not matter which session controller is listening, and which one is making the call – once they connection their connection is established, they are equal.
...
First of all, keep things simple – there is no reason to setup 10 set up 10 different PP servers in a cluster, if 2 is enough – having too many servers just complicates the configuration needlessly, and increases the risk that something will go wrong.
Since updates to a session has to have to be synchronous (to ensure that consecutive requests will always see the updated session, even if the requests hits other application servers), the more session controllers added to a cluster, the longer time it will take to finish changing the contents of a session.
...