Hi,
 
Ok..I got Orion to cluster..thanks to the MIRC gang. It was MUCH easier than I thought. I am amazed at how easy things are.
 
Anyways, the team of developers I work with have different views on session fail-over. I am wondering what the popular concensus is from those of you familiar with this topic. WebLogic and SilverStream employ a "buddy" type of system for session replication. That is, there is a primary server (the one the session is created on) and it finds a secondary (if there is another server on the farm) and replicates the session data there. If the primary goes down, the secondary takes over..becoming the primary and it then looks for another secondary (yet again making itself the secondary if no other servers are available). The advantage to this approach is the more servers you add, it does NOT cost in replicating the session data. It is ALWAYS two servers (or one if only one server is left). With Orion, and some other app servers, every server added to the farm makes the session replicate to it. Thus, if you add 10 servers to the farm, the session data is replicated to all of them.
 
So my argument is, is it worth the extra time to replicate each session to every server, or is it better to do the two-server approach. I would think in terms of performance, replicating to only two servers would yield much faster returns of pages. Each time an object is added to a session, the session is only replicated to one more server. Is this in actuality true? Is it faster to only replicate to two servers than to every server on the farm?
 
On the other hand, by replicating to every server on the farm, if two or more go down, you still have the session alive somewhere else. In terms of failure, its very unlikely that both the primary and secondary servers would crap out (in the WebLogic/SilverStream approach to session fail-over), but it is possible. So the advantage of Orion and others is that it guarnatees absoulte maximum up-time at the cost of performance. What if a session when created stores 200 objects in it, and you have 10 servers..does Orion end up create 2000 objects on 10 servers? If so..doesn't that take alot more time than say WebLogic that would only create 400 objects on two servers, even if 10 were in the farm?
 
I am wondering..is it that much harder for Orion to give the choice of how to replicate sessions? I think that would be a kick-ass option. You want a bit more performance out of your farm..only replicate to X number of servers, otherwise replicate to all of them.
 
 
Now, one dilema eludes me..if in a normal setup you use Orion as the web server AND servlet container in one instance (one server), does the load-balancer need to keep track of sessions (cookies) in order to send the client to the right server (if it were a primary/secondary setup), or does Orion have "smartness" built in so that if a request comes in..it would check the various servers on the farm to see if the sessoin exists before creating it. I would still think some sort of session list would need to be maintained on all servers for this to work, but at least if a request came in with a session key, that particular instance would send out across the multi-cast ip to check if the session exists on any of the other servers in the farm. If it does..it reroutes the request to that server. If not, it creates it (and replicates it out to one or more servers). Oh yeah..what I am describing in this paragraph is assuming Orion allowed x number of servers for replication.
 
I would love to hear anyones views on this, especially if you have experience with it.
 
Thanks.
 

Reply via email to