About Clustering
  • 28 Apr 2022
  • 1 Minute to read
  • Dark
    Light

About Clustering

  • Dark
    Light

Article Summary

Clustering in development environments is not supported.

Overview

A Cluster is an environment of one or more Application Server instances on the same database back-end. The servers work together to appropriately distribute workloads to prevent over or underutilization of any particular server.

This allows for an overall increase in availability and provides the ability to share a single storage location. 

To further improve an environment's resilience, it is recommended to use a clustered SQL server environment to prevent database failures from interrupting service.


High Availability

High Availability configurations aim to remove any single points of failure in a process by creating a cluster of at least two Application Servers and a Load Balancer.

With the Application Servers configured for redundancy i.e. identically, it is recommended for users may construct an active-active cluster to boost processing power by dedicating more computing power to the system. It is recommended that the active-active cluster contains geographic separation.

Active-passive clusters are not recommended for most general purposes.


Transaction Data and Peer Communication

When a Flow or a Rule stores data, it is immediately written so it is not at risk during an outage. However, uncommitted i.e. in-progress Flow/Rule data may be lost. 

In the event of an outage, Flows with states can resume from their last recorded state before service interruption. Short workflows pose little risk of loss since they complete in milliseconds.

Yet for critical Flows or Rules, any chance of interruption is unacceptable. To solve this, combining leased work with work queues establishes reliable Flow/Rule executions and retry attempts.

Failover servers further reduce outage disruption in their clustered environments by running any subsequent executions instead of the down server(s).

Clustered servers communicate with one another to clear cached data, when data changes, and when it should reload from the system's record to maintain efficiency.

It is also possible to rely on messaging using Rabbit, Kafka, Azure SB, AWS, and other services that may fit a customer's architecture.


For further information on Installation, visit the Decisions Forum.

Was this article helpful?