On Tue, 22 May 2001, Darko Krizic wrote:
> I have running a few Apache servers with mod_ssl (current versions) which are
> acting as reverse proxies and doing the SSL stuff. They are load balanced
> using a Cisco Local Director (LDIR). The LDIR has set the sticky bit in order
> to keep a specific IP-Address on a specific web server. This works so far and
> improved the overall performance.
>
> The Problem now are rotating outgoing proxies which are used by AOL or for
> example Deutsch Bank. Every request - even from the same user - comes in every
> time from a different IP address. This makes the stick-bit feature of the LDIR
> useless and the performance for these guys is low, since every time a new SSL
> handshake has to happen.
Yup. But then again, in an ideal world you wouldn't want to use sticky
load-balancing anyway because it defeats the purpose(s) of load-balancing - ie.
you want to proxy requests onto a server that is (a) alive, and (b) chosen based
on some load-related logic, not chosen to appease some SSL session caching
trickery. Unfortunately, companies like AOL are forcing this issue to the point
that finding a solution becomes more than architectural fine-tuning, it becomes
a serious problem.
The other point is that ideally one machine should be able resume sessions
established on another anyway, otherwise you have very little fault-tolerance -
and if you start getting hit by large-scale screen-scraper gateways and
what-not, you may want to *deliberately* spread session-resumes for identical
sessions across multiple servers.
> Is it possible to make several mod_ssls on several servers share their SSL
> session keys?
It's a WIP. (Work In Progress)
> Are there any other (not mod_ssl) solutions on the market?
Apache-SSL is also available and has some support for this sort of thing,
although some tests I ran a while ago on it came up with some rather
unimpressive performance figures. The standard session cache works as a daemon,
and typically listens on a domain socket but this can be configured to listen on
an IP address and thus serve requests from multiple machines. However, using IP
sockets can quite easily cause the socket-tables to bloat up under load (some
moderate load-testing I did had the cache failing fairly quickly). Also,
internally the cache is just a global resizing array with no indexing, and the
loop logic has no concurrency whatsoever (ie. it accept()s, read()s, processes,
write()s, close()s, then goes back to the beginning again). So everything is
completely serialised in the cache server - so any latency in your network (or a
single server misbehaving) can bring everything to a halt fairly
comprehensively.
Apache-SSL also has a masterless cache that is built using Splash (a distributed
masterless database) which in turn is built using Spread (a multicast messaging
bag of tricks from a group at John Hopkins). I haven't had a chance to test that
seriously although I fear the performance looks (from the code at least) to be
no better than the regular cache, although it is obviously going to be a little
more fault-tolerant. The other possible problem is that it uses Spread to ensure
that every web-server has a complete up-to-date cache with *all* sessions from
all machines ... session caching has certain properties that make a masterless
solution possible without resorting to the kind of network flooding this
everything-to-everyone approach generates. (See the "WIP" above).
In my copious spare time, I'm working on standardising a session caching scheme
together with tools that implement it. As/when this starts to mature, I will be
providing code/patches to allow this to work with both mod_ssl and Apache-SSL.
Unfortunately, my spare time is *so* copious, and the other projects I'm working
on are *so* minor, that I should probably be finished as soon as ... oh ...
maybe 2015. If there's some serious coders out there who want to collaborate on
this, please let me know - especially if you're able to set up and/or administer
such a project ... I've already got the basic design mapped out - but getting it
all turned into portable, optimal, and reliable code is currently more
intimidating than I have time to tackle (alone).
Cheers,
Geoff
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
