|
| 1 | +# Clustering |
| 2 | + |
| 3 | +An EventMesh cluster is a logical grouping of one or several peers, each sharing Clients, Virtual Private Network, Sessions. |
| 4 | +Any node present in the cluster must be able to process any type of request such as: add VPN client, create subscription session. |
| 5 | +Only queues are not replicated everywhere. |
| 6 | + |
| 7 | +Because queues are not replicated among all the nodes but only on a specific amount. The queue availability cannot be guaranteed on all the nodes. |
| 8 | + |
| 9 | +Two types of data can easily be identified: |
| 10 | +* Server data : data needed by a peer to process a request. |
| 11 | +* Client data : messages that the client is interested in consuming. |
| 12 | + |
| 13 | +For each data type, there is a different data replication strategy. |
| 14 | + |
| 15 | +# Server data - Gossip protocol |
| 16 | + |
| 17 | +EventMesh implements the [Gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) to replicate the data among all the peers. |
| 18 | + |
| 19 | +Gossip protocol is used to replicate the following data : |
| 20 | +* Clients |
| 21 | +* Virtual Private Network |
| 22 | +* Sessions |
| 23 | + |
| 24 | +# Client data - Distributed queue |
| 25 | + |
| 26 | +To ensure fault tolerance, EventMesh replicates queues across peers using the [Raft protocol](https://en.wikipedia.org/wiki/Raft_(algorithm)). |
| 27 | + |
| 28 | +Data is divided into partitions. Each partition has a number of replicas. Among the replica set, a leader is determined by the raft protocol which takes in requests and performs all of the processing. |
| 29 | +All other peers are passive followers. When the leader becomes unavailable, the followers transparently select a new leader. |
| 30 | + |
| 31 | +Eah peer in the cluster my be both leader and follower at the same time of different partitions. |
| 32 | + |
| 33 | +In EventMesh, the partition key corresponds to the `groupId` or the `topic` name |
| 34 | + |
| 35 | +Now, you have a better understanding of the different data replication strategy. |
| 36 | +We are going to explain how to form a cluster. |
| 37 | + |
| 38 | +# Cluster Formation |
| 39 | + |
| 40 | +An EventMesh cluster can be formed in a number of ways : |
| 41 | +* Listing cluster nodes in configuration file (via a plugin). |
| 42 | +* Using etcd-based discovery (via a plugin). |
| 43 | +* Using in-memory list on nodes (enabled by default). |
| 44 | + |
| 45 | +In order to have an up and running cluster one plugin must be enabled. |
| 46 | +For more information please refer to the `Plugins` chapter. |
| 47 | + |
| 48 | +# Quick start |
| 49 | + |
| 50 | +In this tutorial, we are going to install two EventMesh servers with the plugin `DiscoveryEtcd` enabled via Docker. |
| 51 | + |
| 52 | +TODO |
0 commit comments