Integration Suite Clustering

Question:

We are looking to setup a two node Adeptia Integration Suite cluster in our Production environment, mostly for fault tolerance, and hopefully load distribution as well. We currently only have a single 5.2 system in our Prod environment.

I’ve been reading the Clustering section of the Admin Guide, but it seems to be missing some pertinent information. Specifically, these are the questions I have up front…

1. The prerequisites mention that the both the Log database and the “Backend” databases should be shared between all the cluster nodes. Is there any procedure for setting this up? We only have a single 5.2 server running in our Prod environment right now, and the Log database is on a separate SQL 2008 R2 server. I can’t find any information about what the “backend” database is, or how to set it up. I’m assuming it stores all the objects and users, and perhaps by default an embedded database or flat file system is used to store that info? If that is the case, how would we migrate to a non-local and shared backend DB?

Answer:

The cluster nodes are actually the Adeptia KERNEL and WEBRUNNER processes running on different servers (in a cluster). The clustered environment shares the Log DB and the “Backend” DB (which is the repository of objects such as flows, schemas, maps etc.). It is recommended that there be a separate DB server where the Log DB and Backend DB are running. You can find instructions on how to setup the backend DB on an external database on here: http://support.adeptia.com/entries/21260577-moving-backend-database. By default, the backend database is embedded in Adeptia.

You also need to make sure that there is a common file share between the clustered nodes for the run-time repository folder.

Question:   

      2. How do releases to clusters work? Do you have to promote objects to every node and manually keep them in sync, or do the objects get shared somehow (I guess that leads back to question #1).

Answer:

The objects are shared since the backend database is shared by all the nodes.

Question:

      3. I’m also curious how the load balancing works exactly. I would imagine everything picked up by Adeptia in some Queue is just load balanced by the Adeptia application itself somehow, but I assume we’ll need to use our F5 load balancer to balance any incoming connections directly to the web service?

Answer:

The load balancing for the process flow execution (Adeptia KERNEL) works via this clustered setup. One node is automatically designated the PRIMARY node and it manages the job queue and issues jobs to be run on different nodes based on a round-robin algorithm. If any node crashes, the PRIMARY node knows thru a heartbeat mechanism and stops issuing jobs to that node. If the PRIMARY node crashes, one of the remaining nodes automatically becomes the PRIMARY.

 For the incoming connections, the load balancing is thru the Adeptia WEBRUNNER process running on each node. As you correctly said, you need to use the F5 load balancer to take the incoming connections and have it route them to the clustered nodes. Even in this case, even if the WEBRUNNER process in one node takes the request, the processing is done via the KERNEL cluster logic described above.

 Question:

         4. What is the role of clustered environment when there will be multiple REST calls fired and Process Flows ( bind as REST WS providers) get executed?

Answer:

Clustering is implemented at Kernel level – for process flow execution. All the process flow execution invoked through rest calls (received on any cluster node) shall always be load balanced on Kernel in clustered nodes

Question:

         5. Will cluster distribute the jobs equally on both primary and secondary nodes? and Where are all the requests handled i.e. Primary/Master node or it can reach directly to secondary node?

Answer:

Yes, the cluster will distribute the jobs equally on all nodes. The node on which Rest call is received queries the Primary node for next available node for process flow execution (as per round-robin load balancing algorithm). Thereafter, the process flows instance is created and executed on next available node via RMI call. If there is some exception while doing this load balancing, then process flow is executed on same node where the request is received.

For more information regarding clustering, read our Clustering Deployment guide: https://adeptia.com/clustering-deployment-guide