This section describes "n + 1" clustering of Session. The Connected Services Framework Session component supports "n + 1" clustering, where "n" servers are configured to run the Session component, and one box (the "+1") is a warm standby box. The following diagram shows Connected Services Framework Session component server clustering:
Common.config will specify the initial SessionManager endpoint that should be used for CreateSession calls only. This is because only CreateSession is clustered, and the physical machines that will service the remaining Session methods are in the CreateSessionResponse.
As a rule, applications that use the Session component must use the Session and SessionManager URIs that are returned in the CreateSessionResponse message.
When one of the machines in the cluster fails, the standby (or +1) machine will recover the sessions for the failed machine from the database. If multiple machines fail, then the standby server will recover the sessions for all of the machines that have failed. In order for Session clustering to work, the "serialize" attribute of the Session Manifests needs to be "OnCreate" or "OnChange".
The Session.config file will indicate if Session is clustered, and it will also list the DNS names of all the Session machines in the cluster.
Session clustering configuration has moved from being exclusively set in the session configuration files to being set in the session database in the ConfigurationItem table. The setup of the database parameters requires the use of the Admin Tool described in this Dev Guide in the "Connected Services Framework Administration Tool" section. The database should not be edited directly as that is likely to result in corruption of the XML data structures stored there.
The details of how to setup session clustering are in the CSF Operations Guide.