On 13/11/2001 06:53 pm, "Tom Drake" <[EMAIL PROTECTED]> wrote:
> | > SNMP, ah ja. I've got no knowledge at all 'bout that, so fight with some
> | > other lobbyists :-)
> |
> | Same here...
>
> Didn't mean to take a left turn. Sorry I mentioned it.
Oh, I mean, I don't mind... The only thing is that I have no clue on how
SMTP works :) :) :)
> I want a distributed session store, where all sessions are known (or
> are knowable) by all members of the cluster, with a built-in
> fail-over mechanism?
>
> I want to be able to scale my web server by simply adding
> more standalone Tomcats and possibly session managers.
> I want to be able to use a brand-x HTTP load-balancer that
> redirects web-traffic on a request-by-request basis to the tomcat
> webserver that it thinks can best handle the request. I also want
> to be able to bring down individual Tomcats without destroying
> any user sessions.
>
> Apache's 'smart' approach (that remembers which JSESSIONID's
> are hosted by which Tomcat Servers) doesn't let me bring down
> individual Tomcat servers without losing sessions. This means
> that Tomcat servers are simply not 'hot-swappable' in this configuration.
>
> ASFAICT, minimal redundance is all that is required. There's simply
> no need to keep a gratuitous number of session copies around.
Well, for fault tolerance, we require at minimum TWO copies of a session
hosted on two different JVMs, because, in case one of those two fails, the
other one needs to take over. So, yes, minimal redundancy can be achieved.
The fact of having a smart load balancer in the front doesn't preclude or
modify the behavior of the backend.
Thinking about it, the modules up front could actually perform their load
balancing depending on the configuration of the backend, if those
information could be shared amongst both the web server and the servlet
container...
> This is only an issue in the event that the Session Manager is a seperate
> entity.
But at that point, if we want to use a session manager separated from the
servlet engine, we could simply provide the session manager with the same
"WAR" file given to the servlet engine, and forget about it...
> One thing to remember here is that the number of 'clients'
> in our discussion is always fixed - it is the number of Tomcat
> web servers in the 'cluster'. The load of the session managers
> is a direct function of the load on it's clients. Hopefully, the load
> balancer on the front end (either Apache round-robin, or some
> firmware solution) is doing a 'reasonable' job of spreading the
> load across web servers / tomcats. Therefore, as long as the
> number of Tomcats served by each Session manager is
> approximately the same, we can deduce that the load placed
> on the session managers will ALSO be reasonably well balanced.
> If my deduction is correct, then there should be no need for
> posting load factors, and continual switching back and forth
> between session managers.
You assume that the number of servlet containers is fixed and well known,
and that the round robin algorithm in front is kinda smart... What if one of
the container crashes and I want to deploy another one on the fly? What if I
want to scale without having to "reboot" my whole pool? IMO, on the fly
addition/removal of servlet containers and/or session managers is a must.
> Lets create some more examples:
>
> 1) 10 Tomcat webservers (1-10). Servers 1 and 2 happen to be
> identifed as 'Session Managers' as well as web servers.
> Servers 3-10 are just plain web servers, not session managers.
>
> In this scenario, Tomcat servers 1 and 2 are burdened by satisfying
> session requests (queries & updates) from the other 9 servers, as well
> as handling their own web-traffic. They must also initiate communication
> to the other 9 servers whenever a session is invalidated (due to update,
> maxAge, or on demand). They must also communicate all session deltas
> to the 'other' session manager.
>
> 2) 10 Tomcat webservers, all 10 are identified as 'Session Managers'
>
> In this scenario each Tomcat must communicate session deltas to each
> of the other 9 servers. All servers must perform significant extra work
> in order to keep their Session store up-to-date.
>
> 3) 10 Tomcat webservers, 2 separate Session Managers.
> Tomcats 1-5 point to SM1, Tomcats 6-10 point to SM 2.
>
> In this scenario, each Tomcat only communicates with 1
> session manager. Each session manager communicates
> session deltas with the other SM, and with only the Tomcat
> servers that it connect themselves to it (5 in this example)
> on an as-needed basis (e.g. when the Tomcat instance asks
> for the session data). Each SM must also send tell all it's clients
> when sessions are invalidated.
>
> Fail-over could be handled in a similar manner in all scenarios.
> Addition of a new SessionManager (or SessionManager capable Tomcat)
> could be handled in a similar manner in all scenarios.
Hmm... I don't agree with those three scenarios... I would love to see a
configuration where 10 Tomcats are both web servers and session managers:
all they have to do is replicate a session instance into other N Tomcats
depending on their loads, where N is the redundancy factor that the
administrator wants to get...
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
