--- schema_version: "1" id: 0e18d4deaa4e383ef85071ee4ae282e3ba1ca365910fd28a74beb0ffaac88448 title: Cluster On-Premises Mule Runtime Instances collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/on-premises/4.12/choosing-the-right-clustering-topology.md canonical_url: https://docs.mulesoft.com/on-premises/4.12/choosing-the-right-clustering-topology source_site: docs.mulesoft.com content_type: documentation content_hash: 2b0c004f8139383c343924d06f6c7f8ae8037282ec673db7e06ce5fed30026d6 description: MuleSoft Documentation Site release: "4.12" latest: false --- --- product: On-premises Runtimes version: 4.12 keywords: hazelcast, quorum, split brain, node failure, failover, virtual IP, load balancer, server group, object store, mule-cluster.properties, 5701, multicast, unicast, on-premises, on-prem, standalone --- # Cluster On-Premises Mule Runtime Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Clustering is optional. Use it when on-premises runtime must keep serving traffic if a node fails. Clustering requires Mule Enterprise Edition and an [Enterprise license](https://docs.mulesoft.com/on-premises/4.12/installing-an-enterprise-license). You supply the load balancer. The cluster doesn’t create a virtual IP and doesn’t copy Mule application artifacts from node to node. A server group isn’t a cluster. A server group is a set of unclustered servers that Runtime Manager can deploy to together. Server groups and Runtime Manager clusters are in [Hybrid Standalone Runtimes](https://docs.mulesoft.com/hybrid-standalone/). See the Cluster stage in [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.12/). After you choose a topology, see [On-Premises Mule Runtime High Availability Cluster Overview](https://docs.mulesoft.com/on-premises/4.12/mule-high-availability-ha-clusters) for node behavior, [Create and Manage an On-Premises Mule Runtime Cluster Manually](https://docs.mulesoft.com/on-premises/4.12/creating-and-managing-a-cluster-manually) to create the cluster, and [High Availability and Disaster Recovery for On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.12/on-premises-hadr) for standby options. ## Choose a Clustering Topology A cluster shares memory, VM queues, and object-store data across nodes. Deploying a Mule application into a cluster is useful for: - High availability (HA): making your system continually available in the event that one or more servers in the cluster, or a data center, fails. - Fault tolerance (FT): ensuring recovery from failure of an underlying component. Typically, the recovery is achieved through transaction rollback or compensating actions. - Scaling: ensuring that your application can scale horizontally to meet increased demand. ## Understand On-Premises High Availability **_Enterprise Edition_**

Mule High Availability provides basic failover capability for Mule. When the primary Mule instance become unavailable (e.g., because of a fatal JVM or hardware failure or it’s taken offline for maintenance), a backup Mule instance immediately becomes the primary node and resumes processing where the failed instance left off. After a system administrator has recovered the failed Mule instance and brought it back online, it automatically becomes the backup node.

Seamless failover is made possible by a distributed memory store that shares all transient state information among clustered Mule instances, such as:

  • SEDA service event queues

  • In-memory message queues

Mule High Availability is currently available for these transports:

  • HTTP (including CXF Web Services)

  • JMS

  • WebSphere MQ

  • JDBC

  • File

  • FTP

  • Clustered (replaces the local VM transport)

A high-availability architecture featuring web services and a reverse proxy server

Mule High Availability is available with Mule Enterprise subscriptions. For details including technical highlights, requirements, and installation details, [contact us](mailto:sales@mulesoft.com). ## Use JMS Queues for High Availability JMS can be used to achieve HA & FT by routing messages through JMS queues. In this case, each message is routed through a JMS queue whenever it moves from component to component. ![A Mule server cluster interfacing with external JMS queues](/mulesoft/current/en-us/on-premises/4.12/_images/jms-queues.png) Pros: - Easy to do - Well understood by developers Cons: - Requires lots of transactions, and transactions can be complicated - Performance hit if you’re using XA ## Use Load Balancers with Clusters Load balancers simply route requests to different servers based on the current load of each server and which servers are currently up. Load balancers can be software or hardware based. This approach is commonly used with clustered databases (see below). Pros: - Straightforward to do - Well understood by developers Cons: - Not a complete solution on its own, doesn’t provide fault tolerance. ## Review a Clustered Topology Example In this example architecture, HTTP requests come in through a load balancer and are immediately put on a JMS queue. The JMS queue is clustered between the different servers. A server will start processing a message off the JMS queue and wrap everything in a transaction. ![A flow including an HTTP and JMS configurations](/mulesoft/current/en-us/on-premises/4.12/_images/http-and-jms.png) If the server goes down, the transaction will roll back and another server will pick up the message and start processing it. **Note**: If the HTTP connection is open for the duration of this process, this approach will not work, as the load balancer will not transparently switch connections between servers. In this case, the HTTP client will need to retry the request. ## Maintain State in a Database If you have a clustered database, one option for your application is to simply store all state in the database and rely on it to replicate the data consistently across servers. Pros: - Straightforward to do - Well understood by developers Cons: - Not all state is amenable to being stored in the database ## Handle Stateful Components While most Mule applications can be supported by the above techniques, some require sharing state between JVMs more deeply. One common example of this is an aggregator component. For example, assume you have an aggregator that is aggregating messages from two different producers. Producer #1 sends a message to the aggregator, which receives it and holds it in memory until Producer #2 sends a message. ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` If the server with the aggregator goes down between Producer #1 sending a message and Producer #2 sending a message, Producer #2 can’t just send its message to a different server because that server will not have the message from Producer #1. The solution to this is to share the state of the aggregator component across different machines through clustering software such as Terracotta, Oracle Coherence, JGroups, etc. By using one of these tools, Producer #2 can simply fail over to a different server. Note that MuleSoft has not tested Mule with these tools and doesn’t officially support them. Pros: - Works for all clustering cases - Can work as a cache as well Cons: - Not officially supported by MuleSoft - Requires performance tuning to get things working efficiently ## Review Related Clustering Topics These topics also affect topology design: - Maintaining geo-distributed clusters - Data partitioning - ACID vs. BASE transactions - Compensation and transactions If you need more assistance, MuleSoft Professional Services can review your architecture plan. For more information, [contact us](https://www.mulesoft.com/contact). ## See Also - [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.12/) - [Install an Enterprise License on On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.12/installing-an-enterprise-license) - [On-Premises Mule Runtime High Availability Cluster Overview](https://docs.mulesoft.com/on-premises/4.12/mule-high-availability-ha-clusters) - [Create and Manage an On-Premises Mule Runtime Cluster Manually](https://docs.mulesoft.com/on-premises/4.12/creating-and-managing-a-cluster-manually) - [High Availability and Disaster Recovery for On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.12/on-premises-hadr) - [Hybrid Standalone Runtimes](https://docs.mulesoft.com/hybrid-standalone/)