The RAFT protocol was designed by Diego Ongaro and John Ousterhout from Standford University in 2014 – In Search of an Understandable Consensus Algorithm. It is a fairly new protocol. The etcd (https://etcd.io) protocol that's used in Kubernetes and CockroachDB
(https://github.com/cockroachdb) is a good example of RAFT implementation along with HashiCorp's Consul
.
The RAFT protocol in Consul is used to elect a leader from three or five servers that run in a data center. Every node using RAFT can have three states: leader, follower, and candidate. Here, the following steps are taken:
- Each node starts with a follower state with no leader.
- After a timeout period, a node elevates itself to a candidate state and asks for votes.
- The node that gets the majority votes promotes itself to be the leader with a message to all the other nodes.
- Once a leader has been elected, all changes to the state of the cluster go through the leader, which is responsible for state management.
Only Consul servers in a data center participate in RAFT and are part of a peer set. A majority quorum within a peer set is required to agree to a committed state. The ideal number of Consul servers is either 3 or 5. New servers can get added to the peer set to increase the quorum size. When servers start for the first time, Consul adopts a practice called bootstrap mode in which the first server elects itself as a leader. The other servers are added to the peer set.