Introduction to Raft algorithm
6 likes2,249 views
The document presents the Raft consensus algorithm, emphasizing its usability and structural differences from Paxos, aiming to provide an understandable solution for managing replicated logs in distributed systems. It discusses Raft’s unique features, including strong leadership, efficient leader election, and fault tolerance, along with its key properties and guarantees ensuring safety and consistency during consensus operations. The seminar showcases the relevance of Raft in real-world implementations, highlighting its application in distributed systems like Kubernetes and etcd.
Introduction to Raft algorithm
- 1. Raft Understandable Consensus Algorithm Presentation for Seminar Muayyad Saleh Alsadi (20158043) Based on Raft Paper “In Search of an Understandable Consensus Algorithm” Diego Ongaro and John Ousterhout, Stanford University
- 2. Raft Introduction Introduction Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to multi-Paxos, and it is as efficient as Paxos but with completely different structure meant to be understandable as the most key objective.
- 3. Raft Introduction to consensus algorithms What is a consensus algorithm? “Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. Because of this, they play a key role in building reliable large-scale software systems.”
- 4. Raft Introduction to consensus algorithms Replicated State Machine a collection of servers compute identical copies of the same state and can continue operating even if some of the servers are down. Replicated state machines are used to solve a variety of fault tolerance problems in distributed systems.
- 5. Raft Introduction to consensus algorithms Why not Paxos? “There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system… the final system will be based on an unproven protocol” Quoted from Google's Chubby implementers
- 6. Raft Introduction to consensus algorithms Why not Paxos? #1 Single-decree Paxos is dense and subtle: it is divided into two stages that do not have simple intuitive explanations and cannot be understood independently. Because of this, it is difficult to develop intuitions about why the single-decree protocol works. The composition rules for multi-Paxos add significant additional complexity and subtlety.
- 7. Raft Introduction to consensus algorithms Why not Paxos? #2 it does not provide a good foundation for building practical implementations. One reason is that there is no widely agreed-upon algorithm for multi-Paxos. Lamport’s descriptions are mostly about single-decree Paxos; he sketched possible approaches to multi-Paxos, but many details are missing.
- 8. Raft Properties and key features Novel features of Raft: ● Strong leader: Log entries only flow from the leader to other servers. This simplifies the management of the replicated log and makes Raft easier to understand. ● Leader election: beside heartbeats required in any consensus algorithm, Raft uses randomized timers to elect leaders. This helps resolving conflicts simply and rapidly. ● Membership changes: changing the set of servers in the cluster uses a new joint consensus approach where the majorities of two different configurations overlap during transitions. This allows the cluster to continue operating normally during configuration changes.
- 9. Raft Properties and key features consensus algorithm properties ● Safety: never returning an incorrect result in any condition despite network delays, partitions, and packet loss, duplication, and reorder ● Fault-tolerant: the system would be available and fully- functional in case of failure of some nodes. ● Does not depend on time consistency: ● Performance is not affected by minority of slow nodes
- 10. Raft Sub-problems ● Leader election: system should continue to work even if its leader fails, by electing a new leader ● Log replication: leader takes operations from clients and replicate them into all nodes. Forcing them all to agree. ● Safety: assert that the 5 guarantees (next slide) are all satisfied at any time
- 11. Raft The 5 guarantees 1)Election Safety: at most one leader can be elected in a given term. 2)Leader Append-Only: a leader never overwrites or deletes entries in its log; it only appends new entries. 3)Log Matching: if two logs contain an entry with the same index and term, then the logs are identical in all entries up through the given index. 4)Leader Completeness: if a log entry is committed in a given term, then that entry will be present in the logs of the leaders for all higher-numbered terms. 5)State Machine Safety: if a server has applied a log entry at a given index to its state machine, no other server will ever apply a different log entry for the same index.
- 12. Raft The Basics: The 3 node states
- 14. Raft The Basics: no emerging leader term
- 15. Raft The Basics: Heartbeat RPC used to append
- 16. Raft The Basics: Request Vote
- 17. Raft Partition tolerance Node B consider itself a lead (from old term) but it can reach Consensus so it won't affect consistency
- 18. Raft Follower Cases A follower might have missed some entries as in a-b. Or have extra “uncommitted” entries as in c-f (that should be removed) F was a leader of term 2 that committed some changes then failed
- 19. Raft Working conditions broadcastTime ≪ electionTimeout ≪ MTBF Where MTBF: is mean time between failures
- 20. Raft Tuning for time without leader Time without leader By tuning random timeout range
- 22. Raft Resources ● The Paper ● Visualization of Raft operations ● Etcd - implementation ● Consul – another implementation ● http://raftconsensus.github.io/ ● CoreOS/Fleet uses Etcd ● Google Kubernetes - a distributed system ● Mesos / Mesosphere– a distributed system