HornetQ HA and load balance: a deepdiving question

[yalwang]

Hi,

HornetQ uses active/passive node for failover and "store and forwading" for load balancing within cluster. Active/passive requires additional config and maintaining of states, while "store and forwarding" introduce additional hops. There is an alternative I will list below, which I believe HornetQ developers had checked and decide not to take. I would like to know the reasoning. We are evaluating to use hornetQ or build our own solution using the alternative.Ppersistence storage and no message loss is a must for our scenario.

So alternative is to use a central storage (like db, which can be horizontally partitioned and configured as master/slave behind a virtual host). All the broker nodes write (produce) and read (consume) from it. Thus, we dont have to maintain active/passive config for broker node, and failover and load balance can be achieved at the same time without any state maintenance or forwarding. Any potential problem with this approach?

Thanks!

[ataylor]

So alternative is to use a central storage (like db, which can be horizontally partitioned and configured as master/slave behind a virtual host). All the broker nodes write (produce) and read (consume) from it. Thus, we dont have to maintain active/passive config for broker node, and failover and load balance can be achieved at the same time without any state maintenance or forwarding. Any potential problem with this approach?

1.    databases are not really a good fit for messaging systems, messaging is append only so performance is poor (most messaging vendors will not use a db as theeir primary persistence) this is why we use a journal. take a look at this forum discussion https://community.jboss.org/thread/153581?tstart=120

2     providing redundancy for databases can be cost restrictive for some users

3     It is a central point of failure

The main point here is 1, the reason we get such good performance(and scalability) is because we use a journal and leverage libaio (or NIO), using a central storage(whether DB or not) would drastically effect this.

a couple of other points

we dont have to maintain active/passive config for broker node

You can use the same configs, all you need is to use some properties , i.e. <backup>${hornetq.backup:false}</backup>, and set them via a script or something

and failover and load balance can be achieved at the same time without any state maintenance or forwarding

you could never completely remove forwarding, even messaging products that use a database sstill would need to talk to each other (and clients who wouldnt have access to the shared storage) for things like detecting node failure etc. As for state maintenance, just because its centrally stored doesnt mean it doesn't need maintained, nodes would have to keep current state in memory not just read it from the DB when needed, for instance if a node was to fail the whole state of that node needs to be re created by the node taking over, Also if you use shared store in HornetQ the information passed around is quite small.

We are evaluating to use hornetQ or build our own solution using the alternative

I don't know your use case fully, but why invent the wheel, even if you don't use HornetQ there will be many other solutions available. Also if using DB(or some central store) is high on your list do you really need a messaging system, maybe you could just use a database and read/write.

Ppersistence storage and no message loss is a must for our scenario

Of course HornetQ provides all this.