Consensus Concurrent problem
1 like264 views
Il documento tratta del problema del consenso e del commit in sistemi distribuiti, introducendo concetti chiave come validità, terminazione e accordo. Vengono presentati gli algoritmi Floodmin per il problema del k-agreement e le varianti a due e tre fasi per il problema del commit, analizzandone i requisiti e la correttezza. Si discute anche della complessità degli algoritmi, evidenziando le sfide legate ai fallimenti dei processi.
![Esempio: Fase 1
1
1
1
0
v[i]
!=
null
&&
v[i]
==
1
?
4 5
2 3
1](https://image.slidesharecdn.com/consensus-141018180338-conversion-gate02/85/Consensus-Concurrent-problem-25-320.jpg)
![Esempio: Fase 1
1 1
1
1
0
v[i]
!=
null
&&
v[i]
==
1
?
4 5
2 3](https://image.slidesharecdn.com/consensus-141018180338-conversion-gate02/85/Consensus-Concurrent-problem-26-320.jpg)
![Esempio: Fase 1
1
1
1
1
1
v[i]
!=
null
&&
v[i]
==
1
?
2 3
1
4 5](https://image.slidesharecdn.com/consensus-141018180338-conversion-gate02/85/Consensus-Concurrent-problem-36-320.jpg)
![Esempio: Fase 1
1
1
1
1
1
1
v[i]
!=
null
&&
v[i]
==
1
?
2 3 4 5](https://image.slidesharecdn.com/consensus-141018180338-conversion-gate02/85/Consensus-Concurrent-problem-37-320.jpg)
Consensus Concurrent problem
- 1. Altri problemi del Consenso • Introduzione al problema del consenso Gianvito Siciliano Lorenzo Valente • Problema del K-Agreement • Problema del Commit
- 2. Problema del consenso • Un gruppo di processi deve mettersi d’accordo su un valore: è l‘astrazione di una classe di problemi in cui i processi partono con le loro opinioni (eventualmente divergenti) e devono accordarsi su un’opinione comune • Validity: Se un processo decide per un valore, allora quel valore è stato proposto da qualche processo. • Termination: Prima o poi ogni processo attivo prende una decisione • Agreement: Nessuna coppia di processi attivi decide per due valori diversi Un processo si definisce attivo se non è fallito alla fine del round corrente
- 3. Consenso: sistema sincrono • Il sistema comprende n processi comunicanti tramite scambio di messaggi • I canali di comunicazione sono affidabili • Al più f processi sono soggetti a fallimenti (stopping failure) • Il processo pi (i=1…n) possiede una propria variabile di decisione, e propone un proprio valore vi appartenente ad un insieme D. • Ciascun processo parte da uno stato di indecisione e mira a raggiungere uno stato di decisione, in cui il valore di è immutabile.
- 4. Il problema del K-Agreement È una generalizzazione del problema del consenso, nella quale viene chiesto ai processi di accordarsi, non sullo stesso valore, ma su un insieme k di valori. Utilizzi: • Frequenze di trasmissione in una rete di comunicazione
- 5. Ambiente • Distribuito • Sincrono • Modello a grafo per la rete (completo e indiretto con n nodi) • Link della rete sicuri (nessuna possibilità di perdita di messaggi) • Nodi della rete insicuri (possibilità di fallimenti nei processi) • Input e valori decisionali compresi in un insieme V finito e totalmente ordinato.
- 6. K-Agreement: requisiti • Validity: Se un processo decide per un valore allora quel valore è il valore iniziale di qualche processo (Strong validity per 1-Agreement) • Termination: Ogni processo attivo fino alla fine prende una decisione • Agreement: 1. Tutti i valori di decisione appartengono ad un insieme W sottoinsieme di V 2. Ci sono al più k valori decisionali differenti (|W| = k)
- 7. Algoritmo FloodMin Informalmente: 1. Ogni processo memorizza il valore minimo (min-val) del round precedente (inizialmente è il suo valore di input) 2. Per ogni round: • I processi inviano in broadcast il loro min-val • Ogni processo resetta il suo min-val in base ai vecchi valori e a quelli ricevuti nei messaggi del round corrente 3. Alla fine il valore decisionale sarà il min-val
- 8. Round del FloodMin Quanti round servono per garantire la soluzione? • 1-Agreement: f+1 round • K-Agreement: (f/k) + 1 round Consentendo k valori decisionali, il numero di round totali viene diviso per k.
- 9. FloodMin: formale • Statesi: • rounds ∈ N (inizialmente 0) • decision ∈ V ∪ {unknown} (inizialmente 0) • min-val ∈ V (inizialmente input) • Msgsi: Se rounds <= (f/k) allora invia min-val a tutti gli altri processi • Transi: rounds := rounds + 1; mj := messaggio ricevuto da ogni processo j min-val := min({min-val} ∪ {mj : j≠i}) se rounds = (f/k)+1 allora decision := min-val
- 10. FloodMin: prova di correttezza • Teorema: FloodMin, per (f/k) + 1 round, risolve il problema del K-Agreement • Lemma 1: M(r) = insieme dei min-val dei processi attivi dopo r round => l’insieme può solo decrescere => ogni min-val dopo r+1 è un min-val dopo r round • Lemma 2: ∀d ∈ N, d ≤ f+1, se durante r con 1 ≤ r ≤ (f/k)/1, falliscono al più d-1 processi, allora |M(r)| ≤ d. … ci sono, cioè, al più d differenti min-val per i processi attivi dopo il ciclo r.
- 11. Dimostrazione Lemma 1 M(r) ⊆ M(r-1) per ogni r, 1 ≤ r ≤ (f/k) + 1 Dimostrazione: 1. Supponiamo che m∈M(r), allora min-val i = m per qualche processo i, per definizione di M(r). 2. Esistono due possibili casi: a) min-vali = m alla fine del round r – 1 b) min-valj = m per qualche j alla fine del round r – 1 3. Quindi: a) Se i era attivo al round r lo era anche dopo il round r-1 b) Se j ha inviato min-valj al round r, era attivo alla fine del round r-1 In ogni caso, m∈M(r-1)
- 12. Dimostrazione Lemma 2 Se al più d-1 processi falliscono nel ciclo r, allora |M(r)| ≤ d Dimostrazione (per assurdo): 1. Supponiamo che |M(r)| > d (dimostrare che almeno d processi falliscano in r) 2. Sia m = max(M(r)) e m’ ≠ m un qualsiasi elemento in M(r). 3. Allora m’∈M(r-1) per il Lemma 1 4. Sia pi t.c. m’=min-vali al round r-1. Se i non fallisse durante il round r, ogni processo riceverebbe il valore m’ e quindi non esisterebbe un pj t.c. m=min-valj siccome m>m’. Segue che pi fallisce durante il round r. 5. Per ogni elemento m’∈M(r) t.c. m’ ≠ m, un processo fallisce durante il round r. Se |M(r)| > d, falliscono almeno d processi (che contraddice l’ipotesi)
- 13. Dimostrazione Teorema L’algoritmo FloodMin risolve il problema del K-Agreement per il modello con stopping failure. Dimostrazione: • Validity / Termination: facile • Agreement: 1. Assumiamo un esecuzione con > k valori decisionali differenti. 2. Quindi il numero dei min-val per i processi attivi dopo i (f/k)+1 round è > k 3. Per il Lemma1, |M((f/k)+1)|>k => |M(r)|>k, per ogni 0≤r≤(f/k) +1… 4. Per il Lemma2, almeno k processi falliscono in ogni round. 5. Quindi ci sono almeno ((f/k)+1)*k fallimenti totali, che è > f …Contraddizione!
- 14. FloodMin: Complessità • Il numero di round (f/k)+1 • Sia n il numero di processi della rete; il numero di msg sarà al più ((f/k)+1)*n2 • Sia b un upper bound del numero di bit necessari per rappresentare un msg (ovvero un singolo elemento di V); il numero di bit inviati sarà ((f/k)+1)*n2*b
- 15. Il problema del Commit Un gruppo di processi partecipa per arrivare ad una decisione: approvare o meno una transazione (ad esempio, scrittura in un Database). Due possibili decisioni: • Commit (il risultato della transazione viene reso permanente) • Abort (il risultato della transazione viene scartato)
- 16. Ambiente • Distribuito • Sincrono • Link della rete sicuri (nessuna possibilità di perdita di messaggi) • Nodi della rete insicuri (possibilità di fallimenti nei processi)
- 17. Formulazione formale • Input e Output: {0, 1} • Agreement: Tutti i processi prendono la stessa decisione • Validity: 1. Se uno qualsiasi dei processi decide 0, allora 0 sarà l’unica decisione finale possibile 2. Se tutti i processi decidono 1, allora 1 sarà l’unica decisione finale possibile • Termination: 1. Weak: In assenza di fallimenti, garantisce che tutti i processi arrivino prima o poi ad una decisione 2. Strong: Garantisce che tutti i processi non fallimentari arrivino prima o poi ad una decisione
- 18. Gli algoritmi del Commit • Algoritmi bloccanti: Algoritmi che garantiscono la Weak termination ma non la Strong termination. Un unico fallimento può pregiudicare la corretta terminazione di ogni processo e potrebbero verificarsi condizioni di stallo. • Algoritmi non bloccanti: Algoritmi che garantiscono sia la Weak termination che la Strong termination. Solo i processi fallimentari possono non giungere alla corretta terminazione
- 19. L’algoritmo del Commit a due fasi • Pro: semplice ed intuitivo • Contro: non garantisce la Strong termination • Possibili stati dei processi: 1 (ha deciso Commit) 0 (ha deciso Abort) Uncertain Failed
- 20. L’algoritmo del Commit a due fasi Prima fase: Uno dei processi assume il ruolo di coordinatore, raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se tutte le decisioni hanno valore 1, allora il coordinatore decide 1; • Se almeno una delle decisioni è nulla o 0, allora il coordinatore decide 0. Seconda fase: Il coordinatore invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
- 21. L’algoritmo del Commit a due fasi 7.3. THE COMMIT PROBLEM 185 processes 1 . . . . . . . . "l 2 3 4 1 2 rounds F i g u r e 7.4: Communication pattern in TwoPhaseCommit. messages. Then no other process ever learns process l's initial value, so, because of the validity condition, no process can decide 1. On the other hand, no process
- 22. Esempio: Fase 1 2 3 1 4 5
- 23. Esempio: Fase 1 2 3 1 4 5 ✔ ✔ ✔ ✗
- 24. Esempio: Fase 1 1 2 3 4 5
- 25. Esempio: Fase 1 1 1 1 0 v[i] != null && v[i] == 1 ? 4 5 2 3 1
- 26. Esempio: Fase 1 1 1 1 1 0 v[i] != null && v[i] == 1 ? 4 5 2 3
- 27. Esempio: Fase 2 1 2 3 4 5
- 28. Esempio: Fase 2 2 3 1 4 5
- 29. Terminazione L’algoritmo a due fasi risolve il problema del Commit garantendo solamente la Weak condition. Questo perché, nel caso in cui sia il processo 1 a fallire, non sarebbe garantito l’arrivo ad una decisione per gli altri processi. Un ulteriore fallimento di uno dei processi, inoltre, potrebbe portare a condizioni di stallo 1
- 30. L’algoritmo del Commit a tre fasi • Pro: Introduce lo stato ready per evitare le ambiguità dell’algoritmo a due fasi. Introduce inoltre un protocollo di terminazione che garantisce la Strong termination. • Contro: complessità computazionale e di progettazione maggiore • Possibili stati dei processi: 1 (ha deciso Commit) 0 (ha deciso Abort) Ready Uncertain Failed
- 31. L’algoritmo del Commit a tre fasi Prima fase: Uno dei processi assume il ruolo di coordinatore, raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se tutte le decisioni hanno valore 1, allora il coordinatore passa in stato ready; • Se almeno una delle decisioni è nulla o 0, allora il coordinatore decide 0. Seconda fase: • Se il coordinatore si trova in stato ready, quest’ultimo invita anche il resto del gruppo a passare in stato ready. Al termine della comunicazione, il coordinatore decide 1. • Se il coordinatore ha deciso 0, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale Terza fase: • Se il coordinatore ha deciso 1, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
- 32. L’algoritmo del Commit a tre fasi 7.3. THE COMMIT PROBLEM 187 . . . . . . . . . . . . . . . . . . . . . . . 2 ~ . ..... 3 4 1 2 3 F i g u r e 7.5- Communication pattern in ThreePhaseCommit. 2. If any process's state is in decO, then no process is in dec1, and no non-failed
- 33. Esempio: Fase 1 2 3 1 4 5
- 34. Esempio: Fase 1 2 3 1 4 5 ✔ ✔ ✔ ✔ ✔
- 35. Esempio: Fase 1 1 2 3 4 5
- 36. Esempio: Fase 1 1 1 1 1 1 v[i] != null && v[i] == 1 ? 2 3 1 4 5
- 37. Esempio: Fase 1 1 1 1 1 1 1 v[i] != null && v[i] == 1 ? 2 3 4 5
- 38. Esempio: Fase 2 1 2 3 4 5
- 39. Esempio: Fase 2 1 2 3 4 5
- 40. Esempio: Fase 2 1 2 3 4 5
- 41. Esempio: Fase 3 1 2 3 4 5
- 42. Esempio: Fase 3 1 2 3 4 5
- 43. Terminazione I tre round dell’algoritmo a tre fasi non sono sufficienti a garantire la Strong termination. Se il processo coordinatore non fallisce, allora tutti i processi non falliti giungeranno ad una decisione. Ma se il processo coordinatore fallisce, gli altri processi potrebbero essere lasciati in uno stato indefinito. Per risolvere questo problema, I processi rimanenti devono eseguire un protocollo di terminazione al termine dei tre round 1
- 44. Protocollo di terminazione dell’algoritmo a tre fasi Quarto round: Si nomina un nuovo coordinatore, il quale raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se almeno una delle decisioni ha valore 1, allora il coordinatore decide 1; • Se almeno una delle decisioni ha valore 0, allora il coordinatore decide 0; • Se tutte le decisioni pervenute sono uncertain, allora il coordinatore decide 0; • Se almeno una delle decisioni è ready ed il restante è uncertain, allora il coordinatore passa in stato ready Quinto round: • Se il coordinatore si trova in fase ready, quest’ultimo invita anche il resto del gruppo a passare in stato ready. Al termine della comunicazione, il coordinatore decide 1. • Se il coordinatore ha già deciso 0 o 1, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale Sesto round: • Se il coordinatore ha deciso 1, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
- 45. Esempio: Round 4 1 2 3 4 5
- 46. Esempio: Round 4 1 2 3 4 5
- 47. Esempio: Round 4 1 2 3 4 5
- 48. Esempio: Round 4 1 2 ? r ? ? 3 4 5
- 49. Esempio: Round 4 1 2 ? r ? ? 3 4 5
- 50. Esempio: Round 5 1 2 3 4 5
- 51. Esempio: Round 5 1 2 3 4 5
- 52. Esempio: Round 5 1 2 3 4 5
- 53. Esempio: Round 6 1 2 3 4 5
- 54. Esempio: Round 6 1 2 3 4 5
- 55. L’algoritmo a tre fasi completo Nel caso in cui anche il secondo coordinatore fallisca, i tre round del protocollo di terminazione sono ripetuti nominando coordinatore il terzo processo e così via. L’algoritmo a tre fasi, comprensivo del protocollo di terminazione, viene definito completo e garantisce la Strong termination. La condizione di terminazione forte è garantita dal fatto che, nonostante eventuali fallimenti dei coordinatori, gli altri processi hanno la possibilità di essere nominati coordinatori nei round successivi e di terminare correttamente. 1
- 56. Complessità degli algoritmi del Commit • Algoritmo a due fasi (2PC): L’algoritmo richiede sempre e solo 2 round. In assenza di fallimenti, se n è il numero di processi, il massimo numero di messaggi scambiati è 2n-2 • Algoritmo a tre fasi (3PC): Nel caso peggiore ovvero in cui ogni coordinatore fallisca, se n è il numero di processi, sarebbero necessari 3n round per completare l’algoritmo. Se si escludono dal protocollo di terminazione quei processi che sono già giunti ad una decisione, l’algoritmo termina in pochi round e con O(n) messaggi scambiati.