Integration Server Clustering

Currently we have IS/Broker 6.x in Production (no IS or Broker Cluster now). We are upgrading to WM 8.2 version.
As part of the upgrade, we are planning to set up IS Cluster in QA and PROD environments.

I have the following questions about IS Clustering.
Information about our new environment:
IS 8.2 SP1, Broker 8.2 SP1
IS Adapters: EnterpriseOne Adapter, WebSphere MQ Adapter, JDBC Adapter, Flatfile adapter

  1. About 3rd party Load balancer:
    In general, what are the types of IS service requests that get Load Balanced?
    Specifically we have EnterpriseOne Adapter RTEs (Real Time Events), MQ Messages (using WebSphere MQ Adapter), File Polling transactions:
    Do these all get load balanced across Integration Servers in the Cluster (IS Flow/Adapter Services)?
    OR the Load balancing is only for Http and Web Service requests (coming from external IS clients)?

The reason I ask is: We only have a couple of web services. So if the Load Balancer doesn’t support E1 Adapter/MQ Adapter services then we don’t want to use the 3rd Party Load Balancer.
Is it OK NOT to use Load Balancer while doing IS Clustering?? Is it architecturally supported by WM?

  1. Are there any IS services (any specific adapter services, file polling port services) that should NOT be clustered (might cause problems in a Cluster setup)?

Any help or guidance you provide are greatly appreciated:


“2. Are there any IS services (any specific adapter services, file polling port services) that should NOT be clustered (might cause problems in a Cluster setup)?”

Regarding 2, No issues as far I know either in IS 7.x or 8.x related with the above assets mentioned in the cluster environment (coherence) as long as you have all the core fixes/SP’s installed:

What 3rd party load balancer are you asking about?


Thank you. We have “Citrix Netscaler” as a Load Balancer.
Main question is: which IS transactions or services get Load Balanced?
We know that http requests and web services get Load balanced.
But it is not clear from the “IS Clustering Guide” whether E1 Adapter RTEs, MQ Adapter services and File Polling services get Load Balanced.

That is a bit confusing.
If you can provide guidance, that will be helpful.


My advice 1-don’t cluster 2- see 1

Use your load balancer for your web services and http stuff (ie independent IS instances. Don’t introduce the complexity of a cluster unless absolutely necessary.

I agree with Mark above.

Load balancing (which is a form of clustering) and IS clustering are 2 different things. IS clustering does not provide load balancing.

“which IS transactions or services get Load Balanced?”

Every service called via your LB device is load balanced. Those called directly on IS are not.

A misleading thing about the IS Clustering Guide is that it implies that IS itself will balance/failover HTTP requests. It doesn’t. Only IS clients using the IS API will do this–and it is the client that is doing the failover, not the server. It is the bit that notices an IS is down and so tries another. In my experience, I’ve never seen anyone use such a client.

When reviewing the IS Clustering Guide think in terms of components being “cluster aware” instead of being load balanced. Some components are aware of the cluster. E.g. the task schedules you set up in IS Administrator can be configured to run on only one server, any server in the cluster, or all servers in the cluster. JDBC notifications can be cluster aware.

For each component you’re wondering about, check the doc for that component. It should mention how it behaves in a cluster, if it is cluster aware. If it doesn’t say anything, it most likely is not.

All that said, IS clustering is to be avoided if at all possible. An LB cluster is usually sufficient.

IS clustering is to be avoided if at all possible"–> Why any strong reason to avoid cluster IS’s?

There are a number of aspects to consider. This thread covers many of them.

A great legacy thread::slight_smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.