yay even more slides

This commit is contained in:
Laureηt 2023-01-08 17:07:57 +01:00
parent 0ceeaebfee
commit 8caf96d640
Signed by: Laurent
SSH key fingerprint: SHA256:kZEpW8cMJ54PDeCvOhzreNr4FSh6R13CMGH/POoO8DI
7 changed files with 95 additions and 24 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

BIN
figs/leader-election.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 104 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 65 KiB

BIN
figs/log-structure.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 101 KiB

119
slides.md
View file

@ -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
- Leaders 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>