Some applications require that a user continues to connect to the same backend server. This persistence is achieved through sticky sessions, using the appsession parameter in the backend that requires it.
In this tutorial, I will show you how to setup haproxy as a load balancer that uses sticky sessions. In case you didn’t already know, haproxy is a reliable and free high-availability load balancer that allows you to distribute web traffic among multiple web servers.
For the purposes of this example, let’s say that we have three servers with three separate IP addresses:
10.0.1.11 – The server that has haproxy installed. This is our Load Balancer.
10.0.2.11 – Our first web server. We will call this Server A.
10.0.2.12 – Our second web server. We will call this Server B.
Note that those IP addresses are fake and that I am only using them as an example.
The problem with using a load balancer is that by default, traffic bounces from one server to the next. For example: If your web server is using PHP’s default session handling, then all session data will be saved to a file in a temporary location on that web server. If a user logs into Server A, his or her session data will be saved in a file on Server A. If the load balancer distributes their next request to Server B, then the web server on Server B will be unable to read their session data. Why? Because the user’s session data was saved on Server A and Server B has no way to access it. There is no synchronization between our web servers as they are completely unaware of each other.
To solve this problem, we configure our haproxy load balancer to use sticky sessions. When sticky sessions are enabled, a client will be “stuck” to a certain web server. i.e. If a user lands on Server B, then he or she will be “stuck” on Server B until the sticky session cookie has expired.
Enabling haproxy sticky sessions.
Note that I have haroxy version 1.6.3 installed on Ubuntu 16.04.3 LTS. On my server, the configuration file for haproxy is located at /etc/haproxy/haproxy.cfg – This may be different on your server.
Let’s take a look at the listen proxy that I have created:
cookie SRVNAME insert
timeout connect 30000
timeout client 30000
timeout server 30000
server ServerA 10.0.2.11:80 cookie SA check
server ServerB 10.0.2.12:80 cookie SB check
As you can see, I have created a listen proxy for my_website_name. There are three important parts to this configuration that are needed for sticky sessions.
cookie SRVNAME insert: This directive enables cookies and tells haproxy to insert the name of the current server into it.
server ServerA 10.0.2.11:80 cookie SA check: Here, we added Server A to our load balancer. We’ve called it “ServerA” and we have binded it to the IP address 10.0.2.11 and port 80. More importantly for us, we have named the cookie for this server as “SA”.
server ServerB 10.0.2.12:80 cookie SB check: Here, we added Server B to our load balancer. We’ve called it “ServerB” and we have binded it to the IP address 10.0.2.12 and port 80. In this case, we have named the cookie for this server as “SB”.
Once you have made the above changes, simply restart haproxy for the changes to take effect. If everything is correct, then new users will stick to either Server A or Server B. i.e. Their requests will not randomly bounce between them.
Hopefully, you found this article to be helpful!
Post a Comment