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

Du système au système de systèmes

ou : Pourquoi Google n'est pas français

Du système au système de systèmes

ou : Pourquoi Google n'est pas français

Marc ShapiroDirecteur de recherche

Équipe-projet Regal

2Du système au système de systèmes – Rocquencourt – 15 mai 2008

Le « système »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ériquesMétriques de performance :• latence, débit• disponibilité ; résistance aux pannes,

aux attaques• coût logiciel, matériel• énergie : batteries, chaleur

Systèmes répartisSystèmes répartis


Informatique répartieInformatique 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


Réplication des donnéesRé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


Profiter du parallélisme ? Profiter du parallélisme ?

• Opérations commutatives : dans n’importe quel ordre

“Embarassingly parallel”• Dépendance causale : dans l’ordreOrdre 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

aa

bb

cc

dd

ee ff


Ordonnancer les opérations concurrentes

Ordonnancer les opérations concurrentes

Exemples :• Qui a la dernière place dans l'avion ?• Verrouillage atomique d'un fichier• Ordre des voitures dans un train

Praxitèle (?)

Consensus

aa

bb

cc

dd

ee ff


Fischer, Lynch, Patterson 85

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


Tolérance aux fautesTolérance aux fautes

Fautes bénignes : silencieuses• perte de message• crash

Tolérer f crashes sur n sites :• n’attendre que n – f

messages⇒ Il faut 2f+1 sitesPropriété de recouvrement

A 14: 547

15: 333

? 14: 547

B 14: 547

C 14: 547

15: 333

15: 333

15: 333

10

Du système au système de systèmes – Rocquencourt – 15 mai 2008

L'algorithme de consensus PaxosL'algorithme de consensus Paxos

Clients invoquent "learner"• en parallèle

Ordonner totalement requêtes

• de façon tolérante aux fautes :

• 2f+1 "Acceptor"• Choix de la prochaine :• "Leader" tournant

Primitive de base

Req(3

14)

Acceptor 1

Acceptor 2

Acceptor 3

Req(3

3)

Req(5

49)

Req(7

7)

Proposer

Proposer

…

Learner Learner …

11


Paxos

Client 1

Client 2

Proposer 1

Proposer 2

Acceptor 1Acceptor 2

Acceptor 3

Learner 1

Req(3

3)

Prep

are(

1)

Prom

ise(

1)

Acc

epte

d(7

7)

Resp

onse

(77)

Accep

t!(77

)

Choix du leaderInstallation valeur

Acc

epte

d(3

3)

Resp

onse

(33)

Accep

t!(33

)Req(7

7)

Nouvelle instance,même leader

12


Tolérance aux fautes dans Paxos

Client 1

Client 2

Proposer 1

Proposer 2

Acceptor 1Acceptor 2

Acceptor 3

Learner 1

Prep

are(

1)

Prom

ise(

1)

Resp

onse

(77)

Accep

t!(77

)Req(7

7)

Acc

epte

d(7

7)

Prep

are(

4)

Req(3

3)

Prom

ise(

4)

Prom

ise(

4,7

7,1

)

Accep

t!(77

)

Acc

epte

d(7

7)

13


Fautes byzantinesFautes byzantines

Les processus peuvent faire n'importe quoi : collusion, mensonge, etc. : pannes logicielles, attaques de sécurité«Il a dit...»Tolérer f fautes ==> 3f+1

Général Général félonfélon

Lieut. ALieut. A Lieut. BLieut. B

retraite !

attaque !

Il a dit «retraite»

GénéralGénéral

Lieut. ALieut. A Lieut. B Lieut. B félonfélon

attaque !

attaque !


GénéralGénéral

Lieut. ALieut. A Lieut. B Lieut. B félonfélon

attaque !

attaque !

Lieut. CLieut. C


Il a dit«attaque»

attaque !

14


Byzantine Fault ToleranceByzantine Fault Tolerance1982 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 !

Réplication optimisteRéplication optimiste

16


Approche optimisteApproche optimiste

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

xx33

xx11

xx22

xx f (xf (x11))

g(xg(x22))

f f (x(x33))

g(xg(x11))

g(xg(x33))

18


Graphe actions-contraintes

Graphe actions-contraintes

f g h→

∦⇄

j k

→

f g h→

j

h

k

→

◁→

∦ Non commutatif (le système doit ordonnancer)→ Not-after (le système doit briser les cycles)⇄ Antagonisme (un cycle de →)

Dépendance causale

20


ContraintesContraintes

f g f≺g f ‖gcredit (a,

v)debit (a,

v')∅

debit (a, v)

debit (a, v')

∅ ∦

autres cas ∅ ∅

∦ 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

22


DécisionDécision

Obligation de vivacité :• Briser cycles → par abort• Ordonnancer ∦ par → ou abort

Le système ajoute des contraintes

f g h

j k

→

∦ →⇄

f g h

j k

→

∦ →⇄

◁→

→

23


Cohérence à termeCohé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


TelexTelex

Graphe actions-contraintes persistantDocument stocké comme répertoire

contenant des fichiers de type journal• nommage• pas de contention• localité

/users/shapiro/mydoc

/users/shapiro/mydoc

MarcMarc

PierrePierre

RubyRuby

Multiprocesseurs multi-cœur

Multiprocesseurs multi-cœur

30


Limites des architectures UC traditionnelles

Limites des architectures UC traditionnelles

10,000

1,000

100

10

1

‘70 ‘80 ‘90 ‘00 ‘10

Pow

er

Densi

ty (

W/c

m2)

40048008

8080

8085

8086

286386

486

Pentium® processors

Hot Plate

Nuclear Reactor

Rocket Nozzle

Sun’s Surface

Intel Developer Forum, Spring 2004 - Pat Gelsinger

Dissipation de chaleur

⇒ Ralentir l’horloge ⇒ Parallélisme

CPU Clock Speed

DRAM Access Speed

Speed (

MH

z) (

MH

z)

10,000

1,0001,000

100100

1010

1990199019921992 19941994 19961996 19981998 20002000 20022002 20042004

Memory Wall~90 cycles of the CPU clock

to access main memory!

Modern Microprocessors - Jason Patterson

Goulot d’étranglement de

l’accès à la mémoire⇒ Réplication

31


Processeurs multi-cœurProcesseurs multi-cœur

LPIA x86

LPIA x86

DRAM ctlr

DRAM ctlr

OoO x86

LPIA x86

LPIA x86

1 MB cache

1 MB cache

LPIA x86

LPIA x86

1 MB cache

GPU GPU

PCIe ctlr

PCIe ctlr

NoC NoC1 MB

cache1 MB

cache

LPIA x86

LPIA x86

1 MB cache

GPU GPU

LPIA x86

LPIA x86

1 MB cache

1 MB cache

LPIA x86

LPIA x86

DRAM ctlr

DRAM ctlr

OoO x86

LPIA x86

LPIA x86

DRAM ctlr

DRAM ctlr

DRAM ctlr

DRAM ctlr

LPIA x86

LPIA x86

LPIA x86

LPIA x86

1 MB cache

1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

LPIA x86

LPIA x86

1 MB cache

1 MB 1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

LPIA x86

LPIA x86

1 MB cache

1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

PCIe ctlr NoC NoC NoC NoC NoC NoC PCIe

ctlr

LPIA x86

LPIA x86

1 MB cache

1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

LPIA x86

LPIA x86

1 MB cache

1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

LPIA x86

LPIA x86

1 MB cache

1 MB cache

1 MB cache

1 MB cache

LPIA x86

LPIA x86

LPIA x86

LPIA x86 Custom acceleration LPIA

x86LPIA x86

ServerServerDesktopDesktop

Ultra-MobileUltra-Mobile

LPIA x86

1 MB cache

1 MB cache

DRAM ctlr

LPIA x86

1 MB 1 MB cache

PCIe ctlr

GPU

GPUcache Source : Andrew Herbert, EuroSys 2008

ConcurrenceComplexité

Coûts mémoire

34


La révolution est déjà en cours

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 compositionnelCoup de fouet à la recherche


Example : verrous couplés

Example : verrous couplés

Ensemble d'entiers réalisé par liste chaînée triée

Concurrence à grain fin : verrous couplésProuver :

• 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

5H 10 15 20 T5H 10 15

37


Rely-GuaranteeRely-Guarantee

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

[p1, r1] C1 [g1, q1] [p2, r2] C2 [g2, q2]g1 ⇒ r2 g2 ⇒ r1⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

[p1 ∧ p2, g1 ∧ g2] C1 || C2 [g1 ∨ g2, q1 ∧ q2]

37

38


Ne pas rater cette révolution

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 l’INRIA ?

39


CPU

Crossbar

L2 cache

micro-Ethernet

L1I

Crossbar

L2 cache

Crossbar Crossbar

L2 cache

CPU

L1I

L1D

CPU

L1I

RAM

L2 cache

L1D

CPU

L1I

L1D

CPU

L1I

L1D

CPU

L1I

L1D

CPU

L1I

CPU

L1I

L1D L1D L1D

Multi-processeur TsarMulti-processeur Tsar

Source : Alain Greiner

ConclusionsConclusions

41


Importance du systèmeImportance du systèmeModèle + algorithme +

expérimentation !!!• Pas de théorie sans pratique et vice-

versa• Comprendre les compromis / trade-

offsInté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égiqueImportance 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 n’est-il pas français ?

Pourquoi Google n’est-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

Documents

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