Efficient Use of Network Load-Balancing w/ SSL?

vw asks: "I was wondering if anyone has setup a webserver farm that uses both SSL and zero-affinity network-load-balancing. (i.e. requests in an SSL channel can be handled by any server in the farm) I have been having a very difficult time locating information on this specific combination of features in a web server product. The closest I found was WLBS, which implies that there must be an affinity toward a particular server for a given client IP. I understand the problem has something to do with sharing SSL certificates between physical machines. Any suggestions?"

Comments

Apache + Splash is the solution

[Crutcher]

This is a solved problem, check out the splash project http://anoncvs.aldigital.co.uk/splash/ for details.

Basically, it is an Apache module which uses the spread http://spread.org secure mesaging server to synchronizes ssl conection information.

Re:Apache + Splash is the solution [more info]

[Crutcher]

Splash provides a distributed database using Spread. Apache-SSL has a plugable SSL conection cache layer, and there is a Splash implementation available. So, when a client connects to an Apache-SSL server in the pool, and the server checks the cache for SSL cache information, it is checking a DB it shares with all the other machines in the pool. This is exactly what is being requested for this Ask Slashdot.

Somewhat Simple -- perhaps non-obvious.

[rtaylor]

Setup an OpenBSD box with a crypto card. Let it do all of the dirty work. That box should proxy requests to the load balancer and other webservers in unencrypted form.

Lets you buy a single cert, and with hardware crypto you should be able to handle enough for a modest load -- more than a few million pages daily.

it's not simple...

[trims]

Given the technological design behind SSL (in that it operates immediately above IP, and below TCP/UDP), the summary you provide above is true.

That is, you can set up a cluster of web servers behind a typical redirector. Say Server A, B, and C. Each machine has a different IP address, which is a routable address (let's call it w1.foo.com, w2.foo.com, w3.foo.com). There is a single IP address for the "master" domain (say www.foo.com). All machines are set up to serve www.foo.com, both HTTP and HTTPS. For normal HTTP requests, the redirector does it's thing, with EACH http request coming to www.foo.com being served by the next available machine. Any connection a client makes can potentially be served by any machine.

However, since SSL operates below the TCP/HTTP header, a client making a SSL connection to https://www.foo.com will initially be load-balanced across the machines. However, for the rest of that SSL session, it will continue to communicate ONLY with the machine which initially answered the beginning SSL connection.

This isn't a real big problem for most web apps, since each connection is really just getting a bunch of web pages. If the server goes down, you simply have to push RELOAD on the client, and it re-initiates the HTTPS session, getting another machine to answer. It can be a serious problem with other SSL apps, as the termination of a session by the loss of the answering machine may make it difficult to programatically re-start the session.

Just to make this clear: each time a client initiates an SSL session, it gets bound to a single server. This server may be different for each session, but remember that a "session" may include many data requests.

There is no problem sharing certificates between multiple machines (as the cert is tied to hostname, and it's easy to duplicate across multiple web servers). It's an SSL protocol limitation.

-Erik