Thanks for the input, Andy. The discussion of how the server-side works on the wiki doc
is still very thin. Also, we also had a conf call right before I went on holiday; I need
to update the docs for that.
How the HASingleton should work is an open issue. If the load balance calculation is
stateless, it's a trivial HASingleton problem; if the current master fails/shuts down,
the new one takes over and starts sending data to the mod_cluster instances. But, in
reality the load balance calculation is unlikely to be stateless; e.g. most will probably
use some sort of time-decay function. So, we need something like a master/slave, where the
slaves maintain the necessary state to take over the load balance calculation if they are
elected master.
A few approaches to this come to mind:
1) Nodes multicast their node data to the cluster. So, any node that is interested in
maintaining state has it. Don't much like that, as it's pretty chatty in a large
cluster. If the underlying JGroups channel isn't UDP-based, then its a lot of
traffic.
2) Nodes are aware who the master and slaves are, and send multiple unicasts. Again
chatty.
3) Master knows who the slaves are and sends a copy of aggregated, pre-digested state to
them every time it recalculates. This seems the most logical.
In any case, a good load balancing algorithm should have smoothing functions built in to
ensure the results do not change too radically if some state gets dropped..
The current HASingleton infrastructure should support these options pretty well; any
HASingletonSupport subclass is a regular service that adds a couple extra lifecyle stages
to the standard 4:
create
start
become master
stop master
stop
destroy
They also get callbacks for cluster topology changes. So, it's easy for the
ModClusterService to run on each node in the "started" mode, monitoring state if
they believe their position in the topology makes them a "slave". Then take
over interacting with the mod_cluster instances when they "become master".
Re: communication across the firewall, the intent is to use http/https from the AS side to
the httpd side for the load balancing information. What port and whether http or https is
used depends on how the user configures httpd. Basically, mod_cluster functions as an
httpd mount, similar to the jkstatus web app that comes with mod_jk. Here's the
config you add to httpd.conf for that; I assume mod_cluster would use something similar
(with a different "Allow from"):
| <Location /status/>
| JkMount jkstatus
| Order deny,allow
| Deny from all
| Allow from 127.0.0.1
| </Location>
|
For normal request traffic from mod_cluster to JBossWeb, communication will use AJP. The
AS-side endpoint will be the standard AJP Connector; there is no intent to modify that at
all for this. So, if Mladen et al decide to add TLS support to AJP, then it would be
handled.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117745#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...