--- schema_version: "1" id: 03d98123d9d3aefdaf04f3216190a9a8729a7f0273bc2fac8b1aadfd3c500361 title: Clustering collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub-2/ch2-clustering.md canonical_url: https://docs.mulesoft.com/cloudhub-2/ch2-clustering source_site: docs.mulesoft.com content_type: documentation content_hash: 92ac240a5332acab544df0f171c5fdc5984978bce72b92ac5146d43629481221 description: MuleSoft Documentation Site latest: true --- --- product: CloudHub 2.0 --- # Clustering > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Clustering provides scalability, workload distribution, and added reliability to your applications on CloudHub 2.0. This functionality is powered by CloudHub’s scalable load-balancing service and replica scale-out. You can enable clustering features on a per-application basis using the Anypoint Runtime Manager console when either deploying a new application or redeploying an existing application. ## High Availability and Clustering _High availability_ refers to having multiple replicas that, unlike clustering, do not share data between each replica. _Clustering_ enables multiple replicas to communicate with each other and share data because they share memory. ### CloudHub 2.0 Clustering and Object Store v2 CloudHub 2.0 supports clustering using Mule in addition to Object Store v2 for Mule 4 apps. When you enable Object Store v2 in CloudHub 2.0, note that it is rate limited. For more information, see [Object Store v2 Overview](https://docs.mulesoft.com/object-store/). > [!IMPORTANT] CloudHub 2.0 clears local disk storage when an app restarts or redeploys. Because > `persistent="true"` writes to local disk, CloudHub 2.0 doesn’t preserve data across restarts. > > In Anypoint Studio and standalone Mule runtimes, object stores retain data across restarts because > the local file system persists. CloudHub 2.0 replicas use volatile disk storage. > > To persist data across restarts, use [Object Store v2](https://docs.mulesoft.com/object-store/) to store data externally. > [!NOTE] If you enable both **Clustering** and **Use Object Store V2** on CloudHub 2.0, all Object > Store access routes to Cloud Object Store v2, including internal runtime, policy, and connector > usage. This can result in metered, billable usage even if your application doesn’t explicitly use > Object Store. You don’t configure apps to use Object Store in CloudHub 2.0. Mule 4 apps support Object Store v2, which you enable in Anypoint Runtime Manager. ## Before You Begin Clustering requires: - The Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform - A CloudHub Enterprise or Partner account type that enables you to use this feature. - Familiarity with deploying applications using Runtime Manager. ## Replica Scale-out CloudHub 2.0 enables you to select vCore options for your application, providing horizontal scalability. This fine-grained control over computing capacity provisioning gives you the flexibility to scale up your application to handle higher loads (or scale down during low-load periods) at any time. You can deploy your application with up to 8 replicas, or you can deploy with up to 16 replicas if you have the Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform. To ensure that you have sufficient resources, see [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas). Replica scale-out also adds additional reliability. Mule runtime engine (Mule) automatically distributes multiple replicas for the same application across two or more data centers for maximum reliability. When deploying your application to two or more replicas, you can distribute workloads across these instances of Mule. CloudHub provides the following an HTTP load balancing service that automatically distributes HTTP requests among your assigned replicas. Batch jobs only run on a single replica at a time, and cannot be distributed across multiple replicas. If Mule restarts in the same deployment, the status persists and the batch continues processing. If the entire application is updated or redeploying while the batch is running, the rest of the batch job doesn’t continue. The main solution for persistent batch jobs in CloudHub 2.0 is to use [Object Store v2 Overview](https://docs.mulesoft.com/object-store/). In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource to scale the workload to match demand. Horizontal scaling automatically deploys more pods as a response to an increased load. As a result of these regular autoscaling operations, an application can be changed to a new replica without user action. ## Enable Clustering Features You can enable and disable either or both of cluster mode and horizontal autoscaling in one of two ways: - When you deploy an application to CloudHub 2.0 for the first time using Runtime Manager: - Use the **Replica Count** and **Replica Size** drop-down menus on the **Runtime** tab to select the vCore options and configure the computing power you need. - Check the **Run in Runtime Cluster Mode** in the **Runtime Options** section to enable Mule clustering across each replica of the application. This option requires at least two replicas. - For previously deployed applications, use the **Replica Count** and **Replica Size** drop-down menus on the **Deployment Target** tab. - Check the **Run in Runtime Cluster Mode** in the **Runtime Options** section to enable Mule clustering across each replica of the application. This option requires at least two replicas. See [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas) for more information about deploying to multiple replicas. If your application is already deployed, you must redeploy it for your new settings to take effect. ## How High Availability is Implemented HTTP load balancing is implemented by an internal reverse proxy server. Requests to the application (domain) URL are automatically load balanced between all the application’s replica URLs. ## How Clustering is Implemented When you enable clustering, all the replicas of a Mule application act as a unit. A cluster is a virtual server composed of multiple replicas. The nodes in a cluster communicate and share information through a distributed shared memory grid. Thus, data is replicated across memory in different replicas. For more information, see [On-Premises Mule Runtime High Availability Cluster Overview](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters). ## Use Cases You can combine clustering features in a single application.
Use CaseSuggested Clustering ConfigurationImplications

You want to scale out your application, but you are satisfied with the existing highly available CloudHub 2.0 architecture in terms of preventing service interruption or message loss. You agree with having the mule schedules executed multiple times simultaneously. Ideally, the schedule flows are idempotent to avoid any conflicts.

Number of Replicas: Two or more
Clustering not enabled

  • Application performance isn’t affected by message queue latency.

  • No need to configure your application to support Anypoint MQ.

  • Application schedules are executed on all replicas independently.

  • Object Stores are not shared between replicas.

  • If the object is written to one replica, the other replicas won’t see the object, unless Cloud Object Store is used.

  • If one data center experiences an outage, your replicas are available in a different data center.

You have a high-stakes process for which you need to protect against message loss, but you are not experiencing issues with handling processing load and are OK with some service interruption in the case of a data center outage.

Number of Replicas: One
Clustering not enabled

  • The application can experience some message queue latency.

  • Configure your application to support Anypoint MQ before deploying.

  • Application schedules are executed once on a single replica.

  • Application schedule execution can be missed if the application runtime is not available at the time of execution.

  • If the data center in which your replica operates experiences an outage, CloudHub 2.0 automatically migrates your application to another availability zone. You can experience downtime during the migration; however, your message queues ensure zero message loss.

You have a high-stakes process for which you need to protect against message loss, avoid any chance of service interruption, and handle large processing loads.

Number of Replicas: Two or more
Clustering enabled

  • The application can experience some message queue latency.

  • Configure your application to support Anypoint MQ before deploying.

  • Application schedules are executed only once on the primary replica.

  • Application schedules can be missed during the lead election.

  • Object Stores are replicated and shared with each replica.

  • All replicas can read objects written by another replica, with or without Cloud Object Store.

  • If one data center experiences an outage, your replicas are automatically distributed to ensure redundancy.

You have an application that does not have any special requirements regarding either processing load or message loss.

Number of Replicas: One
Clustering not enabled

  • Application performance isn’t affected by message queue latency.

  • You don’t need to configure your application to support Anypoint MQ.

  • Application schedules are executed once on a single replica.

  • If the data center in which your replica operates experiences an outage, CloudHub 2.0 automatically migrates your application to another availability zone; however, you can experience some downtime and message loss during the migration.

## See Also - [CloudHub 2.0 Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-architecture) - [Object Store v2 Overview](https://docs.mulesoft.com/object-store/)