yay even more slides
This commit is contained in:
parent
0ceeaebfee
commit
8caf96d640
BIN
figs/election-correctness.png
Normal file
BIN
figs/election-correctness.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 47 KiB |
BIN
figs/leader-election.png
Normal file
BIN
figs/leader-election.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 104 KiB |
BIN
figs/log-consistency-check.png
Normal file
BIN
figs/log-consistency-check.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 88 KiB |
BIN
figs/log-inconsistencies.png
Normal file
BIN
figs/log-inconsistencies.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 100 KiB |
BIN
figs/log-matching-property.png
Normal file
BIN
figs/log-matching-property.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 65 KiB |
BIN
figs/log-structure.png
Normal file
BIN
figs/log-structure.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 101 KiB |
119
slides.md
119
slides.md
|
@ -2,6 +2,7 @@
|
|||
marp: true
|
||||
paginate: true
|
||||
author: Clément Contet, Laurent Fainsin
|
||||
math: katex
|
||||
---
|
||||
|
||||
<style>
|
||||
|
@ -11,7 +12,7 @@ section::after {
|
|||
}
|
||||
</style>
|
||||
|
||||
# The Raft Consensus Algorithm
|
||||
# The RAFT Consensus Algorithm
|
||||
|
||||
<!-- https://github.com/raft/raft.github.io -->
|
||||
<!-- https://ongardie.net/static/coreosfest/slides -->
|
||||
|
@ -19,9 +20,11 @@ section::after {
|
|||
![bg right:60%](https://raft.github.io/logo/solo.svg)
|
||||
|
||||
<footer>
|
||||
Reliable, Replicated, Redundant, And Fault-Tolerant.<br>
|
||||
Diego Ongaro,
|
||||
John Ousterhout,
|
||||
Stanford University
|
||||
(2014)
|
||||
</footer>
|
||||
|
||||
---
|
||||
|
@ -36,16 +39,16 @@ Stanford University
|
|||
|
||||
> Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. – RAFT authors
|
||||
|
||||
<!-- Les algorithmes de consensus permettent à un ensemble de machines de fonctionner comme un groupe cohérent qui peut survivre aux défaillances de certains de ses membres. -->
|
||||
|
||||
<br>
|
||||
|
||||
- Accord sur l'état partagé (image système unique)
|
||||
- Réparation autonome en cas de défaillance d'un serveur
|
||||
- Réparation (réplication) autonome en cas de défaillance d'un serveur
|
||||
- Une minorité de serveurs HS: pas de problème
|
||||
- La majorité des serveurs HS: perte de disponibilité, maintien de la cohérence
|
||||
- La clé pour construire des systèmes de stockage cohérents
|
||||
|
||||
<!-- Le consensus permet à plusieurs machines de se mettre d'accord, de former un groupe cohérent, capable de prendre des decisions, même si certains membres sont défaillants. -->
|
||||
|
||||
---
|
||||
|
||||
<header>
|
||||
|
@ -54,6 +57,8 @@ Stanford University
|
|||
|
||||
![bg 95%](https://ongardie.net/static/coreosfest/slides/rsm.svg)
|
||||
|
||||
<!-- Un ou plusieurs clients. Et plusieurs serveurs formant un groupe de consensus (généralement > 3 et impair). Quand client RPC serv, leader réplique cela sur ses suiveurs et une fois cela validé, répond au client. -->
|
||||
|
||||
<!--
|
||||
|
||||
- Replicated log -> replicated state machine
|
||||
|
@ -90,7 +95,7 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
|
|||
|
||||
<header>
|
||||
|
||||
# Pourquoi RAFT ?
|
||||
# Les différences de RAFT ?
|
||||
|
||||
</header>
|
||||
|
||||
|
@ -122,11 +127,11 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
|
|||
- Sélectionner un serveur qui sera le leader
|
||||
- Détecter les pannes, choisir un nouveau leader
|
||||
2. Réplication des logs (fonctionnement normal)
|
||||
- Le leader accepte les commandes des clients et les ajoute à son journal.
|
||||
- Le leader réplique son journal aux autres serveurs (écrase les incohérences).
|
||||
- Le leader accepte les commandes des clients et les ajoute à son journal
|
||||
- Le leader réplique son journal aux autres serveurs (écrase les incohérences)
|
||||
3. Sécurité
|
||||
- Maintenir la cohérence des journaux
|
||||
- Seuls les serveurs dont les journaux sont à jour peuvent devenir des leaders.
|
||||
- Seuls les serveurs dont les journaux sont à jour peuvent devenir des leaders
|
||||
|
||||
---
|
||||
|
||||
|
@ -136,15 +141,20 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
|
|||
|
||||
</header>
|
||||
|
||||
<!-- Il n'y a que 3 états possibles pour les serveurs ! -->
|
||||
<!--
|
||||
Il n'y a que 3 états possibles pour les serveurs !
|
||||
Et les changements d'états sont assez simples. -->
|
||||
|
||||
![bg 90%](https://oracleblog.org/wp-content/uploads/2018/10/QQ%E6%88%AA%E5%9B%BE20181001142911.png)
|
||||
|
||||
<!--
|
||||
|
||||
Follower: Passive (but expects regular heartbeats)
|
||||
Follower: Passive (but expects regular heartbeats to stay in this state, get a random timeout time at startup), if after some time there is no heartbeat, timeout, change to candidate.
|
||||
|
||||
(RPC: https://en.wikipedia.org/wiki/Remote_procedure_call)
|
||||
|
||||
Candidate: Issues RequestVote RPCs to get elected as leader. After results, if majority, becomes new leader. if other leader gets elected or is already present, step down.
|
||||
|
||||
Candidate: Issues RequestVote RPCs to get elected as leader
|
||||
|
||||
Leader: Issues AppendEntries RPCs:
|
||||
- Replicate its log
|
||||
|
@ -165,7 +175,7 @@ Leader: Issues AppendEntries RPCs:
|
|||
<!--
|
||||
|
||||
- At most 1 leader per term
|
||||
- Some terms have no leader (failed election)
|
||||
- Some terms have no leader (failed election, example: 3 servers, all switch to candidate at same time, no majority)
|
||||
- Each server maintains current term value (no global view)
|
||||
- Exchanged in every RPC
|
||||
- Peer has later term? Update term, revert to follower
|
||||
|
@ -179,21 +189,29 @@ Terms identify obsolete information
|
|||
|
||||
<header>
|
||||
|
||||
# Leader Election
|
||||
# Élection du leader
|
||||
|
||||
</header>
|
||||
|
||||
TODO
|
||||
![bg 70%](figs/leader-election.png)
|
||||
|
||||
---
|
||||
|
||||
<header>
|
||||
|
||||
# Election Correctness
|
||||
# Exactitude des élections
|
||||
|
||||
</header>
|
||||
|
||||
TODO
|
||||
- Sécurité: autoriser au maximum un gagnant par mandat
|
||||
- Chaque serveur ne donne qu'un seul vote par mandat (persistant sur disque)
|
||||
- Majorité requise pour gagner l'élection
|
||||
![](figs/election-correctness.png)
|
||||
- Vivacité: un candidat doit finir par gagner
|
||||
- Délais d'expiration des élections aléatoire dans $[T, 2T]$ (i.e. 150-300 ms)
|
||||
- Le serveur gagne l'élection en dépassant le délai d'attente avant les autres
|
||||
- Fonctionne bien si $T \gg T_{\text{diffusion}}$
|
||||
- Approche aléatoire plus simple que les autres comme le ranking
|
||||
|
||||
---
|
||||
|
||||
|
@ -233,31 +251,84 @@ Normal Operation:
|
|||
|
||||
<header>
|
||||
|
||||
# Log Structure
|
||||
# Structure des journaux
|
||||
|
||||
</header>
|
||||
|
||||
TODO
|
||||
![bg 100%](figs/log-structure.png)
|
||||
|
||||
<!--
|
||||
|
||||
- Must survive crashes (store on disk)
|
||||
- Entry committed if safe to execute in state machines
|
||||
- Replicated on majority of servers by leader of its term (that the goal of the leader)
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<header>
|
||||
|
||||
# Log Inconsistencies
|
||||
# Incohérences des journaux
|
||||
|
||||
</header>
|
||||
|
||||
TODO
|
||||
![bg 65%](figs/log-inconsistencies.png)
|
||||
|
||||
<!--
|
||||
|
||||
Logs may be inconsistent after leader change
|
||||
- No special steps by new leader:
|
||||
- Start normal operation
|
||||
- Followers’ logs will eventually match leader
|
||||
- Leader’s log is “the truth”
|
||||
|
||||
Crashes can result in log inconsistencies:
|
||||
- Raft minimizes special code for repairing inconsistencies:
|
||||
- Leader assumes its log is correct (se pose pas de question sur la validité des ses propres logs, source de vérité)
|
||||
- Normal operation will repair all inconsistencies
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<header>
|
||||
|
||||
# Log Matching Property
|
||||
# Propriété de correspondance des journaux
|
||||
|
||||
</header>
|
||||
|
||||
TODO
|
||||
![bg 90%](figs/log-matching-property.png)
|
||||
|
||||
<!--
|
||||
|
||||
Goal: high level of consistency between logs
|
||||
|
||||
- If log entries on different servers have same index and term:
|
||||
- They store the same command
|
||||
- The logs are identical in all preceding entries
|
||||
- If a given entry is committed, all preceding entries are also committed
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<header>
|
||||
|
||||
# Réparation des journaux par correspondance
|
||||
|
||||
</header>
|
||||
|
||||
![bg 95%](figs/log-consistency-check.png)
|
||||
|
||||
<!--
|
||||
|
||||
AppendEntries RPCs include <index, term> of entry preceding new one(s)
|
||||
- Follower must contain matching entry; otherwise it rejects request
|
||||
- Leader retries with lower log index
|
||||
- Implements an induction step, ensures Log Matching Property
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
@ -281,7 +352,7 @@ TODO
|
|||
|
||||
<header>
|
||||
|
||||
# How much randomization is needed to avoid split votes?
|
||||
# Quel degré de hasard est nécessaire pour éviter les votes non concluants ?
|
||||
|
||||
</header>
|
||||
|
||||
|
@ -291,7 +362,7 @@ TODO
|
|||
|
||||
<header>
|
||||
|
||||
# User Study: Is Raft Simpler than Paxos?
|
||||
# Étude: Raft est-il plus simple que Paxos ?
|
||||
|
||||
</header>
|
||||
|
||||
|
|
Loading…
Reference in a new issue