Du syst - PowerPoint PPT Presentation

1 / 33
About This Presentation
Title:

Du syst

Description:

Logiciels de base, complexes, pour simplifier les applications : ... Ordonner totalement requ tes. de fa on tol rante aux fautes : 2f 1 'Acceptor' Choix de la ... – PowerPoint PPT presentation

Number of Views:46
Avg rating:3.0/5.0
Slides: 34
Provided by: pagespers
Category:
Tags: ordonner | syst

less

Transcript and Presenter's Notes

Title: Du syst


1
Du système au système de systèmesou Pourquoi
Google n'est pas français
  • Marc Shapiro
  • Directeur de recherche
  • Équipe-projet Regal

2
Le système
  • Logiciels de base, complexes, pour simplifier les
    applications
  • Système d'exploitation
  • Système réparti
  • Temps réel, systèmes enfouis
  • Abstractions et mécanismes génériques
  • Métriques de performance
  • latence, débit
  • disponibilité résistance aux pannes, aux
    attaques
  • coût logiciel, matériel
  • énergie batteries, chaleur

3
Systèmes répartis
4
Informatique répartie
  • Toute informatique est répartie
  • sites / processus
  • messages asynchrones, coûteux
  • pannes partielles
  • redondance matérielle
  • Peer-to-peer décentralisé, effet de masse,
    auto-organisant
  • Amazon, Google, etc. PC, disques, etc., bon
    marché redondance

5
Réplication des données
  • Accès distant, partagé ? répliquer
  • performance
  • disponibilité tolérance aux fautes
  • travail déconnecté et collaboratif
  • Répliques m-à-j ? maintien de la cohérence
  • Consensus

6
Profiter du parallélisme ?
a
c
b
d
e
f
  • Opérations commutatives dans nimporte quel
    ordre
  • Embarassingly parallel
  • Dépendance causale dans lordre
  • Ordre partiel Happened-before
  • Opérations non commutatives le système les
    ordonne
  • Dans le doute ordre total
  • Solutions
  • attendre (pessimiste)
  • spéculer (optimiste) retour arrière

7
Ordonnancer les opérations concurrentes
a
c
b
d
e
f
  • Exemples
  • Qui a la dernière place dans l'avion ?
  • Verrouillage atomique d'un fichier
  • Ordre des voitures dans un train Praxitèle (?)
  • Consensus

8
Fischer, Lynch, Patterson 85
  • Impossibilité du consensus si
  • messages asynchrones
  • pannes non détectables
  • déterministe
  • On doit sacrifier
  • soit la sûreté l'algorithme fait des erreurs
  • soit la vivacité l'algorithme se bloque
  • soit les hypothèses

9
Tolérance aux fautes
?
14 547
15 333
15 333
A
14 547
15 333
15 333
  • Fautes bénignes silencieuses
  • perte de message
  • crash
  • Tolérer f crashes sur n sites
  • nattendre que n f messages
  • ? Il faut 2f1 sites
  • Propriété de recouvrement

10
L'algorithme de consensus Paxos
  • Clients invoquent "learner"
  • en parallèle
  • Ordonner totalement requêtes
  • de façon tolérante aux fautes
  • 2f1 "Acceptor"
  • Choix de la prochaine
  • "Leader" tournant
  • Primitive de base

11
Paxos
Client 1
Client 2
Proposer 1
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Learner 1
12
Tolérance aux fautes dans Paxos
Client 1
Client 2
Proposer 1
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Learner 1
13
Fautes byzantines
Général félon
retraite !
attaque !
Lieut. A
Lieut. B
  • Les processus peuvent faire n'importe quoi
    collusion, mensonge, etc. pannes logicielles,
    attaques de sécurité
  • Il a dit...
  • Tolérer f fautes gt 3f1

14
Byzantine Fault Tolerance
  • 1982 Lamport, Shostak, Pease "The Byzantine
    Generals Problem"
  • 1990 Lamport Paxos "The part-time parliament"
  • Deux idées de théoricien fou...
  • 1999 Castro, Liskov OSDI
  • Paxos Byz NFS Practical Byzantine Fault
    Tolerance
  • 2008
  • Farsite, Oceanstore
  • Google Chubby, GFS
  • IBM SAN Volume Controller
  • Microsoft Autopilot cluster mgt service
  • SOSP 2007 une session entière !

15
Réplication optimiste
16
Approche optimiste
f (x1)
x
x1
g(x2)
x2
x3
  • Répliques x1, x2, x3,..., y1, y2, ... sur sites
    1, 2, 3, ...
  • Site 2 propose g(x2) propagation  1, 3, ...
    rejouent
  • Ordre différent  résultats équivalents ?
  • À l'essai
  • Prendre en compte sémantique commutativité,
    etc.
  • Réconciliation a posteriori consensus

17
Sémantique de la concurrence
  • Opérations pré-conditions / post-conditions
  • Ordonnancements
  • Ne permettre que ceux sûrs pre/post
  • Equivalence modulo commutativité
  • Graphe Actions-Contraintes structure de données
    pour la concurrence
  • Sommet action
  • Arc contrainte approximation sûre des
    pré/post/commutativité

18
Graphe actions-contraintes
  • ? Non commutatif (le système doit ordonnancer)
  • ? Not-after (le système doit briser les cycles)
  • ? Antagonisme (un cycle de ?)
  • Dépendance causale

?
?
f
?
h
g
19
Contraintes (1)
?
?
? Non commutatif (le système doit
ordonnancer) ? Not-after (le système doit briser
les cycles) ? Antagonisme (un cycle de
?) Dépendance causale
f?g f ?g
?
20
Contraintes
?
?
? Non commutatif (le système doit
ordonnancer) ? Not-after (le système doit briser
les cycles) ? Antagonisme (un cycle de
?) Dépendance causale
Exemple compte bancaire
f g f?g f ?g
credit (a, v) debit (a, v') Ø
debit (a, v) debit (a, v') Ø ?
autres cas  autres cas  Ø Ø
21
Constraints (3)
? Non commutatif (le système doit
ordonnancer) ? Not-after (le système doit briser
les cycles) ? Antagonisme (un cycle de
?) Dépendance causale
Exemple Base de données RW state replay
?
22
Décision
  • Obligation de vivacité
  • Briser cycles ? par abort
  • Ordonnancer ? par ? ou abort
  • Le système ajoute des contraintes

?
?
f
g
h
?
?
?
?
j
k
23
Cohérence à terme
  • Cohérence à terme
  • Toutes les opérations sont décidées à terme
  • Pas de décisions illégales
  • Consensus
  • En tâche de fond hors du chemin critique
  • Application non ralentie
  • Optimisations regroupement, heuristiques,
    sémantique

24
Telex
Marc
Pierre
Ruby
  • Graphe actions-contraintes persistant
  • Document stocké comme répertoire contenant des
    fichiers de type journal
  • nommage
  • pas de contention
  • localité

25
Example
26
Designing for commutativity
  • If concurrent operations commute, no concurrency
    control needed
  • How to design for commutativity
  • Small, independent objects
  • Commutative operations on single object?
  • true commutativity vs. precedence

27
Shared editing scenario
  • Several users sharing a text buffer
  • Replicated at every site
  • User initiates edit operations
  • Executed, logged, sent to other sites
  • Sites replay remote operations locally
  • Eventually, all sites execute all operations
  • Problem different execution orders
  • How to ensure eventual consistency?

28
treedoc
  • Goals
  • Commutative insert and delete operations
  • Block operations (e.g. cut-paste)
  • Minimise space overhead
  • Techniques
  • Binary tree minimal metadata
  • insert adds a leaf ? non-destructive, identifiers
    dont change
  • Structure changes background consensus
  • Simple, non-aborting transactions

29
Multiprocesseurs multi-cœur
30
Limites des architectures UC traditionnelles
31
Processeurs multi-cœur
Server
Desktop
LPIA
LPIA
DRAM
DRAM
DRAM
DRAM
LPIA
LPIA
x86
x86
ctlr
ctlr
ctlr
ctlr
x86
x86
LPIA
LPIA
DRAM
DRAM
OoO
x86
x86
ctlr
ctlr
x86
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA
x86
x86
cache
cache
cache
cache
x86
x86
LPIA
LPIA
1 MB
1 MB
x86
x86
cache
cache
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA
x86
x86
cache
cache
cache
cache
x86
x86
LPIA
LPIA
1 MB
GPU
GPU
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA
x86
x86
cache
x86
x86
cache
cache
cache
cache
x86
x86
PCIe
PCIe
1 MB
1 MB
NoC
NoC
PCIe
PCIe
ctlr
ctlr
cache
cache
NoC
NoC
NoC
NoC
NoC
NoC
ctlr
ctlr
LPIA
LPIA
1 MB
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA
GPU
GPU
x86
x86
cache
x86
x86
cache
cache
cache
cache
x86
x86
LPIA
LPIA
1 MB
1 MB
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA

x86
x86
cache
cache
x86
x86
cache
cache
cache
cache
x86
x86
LPIA
LPIA
1 MB
1 MB
1 MB
1 MB
LPIA
LPIA
LPIA
LPIA
DRAM
DRAM
OoO
x86
x86
cache
cache
cache
cache
x86
x86
x86
x86
ctlr
ctlr
x86
LPIA
LPIA
LPIA
LPIA
Custom acceleration
x86
x86
x86
x86
Ultra-Mobile
Concurrence Complexité Coûts mémoire
LPIA
1 MB
1 MB
DRAM
GPU
x86
cache
cache
ctlr
LPIA
1 MB
1 MB
PCIe
GPU
x86
cache
ctlr
cache
Source Andrew Herbert, EuroSys 2008
32
Ex. Sun Niagara
Source http//tbp.berkeley.edu/jdonald/research
/hyperthreading/romanescu_niagara.pdf
32
33
Profiter du parallélisme ?
Source Wikipedia, Amdahls Law
34
La révolution est déjà en cours
  • Bientôt des millions de processeur par
    personne...
  • Comment est-ce qu'on va programmer ça ?
  • Concurrence très complexe !
  • Très difficile à programmer et déboguer
  • Énorme  tous les développeurs sont concernés
  • Abstractions ne suffisent pas  interférence, non
    compositionnel
  • Coup de fouet à la recherche

35
Linéarisabilité
pre
post
post
  • Objets (indépendants) linéarisables
  • méthode prend effet de manière instantanée (ordre
    total)
  • entre l'appel et la réponse (compatible temps
    réel)
  • Comportement atomique, réalisation non atomique
  • Compositionnel

36
Example  verrous couplés
  • Ensemble d'entiers réalisé par liste chaînée
    triée
  • Concurrence à grain fin  verrous couplés
  • Prouver 
  • invariant de liste chaînée
  • invariant de l'abstraction
  • linéarisable ? compositionnel
  • Invariant-clef  un nœud verrouillé reste
    accessible, quelles que soient les opérations
    concurrentes

37
Rely-Guarantee
p1, r1 C1 g1, q1 p2, r2 C2
g2, q2 g1 ? r2
g2 ? r1 ????????????????????? p1 ?
p2, g1 ? g2 C1 C2 g1 ? g2, q1 ? q2
  • Extension de la logique de Hoare au parallélisme
    fin  preuve de non-interférence
  • pre C post ? prei, relyi Ci guari,
    posti
  • par fil i  preuve séquentielle classique
  • global  ?j ? i guarj ? relyi

37
38
Ne pas rater cette révolution
  • Questions
  • Algorithmes ?
  • verrous à grain fin
  • sans verrou
  • mémoire transactionnelle
  • spéculation
  • opportunisme / caches
  • Langages, paradigmes ?
  • Preuves, simulations, débogage, test ?
  • Maîtriser la complexité
  • Auto-configuration, auto-administration
  • Réutiliser algorithmes système réparti
  • Que fait lINRIA ?

39
Multi-processeur Tsar
CPU
CPU
CPU
CPU
L2 cache
L2 cache
L1 I
L1D
L1 I
L1D
L1 I
L1D
L1 I
L1D
Crossbar
Crossbar
RAM
micro-Ethernet
Crossbar
Crossbar
L1 I
L1 I
L1 I
L1D
L1 I
L1D
L1D
L1D
L2 cache
L2 cache
CPU
CPU
CPU
CPU
Source Alain Greiner
40
Conclusions
41
Importance du système
  • Modèle algorithme expérimentation !!!
  • Pas de théorie sans pratique et vice-versa
  • Comprendre les compromis / trade-offs
  • Intérêt de recherche
  • lien théorie-pratique très fort
  • impact 8 sur 11 premières dans CiteSeer
  • voir MIT, Stanford, CMU, Berkeley, etc.
  • INRIA
  • Grilles, P2P,
  • Ne pas rater la révolution du multi-cœur !

42
Importance stratégique
  • Couche de base ? stratégique
  • technologies essentielles (p.ex. sécurité)
  • impact économique (Microsoft, Google)
  • formation indispensable
  • Insuffisamment développé en Europe
  • mais voir EPFL, ETHZ, Max Planck, Cambridge
  • INRIA ?

43
Pourquoi Google nest-il pas français ?
  • Et Akamai, Amazon, Apple, eBay, Google, Groove,
    IBM, Microsoft, RedHat, SMC, Skype, Sun, Suse,
    Symbian, VMWare, Xen?
  • Forces systèmes enfouis, transports, P2P,
    grilles, Linux
  • Pour mieux développer le système
  • expérimental durée des thèses
  • recrutement
Write a Comment
User Comments (0)
About PowerShow.com