|
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 ?
no.
> 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
Joe
--
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
|
