When Access Manager servers are deployed behind a load balancer, cookie-based sticky request routing prevents a client request from being misrouted to an incorrect Access Manager server (that is, to a server that is not hosting the session).
In the previous behavior, without cookie-based sticky request routing, requests from non-browser based clients (such as policy agents and clients using the remote Access Manager client SDK) were often misrouted to an Access Manager server that was not hosting the session. Then, in order to send the request to the correct server, the Access Manager server had to validate the session using back-channel communication, which usually caused some performance degradation.
Cookie-based sticky request routing prevents the need for this back-channel communication and thus improves Access Manager performance.
The Access Manager deployment must be configured as a site. For information, see Configuring an Access Manager Deployment as a Site. When you configure a deployment as a site, Access Manager automatically sets the fqdnMap property (in memory) to include the load balancer.
To specify a cookie name, set the com.iplanet.am.lbcookie.name property in the AMConfig.properties file.
Access Manager then generates the load balancer cookie value using the two-byte server ID (such as 01, 02, and 03). If you do not specific a cookie name, Access Manager generates the load balancer cookie value using the default name amlbcookie plus the two-byte server ID.
If you set the cookie name on the Access Manager server, you must use the same name in the AMAgent.properties file for a Policy Agent. Also, if you are using the Access Manager client SDK, you must also use the same cookie name used by the Access Manager server.
Note: Do not set the com.iplanet.am.lbcookie.value property, because Access Manager sets the cookie value using the two-byte server ID.
Configure the load balancer with the cookie name from Step 1.
You can use a hardware or software load balancer with your Access Manager deployment. For information about configuring the BIG-IP® load balancer manufactured by F5 Networks, see Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover.
If session failover is implemented, enable the com.sun.identity.session.resetLBCookie property for both Policy Agents and the Access Manager server. For example:
For a Policy Agent, add and enable the property in the AMAgent.properties file.
For the Access Manager server, add and enable the property in the AMConfig.properties file.
If a failover situation occurs, the session is routed to a secondary Access Manager server, and the load balancer cookie value is set using the server ID for the secondary Access Manager server. Any subsequent requests for the session are routed to the secondary Access Manager server.