The combination of load balancing and statefull, secure applications creates
an issue which typically requires additional capitol to fix. Here are some
options for you to consider.
1) Create a hot stand-by configuration where 1 server handles all of the
traffic until it has an issue. Then the back up server will service all of
the traffic.
You will be sacrificing scalability and it may cost you to upgrade the
server to be able to handle the load, but it may be a good short-term
solution.
2) Get the application team to push their state information to a shared,
back-end database.
This is probably the most expensive solution for existing applications to
migrate to.
3) Invest in an SSL Acceleration device.
You can load balance the SSL accelerators via port 443
Note: 1) Configure the load balancer to perform the TCP hand shake with the
client.
2) Configure SSL ID persistence on the SSL accelerators so that you
can minimize the performance hit to the browser.
Once the traffic is decrypted you can make the persistence decision based on
cookie, etc.
Please note that the load balancer with have to make 2 load balancing
decisions for each request.
I hope this helps.
Ken C
-----Original Message-----
From: Tim Maestas [mailto:lbIZZATdnsconsultants.com]
Sent: Tuesday, February 05, 2002 9:42 AM
To: lb-lIZZATvegan.net
Subject: Re: [load balancing] SSL Session ID Load Balancing
Yes that sounds correct. SSL Session ID is pretty
useless these days for maintaining persistence. If
you are terminating SSL on your load balancers, doing
cookie based persistence is probably your best bet.
If you are not terminating on the load balancer and
are encrypted all the way through, you are pretty
much stuck with source ip based persistence, which
basically sucks if you have lots of clients coming
through proxies.
-Tim
On Tue, 5 Feb 2002, Allan Liska wrote:
>
> Hi all,
>
>
> I am trying to develop a definitive policy for SSL Session-ID based load
> balancing, and I am wondering if you all can help, because there seems to
> be a lot of confusion.
>
> This is my understanding of how the process works, and the problem with
> the Microsoft bug, if I am missing anything, please let me know:
>
> 1. A client initiates a session with a server.
> 2. The client and the server share the following information:
> Protocol Version
> Session ID -- Generated by the Client
> Cipher Suite
> Compression Method
> ClientHello.random
> ServerHello.random
> 3. After the hello session has completed, the server sends its certificate
> to the client.
> 4. In subsequent transactions, the server will use the SSL Session ID to
> track session information with the client.
>
> In the case of the browsers listed here:
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q265369
>
> The SSL session ID is regenerated every 2 minutes, which creates a new
> session. Making it possible for a client to lose persistency if the site
> is being load balanced.
>
>
>
> Does all of this sound correct?
>
>
> Thanks!
>
>
> allan
>
>
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2b30 : Tue Feb 05 2002 - 15:37:45 EST