I guess that it's not easy to implement session affinity on the SSL level. You cannot access information like cookies or other HTTP headers (since they are inside the SSL payload that you're trying to handle). So you have to use the little information you have: source IP address and port, and session data.
The idea would be to make sure that a given client is always sent to the same SSL handler.
We could imagine having two layers of load balancers:
- first layer would use source IP address and/or session data to determine to which server of the second layer the connection should be forwarded;
- second layer would receive the connection and to the proper SSL handling.
I believe that this would work, but it seems that it would require a custom "half-implementation" of SSL on the first layer of load balancers. I don't know if there is any provision for that in OpenSSL or GNUTLS. Also, since there are already hooks to do session caching in most SSL-enabled servers, using those hooks to plug in a memcached backend seems to be less "disruptive" (read "easier to understand, implement and debug").
You can balance ssl traffic at a TCP level using the client's IP to set affinity. The only real catch is if you have a large base of clients behind a single NAT, but in most cases traffic will balance out pretty well.
Sometimes though, you don't want affinity at all. If you don't care what backend server takes the request, you can balance the load more efficiently, and more easily rotate servers in and out of service.
The idea would be to make sure that a given client is always sent to the same SSL handler.
We could imagine having two layers of load balancers: - first layer would use source IP address and/or session data to determine to which server of the second layer the connection should be forwarded; - second layer would receive the connection and to the proper SSL handling.
I believe that this would work, but it seems that it would require a custom "half-implementation" of SSL on the first layer of load balancers. I don't know if there is any provision for that in OpenSSL or GNUTLS. Also, since there are already hooks to do session caching in most SSL-enabled servers, using those hooks to plug in a memcached backend seems to be less "disruptive" (read "easier to understand, implement and debug").