- certificats
- Dist SyS
- Datacenter Design
- BGP/OSPF
Système Distribué
Introduction
Très Académique
L’art et la manière de faire croire qu’un système compose de plusieurs machines fonctionne comme une seule. (Ce n’est pas possible).
Pourquoi distribuer mon système ?
Exemple : Base de données
- Backup
- Redondance
- Unité fonctionnelle
- Geodistribution (Comme les CDL)
- Charge d’accès (Load balancing)
- Disponibilité
Scaling vertical : Augmenter les capacités de la machine (CPU, RAM)
Structure
- Stateless (Trivial) : Load balancer
- Stateful (Entrain de manipuler une database):
- Partitionnement : On divise la base en plusieurs morceaux. (A->M et N->Z)
- Si une machine tombe, on perd la moitié des données
- Trouver une clé de partitionnement (hash)
- Replication : Une replique la base de données dans plusieurs machines
- Si une machine tombe on perd rien
- Prend plus de place
- Cout d’écriture plus important
Comment synchroniser les machines ?
Modelisation
-
Synchrone (Modele idéal) : Au bout d’un moment, nous sommes sur que le
message a été reçu et les horloges sont synchronisées.
-
Asynchrone : Aucune garantie (reception, corruption, …)
-
Modèle d’échec
- Crash-stop : Plante et nécessite une intervention humaine pour se
relancer.
- Crash-recovery : Plante et redémarre plus tard en n’étant plus a jour.
- Byzantin : Elle peut échouer en se comportant de manière arbitraire
voir malicieuse.
-
Problème du consensus : C’est le coeur des systemes distribués pour leurs
résolutions
- FLPTheorem : Dans un système distribuée dans un modèle d’échec
crash-top. Alors si nous sommes dans un système asynchrone, il n’existe
pas de moyen dans un réseau d’une seule machine. C’est un théoreme
d’impossibilité
-
Modèle partiellement synchrone : En temps normal l’état des choses n’est
pas le chaos. Mais ponctuellement il arrive des problèmes et tôt ou tard,
ce problème sera resolu. Lors d’un problème, le réseau tourne en mode
reduit. Comment détecter s’il y a un problème ?
- Comment détecter si mon copain serveur est mort ? : Deuxième
théoreme d’impossibilité. On ne peut pas faire la différence entre :
- Le réseau est mort
- Le serveur est mort
Theoreme CAP
Il y a trois grandes propriétes dans les systèmes distribuées :
- C (Strong Consistency) : Il n’y a pas de temps de propagation =
toute opération I/O est visible instantanéement.
- A (Availability) : On reçoit une réponse à toute requête.
- P (Partition Tolerance) : Prendre conscience de l’éventualité d’une
coupure réseau.
Le théoreme d’impossibilité CAP : On ne peut pas avoir les 3, juste 2. On peut soit sacrifier le C, soit le A. En cas de partitionnement réseau §, je serai obligé de sacrifier soit le C soit le A.
3 types de système :
- CP : En cas de coupure, on attend.
- AP : En cas de coupure, on collecte et on resynchronise quand la connexion se retablit.
- CA (Legacy) : Elle prédate ce théorème et part du principe que la machine est morte.
Systeme SQL Old School
C’est un système CA. En cas de requête,
- on valide la requête avant de répliquer
Le répliqueur tombe entre le moment ou il valide la requête et il envoi la
donnee a répliquer. Faux positif
- Avec une vérification avant :
- Le primaire envoi une première salve de requête : Vous êtes prêt.
- Le primaire envoi une salve de commit : Envoi de l’entrée.
Algorithme CP
Si une machine attend, il y a de forte chance, que la panne ne soit pas
atomique (il y a pas deux blocs distincts mais beaucoup plus). On choisit quels blocs peuvent continuer et les autres attendront la reprise réseau.
S’il existe une partition possédant la majorite absolue, il n’y en a qu’une
seule. Cette dernière pourra continuer (Dans le cas où on n’est pas dans un
système byzantin). C’est une des raisons pour laquelle les systémes de
replication sont en nombre impaire.
PAXOS: Un algo légendairement dur.
- Impossible à comprendre
- Impossible à expliquer
- Impossible à implémenter.
(The Part-Time Parliament, Leslie Lamport (Time code : 1:01:00) Problème du
consensus.)
Website
Google développe la première implémentation industrielle de PAXOS : CHUBBY. Et fait un papier de recherche : Paxos made live.
En 2006, un autre algo est sorti. Il est aussi puissant que PAXOS mais facile à expliquer, comprendre et implémenter : RAFT.
Explication de RAFT et par Chewie 1:15:00-01:21:00
La théorie des systèmes distribuées, c’est un master entier de Paris VI
Système AP
Il accepte la divergence, et donnne des algos de reconciliations. Au pire ce
sera au client de résoudre le problème.
CRDT (Convergent Replicated Data Type) : Certaines données peuvent résoudre la divergence de manière automatique. Par exemple dans un ensemble, il
n’y a pas d’ordre.
Bibliographie :
Système Distribué
Introduction
Très Académique
L’art et la manière de faire croire qu’un système compose de plusieurs machines fonctionne comme une seule. (Ce n’est pas possible).
Pourquoi distribuer mon système ?
Exemple : Base de données
Scaling vertical : Augmenter les capacités de la machine (CPU, RAM)
Structure
- Si une machine tombe, on perd la moitié des données
- Trouver une clé de partitionnement (hash)
- Si une machine tombe on perd rien
- Prend plus de place
- Cout d’écriture plus important
Comment synchroniser les machines ?
Modelisation
Synchrone (Modele idéal) : Au bout d’un moment, nous sommes sur que le
message a été reçu et les horloges sont synchronisées.
Asynchrone : Aucune garantie (reception, corruption, …)
Modèle d’échec
relancer.
voir malicieuse.
Problème du consensus : C’est le coeur des systemes distribués pour leurs
résolutions
crash-top. Alors si nous sommes dans un système asynchrone, il n’existe
pas de moyen dans un réseau d’une seule machine. C’est un théoreme
d’impossibilité
Modèle partiellement synchrone : En temps normal l’état des choses n’est
pas le chaos. Mais ponctuellement il arrive des problèmes et tôt ou tard,
ce problème sera resolu. Lors d’un problème, le réseau tourne en mode
reduit. Comment détecter s’il y a un problème ?
théoreme d’impossibilité. On ne peut pas faire la différence entre :
Theoreme CAP
Il y a trois grandes propriétes dans les systèmes distribuées :
toute opération I/O est visible instantanéement.
coupure réseau.
Le théoreme d’impossibilité CAP : On ne peut pas avoir les 3, juste 2. On peut soit sacrifier le C, soit le A. En cas de partitionnement réseau §, je serai obligé de sacrifier soit le C soit le A.
3 types de système :
Systeme SQL Old School
C’est un système CA. En cas de requête,
Le répliqueur tombe entre le moment ou il valide la requête et il envoi la
donnee a répliquer. Faux positif
Algorithme CP
Si une machine attend, il y a de forte chance, que la panne ne soit pas
atomique (il y a pas deux blocs distincts mais beaucoup plus). On choisit quels blocs peuvent continuer et les autres attendront la reprise réseau.
S’il existe une partition possédant la majorite absolue, il n’y en a qu’une
seule. Cette dernière pourra continuer (Dans le cas où on n’est pas dans un
système byzantin). C’est une des raisons pour laquelle les systémes de
replication sont en nombre impaire.
PAXOS: Un algo légendairement dur.
(The Part-Time Parliament, Leslie Lamport (Time code : 1:01:00) Problème du
consensus.)
Website
Google développe la première implémentation industrielle de PAXOS : CHUBBY. Et fait un papier de recherche : Paxos made live.
En 2006, un autre algo est sorti. Il est aussi puissant que PAXOS mais facile à expliquer, comprendre et implémenter : RAFT.
Explication de RAFT et par Chewie 1:15:00-01:21:00
La théorie des systèmes distribuées, c’est un master entier de Paris VI
Système AP
Il accepte la divergence, et donnne des algos de reconciliations. Au pire ce
sera au client de résoudre le problème.
CRDT (Convergent Replicated Data Type) : Certaines données peuvent résoudre la divergence de manière automatique. Par exemple dans un ensemble, il
n’y a pas d’ordre.
Bibliographie :
single-page.html)
et aphyr.tumblr.com /!\