What is Session Affinity in a Load Balancer?
distribute client access requests between backend server pools using several different algorithms, combined with real-time knowledge about the load and state of the servers in the pool. This allows the incoming connection requests to be spread out over the servers in the pool by allocating them to the one most suited to handle it at the time the request arrives.
For many applications this is the best way to handle incoming requests. However, some web applications are dynamic in nature, and a user session that interacts with them will require multiple requests flowing back and forth between the clients, the load balancers, and the servers in the pool. For connections like this, it is vital that all related requests, after the initial connection allocation, are passed to the same server in the pool and not spread out over multiple servers. This is especially true for web applications that have dynamic elements like forms or shopping carts that can take significant periods of time to interact with or complete.
Session affinity is a feature available on load balancers that allows all subsequent traffic and requests from an initial client session to be passed to the same server in the pool. Session affinity is also referred to as session persistence, server affinity, server persistence, or server sticky.
When session affinity is enabled on LoadMaster, all new connection requests from clients are allocated to the server in the pool best placed to handle them. But returning connection requests go to the server they were previously using. Session affinity is not enabled by default on LoadMaster. When it is required, it can be configured separately for each Virtual Service, allowing fine-grained configuration.
Methods that Enable Session Affinity
Session affinity is configured on Virtual Services running at Application Layer 7. They all go beyond basic IP address and port numbers to give a range of options that can be used depending on what level of persistence is needed.
- Server Cookie Persistence
- Active Cookie Persistence
- Server Cookie or Source IP Persistence
- Active Cookie or Source IP Persistence
- Hash All Cookies Persistence
- Hash All Cookies or Source IP Persistence
- Source IP Address Persistence
- Super HTTP
- URL Hash
- HTTP Host Header
- Selected Header
- SSL Session ID
- UDP Session Initiation Protocol (SIP)
For more details on these methods, see this support article
When using HTTPS and TLS secured sessions, then there are some methods from the above list that will not work if the TLS session is not terminating at the load balancer. In that case, the only techniques that can be used are Source IP Address Persistence or SSL Session ID Persistence. If the TLS is being terminated at the load balancer, as in LoadMaster SSL/TLS offloading then any of the methods outlined above (and in the linked support article) can be used.
Using Timeout to determine Session Affinity Duration
For each of the session affinity methods, there is a configurable timeout value that can be used to set the time that the persistence for a user session is honored. This timeout can be set from one minute to seven days.
The timeout clock is started when the original connection is made. It is then restarted from zero if they disconnect and then reconnect within the timeout period. For example, if the timeout is set to 30 minutes and a session starts at 15:00 and lasts for 12 minutes, then the same user connects at 15:26 again they will be connected to the same real server in the pool and their timeout clock will be reset to 30 minutes. So the session affinity timeout, in this case, would now be 15:56. If they disconnect and reconnect before this time the timeout clock is reset to 30 minutes again.