Re: My app does not serialize.. any user-to-lvs controle possible?

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>, jpcl@xxxxxxxxxxxxxx
Subject: Re: My app does not serialize.. any user-to-lvs controle possible?
From: Joseph Mack <mack.joseph@xxxxxxx>
Date: Fri, 28 Feb 2003 09:18:39 -0500
Joao Pedro Clemente wrote:
>  a) Using persistence - very bad, as I would have
>    a1) To use a very large timeout to handle long user sessions

it's not as bad as we used to think - memory is cheap. 
The real problem is that with persistence you can't failover a realserver.
How big a problem is this?

>    a2) As persistence is "per-ip", a lousy load balancing when having a
> proxy in the middle (that I know I'll have)

boxes are cheap now. So you have a few that aren't well balanced. Is that
a big deal?

>  b) Try some way to have some control over WHEN the timeout and the
> stickiness of the session work: It would be needed that somehow the lvs
> director would be informed that
> "a new http session 'bla' started ... -> start a tcp session
> session 'bla' ended .... -> end the tcp session"

you could get into a big mess here for what you are going to get out of it.
>  Question: is this the job of FWMark ?

>  c) Switch to a upper lever balancing, with cookie (l7) support. Then set
> up a lvs in front of a set of layer-7 load balancers.

it's the no-brainer solution designed for suits. 
If you have lots of money and can accept the low speed, then go ahead.
> I will lose fault tolerance anyway. My app is unable to replicate info, so
> I'll never have a chance to do it.

so you can accept no fault tolerance, then use persistence
> The question is: Is there a way to "pin" http sessions (insted of
> user-session), even if some workaround is needed? Or I'll really need to
> get to l7 load balancing?

hmm, not sure what you mean by http sessions here

Joseph Mack PhD, Senior Systems Engineer, SAIC contractor 
to the National Environmental Supercomputer Center, 
ph# 919-541-0007, RTP, NC, USA. mailto:mack.joseph@xxxxxxx
<Prev in Thread] Current Thread [Next in Thread>