|
First of all, thank you for the fast reply.
I'll post my comments along the mail:
> 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?
Actually, were I stand there is no difference: if I can't replicate my
http sessions, there is no way to recover from a realserver crash
anyway...
Hmmm... Wait a minute... Yes, there is a problem:
Even not being able to recover a lost [http] session, it would be nice to
have another realserver answer my clients (who would need to start all
over again what they were doing, like "logging in"). IIRC (If I Remenmber
Correctly), the persistance would prevent me from obtaining this failover
(even if it is failover without recovery), right?
Or has there been found a way to "clear" the persistence table for some
realserver?
>> 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?
Ok, I guess not...
>> 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
With persistence or not, I'll not have fault-tolerance (as I cant
replicate the contents of my http session through the realservers)..
Persistence seems to be the only way to be able to let my user interact
for a while [as long as persistence lasts] with the app...
I think, regarding fault-tolerance, I've reached a "no win" situation... :-(
>> 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
I was refering to the solution b). [http session vs ip/tcp-session].
I've already put that out of the question, thanks :-)
Fortunatly, I've been talking to the app developers and maybe we can
workaround some things to (at least try to) support serialization...
If not, I'll try the persistence :-)
In fact, I was already using it with a small timeout just to improve the
behaviour with http1.0 browsers ;-)
Thanks once again!
Joao Clemente
|
