[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Next Gen Web Tier Load Balancing Design

[bstansberry@jboss.com]

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#4117745

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117745