I have two Integration servers(8.2) installed on local machine. I want to cluster them. Anyone could give me the steps to do the same. Help is appreciated. I have gone through the clustering guide but couldn’t get much out of it, since it doesn’t give details on setup from scratch.

Thanks
Bharat

Which parts of the clustering guide are unclear? Chapter 2 has the information and specific steps.

Thanks for reply. Yes chapter 2 gives only these details:
Enabling Clustering and Specifying Clustering Parameters
Use the following procedure to turn clustering on for this Integration Server and to
specify various clustering parameters:
1 In the Settings menu of the navigation area, click Clustering.
2 Click Edit Cluster Settings.
3 Click Enable Cluster.

But the question is before we do these above settings in the IS admin page, the cluster node has to be formed(having 2 IS) and they should share same repository. I have read that there should be some "Internal Database and Load Balancing"in place before the clustering is done.

I am looking for those setup steps.

Thanks
Bharat

I have read that there should be some "Internal Database and Load Balancing"in place before the clustering is done.–>As far I know yes they should share same DB (2 IS in cluster) but LB is not necessarily required.

HTH,
RMG

Thanks RMG, yes load balancing is not necessary until volume of transactions are high. Still i am looking for step by step instructions for clustering setup.

Thanks
Bharat

It does not make any sense to set up IS clustering if there is no load balancer in place in front of the cluster. Keep in mind that using LB also provides for more than just increased volume.

A load balancer is needed to distribute traffic going to IS (web and service clients). I know some scenarios where you do not have traffic going to IS, but still want clustering, e.g. for failover.

Clustered IS need a common reopisitory which must reside in a database. Usually the database will be clustered as well (with database own clustering methods).

You should consider if you really need IS clusters, basic balancing and failover can also be reached by sharing queues between 2 (or more) IS. As documents are only commited when a service executes succcessfull, you also get basic failover. I have good experience with IS clusters, but other forum members have not and it adds complexity to your solution.

Integration_Server_Clustering_Guide should give all necessary information to setup an IS cluster.

Regards

Martin

Interesting. I hadn’t really thought about that scenario as I’ve never seen the case where IS is used only for scheduled tasks and adapter notifications (both of which are supported for failover by IS clustering) and didn’t have some inbound HTTP traffic of some sort (IS API clients are relatively rare, IME). But I suppose one could leverage IS clustering without an LB in front of the IS instances. It’s just that I’ve never seen that done.

Agreed. I refer to those as “Broker client cluster”. One may also have a “TN cluster”. Each of these is independent of IS clustering. I fully agree with “it adds complexity” and is the basis for that big thread titled “IS clustering to be avoided”. Implementers need to make sure they understand what IS clustering does and does not provide.

We have this similar setup/scenarios in place and it’s working so far but YES having LB is also a added advantage…I am not opposed to LB:

Normally LB is put at entry point that is RI servers. In EAI model rarely LB is used as the traffic is very predictable as well can be scheduled/controlled well.

I have not seen LB being used in EAI projects even though volumes are high (millions). If I understand well if some how the point of entry can be contolled then LB make sense as we will have to mange single IP where load is balanced. Mutiple IP’s as entry then LB it self becomes complex.

Schedulers / Notifications / Ports (except email) work well in cluster.

Atul

My experience has been different. If by “EAI model” you mean “all participants inside the firewall” then the majority of implementations I’ve been associated with have used an LB device. An LB will expose a single hostname/IP and distribute traffic to the nodes behind it. I’ve never seen the case where the LB exposed multiple IPs for a given cluster.

Using an LB provides the obvious “load balancing” and support for higher volumes but it also contributes to high availability and the ability to do maintenance without taking the integrations completely out of service. E.g. take a node out of the cluster, do maintenance, put it back into the cluster, then do the same for the other nodes. The end systems are none the wiser.

I have not seen LB being used in EAI projects even though volumes are high (millions)

Can you elaborate here?..you mean only B2B/eMarketplace projects LB needs to be used?

Here is my reply point wise -

If by “EAI model” you mean “all participants inside the firewall” - Yes.
An LB will expose a single hostname/IP and distribute traffic to the nodes behind it - Very True
I’ve never seen the case where the LB exposed multiple IPs for a given cluster - I have also not seen.

I agree with what Reamon has mentioned. Without LB also if IS is clustered we can still shutdown one IS, do the maintenance and put it back in cluster. Very much possible, only the point is we cannot achive load balancing. Cluster acts only as failover.

Atul

Without LB also if IS is clustered we can still shutdown one IS, do the maintenance and put it back in cluster. Very much possible, only the point is we cannot achive load balancing. Cluster acts only as failover. –>Absolutely

True but how do HTTP and FTP clients connect to IS? They’d need to use the node-specific hostname. So when that node is down, those clients cannot connect. IS clustering provides no benefit in this regard.

An IS cluster supports failover only for clients using the IS API. No other protocol is supported for failover. And it is the IS API that is responsible for noticing that a node is down and connecting to another node. IS provides no direct support for that. IS cluster failover is very narrow in what it supports.

For these reasons, an LB is pretty much a necessity when using IS clustering.

IME, IS clustering has been one of the most misunderstood features of the suite. Usually the view is that it can do more than it really does.

HTTP / FTP → Use VIP (virtual IP / DNS) on those servers.

When you mean IS API, it sounds same as WM REPO server which manages the IS cluster.

I agree clustering using LB is complex there are many combinations to it makes it a bit challanging.

That’s a load balancer, no? Perhaps this is just a terminology issue. When I say LB I mean any device (e.g. F5) that “hosts” the VIP and directs traffic to one or more physical machines represented by the VIP. The device doesn’t need to do load balancing per se. It may just route all traffic to one node and if that node goes down, routes to the other node. Isn’t this sort of device generically referred to as a load balancer?

But I’ll rephrase my earlier statement: a VIP is pretty much a necessity when using IS clustering.

The IS API has nothing to do with the wM repository server. The only types of clients that IS cluster supports directly for failover are clients that connect to IS using the Context and TContext classes. No other type of client is supported.