Hello,
> 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.
"only one reason" is probably a bit strong... It depends of your business:
you may need high availability or/and you may need very high throughput
while keeping the cluster state consistent without worring much about lost
clients when a server dies.
> 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 :)
Yes sure, if you are serious about fail-over, you buy a 1M$ TPM with a Sun
Enterprise 10000 ;), SAN replicated datastore, Oracle DB cluster, ... ;)
I think we need to focus on both aspects without imposing that 99% of JBoss
user only want fail-over. It is not because some other products also offer
this feature that we should not provide it! (Furthermore, I hadn't the
feeling that we were only speaking about LB.)
But I agree, load-balancing without HA is not very functionaly interesting
whereas HA without load-balancing is a bit "unfinished work".
> so the whole round robin thing? let's focus on the main issue.
<focus status=ON target=MAIN_ISSUE>
> let's focus on the important things
<focus status=ON target=IMPORTANT_THINGS>
> 1. how do we share data in the JNDI tree
I was suggesting to use a standard CORBA NS and extend it to be able to
share the same binding name more than once.
=> The container knows the extended IDL and is able to register it
correctly.
=> When a client asks to resolve a name, the NS build a multi-profile IOR
(here comes the HA) thanks to a particular algorith. The algo could be :"
put the profiles from the least loaded server first" or whatever plugged
algorithm is selected.
We may use the JavaGroups framework to replicate the different instances of
extended NS and thus insure that all NS can receive Read and Write
invocations while staying consistent.
For the egg and chicken problem... we need to be able to give to the client
the complete list of NS which are available if one fails : either with an
multi-profil IOR (beurk) or with any other bootstraping system (don't have
enough info at the moment)
> 2. how do we solve JNDI naming conflicts (ie two server nodes try to bind
> different objects with the same name)
conflicts would be at the heart of the system! ;)
> 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)
I think we need to develop an hardware-less solution as much as possible.
For the stub, this would work for Java client but with standard CORBA
client, it wouldn't => multi-profile IOR idea.
> 4. cluster management/communication
base on JavaGroups? no real idea at the moment...
> 5. deployment management, does every node in a cluster have the same
> deployment configuration, or will this be automatically replicated
I suggested to be able to choose, in the cluster, to which node an
application is deployed (subset)
</focus>
</focus>
> Am I completely out in the blue? please let me know.
No or we are two ;)
Cheers,
Sacha
