I have two physical Apache servers behind a load balancer. The load balancer was supposed to be set up so that a user would always be sent to the same physical server after the first request, to preserve sessions.

This worked fine for our web apps until we added SSL to the setup. Now the user can successfully login, see the home page, but clicking on any other internal links logs the user right out. I traced the issue to the fact that while initial authentication is performed by server 1, clicking on internal links leads to having the request sent to server 2. Server 2 does not share sessions with server 1, and the user is kicked out.

How can I fix it?

Do I need to share sessions between the two servers? If so, could you point me to a good guide for doing this?



If you want to have session stickiness in your load balancer, then you have to terminate the SSL on the load balancer. This means that you have to install the SSL certificate into load balancer.

Another solution is to configure the load balancer to use source IP stickiness for SSL (HTTPS).

A 3rd solution would be to keep the sessions in a common database (e.g. memcached, SQL database). For .NET see: http://support.microsoft.com/kb/317604 For PHP see: http://kevin.vanzonneveld.net/techblog/article/enhance_php_session_management/

  • 1
    +1 for 3 good solutions. I typically lean toward a combination of #2 and #3 for the reasons in my answer. – voretaq7 Mar 16 '11 at 15:28

Your load balancer is likely using HTTP header data to determine which box it's sending your users to (instead of judging by IP address).
[If you can tell us what kind of load balancer you're using helpful information on configuring it may go here :-)]

In addition to reconfiguring your load balancer you may want to consider sharing sessions across the two servers. You can do this by:

  1. Putting the sessions on an NFS share mounted on both servers
    (Traditional & fairly reliable as long as the NFS server doesn't go away).
  2. If you're using PHP, using session_mysql, session_pgsql or any number of other session handlers available.
    (As reliable as the backing store)

(The advantage of sharing sessions is that your servers provide seamless redundancy: If server 1 is down for maintenance server 2 can pick up all of its sessions without forcing users to log in again)

  • +1 because I like the placeholder for when we find out what the heck the load balancer is ;) – Shane Madden Mar 16 '11 at 15:20

It sounds like (hard to say for sure without more information) that persistence is not fully implemented in your Apache configuration for the load balancer. Take a look at the Load Balancer Stickyness section on the Apache documentation for mod_proxy_balancer.

The balancer supports stickyness. When a request is proxied to some back-end, then all following requests from the same user should be proxied to the same back-end. Many load balancers implement this feature via a table that maps client IP addresses to back-ends. This approach is transparent to clients and back-ends, but suffers from some problems: unequal load distribution if clients are themselves hidden behind proxies, stickyness errors when a client uses a dynamic IP address that changes during a session and loss of stickyness, if the mapping table overflows.

The module mod_proxy_balancer implements stickyness on top of two alternative means: cookies and URL encoding. Providing the cookie can be either done by the back-end or by the Apache web server itself. The URL encoding is usually done on the back-end.

From that documentation is the following example:

<Proxy balancer://mycluster>
BalancerMember route=1
BalancerMember route=2
ProxySet stickysession=ROUTEID
ProxyPass /test balancer://mycluster

You said that the load balancer was set up to tend to keep sending the user to the same server as their first request -- sounds like that is not working on SSL, but was working before SSL. Sounds like a config issue with the load balancer; are you able to provide info on what it is and how it's configured?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.