You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nick Bauman <ni...@cortexity.com> on 2001/02/26 15:07:44 UTC
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Pier,
>> If the next request from that client is routed to server Y, then
>> server Y will get a request with that same composite ID of
>> "serverX:sessionPPP". This tells server Y that the first thing it
>> needs to do is get the canonical version of Session sessionPPP from
>> server X. (The exact method for this may vary, but suffice to say it
>> will not involve spawning Threads from Servlets. :-) In the response
The only problem with this is you have N servers in a rotation (sprayed or
DNS round-robin) and one goes down, you lose 1/N sessions.
Some people think that if you are going to bother with session load
balancing / distribution at all, why not try and ensure all the sessions are
safe, not just a majority.
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Posted by Jason Brittain <ja...@olliance.com>.
Nick Bauman wrote:
> Jason,
>
>> Yes, and the way I've seen people solve this issue is to make each
>> server constantly replicate its sessions to another server so that any
>> session's state is stored in two servers (not just one). For example,
>> if you've got four servers, A, B, C, and D, you configure A to
>> replicate to B, B to replicate to C, C to replicate to D, and D to
>> replicate to A. Then the "composite ID" would contain the primary
>> server tag, secondary server tag, and the session ID, like:
>> A:B:sessionXXX. So, if server A went down, the load balancer could
>> still get session info from server B, and at the same
>> time let server D know that A is down and to replicate to B until
>> further notice.
>
>
> Naaaah.
>
> This is once again only making sure a majority of the sessions are saved in
> a rotation. A lot of work for very little real fault tolerance.
Sorry to say, but the folks at BEA disagree with you -- this is exactly
what Weblogic does to facilitate distributed HTTP sessions. In-memory
replication to a selected "buddy" server is pretty fast and fault tolerant
enough for most failures. It can also ensure no single point of failure.
> Also I think your english up there indicates a solution that causes
> tremendous hysterysis amongst the servers.
How so?
>> This also works when each server replicates sessions to more than one
>> backup server so that you've got even higher fault tolerance (but
>> you'll probably never need that level of fault tolerance).
>
>
> Now you may have something: a seperate, parallel, session cluster.
Anyone could sure do it that way. But, I'm not sure that separating it
out from the servers themselves could add much fault tolerance since
the cons to doing this seem to be about as large as the pros. It seems to
me that making it part of the servers (the servlet containers, for instance)
would work just as well.
--
Jason Brittain
Software Engineer, Olliance Inc. http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Posted by Nick Bauman <ni...@cortexity.com>.
Jason,
>
> Yes, and the way I've seen people solve this issue is to make each
> server constantly replicate its sessions to another server so that any
> session's state is stored in two servers (not just one). For example,
> if you've got four servers, A, B, C, and D, you configure A to
> replicate to B, B to replicate to C, C to replicate to D, and D to
> replicate to A. Then the "composite ID" would contain the primary
> server tag, secondary server tag, and the session ID, like:
> A:B:sessionXXX. So, if server A went down, the load balancer could
> still get session info from server B, and at the same
> time let server D know that A is down and to replicate to B until
> further notice.
Naaaah.
This is once again only making sure a majority of the sessions are saved in
a rotation. A lot of work for very little real fault tolerance.
Also I think your english up there indicates a solution that causes
tremendous hysterysis amongst the servers.
> This also works when each server replicates sessions to more than one
> backup server so that you've got even higher fault tolerance (but
> you'll probably never need that level of fault tolerance).
Now you may have something: a seperate, parallel, session cluster.
> --
> Jason Brittain
--
Nick Bauman
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Posted by Jason Brittain <ja...@olliance.com>.
Nick Bauman wrote:
> Pier,
>
>>> If the next request from that client is routed to server Y, then
>>> server Y will get a request with that same composite ID of
>>> "serverX:sessionPPP". This tells server Y that the first thing it
>>> needs to do is get the canonical version of Session sessionPPP from
>>> server X. (The exact method for this may vary, but suffice to say it
>>> will not involve spawning Threads from Servlets. :-) In the response
>>
>
> The only problem with this is you have N servers in a rotation (sprayed or
> DNS round-robin) and one goes down, you lose 1/N sessions.
>
> Some people think that if you are going to bother with session load
> balancing / distribution at all, why not try and ensure all the sessions are
> safe, not just a majority.
Yes, and the way I've seen people solve this issue is to make each server
constantly replicate its sessions to another server so that any session's
state is stored in two servers (not just one). For example, if you've got
four servers, A, B, C, and D, you configure A to replicate to B, B to
replicate to C, C to replicate to D, and D to replicate to A. Then the
"composite ID" would contain the primary server tag, secondary server tag,
and the session ID, like: A:B:sessionXXX. So, if server A went down,
the load balancer could still get session info from server B, and at the
same
time let server D know that A is down and to replicate to B until further
notice.
This also works when each server replicates sessions to more than one
backup server so that you've got even higher fault tolerance (but you'll
probably never need that level of fault tolerance).
--
Jason Brittain
Software Engineer, Olliance Inc. http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org