Consenso distribuito

Transcript

1 Consenso distribuito Sistemi Distribuiti Laurea magistrale in ingegneria informatica A.A Leonardo Querzoni

2 Il problema del consenso Un gruppo di processi devono mettersi d accordo su un valore (es. commit/abort di una transazione). E l astrazione di una classe di problemi in cui i processi partono con le loro opinioni (forse divergenti) e devono accordarsi su un opinione comune. È un problema fondamentale. Siamo interessati a studiare algoritmi e modelli minimali per risolvere questo problema in presenza di guasti. 2

3 Il problema del consenso Fisher, Lynch e Patterson hanno provato nel 1985 che è impossibile risolvere il problema del Consenso in modo deterministico in sistemi asincroni in cui anche un solo processo può guastarsi per crash Michael J Fischer, Nancy A. Lynch and Michael S. Paterson, Impossibility of distributed consensus with one faulty process. Journal of the ACM, Vol. 32, No. 2, April

4 Il problema del consenso Definizione del problema: Insieme di processi distribuiti con valori iniziali {0,1}. Ogni processo propone un valore. Tutti devono decidere lo stesso valore {0,1}. Il valore deciso deve essere tra quelli proposti. P1 P2 P3 P4 P5 P6 P7 Valori iniziali Consenso P1 P2 P3 P4 P5 P6 P7 Valori iniziali

5 Il problema del consenso Specifica del Consenso: <c, Propose v> utilizzabile per proporre il valore v <c, Decide v> notifica il processo che è stato deciso il valore v Il consenso gode delle seguenti proprietà: Termination: ogni processo corretto prima o poi decide un valore. Validity: se un processo decide v, allora v è stato proposto da qualche processo. Integrity: nessun processo decide due volte. Agreement: due processi corretti non decidono mai due valori diversi. 5

6 Flooding-based consensus Il primo algoritmo risolve il problema del consenso usando una semplice strategia: ogni processo propone un valore ogni processo raccoglie i valori ricevuti dagli altri e inoltra questo insieme a tutti ad ogni round i processi attendono di aver visto le proposte di tutti prima di decidere la decisione viene presa applicando una funzione deterministica sull insieme dei valori proposti ogni processo che decide avverte tutti gli altri 6

7 Flooding-based consensus Il problema più complesso è far si che tutti i processi concordino sull insieme dei valori proposti. Utilizza: Best Effort Broadcast Perfect Failure Detector 7

8 Flooding-based consensus upon event <c, Init> do for i=1 to N do receivedfrom[i] = ; proposals[i] = ; receivedfrom[0] = ; round = 1; decision = ; correct = ; upon event <P, Crash Pj> do correct = correct \ {Pj}; upon event <c, Propose v> do proposals[1] = proposals[1] {v}; trigger <beb, Broadcast [PROPOSAL, 1, proposals]>; upon event <beb, Deliver Pj, [PROPOSAL, r, ps]> do receivedfrom[r] = receivedfrom[r] {Pj}; proposals[r] = proposals[r] ps; 8

9 Flooding-based consensus upon event correct receivedfrom[round] decision = do if receivedfrom[round] = receivedfrom[round - 1] then decision = min(proposals[round]); trigger <beb, Broadcast [DECIDED, decision]>; trigger <c, Decide decision>; else round = round + 1; trigger <beb, Broadcast [PROPOSAL, round, proposals[round- 1]]>; upon event <beb, Deliver Pj, [DECIDED, v] > do if Pj correct decision = then decision = v; trigger <beb, Broadcast [DECIDED, decision]>; trigger <c, Decide decision>; 9

10 Flooding-based consensus Esempio: P 1 P 2 P 3 P 4 <c,%propose% %x> <c,%propose% %y> <c,%propose% %y> <c,%propose% %z> <beb,%deliver% %P1,%[Proposal,%{x}]> <beb,%deliver% %P2,%[Proposal,%{y}]> <beb,%deliver% %P3,%[Proposal,%{y}]> <beb,%deliver% %P4,%[Proposal,%{z}]> <c,%decide% %x> <beb,%deliver% %P2,%[Proposal,%{y}]> <beb,%deliver% %P3,%[Proposal,%{y}]> <beb,%deliver% %P4,%[Proposal,%{z}]> <beb,%deliver% %P2,%[Proposal,%{y}]> <beb,%deliver% %P3,%[Proposal,%{y}]> <beb,%deliver% %P4,%[Proposal,%{z}]> <beb,%deliver% %P2,%[Decided,%x]> <c,%decide% %x> <beb,%deliver% %P2,%[Decided,%x]> <c,%decide% %x> ROUND%1 ROUND%2 10

11 Flooding-based consensus Correttezza: Validity e integrity: conseguenza delle proprietà dei canali di comunicazione sottostanti (pl). Termination: ogni processo decide in al più N round (caso in cui N-1 processi si guastano). Agreement: i processi decidono su un insieme di proposte utilizzando una funzione deterministica. L agreement può essere provato ragionando su: il caso in cui un processo vede per due round lo stesso set di processi e decide; il caso in cui un processo decide perché vede la decisione di un processo che si guasta. 11

12 Hierarchical consensus L algoritmo visto usa un enorme numero di messaggi per raggiungere il consenso. Sfruttando un ordinamento precostituito tra i processi è possibile migliorare le prestazioni in alcuni casi comuni Utilizza: Best Effort Broadcast Perfect Failure Detector 12

13 Hierarchical consensus upon event <c, Init> do detectedranks = ; proposal = ; proposer = 0; round = 1; delivered = false N ; broadcast = false; upon event <P, Crash Pj> do detectedranks = detectedranks {rank(pj)}; upon event <c, Propose v> do if proposal = then proposal = v; 13

14 Hierarchical consensus upon event round = rank(self) proposal broadcast = false do broadcast = true; trigger <beb, Broadcast [DECIDED, proposal]>; trigger <c, Decide proposal>; upon event round detectedranks delivered[round] = true do round = round + 1; upon event <beb, Deliver Pj, [DECIDED, v]> do r = rank(pj); if r < rank(self) r > proposer then proposal = v; proposer = r; delivered[r] = true; 14

15 Hierarchical consensus Esempio: P 1 P 2 P 3 P 4 <c,$propose$ $x> <c,$decide$ $x> <c,$propose$ $y> <c,$propose$ $y> <c,$propose$ $z> <beb,$deliver$ $P1,$[Decided,$x]> <c,$decide$ $x> <beb,$deliver$ $P2,$[Decided,$x]> <beb,$deliver$ $P1,$[Decided,$x]> <beb,$deliver$ $P1,$[Decided,$x]> <c,$decide$ $x> <beb,$deliver$ $P2,$[Decided,$x]> <beb,$deliver$ $P3,$[Decided,$x]> <c,$decide$ $x> ROUND$1 ROUND$2 ROUND$3 ROUND$4 15

16 Hierarchical consensus Correttezza: Validity e integrity: conseguenza delle proprietà dei canali di comunicazione sottostanti (pl). Termination: segue dalla proprietà di strong completeness del FD P. Agreement: supponiamo p e q due processi corretti che decidono valori diversi. Supponiamo rank(p)=i < j=rank(q). q può decidere solo al round j>i ma per arrivarci deve essere vera una delle due: p si è guastato (impossibile perché corretto) q ha ricevuto DELIVERED da p In quest ultimo caso q non può decidere un valore diverso da p 16

17 Consenso uniforme Specifica del Consenso: Termination: ogni processo corretto prima o poi decide un valore. (come regolare) Validity: se un processo decide v, allora v è stato proposto da qualche processo. (come regolare) Integrity: nessun processo decide due volte. (come regolare) Uniform Agreement: due processi non decidono mai due valori diversi. 17

18 Flooding-based uniform consensus Nell algoritmo originale un processo decideva dopo aver osservato gli stessi set di proposte per due round successivi. Questo processo potrebbe decidere e guastarsi immediatamente, violando l uniformità. In questa variante ogni processo semplicemente aspetta il round N prima di decidere. 18

19 Flooding-based uniform consensus upon event <uc, Init> do receivedfrom = ; proposals = ; round = 1; decision = ; correct = ; upon event <P, Crash Pj> do correct = correct \ {Pj}; upon event <uc, Propose v> do proposals = proposals {v}; trigger <beb, Broadcast [PROPOSAL, 1, proposals]>; upon event <beb, Deliver Pj, [PROPOSAL, r, ps]> do if r==round then receivedfrom = receivedfrom {Pj}; proposals = proposals ps; 19

20 Flooding-based uniform consensus upon event correct receivedfrom decision = do if round == N then decision = min(proposals[round]); trigger <uc, Decide decision>; else round = round + 1; receivedfrom = ; trigger <beb, Broadcast [PROPOSAL, round, proposals]>; 20

21 Flooding-based uniform consensus Correttezza: Validity e integrity: conseguenza delle proprietà dei canali di comunicazione sottostanti (pl). Termination: tutti i processi corretti terminano l esecuzione decidendo al round N. Agreement: i processi che raggiungono il round N hanno lo stesso set proposals, e quindi decidono lo stesso valore. 21

22 Hierarchical uniform consensus In questo caso l algoritmo mantiene la stessa struttura. Ad ogni round abbiamo due passi: prima il leader propone il proprio valore a tutti quindi attende che tutti gli confermino la ricezione del suo valore Utilizza: Best Effort Broadcast Reliable Broadcast Perfect Link Perfect Failure Detector 22

23 Hierarchical uniform consensus upon event <uc, Init> do detectedranks = ; ackranks = ; proposal = ; decision = ; round = 1; proposed = N ; upon event <P, Crash Pj> do detectedranks = detectedranks {rank(pj)}; upon event <uc, Propose v> do if proposal = then proposal = v; upon event round = rank(self) proposal decision = do trigger <beb, Broadcast [PROPOSAL, proposal]>; 23

24 Hierarchical uniform consensus upon event <beb, Deliver Pj, [PROPOSAL, v]> do proposed[rank(pj)] = v; if rank(pj) round then trigger <pl, Send Pj, [ACK]>; upon event round detectedranks do if proposed[round] then proposal = proposed[round]; round = round + 1; upon event <pl, Deliver Pj, [ACK]> do ackranks = ackranks {rank(pj)}; upon event detectedranks ackranks = do trigger <rb, Broadcast [DECIDED, proposal]>; upon event <rb, Deliver Pj, [DECIDED, v]> do if proposal = then decision = v; trigger <uc, Decide decision>; 24

25 Hierarchical uniform consensus Correttezza: Validity e integrity: conseguenza delle proprietà dei canali di comunicazione sottostanti (pl). Termination: se un processo corretto decide lo fa dopo aver eseguito <rb, Deliver>, quindi, per la proprietà di agreement di rb, tutti i processi corretti prima o poi decidono. supponiamo p il processo corretto con rank più piccolo tutti i processi corretti segnalano il guasto di qualsiasi processo i con rank(i)<rank(p) Prima o poi tutti raggiungono il round rank(p) e non procedono a round successivi Questo round termina correttamente con la decisione di p. 25

26 Hierarchical uniform consensus Correttezza: Agreement: Assumiamo che esistano due processi che decidono valori differenti. Questo può accadere solo se due processi mandano in rbbroadcast due valori differenti. Supponiamo questi siano p e q, con rank(q)>rank(p), che eseguono rb-broadcast di due valori v e v Causa strong accuracy del FD, q deve aver adottato il valore v prima di raggiungere il round rank(q) Se questo non fosse avvenuto p non avrebbe potuto inviare v con rbbroadcast. Quindi deve essere necessariamente v=v 26

27 Rotating coordinator consensus Vediamo ora un algoritmo che realizza consenso uniforma in un sistema parzialmente sincrono; L algoritmo procede per round e ad ogni round esiste un singolo leader Pi è il leader nei round i, i+n, i+2n,... Utilizza: Eventually Perfect FD Best effort broadcast Reliable broadcast 27

28 Rotating coordinator consensus Ad ogni round: ogni processo non leader (witness) propone al leader un valore con il proprio timestamp (round) il leader raccoglie le proposte e sceglie la proposta con timestamp più alto il leader propone a tutti i witness il valore scelto quando un processo witness riceve la proposta del leader la accetta rispondendo con un ACK se sospetta il leader di guasto la rifiuta rispondendo con un NACK e passa al round successivo se il leader riceve una maggioranza di ACK decide il valore che aveva proposto se il leader riceve anche un solo NACK passa al round successivo 28

29 Rotating coordinator consensus upon event <uc, Init> do round = 1; estimate[]=ack[]=false; proposed[]= proposal = decided = ; suspected=estimate- set[]=ack- set[]=nack- set[]= ; upon event <uc, Propose v> do proposal = (v,0); upon event proposal estimate[round]=false do estimate[round] = true; trigger <pl, Send leader(round), [ESTIMATE, round, proposal]>; upon event <pl, Deliver Pj, [ESTIMATE, r, e]> do estimate- set[r] = estimate- set[r] {e}; upon event leader(round)=self estimate- set[round] >N/2 do proposal = highest(estimate- set[round]); trigger <beb, Broadcast [PROPOSE, round, proposal]>; 29

30 Rotating coordinator consensus upon event <beb, Deliver Pj, [PROPOSE, r, v]> do proposed[r] = v; upon event proposed[round] ack[round]=false do proposal = (proposed[round], round); ack[round] = true; trigger <pl, Send leader(round), [ACK, round]>; round := round + 1; upon event <pl, Deliver Pj, [ACK, r]> do ack- set[r] = ack- set[r] {Pj}; upon event leader(round) suspected ack[round]=false do ack[round] = true; trigger <pl, Send leader(round), [NACK, round]>; round = round + 1; upon event <pl, Deliver Pj, [NACK, r]> do nack- set[r] = nack- set[r] {Pj}; 30

31 Rotating coordinator consensus upon event leader(round)=self nack- set[round] do round := round + 1; upon event leader(round)=self ack- set[round] >N/2 do trigger <rb, Broadcast [DECIDE, proposal]>; upon event <rb, Deliver Pj, [DECIDED, v]> decided= do decided = v; trigger <uc, Decide v>; upon event < P, suspect Pj> do suspected = suspected {Pj}; upon event < P, restore Pj> do suspected = suspected \ {Pj}; 31