My primary need for clustering is failover, but I have an interest in load
balancing as well. But if I have to choose the two, I would have to choose
failover. Of course, thats just me, but I'm probably not the only one.
Failover, though, includes the whole J2EE app. I realize jBoss is primarely
an EJB server, but I'm thrilled to see it bundled with things like Tomcat
and Jetty, bringing it closer to a J2EE app server. Along those lines,
failover might also require that the servlet session data be clustered.
There are many choices. I may choose to run my web server/servlet container
on a different physical box than my jBoss server/database engine for
security reasons. If I do this I can run a different servlet server and let
it talk with jBoss. Or I may choose to run two boxes each with a complete
web/servlet/jBoss server. This might be better for load balancing with
round robin DNS.
So the point I'm trying to make is that having two features would be great:
First, jBoss would benefit from the ability to work cooperatively with a
clustered servlet container (maybe the Jetty folks would be interested in
this) and second, it qould be great if all the components were location
transparent, so that the servlet containers and jBoss can all be located on
the same or different hardware.
Just my $0.02.
Jim
--On Wednesday, March 07, 2001 9:23 AM -0800 Filip Hanik <[EMAIL PROTECTED]>
wrote:
> ok, let me raise my voice :)
> the emails around clustering seem to focus a lot on loadbalancing as the
> primary reason to cluster servers.
> well, imho it is not.
> there is only one reason you would cluster servers, fail-over and high
> availability.
>
> if you want to do loadbalancing, you have much better performance using
> non-clustered servers and a stateful loadbalancer.
> as a matter of fact, you can buy a load balancing router for a couple of
> thousand bucks, so why try to replicate functionality that is already
> done. even with weblogic, if you are serious about loadbalancing because
> you have sooooo much traffic, you do it the hardware way. again this is
> in my humble opinion :)
>
> so the whole round robin thing? let's focus on the main issue.
>
> let's focus on the important things
> 1. how do we share data in the JNDI tree
> 2. how do we solve JNDI naming conflicts (ie two server nodes try to bind
> different objects with the same name)
> 3. pinned vs. unpinned server objects (unpinned would be the goal, that
> the remote stub would automatically reconnect to a different server node
> if the main node fails) again, if you have full clustering on the server,
> the load balancing router can reconnect you to a different node, without
> any client logic, but this piece of hardware will not always be in place)
> 4. cluster management/communication
> 5. deployment management, does every node in a cluster have the same
> deployment configuration, or will this be automatically replicated
>
> Am I completely out in the blue? please let me know.
>
> Filip
>
>
> ~
> Namaste - I bow to the divine in you
> ~
> Filip Hanik
> Software Architect
> [EMAIL PROTECTED]
> www.filip.net
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Stefan Siprell
>> Sent: Wednesday, March 07, 2001 8:26 AM
>> To: 'JBoss-Dev'
>> Subject: AW: [jBoss-Dev] CL: Clustering, let's get started
>>
>>
>> to put a tie around all of my complaining, I would also volunteer
>> to create
>> a dcoument describing the main ideas and concepts:
>> -Round Robin (kind of low, but the one that would create working versions
>> the fastest)
>> -Bean-level Request Dispatching
>> -CORBA infrastructure
>> -and maybe JINI and SPACES (my little idea)
>>
>> Might be easier to discuss (if required at all) the future path.
>>
>> -----Ursprungliche Nachricht-----
>> Von: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]Im Auftrag von Peter F. Spicer
>> Gesendet: Mittwoch, 7. Marz 2001 16:39
>> An: JBoss-Dev
>> Betreff: RE: [jBoss-Dev] CL: Clustering, let's get started
>>
>>
>> Lots of good feedback on the Clustering issue. Anybody thought about
>> putting together a requirements document that captures these ideas and
>> defines "The Path" for the effort? Does not have to be fancy - I would
>> volunteer but don't have the chops (domain expertise).
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Micheal J
>> Sent: Wednesday, March 07, 2001 6:41 AM
>> To: JBoss-Dev
>> Subject: RE: [jBoss-Dev] CL: Clustering, let's get started
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy Boynes
>> > Sent: 07 March 2001 06:35
>> > To: [EMAIL PROTECTED]
>> > Subject: RE: [jBoss-Dev] CL: Clustering, let's get started
>> >
>> >
>> > Tom's question was really about approach rather than solutions
>> and you did
>> > ask for views... You might choose a "simple" scenario such as pure SSBs
>> > first, but I tend to agree with Tom that you should consider the core
>> > building blocks (e.g. DTM, cluster membership, resource location, state
>> > replication, and many more) whilst doing so as in reality none of the
>> > scenarios are actually that simple.
>> >
>> >
>> > As for applicability of a DTM, one of the goals of a cluster is
>> > location transparency (at least to the application). So consider a
>> cluster with two
>> > nodes, 1 & 2, and two SSBs A & B; SSB A calls a method on SSB
>> B; SSB A is
>> > deployed to node 1, SSB B to node 2.
>>
>> My definition of application server clustering does not allow a
>> situation as
>> you just described Jeremy. The beans (actually the application) would be
>> deployed to the "cluster" and not to any particular node (or nodes) in a
>> cluster. On an implemenatation level, I would still expect all
>> nodes to host
>> all applications once deployed. This removes the possibility of any
>> application being unavailable even though a cluster is atill active. This
>> could happen if either node 1 or node 2 failed in your example.
>>
>> Also I believe we need to think about the jBoss clustering effort in the
>> wider context of clustering complete J2EE applications. Perhaps I
>> am missing
>> something here but shouldn't think about how a cluster-capable
>> jBoss affects
>> jBoss-Tomcat and/or jBoss-Jetty and other such (aggregated) J2EE stacks?.
>>
>> My Use Cases for a "JBoss Cluster User" includes :
>> - Cluster Management: define/change the set of nodes (JBoss only or
>> JBoss_+_Tomact/Jetty/etc) that belong together as a cluster
>> - Application Deployment: deploy a JAR, WAR, EAR e.t.c on a node
>> (any node?)
>> in a jBoss-Tomcat (or jBoss-Jetty) cluster and have the application
>> automagically deployed (and load-balanced) across all the nodes in the
>> cluster. I presume that there would be a deployment tool for this purpose
>> and that hot-deploy may or may not work (it would be great if it did
>> though).
>>
>> Issues:
>> - WHAT IS DEFINED AS A NODE IN THE CLUSTER?
>> a) A physical computer running jBoss ?
>> A cluster is then a named set of physical computers. This raises
>> questions such as "must all instances (i.e. on different port nos)
>> of jBoss on these computers be automatically clustered?".
>> b) A specific instance (identified by port no) of JBoss running on a
>> specified port on a physical computer?.
>> A cluster may be all instances of jBoss running on the same port on
>> a specified set of physical computers. If the instances are truly
>> isolated, one can run a dev, test and staging cluster on the same
>> set of physical computers for instance. I use multiple instances
>> in this way with Oracle and SQL Server currently.
>>
>> - WHICH APPLICATION RESOURCES CAN BE CLUSTERED?
>> * EJB Jars only ?
>> * WAR, EAR ??
>> * other files ???
>>
>> Cheers!,
>>
>> Micheal
>>
>>
>>
>>
>>
>
