I am investigating solutions that have these requirements
Pretty High volume (so forget about IS software clustering that involves RepoV2 which is a pain in the neck and does not go fast enough)
No downtime allowed (so Hardware clustering is not enough, because it requires downtime during the failover process)
The project will integrate an external provider through a private Extranet to backend systems.
For various reasons, the internal back-ends systems will be integrated from independant ISs, all connected to each other through Broker.
The idea is to have a full redundant system (active-active):
Two IS will listen to outside transactions
Which will be published to a node of two brokers (if one is down, the transactions immediatetly goes to the other)
On the backend side, for each system, there will be two ISs, connected to the two redundant brokers.
So if any of the components is down, there is another one that is not up. The probability that at each layer, both components are down is expected to be very low and acceptable.
The problem is:
Between the external source and the two front end IS, it is possible to use Loadbalancer (because it will be HTTP integration), or Reverse Proxy thingy. So this is OK.
But betweeen the front end and the brokers, we may have to use BrokerClusterPublisher API, but that is custom development and will bypass the IS dispatcher and all set of out-of-the-box services.
Between Brokers and back-end ISs, there is no BrokerClusterSubscriber, and even more custom coding must be done to hardcode in each IS a custom java subscriber to each broker.
So obviously, this involves not-out-of-the-box customizations to reach the goal.
I heard about conexus, a third-party-tool. Any ideas on this ?
Here’s an off-the-wall suggestion–don’t use Broker. I assume that Broker isn’t in place as you stated “…will be integrated…”.
If you don’t have a specific reason to be using Broker (e.g. IS doesn’t have an adapter you need; you really do need pub/sub and the subscribers will change from time to time; etc) then don’t. It adds a layer of complexity for little benefit.
Sounds like using a h/w load balancer to distribute HTTP requests to multiple IS instances would address both load distribution and failover. What requirements lead you to include the two-broker “nodes” in your architecture?
I agree with Rob; unless you need the broker’s pub/sub or asynchronous processing features, adding it to the mix increases complexity unnecessarily.
The real challenge comes when one of your IS services (or the server on which that service is running) fails while processing some unit of work.
In order to restart and complete that transaction on another server, you would have had to have saved the state of the transaction along the way in some manner and be able to determine that the transaction has failed and needs to be restarted on one of the other servers.
If you are using Modeler’s Process Runtime (PRT) much of this is done for you, otherwise you will need to create the needed transaction management utilities to save state at various checkpoints, start and end transactions, restart failed transactions, etc.
I’ve written some custom packages in combination with H/A similar to your project (BCP), it kind of seems to be the solution of your problem. Are you still in need of it?