Hybrid Standalone High Availability and Disaster Recovery

Hybrid Standalone lets you host Mule runtime engine on servers or cloud instances that you control, and manage them centrally through Anypoint Platform. You achieve high availability (HA) by clustering multiple Mule runtime instances, so that another node takes over when one fails. You own disaster recovery (DR) under a shared-responsibility model: because you control the infrastructure, you back up, restore, and recover it with your own tooling, while MuleSoft provides HA best practices and keeps the Anypoint Platform control plane available.

For an overview of HA and DR across all Mule deployment models, see High Availability and Disaster Recovery.

High Availability Versus Disaster Recovery

High availability (HA) measures a system’s ability to remain accessible when a component fails. On Hybrid Standalone, you achieve HA by clustering Mule runtime instances, so that another node takes over when one fails.

Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made disaster, such as flooding, power failures, server failures, or misconfigurations.

Both strategies increase availability but differ in scope: on Hybrid Standalone, HA keeps your application serving requests when a server in the cluster fails with no loss of service, whereas DR restores service and data after an infrastructure disaster and usually incurs a brief loss of service while the DR plan runs.

Two measurable objectives drive your DR plan:

Recovery Time Objective (RTO): The maximum downtime a business tolerates. RTO is the time the system takes to recover after a disruption.
Recovery Point Objective (RPO): The maximum data loss a business accepts after a disaster. RPO drives how often you back up data.

High Availability in Hybrid Standalone

You achieve high availability in Hybrid Standalone by grouping servers into a cluster.

Clustering: A cluster groups up to eight servers that act as a single deployment target. The nodes communicate, coordinate their status, and share information. When one server fails, another server in the cluster automatically takes over, which provides failover with no loss of service.
Shared memory: A cluster uses a distributed shared-memory grid that replicates data across nodes and keeps it available when a node fails. The shared components include object stores, VM queues, and a distributed lock factory. MuleSoft recommends memory-based storage for performance. Choose database-based (JDBC) storage when you need persistence beyond the cluster lifecycle.
Node discovery: A cluster discovers nodes through one of two methods. With unicast, you configure the IP addresses of the nodes, and adding a server restarts the cluster. With multicast, nodes discover each other automatically, but many networks block multicast traffic.

To create and manage clusters, see Creating Clusters and Managing Cluster. For a deeper reference on Mule runtime clustering, see Mule Runtime High Availability (HA) Cluster Overview.

Disaster Recovery in Hybrid Standalone

Because you control the infrastructure in Hybrid Standalone, you and MuleSoft share disaster recovery responsibilities.

Your responsibility: You back up and restore the runtime plane, fail over applications, and run DR procedures with your own tooling and infrastructure. Align your cluster DR with standby-site strategies. Back up your platform configurations, such as connections and properties, with the Anypoint CLI or Anypoint Platform APIs.
MuleSoft responsibility: MuleSoft keeps the Anypoint Platform control plane available across multiple availability zones. The control plane stores only operational metadata and configuration, not your business data. For a full-region control-plane loss, MuleSoft maintains documented recovery objectives.

Considerations and Limitations

Account for these factors when you design a clustered Hybrid Standalone topology:

Network topology: Clustering across availability zones or regions can degrade performance because of network latency. Where possible, place cluster nodes on the same subnet or availability zone.
Simultaneous node restarts: Don’t restart multiple cluster nodes at the same time, such as during operating system patching. Concurrent restarts can trigger cluster-membership eviction and distributed-lock partition migration, which can take applications offline.
Cluster rejoin behavior: After a network interruption, evicted nodes might not rejoin the cluster automatically and can require a manual restart. Account for this behavior in your operational runbooks.
Object Store persistence: Object Store persistence doesn’t support sharing the same database across different clusters. Plan your persistence strategy accordingly.
Object Store locking: For Object Store lock handling in clusters, use an Object Store Connector version that supports configurable lock timeouts, which prevents indefinite lock hangs.

Best Practices

Keep your integrations stateless, and externalize state to an external store, such as a database or a messaging queue.
Run identical Mule runtime, Runtime Manager agent, and Java versions on all cluster nodes.
Schedule cluster changes during maintenance windows.
Test your failover and restore procedures regularly.