Clustering - MigratoryData

MigratoryData implements active/active clustering through the parameters ClusterMembers and ClusterMemberListen to provide:

Fault tolerance with no single point of failure
Horizontal scalability through load balancing

Hence, a MigratoryData cluster inherently provides load balancing and fault tolerance functionalities, eliminating the requirement for a separate load balancer or application delivery network (ADC). However, it is worth noting that deploying a MigratoryData cluster behind a load balancer or an ADC can be advantageous in certain cases, as detailed in this blog post.

Cluster QoS

MigratoryData implements two clustering methods through the parameter ClusterDeliveryMode corresponding to two qualities of service (QoS) as follows:

`Standard`	Standard Message Delivery
`Guaranteed`	Guaranteed Message Delivery

Refer to the QoS section to learn about these two qualities of service.

Minimum Cluster Size for Production

A MigratoryData cluster — which avoids single point of failure — requires at least two nodes for Standard Message Delivery, and at least three nodes for Guaranteed Message Delivery.

QoS	Minimum number of nodes for clustering with no single point of failure
`Standard`	2
`Guaranteed`	3

Seed Nodes

A MigratoryData cluster is defined by the ClusterMembers parameter as an ordered list of nodes — using the same order for each node.

The order of nodes is not significant for Standard Message Delivery. However, for Guaranteed Message Delivery, the node order holds significance. Specifically, the first three nodes in a cluster with three or four nodes, and the first five nodes in a cluster with five or more nodes, are referred to as seed nodes.

The number of seed nodes of a cluster of five and more nodes can be reduced from 5 to 3 via the parameter ClusterSeedMemberCount.

Tolerance of Node Failures

In a MigratoryData cluster, for Standard Message Delivery, the cluster can tolerate the failure of any node as long as at least one node remains operational. Similarly, for Guaranteed Message Delivery, the cluster can tolerate the failure of any node as long as a majority of its seed nodes remain operational. The table below provides a summary of this information:

QoS	Total number of nodes	Number of Tolerated Node Failures
`Standard`	N (where N>=2)	N-1
`Guaranteed`	3	1
`Guaranteed`	4	2 (one seed and one non-seed nodes)
`Guaranteed`	5 (5 seed nodes)	2
`Guaranteed`	5 (3 seed nodes)	3 (one seed and two non-seed nodes)
`Guaranteed`	N (where N>=6) (5 seed nodes)	N-3 (two seed and all non-seed nodes)
`Guaranteed`	N (where N>=6) (3 seed nodes)	N-2 (one seed and all non-seed nodes)

Example — A 12-node cluster configured with Guaranteed Message Delivery, using the default number of 5 seed nodes, has the ability to tolerate up to 9 node failures. These failures can include any two nodes from the first five nodes of the cluster, which are considered as seed nodes, as well as all non-seed nodes, i.e. the last 7 nodes of the cluster.

However, if the number of seed nodes is reduced from 5 to 3 , then the cluster of 12 nodes can tolerate up to 10 node failures. This would include one seed node, which can be any node from the first three nodes of the cluster, along with all non-seed nodes, i.e. the last 9 nodes of the cluster.

Cluster Elasticity

To achieve elasticity in your cluster, you can define the ClusterMembers parameter with a higher number of nodes than the initial deployment. As the load on the cluster increases, you can deploy additional nodes, up to the total number of nodes defined. Conversely, if the load decreases, you can remove nodes, but not below a minimum number of nodes as defined below.

This allows your cluster to dynamically scale up or down based on the system load, either manually or by leveraging automatic deployment systems like Kubernetes that offer autoscaling features. You can learn more about MigratoryData elasticity using Kubernetes here.

The nodes that are defined by ClusterMembers but not deployed can be considered as failed nodes within the cluster. Consequently, the highest number of undeployed nodes would reflect the maximum allowable number of node failures that the cluster can tolerate, as explained earlier.

For clustering using Standard Message Delivery, the minimum number of cluster nodes to be started initially (or scale down) is two. Moreover, these two nodes can be any nodes of the ordered list of nodes defining the cluster. For clustering using Guaranteed Message Delivery, the cluster members to be started initially (or scale down) are the seed nodes. Hence, the minimum number of nodes to be started initially (or scale down) should be as follows:

QoS	Total number of defined nodes	Recommended nodes for initial or scale down deployment
`Standard`	N (where N>=2)	2 (any nodes)
`Guaranteed`	N (where N>=3) (3 seed nodes)	3 (the seed nodes)
`Guaranteed`	N (where N>=5) (5 seed nodes)	5 (the seed nodes)