Failover and Clustering

There are many posts here related to clustering but not much about failover. There is an interesting post from reamon and mcarlson several years back against IS clustering. If this opinion still stands… I am looking for recommendations on setting up IS and Broker for failover or HA.

The old post was pointing out that the IS clustering facilities 1) didn’t do as much as most people thought; 2) weren’t needed in many situations.

There are more IS facilities that are now IS cluster aware so using IS clustering will be more prevalent.

The key points are that one should fully understand what IS clustering does and does not do and if you can do what’s necessary without it you can avoid the additional moving parts/configuration.

A load-balancing cluster for IS is a good way to go, with or without IS clustering. It provides scalability and a level of HA.

For IS failover, it’s pretty much relegated to the client noticing that the interaction with IS failed and trying again. If an IS instance fails, then the LB device will notice and route connections to the other instances. If duplicate transactions must be avoided, then a scheme to detect them and deal with them must be put into place.

For Broker, HA is provided using OS clustering in active/passive mode. Scalability is provided via bigger hardware capacity or by partitioning things using multiple brokers in a territory.


I have a problem that I am phasing on my HTTP/S protocol. Today before upgrading to Clustered Server environment, I only have one Integration Server to work with. For that, the certificates are tightly coupled to the server.

Now, that we have successfully setup the two physical server that contains one Integration Server each. the problem is for Server A will always receive the transaction and not Server B. We have a load balancer that routes and check the server health. If I give the client, Server’s A cert. The client’s transaction will always fire transactions into Server A, and the load balance will never be able to route the transactions to Server B.

Is there anything that we can work on, to resolve this issue?