Hi Kelly,

To do a software solution you could use the following method.

www.mysite.com - Both servers can answer this request, (for example round robin dns)
or some form of hsrp (im sure there is a patch for linux to do this)...
and based upon load and a simple script (perl, java, etc)
they then redirect the traffic server1.mysite.com, or server2.mysite.com


This way the session then stays on server1 or server2.

As I said though, you will need 2 certificates if you do not want the clients complaining about broken ssl certificates.


Anderw



Kelly Vista wrote:

Thanks Andrew.

In answer to your question, some of our app requires SSL -- exactly like an order-style app (but it's not a product ordering app).

So, a person's session might involve the following path:

1. non SSL req
2. non SSL req
3. SSL req
4. non SSL req

and we'd like that entire session to be persistent (i.e., sticky with one particular app server). BTW, it is not an issue for us if that server fails during the session. It will happen rarely and it's an acceptable failure for us (i.e., not mission critical data).

I should have mentioned that we expect 1000 req/hour with this app. However, our app is not necessarily quick (dependent on external resources) and does keep a lot of state.

I'm personally someone in favor of a H/W LB solution, but looking to be convinced that a valid S/W solution exists which is better (or just as good) as a H/W solution. I know the S/W solution will be less reliable (not solid state), but I'm looking to hear from folks who have done SSL session affinity with a S/W only approach.



Andrew

On Feb 22, 2005, at 10:24 PM, Kelly Vista wrote:

Hi -

We are looking to deploy our app, running on Tomcat 5, soon and are exploring load balancing options. We are looking at H/W and S/W solutions, and I was wondering if anyone had any past experience/advice they would like to share.





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to