Session persistence is a common and rather complex topic in CLB. Sometimes, session persistence is referred to as sticky session. It is a mechanism that can identify client-server affinity and guarantee that associated access requests will be allocated to the same server during load balancing.
First, we need to understand some concepts: connection, session and their differences. Note that connection and session mean the same if we only talk about load balancing.
To put it simple, it is a session if users need login. Otherwise, it is a connection.
For data packets in the same connection, CLB will perform network address translation (NAT) on them and forward them to a fixed real server for further processing. A table in CLB system records information about the connection status, such as source IP: port, target IP: port, server IP: port, and idle timeout period (
Idle Timeout). Because the table used to record connection status consumes system memory resources, its size cannot be infinite. All traditional vendors will have certain limits on its size, which is called the maximum number of concurrent connections, i.e., the maximum number of connections that the system can sustain at the same time. In CLB’s current connection status table, an
Idle Timeout parameter is provided. When a connection has no traffic within the idle timeout period, CLB will automatically delete it and release system resources.
After the connection is deleted, client requests may not be sent to the same real server. Instead, the traffic distribution policy of CLB prevails.
In some scenarios where login is necessary, a session is required between the client and server to record client information.
For example, in most ecommerce application systems or online systems that require identity verification, a transaction or request can be completed after several rounds of interactions between the client and server. As these interactions are closely related, the server needs to know the results of the last one or several interactions before performing a new one. This requires that all these interactions are completed on the same server, instead of being distributed to different servers by CLB. Otherwise, the following exceptions may occur:
Session persistence is required to ensure that requests from the same client will be forwarded to the same real server for processing in certain situations. In other words, multiple connections established between the client and servers are sent to the same server for processing. If load balancer is deployed between the client and servers, these connections will likely be forwarded to different servers for processing. If there is no session information synchronization mechanism between servers, other servers cannot authenticate the user and exceptions may occur when the user interacts with the application system.
CLB forwards requests and connections from clients evenly to multiple servers to avoid overload on a single server. The session persistence mechanism requires certain requests to be forwarded to the same server for processing. In actual deployment environment, an appropriate session persistence mechanism needs to be selected based on the application environment.
Session persistence based on source address (also called IP-based session persistence or simple session persistence) is when CLB uses the source address of the access request as the basis to evaluate the associated session. All access requests from the same IP address will be forwarded to the same server during load balancing.
An important parameter in simple session persistence is connection timeout period, which is a time value configured by CLB for each connected session. If the time interval between the last completion of the session and the next is less than this value, CLB will persist the session for the new connection. Otherwise, CLB will consider the new connection as a new session and perform load balancing.
Simple session persistence can be easily implemented based on Layer-3 and Layer-4 information of data packets, improving efficiency.
However, the problem with this method is when multiple clients access servers through proxy or address translation, requests from the same source address will be allocated to the same server, resulting in severe load imbalance between servers.
In another situation, a client generates a large number of concurrent requests that need to be allocated to multiple servers for processing while persisting the session. In this case, session persistence based on source client address will cause load balancing to fail.
If the above problems occur, you must consider using other types of session persistence.
In cookie-based session persistence, the client and load balancer process the cookie, which is transparent to the real server.
This method implements session persistence simultaneously with load balancing by sharing a session among multiple real servers.