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.
|
- MySql? Steven Punte
- Re: MySql? Brian Beaulieu
- Re: MySql? Steven Punte
- RE: MySql? Michael Bushe
- Trouble with Rmi-Cloudscape from Orion Kevin Duffey
- Trouble with Rmi-Cloudscape from Orion Ishpal
- Re: Trouble with Rmi-Cloudscape from Ori... wim veninga
- Re: Trouble with Rmi-Cloudscape from Ori... Ishpal
- Re: Trouble with Rmi-Cloudscape fro... wim veninga
- RE: MySql? Richard Woodward
- Session fail-over of multiple contexts in on... Kevin Duffey
- RE: Session fail-over of multiple contex... Kevin Duffey