Enterprise Edition
There are 3 ways to create and manage clusters:
-
Using the Mule Management Console’s graphical interface
-
Using CloudHub - for more information, see Creating and Managing Clusters
-
Manually, using a configuration file
This page describes manual creation and configuration of a cluster. If you want to create and manage a cluster using the Management Console’s graphical interface, see Creating or Disbanding a Cluster.
|
Caution
|
Do not attempt mixed management of clusters If you create a cluster manually, do not attempt to manage it via the Management Console. The Management Console cannot recognize your manually-created cluster, and overwrites your cluster configuration. |
|
Note
|
All nodes in a cluster must have the same agent version. |
Follow this procedure to create a cluster manually, using a configuration file.
-
Ensure that the node is not running, that is that the Mule Runtime Server is stopped.
-
Create a file named
mule-cluster.propertiesinside the node’s$MULE_HOME/.muledirectory. -
Edit the file with parameter = value pairs, one per line. See the example below.
Note:
mule.clusterIdandmule.clusterNodeIdmust be in the properties file.... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId=<Cluster_ID> mule.clusterNodeId=<Cluster_Node_ID> ... -
Repeat this procedure for all Mule servers that you want to be in the cluster.
-
Start the Mule servers in the nodes.
For the full list of available parameters, see Cluster Configuration Parameters.
Manual management of a cluster is only possible for clusters that have been manually created, which are not managed by the Mule Management Console.
To manually change the configuration of a cluster node, follow these steps:
-
Stop the node’s Mule server.
-
Edit the node’s
mule-cluster.propertiesas desired, then save the file. -
Restart the node’s Mule server.
|
Caution
|
Ensure consistency across nodes Ensure that the options you apply in the configuration file are valid for all cluster nodes. Failure to do so can cause you to break the cluster configuration and inadvertently disable the cluster. |
When managing a manually configured cluster you can now set a minimum quorum of machines required for the cluster to be operational.
When partitioning a network, clusters are available by default. However, by setting a minimum quorum size you can configure your cluster to reject updates that do not pass a minimum threshold.
This helps you achieve better consistency and protects your cluster in case of an unexpected loss of one of your nodes (Mule Runtimes in the cluster).
Under normal circumstances, if a node were to die in the cluster, you may still have enough memory available to store your data, but the amount of threads available to process requests would be reduced as you now would have less nodes available and the partition threads in the cluster could quickly become overwhelmed. This could lead to
-
Clients left without threads to process their requests.
-
The remaining members of the cluster become so overwhelmed with requests that they’re unable to respond and are forced out of the cluster on the assumption that they are dead.
To protect the rest of the cluster in the event of member loss, you can set a minimum quorum size to stop concurrent updates to your nodes, and throwing a QuorumException whenever the number of active nodes in the cluster is below your configured value.
|
Caution
|
QuorumExceptions must be caught When configuring a Quorum Size for your cluster, you need to catch the thrown exception to make some sort of decision (e.g. send an email, stop process, logging, retry strategies, etc) |
To enable quorum, the mule.cluster.quorumsize property has to be placed on the cluster configurations file {MULE_HOME}/.mule/mule-cluster.properties defining the minimum number of nodes of the cluster to remain in an operational state.
|
Note
|
Quorum feature is only valid for components that use Object Store. |
You can persistently store JDBC data in a centralized system, accessible from all cluster nodes.
To enable Object store persistency, you need to add new properties to the {MULE_HOME}/.mule/mule-cluster.properties file defining the database configuration values:
-
mule.cluster.jdbcstoreurl: The JDBC URL for connection to the database
-
mule.cluster.jdbcstoreusername: Database username
-
mule.cluster.jdbcstorepassword: Database user password
-
mule.cluster.jdbcstoredriver: JDBC Driver class name
-
mule.cluster.jdbcstorequerystrategy: SQL dialect
Always keep in mind that the data storage needs to be hosted in a centralized DB reachable from all nodes.
Don’t use more than one database per cluster.
Check the cluster configuration reference for persistency for details on how to configure these values.
You can monitor the events thrown by the cluster members through the JMX technology.
The JMX monitoring option is disabled by default. In order to enable it, you need to add the mule.cluster.jmxenabled property to the {MULE_HOME}/.mule/mule-cluster.properties configuration file.
Please note that enabling JMX might cause some performance overheads given that the underlying structure adds listeners to get the statistics for each individual node.
The following table lists the parameters of the mule-cluster.properties file.
| Property name | Description |
|---|---|
|
Mandatory. Unique identifier for the cluster. It can be any alphanumeric string. |
|
Mandatory. Unique ID of the node within the cluster. It can be any integer between 1 and the number of nodes in the cluster. |
|
Comma-separated list of interfaces to use by Hazelcast. Wildcards are supported, as shown below. |
|
The nodes that belong to the cluster, in the form The port number is optional; if not set, the default is 5701. To include more than one host, create a comma-separated list. This option configures the cluster with the specified fixed IP addresses. Use this option if you are not relying on multicast for cluster node discovery. If using this option, set Examples: Two nodes listening on port 9000: Two nodes listening on port 5701: |
|
Enables you to define the minimum number of machines required in a cluster to remain in an operational state. |
|
(Boolean) Enable/disable multicast. Set to |
|
Multicast group IP address to use. |
|
Multicast port number to use. |
Required only when storing persistent data. |
|
|
Required only when storing persistent data. |
|
Required only when storing persistent data. |
|
Required only when storing persistent data. |
|
Required only when storing persistent data. |
|
(Boolean) Enable/disable monitoring |
|
(Boolean) Enable/disable membership listener. Set to |
|
Caution
|
Oracle database support is a known limitation and is planned for a future release. |
-
Learn about deploying and monitoring clusters.