See below. ----- Original Message ----- From: "Pier Fumagalli" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 12:23 PM Subject: Re: Tomcat: Distributed Session Management revisited
| > 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. Agreed on your first point. As to the second. I'm not so sure. There are alot of assumptions that can be made because we have essentially a fixed number of possible clients (yes, you should be able to add more servers on the fly, and shut them down independantly as well). In concrete terms, and IMHO, as long as the Tomcat clients are fairly evenly distributed across the session servers, we will be as 'load-balanced' as we will ever need to be. | | 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... True. | | > 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... True. But solving this serialization problem is pretty easy. But I suppose we're delving into details here that aren't really too important just yet. | | > 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. | I'll take your point that the relationships between servlet containers and their session managers may need to change dynamically (as servlet containers are added or removed, or as session managers are added or removed). I definately agree that this is a requirement. This being the case, I think we can handle this simply by adding some code that lets the session managers figure out how to spread the load by asking each other how many clients they are supporting. If any are supporting too many or too few, some client server relationships could be shuffled around until an acceptable tolerance is reached. (You may have already said this in your email - above - just in different words). I suppose the 'policy' used for making such a decision (e.g. how many and which clients should be supported by any given session manager) could be as simple as I have described or be based on a more sophisticated algorithm that takes into account measured / available bandwidth, memory, cpu speed, etc.... Perhaps the 'load managing' bits should be abstracted into it's own (set of) interface(s), with a very simple concrete implementation, initially. | > 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... | I don't understand the difference between a 'session manager' and replication. I'm clearly marrying these concepts (in my own head anyway). Because as long as at least 2 session managers are running (bundled w/servlet containers or not) we have enough redundancy to support fail-over. In my view adding session managers does two things: 1) improves overall performance, 2) increases redundancy. I think your scenario is simply an extension of (1) above. 'N' in that case is 2. However, I'm still assuming that each servlet container is caching sessions that they have used. If this is the case, then all servlet containers need to be notified when any session changes in order to ensure that it uses the correct session data when called on to service that session. | Pier | | | -- | To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
