yay even more slides

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