1. What is session persistence?
Session persistence serves to forward session requests from the same client to a specified backend server for processing.
2. How can I enable session persistence?
When you configure Server Load Balancer (SLB) listeners, you can choose to enable session persistence. You can also choose to not enable session persistence. You can configure different session persistence policies for different listeners. The maximum session persistence duration is 86,400 seconds (24 hours).
3. What types of session persistence does SLB support?
SLB supports the following types of session persistence:
For Layer-4 (TCP protocol) services, the SLB system supports source IP-based session persistence. The maximum duration of Layer-4 session persistence is 3,600 seconds.
For Layer-7 (HTTP or HTTPS) services, the SLB system supports cookie-based session persistence. The maximum duration of session persistence based on cookie inserting is 86,400 seconds (24 hours).
4. What types of cookies can be configured for session persistence?
Cookie inserting and rewriting can be used for session persistence for HTTP and HTTPS listeners.
Cookie inserting: If you use the insert method, you only need to specify the cookie timeout. For the first access by a client, the SLB service inserts a cookie (inserts a SERVERID string in the HTTP/HTTPS response message) into the response. The next request from the client will contain this cookie and the SLB service will forward the request to the same ECS instance.
Cookie rewriting: If you use the rewrite method, you can specify the cookie to be inserted into the HTTPS/HTTP response as needed. The SLB service rewrites the original cookie when it discovers a customized cookie. The next request from the client will contain this rewritten cookie and the SLB service will forward the request to the same ECS instance. For more information, see Configure cookie in the backend server.
5. Can I configure different session persistence rules for different domain names?
You can configure different session persistence rules by selecting the Cookie Rewrite session persistence method of the SLB system.
6. What timeout value should I set for the cookie?
Set the cookie timeout value as follows:
For cookie inserting, you can set the timeout value to 1-86400 seconds in the console.
For cookie rewriting, you must maintain the timeout value on the backend ECS instance.
7. How to check the session persistence string?
You can use developer tools in the browser to view whether the response message contains the
SERVERID string or a user-specified key word, or you can run
curl www.xxx.com -c /tmp/cookie123 to save the cookie and run
curl www.xxx.com -b /tmp/cookie123 to initiate the access.
8. Why does the session persistence fail sometimes?
Check whether the session persistence feature has been enabled in the listener configuration.
The HTTP/HTTPS listener fails to insert the cookie required for session persistence into the message containing the
4xxresponse code and returned by the backend server.
Resolution: Use a TCP listener instead. The TCP listener achieves session persistence based on the source IP address of the client. The cookie can be inserted in the backend ECS instance and cookie detection is provided for better guarantee.
302 redirection changes the
SERVERIDstring in session persistence.
When Server Load Balancer is inserted with a cookie and a backend ECS returns a 302 redirection message, the
SERVERIDstring in session persistence will be changed and the session persistence will fail.
Troubleshooting: Capture the request and returned response on the browser or use a tool to capture packets to check whether a 302 response message exists. Then, compare the
SERVERIDstrings in the messages to see if they are different.
Resolution: Use a TCP listener instead. The TCP listener achieves session persistence based on the source IP address of the client, and the cookie can be inserted in the backend ECS instance and cookie detection is provided for better guarantee.
A session persistence duration that is too short can also cause session persistence failure.
9. How can I use Linux curl to test the session persistence of Server Load Balancer?
Create a test page.
Create a test page on all the backend ECS instances of Server Load Balancer. The local intranet IP address is displayed, as shown in the following figure. The intranet IP address is used to determine the physical server to which the requests are assigned. The effectiveness of Server Load Balancer session persistence can be determined by checking the consistency of this IP address.
Perform curl test in a Linux environment.
Assume that the IP address of Server Load Balancer is 220.127.116.11, and the URL of the created test page is http://18.104.22.168/check.jsp.
Log on to the Linux server used for test.
Run the following command to obtain the cookie value of the Server Load Balancer server.
curl -c test.cookie http://22.214.171.124/check.jsp
Note: The default session persistence mode of Alibaba Cloud Server Load Balancer is cookie inserting, but the curl test does not save and send a cookie by default. Therefore you must save the cookie for test first. Otherwise, the curl test result will be random and you may mistakenly infer that the Server Load Balancer session persistence does not take effect.
Run the following command to continue the test.
for ((a=1;a<=30;a++)); 2="" do="" curl="" -b="" 1.cookie="" check.jsp="">/dev/null | grep '10.170.*'; sleep 1; done
Note: a<=30 refers to the number of repeated tests and can be customized; grep ‘10.170.*’ indicates filtering the returned results and can be customized based on the intranet IP address of the backend ECS instance.
Observe the IP addresses returned in the preceding tests. If they are the intranet IP address of the same ECS instance, the SLB session persistence has taken effect. If they are not the intranet IP address of the same ECS instance, there is something wrong with the SLB session persistence.