On Mon, Jan 22, 2001 at 05:13:10PM +0530, Shridhar Bhat wrote:
> We are trying to deploy multiple SSL-based servers
> in a cluster. We want to share the session cache of each
> of these servers so that connections from same client
> (with session id reuse) can be handled by any server in
> the same cluster. The scheme is simple:
> Each server maintains its local cache and also replicates
> the session in a central server. Whenver a request for
> session-id reuse comes in and the server doesn't find the
> id in its local cache, it refers to the central server.
>
> Would this scheme work and be worth implementing? What
> could be the possible bottlenecks in it?
You first have to investigate what your requirements are. If you are using
several IP addresses for the same server name, clients will reuse the
IP address once obtained from DNS and always contact the same server
again, so a "per server" cache might be sufficient.
There is a cost in negotiating a session. This cost is in both bandwidth
and computer time. It's hard to estimate the cost. With Postfix/TLS
a complete handshake with client certificate exchange costs ... 5kB
data send over the wire and approximatly 1 second realtime on unloaded
hosts (this would evaluate to 0.5 sec per host).
Please take these number with extreme care. I have these numbers from
developing Postfix/TLS. Granularity of syslog is 1 second and the amount
of data is from dumping the data with ssldump...
(Hardware are 1996 HP C160/J280).
> The most attractive benefit I see is that any server
> could go down without forcing its clients to renegotiate
> the session. Also, the load balancer need not bother
> about the 'sticky connections'.
Having said my own numbers, you now have to evaluate the cost of a
renegotiation against the cost of maintaining a session database.
(There is a higher cost when client certificates are involved, as new
negotiation will cause a new certificate request which will annoy
your users.)
I cannot give you absolute numbers. Your central database server must
store a session of about 2kb binary data (size depends on certificates
included). Upon each request, your database will be queried.
I don't have the slightest clue on how your database engine will perform
when queried heavily, but I am sure that you have an idea.
Be aware, that there is one "write" operation for each new session, write
operations typically are more expensive.
The interface to handle sessions in the way you want to do it is prepared.
Database oriented session caching is included in mod_ssl, Apache+SSL,
Postfix/TLS...
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
