System scalability and reliability is critical for production integration solutions. Put simply, there must be enough processing capacity available to accept and process integration messages, meet service level agreements, help minimize response times, and improve system reliability. Clustering for on-premise and cloud environment often differ. This article focuses on on-premise clustering.
The most basic form of clustering is when server instances are configured to operate in what is known as a master-slave configuration. When configured this way, a single server acts as the master, processes integration messages, and one or more slave servers stands by ready to pick up work should the master server fail. Both JBoss Fuse and Mule ESB support this type of clustering. However, a significant downside for a master-slave cluster is that processing power is capped by the size of the individual servers used.
A more scalable cluster configuration involves using the combined capacity of multiple server instances to meet processing demands. Combined server processing power can quickly exceed what is possible using a single server. Both JBoss Fuse and Mule ESB Enterprise support multi-server clustering in an active-active configuration where all servers in the cluster can process integration messages.
However, Mule ESB has a documented eight server limit for an active-active cluster.1 If the processing power of eight servers is insufficient to concurrently process all integration flows needed for a complete integration solution deployment, Mule ESB users are forced to determine the subset of message processing volume possible within the cluster. Then the customer needs to create one or more additional clusters capable of handling the remaining integration processing load. Related to this Mule ESB cluster limitation, MuleSoft recommends that integration flows be designed using specific best practices to optimize processing of messages within its cluster limitations. MuleSoft documentation recommends that “You can set up a VM queue explicitly to load balance across nodes. Thus, if your entire application flow contains a sequence of child flows, Mule can assign each successive child flow to whichever node happens to be available at the time. Potentially, Mule can process a single message on multiple nodes as it passes through the entire application flow…”.2 This requires Mule EB developers to design and implement integration solutions specifically with clustering in mind rather than in a way that logically makes sense. This can impact both developer efficiency and long term maintenance costs for integration solutions forced to be spread over multiple flows instead of one due to technical constraints.
While there are practical limits that can vary by customer on the size of JBoss Fuse active-active clusters, there are no artificial limits in the software. As with all software, best practices for using JBoss Fuse and Camel have evolved over the years. Many of the best practices can be found on the world wide web. Others exist in books published books on Camel. Multiple books have been published by Red Hat employees who are active members of the open source community.3 However research has not uncovered any development practices that are specifically recommended when using JBoss Fuse in a clustered environment. However, if you want to follow the Mule ESB best practice for development of integration flows deployed to clusters, JBoss Fuse has SEDA4, VM5, and other components that would allow you to do so. But It isn’t required.
1“Mule High Availability (HA) Cluster Overview.” MuleSoft Documentation. MuleSoft, n.d. Web. 14 Oct. 2015. <https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-high-availability-ha-clusters#about-clustering>. See section labeled: About Clustering
2“Mule High Availability (HA) Cluster Overview.” MuleSoft Documentation. MuleSoft, n.d. Web. 14 Oct. 2015. <https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-high-availability-ha-clusters#about-queues>. See section labeled: About Queues
3“Apache Camel Book Listing.” Amazon.com. Amazon, n.d. Web. 14 Oct. 2015. <http://www.amazon.com/s/ref=nb_sb_ss_c_0_12?url=search-alias%3Dstripbooks&field-keywords=apache%2Bcamel&sprefix=apache%2Bcamel%2Caps%2C136>. Clause Ibsen and Scott Cranton are just 2 Red Hat employees who have published books
4“Chapter 127. SEDA.” Apache Camel Component Reference. Red Hat, n.d. Web. 14 Oct. 2015. <https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.2/html/Apache_Camel_Component_Reference/IDU-SEDA.html>.
5“Chapter 157. VM.” Apache Camel Component Reference. Red Hat, n.d. Web. 14 Oct. 2015. <https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.2/html/Apache_Camel_Component_Reference/IDU-VM.html>.